如果您负责具有任意数量用户的生产服务,您可能会了解客户在您之前发现问题的痛苦。 在 Akita,我们想要解决这个问题 —— 这就是我们构建新的NGINX Plus 认证模块的原因。
在此博客中,我们将介绍该模块的关键方面,包括缩小日志的原因、快速查找和修复系统中问题的方法,以及新的 Akita 模块如何使 NGINX 用户轻松使用此功能。
如今,无数的开发人员发现自己陷入了一种不幸的境地:他们的客户实际上已经成为了他们的监控系统。
这并不是说软件团队没有记录错误。 例如,如果您使用 NGINX 作为反向代理,您将在 NGINX 日志中收到各种信息:时间戳、请求长度和处理时间以及响应状态代码。 如果您有时间和耐心去寻找,信息就在那里。
然而,在具有许多不同请求和响应的系统中,很容易迷失在日志的海洋中! 除非您主动在日志上设置仪表板或其他类型的工具,否则您可能会发现自己正在浏览数千(甚至数百万)条日志行,试图找出潜在问题以及它们的起源。 但设置正确的仪表板和监控方法可能需要数周、数月甚至数个季度的时间。 并且它经常需要与代码同步更新。
在 Akita,我们认为从日志扩展到 API 端点至关重要。 这使得软件团队能够快速查看问题和热点的概述,同时保持实际识别问题所需的粒度。 我们正在通过完全嵌入式指标解决方案解决监控中的信息过载问题,该解决方案可自动监控延迟指标和错误 - 无需更改代码或构建仪表板。 我们的解决方案被动监视 API 流量并自动分析它以提供每个端点的监控和警报。 最重要的是: 用户注册后15分钟内即可开始使用。
我们很高兴推出 Akita 模块,现在可供NGINX 用户使用。 如果您使用 NGINX 作为 Web应用服务器、反向代理或 API 网关,则现在可以将 API 流量发送到 Akita 进行分析。 注册一个免费的 Akita 账户,安装 Akita 模块和代理,并对你的 NGINX 配置文件做一些小的更改。
几分钟内,您将能够导航到 Akita 控制台来查看您的 API 端点、哪些运行缓慢以及哪些引发了错误。
Akita 的 NGINX Plus 认证模块为 NGINX 用户提供了 Akita 的诸多好处,可作为现有 NGINX 设置的扩展。 Akita 将从 HTTP 请求中捕获您的流量并测量其延迟和错误,同时使用预先构建的仪表板向您展示生产过程中发生的情况。
让我们深入了解该模块的功能及其作用。 首先,NGINX 分多个“阶段”处理请求,从网络读取请求开始,经过重写和访问控制检查,最后生成响应和任何日志条目。 Akita 的 NGINX Plus 认证模块在此过程的后期插入(在预内容阶段,在标头重写等功能之后),因此它可以以与应用接收的形式最相似的形式查看请求。 Akita 根据 NGINX 配置中的服务器和位置检查每个传入请求,看其是否被标记为监控。
笔记: 与其他 NGINX 功能和模块一样,您可以仅为部分 Web 服务启用 Akita ,或将其默认为 NGINX 提供的所有内容。
在下一阶段,模块记录请求主体并在完全收到请求后立即将其发送给 Akita 代理。 此行为类似于 ngx_http_mirror 模块,因为相同的数据并行发送到应用和 Akita 代理。
当 NGINX 或上游服务器准备好响应时,Akita 模块会记录该响应(最多 1MB),同时将其流回客户端。 响应不会因缓冲而延迟,缓冲发生在 NGINX 的“内容过滤器”中,它可以在响应主体的每个块可用时对其进行处理。
一旦知道服务器响应时间并且响应成功,该响应就会镜像到 Akita 代理。 代理将请求和响应匹配在一起,然后尝试解析请求和响应主体内容。 这些数据在发送给 Akita 进行分析之前,先由代理在本地进行混淆。 这意味着 Akita 可以看到您的 API 流量的结构,但看不到您的用户发送的或发送给用户的具体值。
Akita 的 NGINX Plus 认证模块会自动从应用流量跟踪中推断您的端点,构建可浏览、可下载的 API 模型,并自动显示延迟和错误信息。 它允许您对每个端点的错误率、特定端点的高延迟,甚至是意外的大量呼叫发出警报。
对于每个端点,Akita 的 NGINX Plus 认证模块使您能够看到:
关于设置 Akita 的 NGINX Plus 认证模块的更多信息可以在这里找到。
Akita 目前处于公开测试阶段。 您可以注册测试版并在不到 30 分钟的时间内获得结果。
“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息,请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”