监控死了吗？ — 长期实时监控

自2008年以来，我们公司主要从事网络项目的基础设施管理和全天候技术支持：我们拥有400多家客户，约占俄罗斯电子商务的15%。 因此，支持非常多样化的架构。 如果有东西掉落，我们有义务在 15 分钟内修好。 但要了解事故已经发生，您需要监控项目并对事件做出响应。 这个怎么做？

我认为组织适当的监控系统存在问题。 如果没有遇到麻烦，那么我的演讲将包含一个主题：“请安装 Prometheus + Grafana 和插件 1、2、3。” 不幸的是，现在不再这样了。 主要问题是每个人仍然相信 2008 年存在的软件组件方面的东西。

关于监控系统的组织，我敢说……具有足够监控能力的项目并不存在。 而且情况非常糟糕，如果有东西掉落，就有可能被忽视——毕竟，每个人都确信“一切都受到监控”。
或许一切都被监控着。 但如何呢？

我们都遇到过这样的故事：某个开发人员、某个管理员正在工作，一个开发团队找到他们并说：“我们已发布，现在进行监控。” 监控什么？ 怎么运行的？

好的。 我们以老式的方式进行监控。 而且它已经在改变了，事实证明你监控了服务 A，它变成了服务 B，服务 B 与服务 C 交互。但是开发团队告诉你：“安装软件，它应该监控一切！”

那么发生了什么变化呢？ - 一切都变了！

2008年一切安好

有几个开发人员，一台服务器，一台数据库服务器。 一切都从这里开始。 我们有一些信息，我们安装zabbix、Nagios、cacti。 然后我们对 CPU、磁盘操作和磁盘空间设置明确的警报。 我们还进行了一些手动检查，以确保网站响应并且订单到达数据库。 就是这样——我们或多或少受到了保护。

如果我们比较管理员当时为提供监控所做的工作量，那么 98% 是自动的：进行监控的人必须了解如何安装 Zabbix、如何配置它以及配置警报。 2% - 用于外部检查：站点是否响应并向数据库发出请求，新订单是否已到达。

2010年负荷越来越大

我们开始扩展网络，添加搜索引擎。 我们希望确保产品目录包含所有产品。 产品搜索有效。 数据库正在工作，正在下订单，站点从外部响应并从两个服务器响应，并且在重新平衡到另一台服务器时用户不会被踢出站点，等等。 还有更多的实体。

此外，与基础设施相关的实体仍然是管理者头脑中最大的实体。 我的脑海里仍然有一个想法，即进行监控的人是会安装zabbix并能够配置它的人。

但与此同时，还需要进行外部检查、创建一组搜索索引器查询脚本、一组用于检查索引过程中搜索是否发生变化的脚本、一组用于检查货物是否已转移到仓库的脚本。送货服务等等等。

注：“一套脚本”我写了3次。 即负责监控的人不再是单纯安装zabbix的人了。 这是一个开始编码的人。 但团队的想法还没有改变。

但世界正在发生变化，变得越来越复杂。 添加了虚拟化层和几个新系统。 他们开始互相互动。 谁说“闻起来像微服务”？ 但每项服务看起来仍然像一个单独的网站。 我们可以求助于它并了解它提供了必要的信息并且可以自行工作。 如果您是一名管理员，不断参与一个已经开发了 5-7-10 年的项目，那么这种知识就会积累：一个新的级别出现 - 您意识到了，另一个级别出现了 - 您意识到了......

但很少有人会陪伴一个项目长达 10 年。

监控员简历

假设您来到一家新初创公司，该公司立即雇用了 20 名开发人员，编写了 15 个微服务，并且您是一名管理员，被告知：“构建 CI/CD。 请。” 您已经构建了 CI/CD，突然您听到：“如果不了解应用程序如何在其中运行，我们就很难在“立方体”中进行生产。 让我们在同一个“立方体”中成为一个沙箱。
您在这个立方体中创建一个沙箱。 他们立即告诉您：“我们想要一个每天从生产中更新的阶段数据库，以便我们了解它可以在数据库上运行，但同时不会破坏生产数据库。”

你生活在这一切之中。 距离发布还剩 2 周时间，他们告诉你：“现在让我们监视这一切......”就是这样。 监控集群基础设施、监控微服务架构、监控与外部服务的工作......

我的同事们把通常的计划从他们的头脑中抛开，说：“好吧，这里一切都清楚了！ 安装一个程序来监控这一切。” 是的，是的：Prometheus + Grafana + 插件。
他们补充道：“你有两周时间，确保一切安全。”

在我们看到的很多项目中，都会分配一个人来进行监控。 想象一下，我们想雇一个人做两周的监控，我们给他写一份简历。 鉴于我们到目前为止所说的一切，这个人应该具备哪些技能？

• 他必须了解钢铁基础设施运行的监控和细节。
• 他必须了解监控 Kubernetes 的细节（每个人都想进入“立方体”，因为你可以从一切事物中抽象、隐藏，因为管理员将处理其余的事情）——它本身、它的基础设施，并了解如何监控应用程序里面。
• 他必须了解服务以特殊方式相互通信，并了解服务如何相互交互的细节。 很可能会看到一些服务同步通信的项目，因为没有其他方法。 例如，后端通过 REST、gRPC 到达目录服务，接收产品列表并将其返回。 你不能在这里等。 它与其他服务异步工作。 将订单转交给送货服务、发送信件等。
  你可能已经摆脱了这一切？ 需要监控这一点的管理员变得更加困惑。
• 他必须能够正确地计划和计划——随着工作变得越来越多。
• 因此，他必须根据创建的服务创建策略，以便了解如何具体监控它。 他需要了解项目的架构及其开发+了解开发中使用的技术。

让我们记住一个绝对正常的情况：有些服务是 PHP 的，有些服务是 Go 的，有些服务是 JS 的。 他们以某种方式互相合作。 这就是“微服务”一词的由来：有太多单独的系统，开发人员无法理解整个项目。 团队中的一部分人用 JS 编写服务，这些服务独立工作，不知道系统的其余部分如何工作。 另一部分用Python编写服务，不干扰其他服务的工作方式；它们在自己的区域中隔离。 第三个是用 PHP 或其他东西编写服务。
这 20 个人全部分为 15 个服务，只有一名管理员必须了解这一切。 停止！ 我们只是将系统拆分为 15 个微服务，因为 20 个人无法理解整个系统。

但它需要以某种方式进行监控......

结果如何？ 结果，有一个人想出了整个开发团队无法理解的一切，同时他还必须知道并能够做我们上面指出的事情——硬件基础设施、Kubernetes 基础设施等。

我能说什么...休斯顿，我们有问题。

监控现代软件项目本身就是一个软件项目

从“监控是软件”的错误信念，我们开始相信奇迹。 但遗憾的是，奇迹并没有发生。 你不能安装 zabbix 并期望一切正常。 安装 Grafana 并希望一切都会好起来是没有意义的。 大部分时间将花在组织检查服务的运行及其相互之间的交互，检查外部系统如何工作。 事实上，90%的时间不会花在写脚本上，而是花在开发软件上。 它应该由了解项目工作的团队来处理。
如果在这种情况下将一个人投入监控之中，那么灾难就会发生。 这是到处都会发生的事情。

例如，有多个服务通过 Kafka 相互通信。 订单到达，我们向 Kafka 发送了一条有关订单的消息。 有一项服务可以侦听有关订单的信息并运送货物。 有一项服务可以侦听有关订单的信息并向用户发送一封信。 然后出现更多服务，我们开始感到困惑。

如果您还在发布前不久的阶段将其提供给管理员和开发人员，那么他们将需要了解整个协议。 那些。 这种规模的项目需要花费大量时间，这应该被纳入系统开发中。
但很多时候，尤其是在初创企业中，我们会看到监控是如何推迟到以后的。 “现在我们将进行概念验证，我们将推出它，让它落下——我们准备好做出牺牲。 然后我们将监控这一切。” 当（或如果）项目开始赚钱时，企业希望添加更多功能 - 因为它已经开始工作，所以需要进一步推出！ 现在，您首先需要监控之前的所有内容，这需要的时间不是 1%，而是更多。 顺便说一句，开发人员需要进行监控，并且让他们更容易开发新功能。 结果，新功能被编写出来，一切都搞砸了，你陷入了无尽的僵局。

那么如何从头开始监控一个项目，如果你拿到一个需要监控的项目，但不知道从哪里开始怎么办？

首先，你需要制定计划。

抒情题外话：他们通常从基础设施监控开始。 例如，我们有 Kubernetes。 让我们首先使用 Grafana 安装 Prometheus，安装用于监控“立方体”的插件。 不仅开发人员，而且管理员也有这样的不幸做法：“我们将安装这个插件，但插件可能知道如何做到这一点。” 人们喜欢从简单直接的事情开始，而不是从重要的行动开始。 而且基础设施监控很容易。

首先，决定要监控的内容和方式，然后选择工具，因为其他人无法为您思考。 他们应该吗？ 其他人自己想到了一个通用系统 - 或者在编写这个插件时根本没有想到。 仅仅因为这个插件有 5 个用户并不意味着它有任何用处。 也许你会成为第 5001 名，因为之前已经有 5000 人了。

如果您开始监控基础设施并且应用程序的后端停止响应，则所有用户都将失去与移动应用程序的连接。 将会出现错误。 他们会来找你并说“应用程序无法运行，你在这里做什么？” - “我们正在监视。” —“如果您没有发现应用程序无法运行，您如何进行监控？！”

1. 我认为您需要准确地从用户的入口点开始监控。 如果用户看不到应用程序正在运行，那就是失败。 监控系统应该首先对此发出警告。
2. 只有这样我们才能监控基础设施。 或者并行进行。 有了基础设施就更容易了——在这里我们终于可以安装 zabbix 了。
3. 现在，您需要深入应用程序的根源，了解哪里出现问题。

我的主要想法是监控应该与开发过程并行。 如果您将监控团队的注意力分散到其他任务上（创建 CI/CD、沙箱、基础设施重组），那么监控将开始滞后，您可能永远无法跟上开发的步伐（或者迟早您将不得不停止它）。

一切按级别划分

这就是我对监控系统组织的看法。

1）应用级别：

• 监控应用程序业务逻辑；
• 监控服务的健康指标；
• 集成监控。

2）基础设施层面：

• 编排级别监控；
• 系统软件监控；
• 铁含量监测。

3）再次是应用层面——但作为工程产品：

• 收集和监控应用程序日志；
• APM；
• 追踪。

4）警报：

• 组织警报系统；
• 组织值班制度；
• 组织事件处理的“知识库”和工作流程。

这一点很重要：我们不是在之后而是立即收到警报！ 无需启动监控并“稍后”确定谁将收到警报。 毕竟，监控的任务是什么：了解系统中哪里出现问题，并让合适的人员知道这一点。 如果你把这个留到最后，那么正确的人只会通过说“没有什么对我们有用”来知道出了什么问题。

应用层-业务逻辑监控

在这里，我们讨论的是检查应用程序是否为用户工作这一事实。

这个级别应该在开发阶段完成。 例如，我们有一个有条件的 Prometheus：它会转到服务器进行检查，拉取端点，然后端点会检查 API。

当经常被要求监视主页以确保网站正常工作时，程序员会提供一个句柄，每次需要确保 API 正常工作时都可以拉取该句柄。 而此时的程序员仍然采取并编写 /api/test/helloworld
确保一切正常的唯一方法是什么？ - 不！

• 创建此类检查本质上是开发人员的任务。 单元测试应该由编写代码的程序员编写。 因为如果你将其泄露给管理员，“伙计，这是所有 25 个功能的 API 协议列表，请监控一切！” - 一切都不会成功。
• 如果你打印“hello world”，没有人会知道 API 应该并且确实可以工作。 每个 API 更改都必须导致检查的更改。
• 如果您已经遇到这样的问题，请停止这些功能并分配将编写这些检查的开发人员，或者接受损失，接受没有任何检查并且会失败的事实。

技术提示：

• 一定要组织一个外部服务器来组织检查——你必须确保你的项目可以被外界访问。
• 组织检查整个 API 协议，而不仅仅是单个端点。
• 使用测试结果创建一个 prometheus 端点。

应用层-健康指标监控

现在我们讨论的是服务的外部健康指标。

我们决定使用外部检查来监视应用程序的所有“句柄”，我们从外部监视系统调用外部检查。 但这些是用户“看到”的“句柄”。 我们希望确保我们的服务本身有效。 这里有一个更好的故事：K8s 具有健康检查功能，因此至少“立方体”本身可以确信该服务正在运行。 但我见过的一半支票都是同样的“hello world”字样。 那些。 所以他部署后拉一次，他回答说一切都很好——仅此而已。 而且，如果服务提供自己的 API，则该服务具有大量同一 API 的入口点，这些入口点也需要进行监控，因为我们想知道它是否有效。 我们已经在里面监视它了。

如何从技术上正确实现这一点：每个服务都会公开一个有关其当前性能的端点，并且在 Grafana（或任何其他应用程序）的图表中我们可以看到所有服务的状态。

• 每个 API 更改都必须导致检查的更改。
• 立即使用健康指标创建新服务。
• 管理员可以找到开发人员并要求“添加一些功能，以便我了解所有内容，并将有关此信息的信息添加到我的监控系统中。” 但开发人员通常会回答：“我们不会在发布前两周添加任何内容。”
  让开发经理知道会有这样的损失，也让开发经理的管理层知道。 因为当一切都崩溃的时候，仍然会有人打电话要求监控“不断下降的服务”(c)
• 顺便说一句，分配开发人员为 Grafana 编写插件 - 这对管理员来说将是一个很好的帮助。

应用层-集成监控

集成监控侧重于监控关键业务系统之间的通信。

例如，有 15 个服务相互通信。 这些不再是单独的站点。 那些。 我们无法单独拉取该服务、获取 /helloworld 并了解该服务正在运行。 因为订购 Web 服务必须将有关订单的信息从总线发送到总线，所以仓库服务必须接收此消息并进一步处理它。 电子邮件分发服务必须以某种方式进一步处理这个问题，等等。

因此，我们无法通过查看每个单独的服务来理解它是否全部有效。 因为我们有某种总线，所有事物都通过它进行通信和交互。
因此，这个阶段应该标志着测试服务与其他服务交互的阶段。 不可能通过监控消息代理来组织通信监控。 如果有一个服务发出数据，又有一个服务接收数据，那么在监视代理时，我们只会看到从一边飞到另一边的数据。 即使我们以某种方式设法在内部监控这些数据的交互 - 某个生产者发布数据，有人读取它，这个流继续进入 Kafka - 如果一个服务以一个版本发送消息，这仍然不会给我们信息，但其他服务没有想到这个版本并跳过了它。 我们不会知道这一点，因为服务会告诉我们一切正常。

我建议做什么：

• 对于同步通信：端点向相关服务发出请求。 那些。 我们采用这个端点，在服务内拉取一个脚本，该脚本会到达所有点并说“我可以拉到那里，拉到那里，我可以拉到那里......”
• 对于异步通信：传入消息 - 端点检查总线上的测试消息并显示处理状态。
• 对于异步通信：传出消息 - 端点将测试消息发送到总线。

正如通常发生的那样：我们有一个将数据发送到总线的服务。 我们来到这项服务并请您告诉我们其集成状况。 如果服务需要在更远的地方（WebApp）生成消息，那么它将生成此测试消息。 如果我们在 OrderProcessing 端运行一个服务，它首先发布它可以独立发布的内容，如果有一些依赖的内容，那么它会从总线读取一组测试消息，了解它可以处理它们，报告它并，如果有必要，进一步发布它们，对此他说 - 一切都很好，我还活着。

我们经常听到这样的问题：“我们如何在战斗数据上测试这一点？” 例如，我们正在谈论相同的订购服务。 订单向货物被注销的仓库发送消息：我们无法在战斗数据上测试这一点，因为“我的货物将被注销！” 解决方案：从一开始就计划整个测试。 您还可以进行模拟的单元测试。 因此，请在更深层次上进行，确保有一个不会损害业务运营的沟通渠道。

基础设施层

基础设施监控长期以来被认为是监控本身。

• 基础设施监控可以而且应该作为一个单独的过程启动。
• 即使您确实想要，也不应该从对正在运行的项目进行基础设施监控开始。 这对所有 DevOps 来说都是一个痛苦。 “首先我将监控集群，我将监控基础设施”——即首先，它将监视下面的内容，但不会进入应用程序。 因为应用对于DevOps来说是一件难以理解的事情。 它被泄露给他，他不明白它是如何运作的。 但他了解基础设施并从它开始。 但不行 - 您始终需要首先监视应用程序。
• 警报的数量不要过多。 考虑到现代系统的复杂性，警报不断出现，您必须以某种方式忍受这堆警报。 值班人员在查看了接下来的一百个警报后，将决定“我不想考虑它”。 警报应该只通知重要的事情。

作为业务单元的应用程序级别

要点：

• 麋鹿。 这是行业标准。 如果由于某种原因您没有聚合日志，请立即开始聚合。
• APM。 外部 APM 作为快速关闭应用程序监控的一种方式（NewRelic、BlackFire、Datadog）。 你可以暂时安装这个东西，至少以某种方式了解你发生了什么。
• 追踪。 在数十个微服务中，您必须跟踪所有内容，因为请求不再独立存在。 以后添加非常困难，因此最好立即安排开发中的跟踪 - 这是开发人员的工作和效用。 如果您还没有实施，那就实施吧！ 参见 Jaeger/Zipkin

警报

• 通知系统的组织：在监控一堆事物的情况下，应该有一个统一的通知系统。 你可以在 Grafana 中。 在西方，每个人都使用 PagerDuty。 警报应该清晰（例如它们来自哪里......）。 建议完全控制通知的接收
• 值班制度的组织：警报不应发送给所有人（要么每个人都在人群中做出反应，要么没有人做出反应）。 开发人员还需要oncall：一定要明确职责范围，明确指示，写明周一周三具体给谁打电话，周二周五给谁打电话（不然即使在工作日也不会打电话给任何人）如果出现大问题 - 他们会害怕叫醒您或打扰：人们通常不喜欢打电话或叫醒其他人，尤其是在晚上）。 并解释说寻求帮助并不意味着无能（“我寻求帮助，这意味着我是一个糟糕的员工”），鼓励寻求帮助。
• 组织事件处理的“知识库”和工作流程：对于每个严重事件，应计划事后分析，并作为临时措施，记录解决事件的行动。 并养成一种习惯，即重复发出警报是一种罪过； 它们需要在代码或基础设施工作中修复。

技术栈

假设我们的堆栈如下：

• 数据采集​​——Prometheus + Grafana；
• 日志分析——ELK；
• 用于 APM 或追踪 - Jaeger (Zipkin)。

选项的选择并不重要。 因为如果您一开始就了解如何监控系统并写下计划，那么您就可以开始选择适合您要求的工具。 问题是您首先选择监视什么。 因为也许你一开始选择的工具根本不符合你的要求。

最近随处可见的几个技术点：

Prometheus 被推入 Kubernetes - 谁想出了这个？！ 如果您的集群崩溃了，您会做什么？ 如果内部有一个复杂的集群，那么集群内部应该有某种监控系统，外部也应该有一些监控系统，它们将从集群内部收集数据。

在集群内部，我们收集日志和其他所有内容。 但监控系统必须在外面。 通常，在内部安装了 Promtheus 的集群中，还有对站点运行进行外部检查的系统。 如果您与外界的连接中断并且应用程序无法运行怎么办？ 事实证明，内部一切都很好，但这并没有让用户的事情变得更容易。

发现

• 监控开发不是实用程序的安装，而是软件产品的开发。 如今 98% 的监控都是编码。 在服务中编码，对外部检查进行编码，检查外部服务，仅此而已。
• 不要将开发人员的时间浪费在监控上：这可能会占用他们 30% 的工作量，但这是值得的。
• DevOps，不要担心你无法监控某些东西，因为有些东西是完全不同的思维方式。 你不是程序员，监控工作正是他们的工作。
• 如果项目已经在运行并且不受监控（并且您是经理），请分配资源进行监控。
• 如果产品已经投入生产，并且您是一名开发人员，被告知“设置监控” - 尝试向管理层解释我写的所有内容。

这是 Saint Highload++ 会议报告的扩展版本。

如果您对我对此以及相关主题的想法和想法感兴趣，那么在这里您可以 阅读频道 🙂

来源： habr.com