监控 Atlassian 插件

如何密切关注你的 Atlassian 部署

负责管理企业 IT 的人员都不希望被告知有应用程序崩溃，特别是由终端客户转告。监控是一种关键的工具，但经常会被忽视。它可以帮助运维团队避免从用户那里听到有应用程序崩溃的尴尬，更重要的是，可以减少发生中断和错误的频率。

在这篇博文中，我们将研究如何将监控应用于你的内部 Atlassian 部署，以防止事故发生并限制停机时间，以及在你的应用程序的规模和功能不断增长的过程中，如何利用监控来优化性能。

监控工具

在我们讲述你应该监控什么之前，先让我们讨论一下监控工具。一般来说，大多数最简单形式的监控工具可分为三个部分：可以存储时间序列数据（名为“指标”）的数据库、能可视化这些指标的前端以及通过各种来源获取数据的方法。

很多工具都会有一个额外的重要组成部分　──　当指标超过定义的阈值时提醒你的一种方式（更多关于如何设置警报阈值的信息将在稍后提供）。典型的设置将包括一个带指标存储数据库的中央应用程序，以及一个用于实现可视化并通过电子邮件发送警报的网络 UI，由多个数据转发器或代理将数据从应用程序或基础设施组件发送回中央集线器。

如今，市场上有大量的监控工具可用，选择使用哪种工具在很大程度上取决于什么最适合你的运维团队　──　没有万能的灵丹妙药。其中有许多大受欢迎的商业产品，比如　AppDynamics、　New Relic、　Dynatrace　和　Datadog　等，它们都具有出色的特性，但标价可能会很高。

如果你要在私有云中托管 Atlassian 插件，比如亚马逊云计算服务或　Microsoft Azure，你可能会对集成到云提供商中的监控解决方案感兴趣，比如　AWS CloudWatch　或　Azure Monitor。

或者，如果你偏向于选择 DIY 方法，那么有大量高度可定制的开源工具可用。我们通过在内部使用　Prometheus with Grafana　获得了成功，但其他选项可能包括　Nagios 或　Elastic Stack (ELK)。这些工具的完整比较应该通过专门的博文进行介绍，因此我们无法在本文中加以详细讨论。

基础设施监控

基础设施监控是一个很好的起点（我所希望的是任何运维专业人士的常识）。

Atlassian 插件监控基础设施非常类似于大部分其他的基础设施。你会想要为常见指标设置监控，比如 CPU、磁盘空间和内存利用率。

监控 CPU 可成为你的应用程序的一个很好的性能指标。常常当像　Jira 软件开发选项这样的应用程序遇到问题时，如果网络应用程序停止运行，你会看到 CPU 利用率飙升。CPU 警报可以有效地为你的运维团队解决问题提供一个有利的开端。

磁盘空间是另一个需要掌握的关键指标。磁盘空间不足肯定会损害你的 Jira 或 Confluence 实例。Atlassian 插件使用文件系统来存储你拥有的任何附件。在较大的实例中，附件的大小会迅速增长，并轻松耗尽你可能认为足够的磁盘空间分配。监控磁盘使用情况能让你的运维团队在应用程序用完磁盘空间之前配置更多磁盘空间或清理未使用的文件，防止发生代价高昂且令人尴尬的事件。另一个考虑因素是，如果你已经在不同的磁盘上设置了你的应用程序主目录和安装目录　──　确保你同时监控两者！

内存利用率是一个稍微复杂的指标。所有核心 Atlassian 插件都是用 Java 语言编写的，因此在 Java 虚拟机　(JVM)　中运行。应用程序的大部分内存分配将在 JVM 中（我们将在下面讨论如何进行监控），它定义了对其内存使用的限制。你不太可能通过监控操作系统内存来检测事故，因为内存不足错误最常发生在 JVM 分配的空间内。但是，监控操作系统内存利用率仍然非常有用，因为它可以帮助你发现难以诊断的问题，例如本机内存泄漏。

可用性监控

正常运行时间。它可能是 SaaS 和随时在线服务时代最受关注的唯一指标，因此肯定是你在监控你的　Atlassian 插件时想要监控的方面。可用性监控只是要测试“我的网站是否在线”（你希望回答是肯定的），如果是，那么需要多长时间才能收到回复。你的网站离线后需要能够立即收到警报，以通知你的 Atlassian 管理员，这对尽快让网站备份来说非常重要。此外，发现工作时间以外发生的中断也非常有用，例如在周末用户自己可能不会注意到。没有人会希望周一来工作时发现自己宝贵的 Jira 网站处于离线状态。你可以使用像　Uptime Robot　或　Pingdom　这样的工具来建立自己的可用性监控。

网络监控

如果你的公司网络出现故障，世界上所有的应用程序和基础设施监控都爱莫能助。甚至可能不需要是整个网络。防火墙更改出错很容易中断 Confluence 应用程序服务器与其数据库之间的连接，或者 Jira 应用程序与外部集成之间的连接。　监控你的应用程序、它们的数据库和各种集成之间的连接将有助于你发现随时出现的问题。

对于数据中心部署，你还需要考虑监控集群中每个节点之间的连接以及从每个节点到共享主目录的连接。例如，如果每个节点之间的时延太高，Jira 数据中心版就会遇到各种问题。

JVM 监控

如前所述，Atlassian 插件是用 Java 语言编写的，因此在 JVM 中运行。调试 JVM 是一门艺术，只有使用大量监控数据来指导你所做的更改才能很好地完成。关于如何监控 JVM，有多种选择。最常见的一种方法是通过 JMX 端点公开数据，然后从你选择的监控工具中使用代理收集此数据。或者，有一些工具可以将数据直接从你的 Atlassian 插件转发到监控工具，无需担心 JMX。

关注的关键 JVM 指标与内存有关。你需要确保收集有关堆利用率和垃圾收集的数据。随着应用程序规模的扩大，最好定期查看 JVM 监控收集的趋势数据，以确定是否需要重新调试 JVM 配置。如果不这样做，可能会导致性能下降，不可避免地出现用户不满，最糟糕的是，你（或你老板）的收件箱中会收到愤怒的电子邮件！

交易示例

我们错过了监控的最后一个关键部分。此时，你很可能正坐在运维指挥中心，当你发现在 IT 服务台中提交的工单时，马上高兴地紧盯着墙板上显示的所有绿色指标。用户报告说，在 Jira 中加载问题需要 10 秒以上的时间，甚至需要更长的时间来创建！当你的所有监控看起来都不错时，这怎么可能？

从用户的角度进行监控对于发现我们刚刚描述的问题来说至关重要。为此，许多监控工具都允许你配置交易示例。该工具将定期执行给定的任务，例如创建问题，并记录操作的持续时间。这可以帮助你发现更复杂的问题，例如 Jira 索引中的故障。

订立基线

我们到目前为止描述的监控可帮助你检测随时发生的事故。然而，要做到这一点，你需要知道正常运行的样子。这一过程被称为订立基线。你可能很想将 CPU 指标的警报阈值设置为 90%，然后就到此为止。但是，如果应用程序的 CPU 利用率通常不超过 50%，那么这个阈值就不会那么有用。最好的方法是将警报阈值视为随着应用程序扩展而更新的动态值。