搭建系统性能监控的小贴士
美国金门大桥一次高的流量可达到16，2414车次每天。再加之风，雨及其它无数的环境因素（更不用说地震了），给桥本身带来了许许多多的压力。
一个Atlassian的系统就像是一座桥。所有用户每天成千上万次的接入系统，其中还要考量到系统本身的大小（里面有海量的评论，页面，repo等等），第三方插件，API接口等。造桥时，需要对桥面过载和车流量超载进行测试。我们也在开发阶段进行类似的测试，用以确保我们的产品可以支持各种量级的使用。
但这不仅仅是测试的事，你需要时不时地关注你的系统，看其是否有问题。 为了做到这一些，你需要知道追踪哪些指标，对异常数据设置警报并有应对之法。找对了方式，做对了事情，那你的DC版系统就会一直平稳运作。
下列建议旨在助你把系统长期保持在稳定运行之中。
监控必要的数据与关键的指标
有两种类型的数据需要监控–使用量和软硬件平台。在了解了它们的不同后，你就可以进行监控了。如此，可确保相应人员被提前知会到。
使用量
这都是关于你公司如何使用（或不使用）你DC版产品及系统管理的关键参数，可以从下列方面来考虑：
你有多少用户?
在一段时间内有多少活跃用户?
Confluence中你有多少个页面?
Jira中你有多少个问题?
对自己的系统内定制化的东西做一个量化/统计的动作亦很重要，举例来说，你系统中使用的第三方插件的数量。
使用量可通过系统管理员界面或数据库来查询。监控它们的变化，利用这些涨势来进行预测未来的负载，做出及时的应对，最终保证系统的“健康成长”。
下列是一些可用于追踪的，基础的使用量参数：
另外，最重要的是，这些参数是否有没有突然增高的情况。例如，如你看到问题数量在过去24小时内增加了10%，那就得去找其根源。很多情况下这可能是插件，搜索查询或其它动作造成的。
但是，那些未使用到的数据占用系统空间怎么办? 这个可能是最会被忽略的一个问题。非活跃用户，不用的配置如自定义字段及废弃的项目–所有这些都会占用地方。
不管是否是归档老项目（添加链接）或者更好地管理你的自定义字段（添加链接），都有几种方式来持续检查未使用的数据。
软硬件平台
当你了解基础的使用量参数时，可开始考虑监控你的软硬件平台。用户在系统中的每一个动作都会给平台加上负载，这些负载可以通过DC版产品来配置。这些参数反映了负载对DC版产品部署的环境产生的影响。
这些参数一般都要用第三方工具来追踪，特别是追踪一个群里多节点的时候（与单节点相比较）。下面是一些需要追踪的参数：
趋势与预警：找出规律，做好准备
当你收集完了系统的使用量和负载情况，就可以开始寻找其规律了：
-
高峰/非高峰时段的使用量
-
增长趋势
每当可以时，对需要深入调查的参数设置提醒。例如，当数据库连接数在5分钟内超过了50个或者JVM（意为Java使用的内存量）使用了超过80%的容量时，可设提醒。设好门槛，监控它们，这样你就可以先一步发现问题。
制定应对之道
当你的系统监控落地后，具体的处理方案也同样重要。它可以帮你限缩甚至把可能发生的问题扼杀在摇篮里。问题的事后分析是一个从这些问题中学习，并把其问题（特别是较严重或经常发生的）转换成处理流程的好方式。这样可以从处理所需时间，流程改进方面为未来的工作进行改进。可以从例如对第三方插件进行审计，系统管理，搭建最佳实践或者使用JQL及创建自定义字段时的规则入手。
结语
每个公司的监控方式都不一样，其取决于你的软硬件环境，目标，KPI等等。
为了帮助您组建属于自己的方式，我们公布了系统架构的样例，其解释了我们Atlassian内部怎样监控自己的DC版系统的。这些样例不只是基于一些客户的数据，同时还包含了我们自己系统中的第一手经验（在自己的系统上发现问题后整理出来的）。不要把它们当做“游戏规则”，可把它看成是一个指引。然后，在此基础上，制定最适合自己公司目标和情况的妙招。