检测 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 Metrics 库通过 Telegraf 将数据发送到 InfluxDB。一旦您克隆下来并完成所有设置，请确保您的服务器正在运行 node server.js，以便 Telegraf 可以开始收集指标。

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

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

当我们开始可视化时，让我们花点时间考虑一下我们正在收集哪些指标以及原因。

CPU 使用率

通常，跟踪应用程序随时间的 CPU 使用率是一个好主意。尽管 Node.js 应用程序通常消耗的 CPU 资源很少，但掌握这些数据可以帮助您了解应用程序的健康状况，突出显示偏离正常情况的实例。能够确定哪些操作（如果有）导致 CPU 使用率过高，无疑是了解应用程序性能的一步。

在 AmazonBay 的案例中，我们正在监控进程（应用程序使用的 CPU 百分比）和系统（整个系统使用的 CPU 百分比）的 CPU 百分比（介于 0-1 之间的值）。我们可以将两者都绘制成图表，如下所示

<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 中有多种可视化选项可用，包括折线图和堆叠图、阶梯图、条形图和仪表，所有这些都可以在您从 Queries 部分切换到 Visualizations 部分时使用。

<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 请求的持续时间是一个重要的指标，尤其因为它通常直接涉及最终用户。由于用户变得比以往任何时候都更加不耐烦，因此缓慢的响应时间会严重损害应用程序的成功。监控这些请求的持续时间可以了解用户是否能够快速有效地与应用程序交互。速度越快，用户满意度就越高，就这么简单。

在这里，您将看到我构建了一个堆叠图，以可视化以毫秒为单位的平均 HTTP 请求/响应持续时间，按不同的 URL 分组

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

数据库查询

在这个特定的应用程序中，库存和订单历史记录使用 PostgreSQL 关系数据库存储，并且在应用程序的各个点，都必须查询数据库。这属于外部依赖项或应用程序与之交互的任何系统的类别。除了数据库之外，还有其他依赖项，例如第三方 API、Web 服务、遗留系统，尽管我们不一定能直接更改在这些服务中运行的代码，但这些依赖项对于应用程序的成功仍然很重要，因此值得跟踪，即使只是为了能够区分应用程序内部出现的问题和外部问题。无论您的应用程序如何与第三方应用程序（内部或外部）通信，等待响应的延迟都可能影响应用程序的性能和客户体验。测量和优化这些响应时间可以帮助解决这些瓶颈。

我们已经跟踪了对 Postgres 数据库的查询持续时间，并将其绘制在线/统计图表中，如下所示

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

总结

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

<figcaption> 成功！</figcaption>

这篇文章就总结到这里。我很想听听您是如何检测您的 Node.js 应用程序的，以及您是如何可视化您的指标和事件的！感谢您参与这次旅程，如有任何问题和/或意见，请随时通过 [email protected] 或 Twitter 与我联系。仪表板愉快！