我叫安东·巴德林。 我在高科技中心工作，负责系统管理。 一个月前，我们的企业会议结束了，我们与本市的 IT 社区分享了我们积累的经验。 我谈到了监控 Web 应用程序。 该材料适用于初级或中级水平，他们并不是从头开始构建此过程。
任何监控系统的基石都是解决业务问题。 为了监视而监视，谁都没有兴趣。 企业想要什么？ 这样一切就可以快速且无错误地进行。 企业希望积极主动，以便我们自己发现服务中的问题并尽快解决它们。 事实上，这些都是我去年在一个客户的项目中解决的问题。
关于项目
该项目是该国最大的忠诚度计划之一。 我们帮助零售连锁店通过奖金卡等各种营销工具提高销售频率。 该项目总共包括 14 个应用程序，在 XNUMX 台服务器上运行。
在采访过程中，我反复注意到管理员并不总是正确地监控 Web 应用程序：许多人仍然关注操作系统指标，偶尔监控服务。
就我而言，客户的监控系统之前是基于 Icinga 的。 它并没有以任何方式解决上述问题。 通常，客户会亲自向我们告知问题，但更多时候，我们只是没有足够的数据来查明原因。
此外，人们清楚地认识到其进一步发展是徒劳的。 我想熟悉 Icinga 的人都会理解我。 因此，我们决定彻底重新设计该项目的Web应用监控系统。
普罗米修斯
我们选择Prometheus主要基于三个指标：
- 大量可用指标。 在我们的例子中，有 60 万个。 当然，值得注意的是我们并没有使用其中的绝大多数（可能大约 95%）。 另一方面，它们都相对便宜。 对于我们来说，与之前使用的 Icinga 相比，这是另一个极端。 在其中，添加指标是一个特别痛苦的事情：现有的指标非常昂贵（只需查看任何插件的源代码）。 任何插件都是 Bash 或 Python 中的脚本，其启动就消耗的资源而言是昂贵的。
- 该系统消耗相对少量的资源。 600 MB 的 RAM、一个核心的 15% 和几十个 IOPS 足以满足我们的所有指标。 当然，您必须运行指标导出器，但它们都是用 Go 编写的，而且也不是很耗电。 我认为在现代现实中这不是一个问题。
- 提供迁移到 Kubernetes 的能力。 考虑到客户的计划，选择是显而易见的。
麋鹿
以前，我们不收集或处理日志。 缺点大家都很清楚。 我们选择 ELK 是因为我们已经有这个系统的经验。 我们只在那里存储应用程序日志。 主要选择标准是全文搜索及其速度。
克里克豪斯
最初，选择落在了 InfluxDB 上。 我们意识到需要收集Nginx日志、pg_stat_statements的统计数据以及存储Prometheus历史数据。 我们不喜欢 Influx，因为它会定期开始消耗大量内存并崩溃。 另外，我想通过remote_addr对查询进行分组，但是在这个DBMS中只能通过标签进行分组。 标签很昂贵（内存），它们的数量是有条件限制的。
我们再次开始寻找。 我们需要的是一个资源消耗最少的分析数据库，最好在磁盘上进行数据压缩。
Clickhouse满足所有这些标准，我们从未后悔过我们的选择。 我们不会向其中写入任何大量数据（插入次数仅为每分钟 XNUMX 左右）。
NewRelic的
NewRelic 一直与我们合作，因为它是客户的选择。 我们将其用作 APM。
ZABBIX
我们专门使用Zabbix来监控各种API的黑匣子。
定义监控方法
我们希望分解任务，从而使监控方法系统化。
为此，我将我们的系统分为以下几个级别：
- 硬件和VMS；
- 操作系统;
- 系统服务、软件堆栈；
- 应用;
- 商业逻辑。
为什么这种方法很方便：
- 我们知道谁负责每个级别的工作，并据此发送警报；
- 我们可以在抑制警报时使用该结构 - 当整个虚拟机不可用时发送有关数据库不可用的警报会很奇怪。
由于我们的任务是识别系统运行中的违规行为，因此我们必须在每个级别突出显示一组在编写警报规则时值得关注的指标。 接下来，我们来看看“VMS”、“操作系统”和“系统服务、软件堆栈”三个级别。
虚拟机
托管为我们分配处理器、磁盘、内存和网络。 我们在前两个方面遇到了问题。 所以，指标：
CPU 被盗时间 - 当您在 Amazon 上购买虚拟机（例如 t2.micro）时，您应该明白，您没有分配到整个处理器核心，而只是分配了其时间配额。 当你耗尽它时，处理器就会从你身边被夺走。
该指标可让您跟踪此类时刻并做出决策。 例如，是否需要采取更丰厚的资费或将后台任务和API请求的处理分散到不同的服务器上？
IOPS + CPU iowait 时间 - 由于某种原因，许多云主机因无法提供足够的 IOPS 而犯错。 此外，低 IOPS 的调度对于他们来说并不是一个论据。 因此，值得收集CPU iowait。 有了这对图表 - 具有低 IOPS 和高 I/O 等待 - 您已经可以与主机交谈并解决问题。
操作系统
操作系统指标：
- 可用内存量（%）；
- 交换使用活动：vmstat swapin、swapout；
- 文件系统上可用 inode 和可用空间的数量（以 % 为单位）
- 平均负载；
- tw状态下的连接数；
- 跟踪表的完整性；
- 可以使用 ss 实用程序（iproute2 包）来监控网络质量 - 从其输出中获取 RTT 连接的指示符，并按目标端口对其进行分组。
同样在操作系统级别，我们有进程这样的实体。 在系统中识别一组在其运行中发挥重要作用的进程非常重要。 例如，如果您有多个 pgpool，那么您需要收集每个 pgpool 的信息。
指标集如下：
- 中央处理器;
- 记忆主要是驻留的；
- IO——最好以IOPS为单位；
- FileFd——打开和限制；
- 严重的页面失败 - 这样您就可以了解正在交换哪个进程。
我们将所有监控部署在 Docker 中，并使用 Advisor 来收集指标数据。 在其他机器上，我们使用进程导出器。
系统服务、软件堆栈
每个应用程序都有自己的具体情况，很难挑选出一组特定的指标。
通用集是：
- 请求率；
- 错误数量；
- 潜伏;
- 饱和。
在这个级别上，我们最引人注目的监控示例是 Nginx 和 PostgreSQL。
我们系统中负载最多的服务是数据库。 过去，我们常常很难弄清楚数据库在做什么。
我们看到磁盘负载很高，但缓慢的日志并没有真正显示任何内容。 我们使用 pg_stat_statements 解决了这个问题，这是一个收集查询统计信息的视图。
这就是管理员的全部需求。
我们构建读写请求活动的图表：
一切都简单明了，每个请求都有自己的色彩。
一个同样引人注目的例子是 Nginx 日志。 很少有人解析它们或在必备清单中提及它们，这并不奇怪。 标准格式信息量不大，需要扩展。
就我个人而言，我添加了 request_time、upstream_response_time、body_bytes_sent、request_length、request_id。我们绘制响应时间和错误数：
我们构建响应时间和错误数量的图表。 记住？ 我有谈论业务任务吗？ 快速且无错误？ 我们已经用两张图表涵盖了这些问题。 您已经可以使用它们呼叫值班管理员。
但还有一个问题仍然存在——确保迅速消除事件起因。
事件解决
从发现问题到解决问题的整个过程可以分为几个步骤：
- 识别问题；
- 通知值班管理员；
- 对事件的反应；
- 消除原因。
重要的是我们必须尽快做到这一点。 如果在发现问题和发送通知的阶段我们无法获得太多时间——无论如何都会花费两分钟，那么后续的改进就只是未耕耘的领域。
让我们想象一下，值班人员的电话响了。 他会做什么？ 寻找问题的答案——什么坏了，坏在哪里，如何反应？ 我们是这样回答这些问题的：
我们只需将所有这些信息包含在通知文本中，为其提供一个 wiki 页面的链接，该页面描述如何响应此问题、如何解决问题并升级问题。
应用层和业务逻辑我还没说。 不幸的是，我们的应用程序尚未实现指标收集。 这些级别的任何信息的唯一来源是日志。
有几点。
首先，编写结构化日志。 消息文本中无需包含上下文。 这使得它们难以分组和分析。 Logstash 需要很长时间才能使这一切正常化。
其次，正确使用严重性级别。 每种语言都有自己的标准。 就我个人而言，我分为四个层次：
- 没有错误；
- 客户端错误；
- 错误在我们这边，我们不赔钱，我们不承担风险；
- 错误在我们这边，我们赔了钱。
让我总结一下。 您需要尝试构建基于业务逻辑的监控。 尝试监控应用程序本身并使用销售数量、新用户注册数量、当前活跃用户数量等指标进行操作。
如果你的整个业务就是浏览器中的一个按钮，那么你需要监控它是否点击并正常工作。 其余的一切都没关系。
如果你没有这个，你可以尝试在应用程序日志、Nginx 日志等中追赶它，就像我们所做的那样。 您应该尽可能接近应用程序。
操作系统指标当然很重要，但企业对它们不感兴趣，我们没有为此付费。
来源： habr.com