为Node/Express应用程序添加监控：查看您的数据

作者：Margo Schaedel / 产品，用例，开发者
2018年3月14日

本文是继为Node/Express应用程序添加监控之后的后续文章。我们将开始探索存储在InfluxDB中的某些数据，并在Chronograf中构建仪表板。如果您还没有开始为您的Node.js应用程序添加监控，我建议您查看我之前的文章，以获得一些背景知识。

在我上次离开时，我们已经有一些数据被收集并存储在InfluxDB中，正如我们通过查询数据库可以看到的

<figcaption>一些数据…</figcaption>

当然，仅仅看到一行行的数字并不完全有帮助。更合理的方法是将数据以图表或表格的形式呈现，这样我们可以更轻松地看到数据中的趋势，最好还能构建一个完整的仪表板，以便我们可以同时查看所有相关数据。使用Chronograf可视化我们的数据正好提供了这样的功能。如果您还没有安装Chronograf，这里有一个指南，它将帮助您使用TICK Stack的所有不同组件——Telegraf、InfluxDB、Kapacitor和Chronograf。

在本节中，我将使用经过监控的Node.js应用程序版本AmazonBay，您可以从GitHub 此处克隆下来。它使用这个Node监控库通过Telegraf将数据发送到InfluxDB。一旦您克隆下来并设置好一切，确保您的服务器正在运行，使用node server.js，这样Telegraf就可以开始收集指标。

让我们启动Chronograf并导航到仪表板部分，我们可以在那里开始构建一个合适的仪表板，以便对收集到的数据进行深入了解。您需要先创建一个仪表板并命名它——为了方便，我的仪表板名为“Instrumented-AmazonBay”。

<figcaption>让我们创建一个新的仪表板</figcaption>

在我们开始可视化之前，让我们花一点时间考虑我们正在收集哪些指标以及为什么。

CPU使用率

跟踪应用程序的CPU使用情况通常是件好事。尽管Node.js应用程序通常消耗很少的CPU，但拥有这些数据可以让您了解应用程序的健康状况，突出那些偏离正常情况的情况。确定哪些操作（如果有的话）导致CPU使用率过高，是理解应用程序性能的关键一步。

在AmazonBay的情况下，我们正在监控进程（应用程序使用的CPU百分比，介于0-1之间）和系统（系统整体使用的CPU百分比）的CPU使用率。如图所示，我们可以将它们绘制成图表

<figcaption>进程和系统的CPU使用率</figcaption>

我通过Chronograf UI构建了查询，但编辑了它，将百分比改为介于0-100之间的值

SELECT (mean("process")*100) AS "mean_process" FROM "telegraf"."autogen"."cpu_percentage" WHERE time > :dashboardTime: GROUP BY :interval: FILL(null)

事件循环延迟

由于Node.js的非阻塞、单线程特性，它在快速异步处理大量事件方面非常快。事件循环对此负责，因此识别和定位事件循环中可能影响应用程序性能的任何延迟至关重要。持续时间较长的延迟会加剧事件循环的每个周期，并最终可能导致应用程序缓慢到无法运行的状态。例如，如果服务器观察到负载增加，这可能导致事件循环中的任务数量增加，这将影响最终用户的响应时间。收集这些延迟的数据可以帮助决定是否增加运行应用程序的进程数量，并将性能水平恢复到平衡状态。

对于我们的事件循环延迟测量，我们可以访问最小、最大和平均延迟时间（以毫秒为单位）。在Chronograf中提供了多种可视化选项，包括线图和堆叠图、阶梯图、柱状图和仪表，这些选项都可以在从“查询”部分切换到“可视化”部分时使用。

<figcaption>Chronograf中提供各种可视化类型</figcaption>

以下展示了事件循环延迟的多种可视化形式

<figcaption>最小、平均和最大样本事件循环延迟（以毫秒为单位）</figcaption>

垃圾收集、堆使用和内存泄漏

内存泄漏是Node.js开发者经常提到的抱怨，因为它通常很难确定原因。当对象被引用时间过长，当变量存储在它们使用后时，就会发生内存泄漏。早期识别它们的存 在对于监控应用程序的健康状况至关重要，可以通过跟踪应用程序的堆使用率（用于存储对象的内存段，包括字符串和闭包）和/或其垃圾收集率（释放未使用内存的过程）来实现。例如，堆使用率的持续增长最终将达到Node.js要求的1.5GB默认限制，并导致服务崩溃和进程重启。同样，您可以在垃圾收集率中寻找模式，因为随着内存中多余的对象的积累，垃圾收集过程所需的时间也会相应增加。当然，一旦发现内存泄漏，确定根本原因的过程相对繁琐，通常涉及比较应用程序不同时间点的堆快照，以查看两者之间有什么变化。

在此情况下，我们将监控堆使用率和垃圾收集率。请参见下文

<figcaption>GC周期持续时间和堆使用（MB）</figcaption>

对于堆使用率，我修改了查询，使其以兆字节而不是默认的（字节）显示

SELECT ("used"/1000000) FROM "telegraf"."autogen"."gc" WHERE time > :dashboardTime:

HTTP请求

HTTP请求的持续时间是一个重要的指标，尤其是在它通常直接涉及最终用户的情况下。由于用户比以往任何时候都更加没有耐心，缓慢的响应时间会严重影响应用程序的成功。监控这些请求的持续时间可以让我们意识到用户是否能够快速高效地与应用程序交互。事情越快，用户的满意度就会越高，这一点很简单。

在这里，您将看到我创建了一个堆叠的图表，用于可视化不同URL的平均HTTP请求/响应持续时间（毫秒）。

<figcaption> HTTP请求/响应持续时间（毫秒）</figcaption>

数据库查询

在这个特定的应用程序中，库存和订单历史记录使用PostgreSQL关系型数据库存储，并且在应用程序的各个点，都需要查询数据库。这属于外部依赖项或与应用程序交互的任何系统。除了数据库外，还有第三方API、网络服务、遗留系统等。尽管我们无法直接更改这些服务中运行的代码，但这些依赖项对应用程序的成功至关重要，因此值得跟踪，至少能够区分应用程序内部和外部的问题。无论您的应用程序如何与第三方应用程序通信，等待响应的延迟可能会影响您的应用程序性能和客户体验。衡量和优化这些响应时间可以帮助解决这些瓶颈。

我们已经跟踪了到Postgres数据库的查询持续时间，并以线图/统计图的形式展示如下

<figcaption> Postgres查询持续时间（毫秒）</figcaption>

总结

一旦将所有内容整合在一起，您就有了一个完整的仪表板，可以监控您的Node.js应用程序的健康状况。

<figcaption> 成功！</figcaption>

这篇文章就到这里。我很乐意听听您是如何对Node.js应用程序进行监控的，以及您是如何可视化指标和事件的！感谢您与我同行这段旅程，如有任何疑问和/或评论，请随时通过 [email protected] 或在 Twitter 联系我。祝您使用仪表板愉快！