我叫安东·巴德林。 我在高科技中心工作，从事系统管理。 一个月前，我们的公司会议结束了，我们在该市的IT社区分享了我们的经验。 我谈到了监视Web应用程序。 该材料适用于初级或中级水平，这不是从头开始构建此过程的。
任何监视系统的基础都是解决业务问题的基础。 为了监视而进行监视对任何人都没有兴趣。 公司想要什么？ 这样一切都将快速运行且没有错误。 业务部门需要主动，以便我们自己确定服务中的问题并尽快消除。 实际上，这就是我去年一直在解决一位客户项目上的任务。
关于项目
该项目是该国最大的忠诚度计划之一。 我们通过奖励卡等各种营销工具帮助零售商提高销售频率。 该项目总共包括在十台服务器上运行的14个应用程序。
在进行采访的过程中，我反复注意到，管理员远不能始终正确地监视Web应用程序：到目前为止，许多管理员已经停止了对操作系统指标的监视，并偶尔监视服务。
就我而言，Icinga以前是客户监视系统的基础。 她没有解决上述问题。 客户通常会自己将问题告知我们，至少我们根本没有足够的数据来弄清原因。
此外，对它的进一步发展毫无用处。 我认为那些熟悉Icinga的人会理解我的。 因此，我们决定完全重新设计该项目上Web应用程序的监视系统。
普罗米修斯
我们基于三个关键指标选择了普罗米修斯：
- 大量可用指标。 在我们的案例中，有6万个。 当然，值得注意的是，我们绝不使用其中的绝大多数（大约95％）。 另一方面，它们都相对便宜。 对我们来说，与以前使用的Icinga相比，这是另一个极端。 其中，添加指标特别麻烦：可用的指标很昂贵（只需查看任何插件的源代码）。 任何插件都是Bash或Python脚本，就消耗的资源而言，启动该插件并不便宜。
- 该系统消耗相对少量的资源。 我们所有的指标都有600 MB的RAM，一个内核的15％和几十个IOPS。 当然，您必须运行度量标准的导出器，但是它们都是用Go编写的，而且暴食率也没有差异。 我认为在现代现实中这不是问题。
- 这使得切换到Kubernetes成为可能。 根据客户的计划，选择是显而易见的。
麋鹿
以前，我们没有收集或处理日志。 这些缺陷对每个人都很明显。 我们选择了ELK，因为我们已经拥有该系统的经验。 我们仅在其中存储应用程序日志。 主要选择标准是全文搜索及其速度。
Clickhouse
最初，选择权落在InfluxDB上。 我们认识到需要收集Nginx日志，来自pg_stat_statements的统计信息以及存储Prometheus历史数据。 我们不喜欢Influx，因为它会定期开始消耗大量内存并崩溃。 另外，我想按remote_addr对请求进行分组，而在此DBMS中仅按标签进行分组。 道路标记（内存），其数量是有条件限制的。
我们再次开始搜索。 我们需要一个分析资源最少的分析库，最好是磁盘上的数据压缩。
Clickhouse符合所有这些条件，我们从不后悔这个选择。 我们不会向其中写入任何未完成的数据（插入的数量每分钟仅约五千次）。
新遗物
从过去开始，NewRelic就一直在我们身边，因为它是客户的选择。 我们将其用作APM。
扎比克斯
我们仅使用Zabbix来监视各种API的黑匣子。
定义监控方法
我们想分解任务，从而使监视方法系统化。
为此，我将系统分为以下几层：
- 硬件和VMS；
- 作业系统
- 系统服务，软件堆栈；
- 申请书
- 业务逻辑。
是什么使这种方法变得方便：
- 我们知道谁负责每个级别的工作，并以此为基础发送警报；
- 我们可以在抑制警报时使用该结构-当虚拟机通常不可访问时，发出有关数据库不可访问的警报会很奇怪。
由于我们的任务是检测系统中的异常情况，因此我们必须在每个级别选择一组特定的指标，在编写警报规则时应注意这些指标。 接下来，我们将遍历“ VMS”，“操作系统”和“系统服务，软件堆栈”级别。
虚拟机
托管为我们提供了处理器，磁盘，内存和网络。 对于前两个，我们遇到了问题。 因此指标：
CPU盗用时间-在Amazon（例如t2.micro）上购买虚拟机时，您应该了解到，您并未分配整个处理器核心，而只是分配了其时间配额。 当您用尽它时，处理器将被从您手中取走。
此度量标准使您可以跟踪这样的时刻并做出决定。 例如，是否有必要增加关税或将API中的后台任务和请求的处理分配给其他服务器。
IOPS + CPU的等待时间-由于某些原因，许多云托管公司都因未交付IOPS而感到不快。 而且，IOPS较低的时间表对他们来说并不是一个论点。 因此，值得收集iowait CPU。 使用这对图表-IOPS低且I / O期望值高-您已经可以与主机对话并解决问题了。
作业系统
操作系统指标：
- 可用内存量，以％为单位；
- 使用swap的活动：vmstat swapin，swapout；
- 文件系统上可用的索引节点数和可用空间，以％为单位
- 平均负载；
- 处于tw状态的连接数；
- conntrack表已满；
- 可以使用ss实用程序iproute2程序包监视网络性能-从其输出获取RTT连接指示器，然后按目标端口分组。
同样在操作系统级别，我们拥有诸如流程之类的实体。 重要的是要在系统中突出显示一组在其工作中起着重要作用的过程。 例如，如果您有多个pgpool，则需要为每个pgpool收集信息。
一组指标如下：
- 中央处理器
- 内存主要是常驻的；
- IO-最好是IOPS；
- FileFd-打开并限制；
- 重大页面故障-因此您可以了解正在交换的进程。
所有监控都部署在Docker中，我们使用advisor收集指标数据。 在其他计算机上，我们使用process-exporter。
系统服务，软件堆栈
每个应用程序都有自己的详细信息，很难区分某些度量标准。
通用集有：
在此级别上最引人注目的监视示例是Nginx和PostgreSQL。
我们系统中负载最大的服务是数据库。 过去，我们经常会遇到一些问题，以弄清楚数据库的作用。
我们在磁盘上看到了很高的负载，但是标语并没有真正显示任何内容。 我们使用pg_stat_statements解决了这个问题，该视图收集有关请求的统计信息。
这就是管理员的全部需求。
我们绘制读写请求的活动：
一切都很简单明了，每个请求都有自己的颜色。
一个同样引人注目的示例是Nginx日志。 毫不奇怪，很少有人解析它们或在所需列表中提及它们。 标准格式不是非常有用，需要扩展。
我个人添加了request_time，upstream_response_time，body_bytes_sent，request_length，request_id，我们绘制了响应时间和错误数量：
我们绘制响应时间和错误数量。 你还记得吗 我说过商业目标吗？ 要快速且没有错误？ 我们已经用两个图表解决了这些问题。 在他们身上，您已经可以致电值班管理员。
但是仍然存在另一个问题-确保迅速消除事故原因。
事件管理
从识别到解决问题的整个过程可以分为多个步骤：
- 问题识别；
- 值班管理员的通知；
- 对事件的反应；
- 消除原因。
重要的是我们尽快这样做。 而且，如果在确定问题和发送通知的阶段我们不能赢得太多时间-无论如何他们都会离开两分钟，那么接下来的只是一个未经改进的领域。
让我们想象一下手机正在值班。 他会怎么做？ 寻找问题的答案-什么地方坏了，哪里地方坏了，如何应对？ 这是我们回答这些问题的方法：
我们将所有这些信息简单地包含在通知文本中，为它提供指向Wiki页面的链接，该页面描述了如何解决此问题，如何解决和升级。
关于应用程序层和业务逻辑，我还什么都没说。 不幸的是，指标收集尚未在我们的应用程序中实现。 这些级别中至少某些信息的唯一来源是日志。
有两点。
首先，编写结构化日志。 无需在消息正文中包含上下文。 这使得很难对它们进行分组和分析。 Logstash需要很长时间才能将所有这些标准化。
其次，正确使用严重性级别。 每种语言都有其自己的标准。 我个人区分四个级别：
- 没有错误；
- 客户端错误；
- 我们身边有一个错误，我们不亏钱，我们不承担风险；
- 错误就在我们这边，我们正在赔钱。
我总结一下。 有必要尝试从业务逻辑中精确构建监视。 尝试监视应用程序本身，并使用诸如销售数量，新用户注册数量，当前活动用户数量等指标进行操作。
如果您的整个业务只是浏览器中的一个按钮，则需要监视其是否受到挤压并正常运行。 其他一切都不重要。
如果您没有此功能，则可以像我们一样尝试在应用程序日志，Nginx日志等中追上它。 您应该尽可能靠近该应用程序。
操作系统指标固然很重要，但对业务而言并不重要，我们无需为此付费。