多方位监控 Angie —— nginx Web 服务器的分支#

27.09.2023

Angie 监控能力的详细概述：用于统计的内置 API、 用于实时可视化的 Console Light，以及无需第三方模块的 Prometheus 集成。

精美的在线演示胜过任何图片：https://console.angie.software/

精美的在线演示胜过任何图片：https://console.angie.software/#

你好，亲爱的读者。我叫 Dmitry。我是 Web Server 公司的系统工程师。在我提供技术支持服务的整个经历中，先是在 Nginx 公司，现在是在开发俄罗斯 Web 服务器 Angie 的公司，我们回答一个非常热门的问题："我如何组织对 Web 服务器状态的监控？"方法如下。

  1. 监控。"为什么要费心？日志里一切正常！"

  2. Angie Web 服务器。"为什么？有 * 不就行了。"如何安装。"有 ** 的构建版本吗？"

  3. API。"我告诉你，有日志！等一下，让我在生产环境中启用它们。"它提供什么。"与日志有什么区别？"如何配置。"它不是自动工作的吗？"获取 Web 服务器配置。"但是有 angie -T。"

  4. Console Light – Web 界面。"又一个监控系统？！1？1！！！"它显示什么。"实时是什么意思？"如何安装。"真的只需几行配置？"

  5. Prometheus 的 API。"但我已经在使用它了！嗯，是的，我们解析日志..."如何配置 Angie 进行集成。"这怎么不用 njs？"与 Console Light 的比较。"这些值真的匹配吗？"

  6. 结论。"所以这就是多方位的意思！"

1. 监控。"为什么要费心？日志里一切正常！"#

所以，我们已经超越了根据用户电话对信息系统运行中的事件做出反应的情况。现在我们的基础设施中有完善的监控系统，包括数据收集、告警系统和"修复一切"按钮。

当回答管理人员、架构师或信息安全专家关于我们如何确保处理基础设施网络请求过程中关键组件之一的可观测性的问题时，我们最常列出以下内容。我们有 Web 服务器进程的系统指标（它消耗多少 CPU 或 RAM，运行了多长时间），我们有来自日志的数据，不太常见的是我们有使用第三方扩展从 Web 服务器导出指标的能力。

获取进程的系统指标是常见做法，是任何基础设施的最低要求。但有时这是极其不够的。我们看到最小的 CPU 消耗，但网站显示 502 Bad Gateway 错误，一切都很糟糕。

从日志获取数据很简单。但架构师指出，本质上，我们是在回顾性地跟踪那个时间点已经被处理的请求。在 DoS 攻击的情况下，我们只会在日志中看到一些请求已经被处理为"处理失败"。但我们需要在 Web 服务器监控中看到已经到达但尚未被上游服务器处理的请求。监控应该显示出拳前的蓄力，而不是显示脸上的瘀伤。

使用第三方解决方案从您的 Web 服务器设置指标导出是一个相当可行的选择。唯一的问题是您需要花时间弄清楚配置，为您的操作系统构建它，并接受明天您的 Web 服务器版本可能与尚未更新的模块不兼容的风险。请记住，信息安全专家从不睡觉。

我们产品的内置功能（我们将在后面讨论）允许实时完整监控 Web/代理服务器负载，并且还具有与客户端基础设施中的监控系统进行高级集成的许多能力。

2. Angie Web 服务器。"为什么？有 * 不就行了"#

对于那些不知道的人，我要说，对于其他人我要提醒，有一个名为 Angie 的产品，它是从 nginx 分支出来的，由 Web Server 公司开发。该公司汇集了 NGINX 公司的前首席工程师。它在 BSD 许可证下分发，它是合法的，这是我们被告知的。

Angie Web 服务器代码库是从 Nginx 1.23.1 分支出来的。从那时起，我们一直在添加开源 nginx 版本中不存在的新功能。同时，我们尝试将 nginx 更新移植到我们的 Web 服务器，确保用户可以从 nginx 无缝迁移到 Angie。

从 2022 年 10 月 的第一个版本开始，Angie 就包含一个 API 模块，该模块实现了一个 HTTP RESTful 接口，用于以 JSON 格式获取有关 Web 服务器的基本信息，以及以下统计信息：

  • 客户端连接

  • 共享内存区域

  • DNS 查询

  • HTTP 请求

  • HTTP 响应缓存

  • stream 模块会话

  • limit_conn http、limit_conn stream 和 limit_req 模块的区域

完整的指标列表可以在 文档 中找到。

最近，发布了新版本 Angie 1.3.0，它实现了对以 Prometheus 格式输出指标的支持。我们准备了一个 Web 界面，用于从选定的实例实时查看指标。现在是时候对 Web 服务器监控能力进行小型比较测试了。

Angie 的独特功能包括：

2.1. 如何安装。"有 ** 的构建版本吗？"#

关于如何安装 Angie 的详细说明在 官方网站 上以俄语和英语提供。

尽管我们在 x86-64 和 arm64 架构上支持 11 个不同版本的发行版，但在本文中，我只提供说明 Web 服务器监控能力所需的步骤。我将在 Debian 操作系统上执行所有安装。

安装 Angie 与从存储库安装任何其他软件包没有什么不同。首先，添加密钥和存储库：

sudo apt-get update && \
sudo apt-get install --no-install-recommends --no-install-suggests --yes \
                    ca-certificates curl lsb-release && \
sudo curl -o /etc/apt/trusted.gpg.d/angie-signing.gpg \
                    https://angie.software/keys/angie-signing.gpg && \
echo "deb https://download.angie.software/angie/debian/ `lsb_release -cs` main" \
                    | sudo tee /etc/apt/sources.list.d/angie.list >/dev/null

然后安装 Angie：

sudo apt-get update && \
sudo apt-get install --no-install-recommends --no-install-suggests --yes \
                    angie

完成。Web 服务器正在运行，欢迎页面可在端口 80 上访问。

curl -I localhost HTTP/1.1 200 OK Server: Angie/1.3.0 ....

3. API。"我告诉你，有日志！等一下，让我在生产环境中启用它们"#

当客户联系技术支持时，他们经常被要求提供日志以进行诊断。经常遇到的情况之一是生产环境中的 Web 服务器日志被禁用。只是为了节省资源。解析日志并将其发送到监控系统的问题根本不会出现。没有日志 – 没有问题。

3.1. 它提供了什么。"与日志有什么区别？"#

但是，如果我们仍然进行日志分析并基于这些数据构建监控系统呢？与通过 API 使用指标有什么区别？这里有几个细微差别。

首先，日志是在请求处理完成后写入的。换句话说，当最后一个字节已发送到客户端时。在这种情况下，我们应该如何处理长连接或慢速客户端？API 在这里派上用场。"server_zones" 中 "requests" 里的 "processing" 指标可以帮助您了解服务器当前正在处理多少个请求。

其次，日志无法告诉您关于服务器使用的 共享内存区域 或 缓存区域 的任何信息。然而，由于巨大的流量或在各种服务器攻击情况下，它们的溢出可能导致灾难性的结果、段错误，从而导致连接断开甚至服务不可用。

在这里，API 再次拯救了我们。您可以查看和计算区域占用情况，并及时响应意外情况。

第三，通过 API 从运行时获取指标，您只需在当前时刻获得更准确的值。而且它们的数量比您从日志中提取的要多得多。您可以在 官方网站 上查看完整的指标树。

回到第三方解决方案的问题，读者可能会问："我为什么要改变什么？我一直在使用基于 vts 模块的综合解决方案。"这里值得注意的是，像 vts 模块这样的解决方案实际上并不提供实时统计信息，因为它们在日志阶段工作，计数器仅在请求处理完成后才计算。换句话说，这种类型的解决方案具有与基于日志的监控相同的缺点。

3.2. 如何配置。"它不是自动工作的吗？"#

要启用 API，只需在配置中添加 "api" 指令即可。

让我们在配置文件 "/etc/angie/http.d/default.conf" 中注释掉 "location /status/" 中的 "allow" 和 "deny" 指令，这样我们就可以立即在浏览器中看到 API 页面。（在生产环境中，出于安全目的，您仍应正确配置这些指令。这也适用于本文的以下部分）：

location /status/ {
  api /status/;
  # allow 127.0.0.1;
  # deny all;
}

为了清晰起见，让我们在配置中添加几个区域和上游：

upstream foo {
  zone http-upstream-foo 256k;
  server 127.0.0.2 max_conns=10 max_fails=10;
  server 127.0.0.3 max_conns=10 max_fails=10;
  server 127.0.0.4 max_conns=10 max_fails=10;
}

server {
#...
    status_zone example;
#...
    location / {
#...
      status_zone location_zone;
    }
#...
}

重启 Angie 以应用配置：

sudo angie -t && sudo service angie reload

然后在您服务器的 /status/ 页面上，您将看到带有 API 指标的 JSON。

3.3. 获取 Web 服务器配置。"但是有 angie -T"#

说到使用 Web 服务器配置。作为额外的奖励，API 现在具有显示服务器配置的能力。具体来说是 Angie 当前正在运行的配置。这在许多情况下都很有用，例如，如果由于某种不可思议的原因您从服务器中删除了所有配置并想要恢复它们。在这里，"angie -T" 命令的输出无法帮助您，因为 "angie -T" 命令执行语法检查并从磁盘输出配置。"angie" 二进制文件将尝试解析启动时默认指定的配置文件。

现在，要了解更新的配置是否已应用，您可以比较 API 和 "sudo angie -T" 的输出。

或者您可以做得更简单，跟踪配置生成。Angie 跟踪其每个进程的配置生成；编号从服务器启动时的一开始，并且随着每次配置重新加载而增长，并在进程名称中指示。

成功重新加载配置后（无论是否有更改），接收新配置的进程的生成编号将增加，如果 先前生成的任何工作进程继续工作，这将从 "ps aux | grep angie" 命令的输出中立即显而易见。

/status/angie/ 部分中的 API 输出也将显示配置生成。但与 ps 输出不同，API 输出将仅显示新的配置生成。

https://angie.software/api/#id5

https://angie.software/api/#id5#

4. Console Light – Web 界面。"又一个监控系统？！1？1！！！"#

从 Angie 版本 1.3.0 开始，添加了 Console Light 功能——一个用于实时活动监控的轻量级可视化控制台，显示关键的服务器负载和性能指标。总的来说，它使管理员更容易跟踪服务器的可用性和状态。

https://console.angie.software/

https://console.angie.software/#

4.1. 它允许您看到什么。"实时是什么意思？"#

这个简单网页的特点是实时显示特定 Web 服务器实例的指标。页面以一定的周期更新（这可以配置）。请注意，如果您有一个由多个 Web 服务器组成的集群，那么集群中的每个实例都有自己单独配置的可视化控制台。

实际上，前面提到的所有指标都在这里分组到推荐的跟踪选项卡中。例如，您可以在 HTTP Zones 选项卡上的 "requests" 中找到 "processing" 指标。在这里它将被称为 Current。您可以在 Shared Zones 和 Caches 选项卡上查看区域占用情况。

您可以在 https://console.angie.software/ 查看我们的 Console Light 演示版本，并且可以在 文档 部分找到选项卡和在那里收集的指标的详细描述。

4.2. 如何安装。"真的只需要几行配置？"#

此功能作为单独的软件包提供；不要让这个事实困扰您，我的读者。Console Light 与 Angie 和 API 完全集成。让我们安装 Console Light 软件包以查看当前的服务器统计信息。

为此，只需执行：

sudo apt-get install angie-console-light

然后通过在 Angie 配置文件（"/etc/angie/http.d/default.conf"）的 "server" 上下文中放置 "location /console" 来连接 Console Light。像这样：

location /console {

  alias /usr/share/angie-console-light/html;
  index index.html;

    location /console/api/ {
      api /status/;
  }
}

更详细的信息可以在 官方网站 上找到。

让我们重启 Angie：

sudo angie -t && sudo service angie reload

然后，转到 /console，我们将看到一个带有指标的页面。在这里，您将立即看到 Requests 和 Responses 指标是如何填充的。由于我们在 "status_zone" 所在的同一个 "server" 中配置控制台，我们看到控制台本身通过访问 API 为我们生成统计信息。我再次注意，在生产环境中您不应该进行这样的配置。最好使用仅用于监控的单独 "server" 块。

5. Prometheus 的 API。"但我已经在使用它了！嗯，是的，我们解析日志..."#

用于构建监控系统的一个相当流行的解决方案是使用 Prometheus 来收集指标。我们假设您已经安装了此服务。很可能，您通过日志分析或 使用第三方导出器 来填充它。

在我们的情况下，我们制作了一个内置的解决方案，用于以 Prometheus 格式导出指标。我要注意的是，我们有灵活可配置的模板，因此您可以为指标收集添加自己的特色。可用指标的完整列表收集在 all 模板 中。

5.1. 如何配置 Angie 以进行集成。"没有 njs 如何实现？"#

新软件包已经包含了一个包含所有可用指标的模板，因此只需在方便的位置添加"prometheus"指令来启用这些指标的传递即可。

location /metrics/ {
  prometheus all;
}

重启 Angie：

sudo angie -t && sudo service angie reload

通过请求 /metrics/ 地址，我们将看到熟悉的 Prometheus 格式。您可以在网上找到使用 njs 从 nginx 导出指标的示例。在我们的案例中，不使用 js 运行时；计算和传递在 Web 服务器运行时中进行，开销最小。

5.2. 与 Console Light 的比较。"数值真的匹配吗？"#

作为一名工程师，我很想看看通过 Prometheus+Grafana 查看指标与通过 Console Light 查看指标之间是否存在差异。我搭建了一个简单的测试环境，配置了 Web 服务器、与 Prometheus 和 Console Light 的集成。我使用 wrk 和脚本在 Web 服务器上创建了人工负载。在下面的截图中，您可以比较相应的指标。结果相当有趣。

总体而言，这些指标在各方面都很相似；当您增加指标收集间隔时，差异就开始出现了。如果 Console Light 每秒获取一次指标，那么在 Grafana 中，2 分钟的间隔会显示有延迟且存在一些差异的指标。因此，截图中存在差异。

../../../_images/7a4e4d00041837c91b26e9234458a72f.jpg

在磁盘使用量开始令人担忧地增长时，Grafana 仍然显示一切正常。

../../../_images/f43b6bc70d9f9868db502245dd791bdd.jpg

当然，最终指标会对齐。

../../../_images/396626a6955163cdd3ff2bdb8f559ae8.jpg
../../../_images/c5a6dbf03d8fb1ed702d8d508e45c857.jpg

运行时请求指标的情况也类似。

../../../_images/982ebe9c1275754142f668366242b3bb.jpg
../../../_images/5d094963d3b500b00518b051cbe69b74.jpg

很多取决于 Grafana 和 Prometheus 本身的设置；您需要选择适合您的间隔。但请做好准备，间隔越短，服务需要在磁盘上存储的数据就越多。

6. 结论。"原来多面性是这个意思！"#

不能说组织 Web 服务器监控系统有唯一正确的方法。但我们试图在 Angie Web 服务器中提供灵活性，以便配置适合您的解决方案。

作为一名工程师，我经常遇到用户在一切都已经发生且尚未配置设置时寻求帮助的情况。因此，请允许我花点时间提醒您：最好提前进行所有必要的设置，以便为不可预见的情况做好准备。幸运的是，有详细的说明可供参考。

那么，关于多面监控方法。多面性体现在您可以继续分析日志，可以使用提供扩展指标 API 的 Angie Web 服务器。您可以在简单的网页 Console Light 上查看 Web 服务器状态。最后，您可以将 Web 服务器状态信息完整集成到基于 Prometheus 的指标收集系统中。

请使用它！很高兴能帮助您！