自2008年以来，我们公司主要从事网络项目的基础架构管理和全天候技术支持：我们有400多个客户，约占俄罗斯电子商务的15％。 因此，支持非常多样化的架构。 如果有问题，我们必须在15分钟内修复。 但是为了了解发生了事故，您需要监视项目并响应事件。 怎么做？
我认为正确的监控系统的组织存在麻烦。 如果没有问题，那么我的演讲包括一个论点：“请安装Prometheus + Grafana以及插件1，2，3。” 不幸的是，这现在不起作用。 主要的问题是，就软件组件而言，每个人都继续相信2008年存在的某些东西。
关于监控系统的组织，我冒昧地说……不存在具有有效监控能力的项目。 如果事情跌落，情况就很糟糕，有可能被人们忽视的风险-每个人都可以确保“所有事情都受到监视”。
也许一切都在监视之中。 但是如何？
我们所有人都遇到了一个类似于以下的故事：某个开发人员，某个管理员正在工作，一个开发团队来找他们，并说：“我们已经掌握了，现在受到监视。” 什么显示器？ 如何运作？
好啦 我们监视老式的方式。 但是它已经在改变，事实证明您监视了服务A，该服务变成了服务B，并与服务C交互。但是开发团队对您说：“安装软件，它必须监视所有内容！”
那么，发生了什么变化？ -一切都变了！
2008年。 一切都很好
有几个开发人员，一个服务器，一个数据库服务器。 从这里开始。 我们有一些INFA，我们放了zabbix，Nagios，仙人掌。 然后，我们在CPU，磁盘操作，磁盘位置上设置清晰的警报。 我们还进行了一些手动检查，以确保该站点回答订单已进入数据库。 就是这样-我们或多或少受到保护。
如果我们比较管理员为确保监控所做的工作量，那么它是98％自动的：被监控的人应该了解如何安装Zabbix，如何配置它和配置警报。 还有2％-用于外部检查：网站响应并向数据库发出新订单到达的请求。
2010年。 负载在增长
我们开始扩展网络，添加搜索引擎。 我们要确保产品目录包含所有产品。 并且该产品搜索有效。 数据库正常工作，正在下达订单，站点在外部进行响应并且正在从两台服务器进行响应，并且用户在重新平衡到另一台服务器时未将其扔出站点，等等。 有更多实体。
此外，与基础架构相关的实体在经理的脑海中仍然是最大的实体。 仍然有一个想法在我的脑海中，即正在监视的人是将安装zabbix并能够对其进行配置的人。
但是同时，还进行外部检查，创建一组查询查询索引器的脚本，一组用于验证索引编制过程中搜索是否发生变化的脚本，一组用于验证货物是否已转移到交货服务的脚本等工作。 等
注意：我写了3次“脚本集”。 也就是说，负责监视的人不再是仅安装zabbix的人。 这是开始编码的人。 但是，团队的想法尚未改变。
但是世界在变化，变得越来越复杂。 虚拟化层，添加了几个新系统。 他们开始互相交流。 谁说“微服务小贴士”？ 但是每个服务仍然看起来像一个站点。 我们可以求助于他，并了解他会提供必要的信息并自己工作。 如果您是一位经常从事5-7-10年开发项目的管理员，那么您已经积累了这些知识：出现了一个新的级别-您意识到了，出现了另一个级别-您意识到了...
但是很少有人陪伴这个项目十年。
人监控摘要
假设您来到一家新的初创公司，该公司立即为20名开发人员评分，编写了15种微服务，而您的管理员则被告知：“构建CI / CD。 请。 您制作了CI / CD后，突然听到：“在不了解应用程序如何在其中工作的情况下，我们很难在“多维数据集”中进行生产。 使我们在同一“多维数据集”中成为沙箱。
您在此多维数据集中创建一个沙箱。 他们立即告诉您：“我们想要一个舞台数据库，该数据库每天都会从生产中进行更新，以了解它可以在数据库上运行，但同时又不会破坏生产数据库。”
你活在这一切中。 他们对您说，离发布还有2周的时间：“现在将全部监视...” 监视群集基础结构，监视微服务体系结构，监视与外部服务的工作...
同事们脑子里冒出了这样一个熟悉的计划，说：“所以这里一切都清楚了！ 安装一个监视所有程序的程序。” 是：Prometheus + Grafana +插件。
他们同时补充道：“您有两周的时间，请确保所有内容都是可靠的。”
在我们看到的大量项目中，分配了一个人进行监视。 想象一下，我们想雇用一个人进行2周的监视，然后我们将给他写简历。 鉴于我们之前所说的一切，此人应具备什么技能？
- 他必须了解铁基础设施工作的监控和细节。
- 他必须了解监视Kubernetes的细节（每个人都希望有一个“多维数据集”，因为您可以忽略一切，隐藏起来，因为管理员会弄清楚它）-本身就是其基础结构，并了解如何监视内部的应用程序。
- 他必须了解服务以特殊方式相互通信，并且必须了解服务之间的交互作用的细节。 看到一个项目中某些服务同步通信是很现实的，因为没有其他方法。 例如，后端在REST上，在gRPC上进入目录服务，接收商品清单并返回。 您不能在这里等。 与其他服务一起，它可以异步工作。 将订单转移到送货服务，发送信件等
您可能已经摆脱了这一切？ 需要监控此问题的管理员游得更多。 - 随着工作变得越来越多，他必须能够正确地计划和计划。
- 因此，他必须从创建的服务创建策略，以了解如何专门监视它。 他需要了解项目的架构及其开发，还需要了解开发中使用的技术。
让我们回顾一个绝对正常的情况：php中的一部分服务，Go中的一部分服务，JS中的一部分服务。 他们以某种方式在彼此之间工作。 这就是“微服务”一词的来历：有太多单独的系统，开发人员无法理解整个项目。 团队的一部分使用JS编写服务，这些服务是自己工作的，不知道系统其余部分的工作方式。 另一部分使用Python编写服务，并且不影响其他服务的工作方式，它们在各自的领域中是孤立的。 第三-用php或其他方式编写服务。
所有这20个人都分为15个服务，只有一位管理员应该了解所有这些内容。 别说了 我们将系统分为15个微服务，因为20个人无法理解整个系统。
但是需要以某种方式进行监视...
结果如何？ 结果，一个人包含了整个开发人员团队无法理解的一切，但他还必须知道并且能够做到我们上面指出的内容-铁基础设施，Kubernetes基础设施等。
我能说什么...休斯顿，我们有问题。
监视现代软件项目本身就是一个软件项目
由于错误地认为监视是软件，所以我们相信奇迹。 但是，奇迹并没有发生。 您无法安装zabbix并等待一切正常。 放上Grafana并希望一切都会好起来是没有道理的。 大多数时间将花在组织检查服务的运行以及它们之间的交互，检查外部系统的工作方式。 实际上，90％的时间将不花在编写脚本上，而是花在软件开发上。 它应该是一个了解项目工作的团队。
如果在这种情况下将一个人投入监视，那么将会发生麻烦。 随处可见。
例如，有几种服务可以通过Kafka相互通信。 接到订单后，我们向Kafka发送了有关该订单的消息。 有一项服务可以侦听有关订单的信息并进行货物运输。 有一种服务可以侦听有关订单的信息，并向用户发送一封信。 然后仍然有很多服务，我们开始感到困惑。
而且，如果您仍在发布前短时间内将其交给管理员和开发人员，那么人们将需要了解整个协议。 即 如此规模的项目需要花费大量时间，因此应将其纳入系统开发中。
但是在很多情况下，尤其是在启动过程中，尤其是在刻录过程中，我们看到了如何推迟监视直到后来。 “现在我们将进行概念验证，我们将从它开始，让它掉下来-我们准备牺牲。 然后我们将监视所有情况。” 当（或如果）该项目开始赚钱时，企业希望削减更多功能-因为它开始工作了，所以您需要走得更远！ 在开始时，您需要监视以前的所有内容，这不会花费1％的时间，而是需要更多的时间。 顺便说一句，开发人员将需要监视，并且更容易将其添加到新功能中。 结果，编写了新功能，所有内容都被打包，您陷入了无休止的僵局。
那么，从一开始就如何监视项目，如果有需要监视的项目却又不知道从哪里开始怎么办？
首先，您需要计划。
抒情离题：通常从监视基础结构开始。 例如，我们有Kubernetes。 首先，我们将Prometheus与Grafana结合在一起，将插件置于“多维数据集”的监视之下。 不仅开发人员，而且管理员也都有不幸的习惯：“我们将安装此插件，并且该插件可能知道如何执行此操作。” 人们喜欢从简单易懂的动作开始，而不是从重要的动作开始。 而且监视基础架构很容易。首先，确定要监视的内容和方式，然后拿起乐器，因为其他人无法为您考虑。 是的，应该吗？ 其他人对通用系统进行了思考，或者在编写此插件时根本没有考虑。 这个插件有5000名用户的事实并不意味着它带来任何好处。 也许您会成为5001st的原因仅仅是因为那里已经有5,000人。
如果您开始监视基础结构，并且应用程序的后端停止响应，则所有用户都将失去与移动应用程序的联系。 一个错误会消失。 他们会来找您，说：“该应用程序无法运行，您在这里做什么？” “我们正在监视。” -“如果没有看到应用程序无法运行，您如何监控？！”
- 我认为有必要从用户的入口点开始监视。 如果用户没有看到应用程序正在运行-就是这样，那就是失败。 监视系统应首先对此发出警告。
- 只有这样，我们才能监视基础架构。 或并行执行。 基础架构更简单-在这里我们终于可以安装zabbix。
- 现在，您需要进入应用程序的根目录，以了解哪些地方不起作用。
我的主要思想是监视应与开发过程并行进行。 如果您让监视团队执行其他任务（创建CI / CD，沙箱，重组基础结构），则监视将开始滞后，您可能永远无法跟上开发的步伐（或早或晚必须停止开发）。
全部按级别
这就是我看到监视系统的组织的方式。
1）应用级别：
- 监视应用程序的业务逻辑；
- 监控服务的健康指标；
- 集成监控。
2）基础架构级别：
3）再次是应用程序级别-但作为工程产品：
4）警报：
- 组织预警系统；
- 监视系统的组织；
- 组织“知识库”和工作流事件处理。
重要提示 ：我们不是立即而是立即发出警报！ 不必开始监视，也不必“稍后”考虑谁将收到警报。 毕竟，监视任务是什么：了解系统中哪些地方不起作用，并让合适的人知道。 如果放任不管，那么正确的人只会发现“出了什么问题”，这才发现问题出在哪里。
应用层-监控业务逻辑
在这里，我们谈论的是检查应用程序对用户有效的事实。
此级别应在设计阶段完成。 例如，我们有条件的Prometheus：它爬到进行检查的服务器，拉出端点，然后端点去检查API。
当经常被要求监视主页以确保站点正常工作时，程序员会给您一支钢笔，每次您需要确保该API正常工作时都可以拉它。 并且程序员此时仍然需要编写/ api / test / helloworld
确保一切正常的唯一方法？ -不！
- 创建此类检查实质上是开发人员的任务。 单元测试应该由编写代码的程序员编写。 因为如果将其合并到管理员“ Dude，这是所有25个功能的API协议列表，请监视所有内容！” -什么都行不通。
- 如果您打印“ hello world”，那么没人会知道该API应该并且确实有效。 对API的每次更改都会导致检查内容的更改。
- 如果您已经遭受了这样的灾难，请停止功能，然后选择开发人员来编写这些检查，或者与损失和解，协调并确保所有检查都不会失败。
技术提示：
- 确保组织一个用于组织检查的外部服务器-您必须确保您的项目可以被外界访问。
- 跨整个API协议组织验证，而不仅仅是各个端点。
- 用测试结果创建一个普罗米修斯端点。
应用程序级别-健康指标监控
现在，我们在谈论服务的外部健康指标。
我们决定使用从外部监视系统调用的外部检查来监视应用程序的所有“笔”。 但是，这些恰恰是用户“看到”的“笔”。 我们希望确保服务本身对我们有用。 这是一个更好的故事：K8s具有运行状况检查，因此至少多维数据集可确保该服务正常运行。 但是我所见的支票有一半是相同的印刷品“ hello world”。 即 在部署之后，他在这里拉过一次，他回答他一切都很好-就是这样。 而且，如果服务使用自己的API，则该服务具有相同API的大量入口点，也需要对其进行监视，因为我们想知道它是有效的。 而且我们已经在监视它了。
如何从技术上正确地实现它：每个服务都设置了有关其当前性能的端点，并且在Grafana（或任何其他应用程序）的图中，我们看到了所有服务的状态。
- 对API的每次更改都会导致检查内容的更改。
- 立即使用运行状况指标创建新服务。
- 管理员可以与开发人员联系，并要求“向我添加一些功能，以便我了解所有内容并将有关此信息添加到我的监视系统中”。 但是开发人员通常会回答：“我们不会在发布前两周添加任何内容。”
让开发经理知道会有这样的损失，让开发经理的老板也知道。 因为当一切都崩溃时，仍然有人会打电话要求监控“不断下降的服务”（c） - 顺便说一句，选择开发人员为Grafana编写插件-这将为管理员提供很好的帮助。
应用层-集成监控
集成监视专注于监视关键业务系统之间的通信。
例如，有15个彼此通信的服务。 这些不再是单个站点。 即 我们无法单靠拉服务，获取/ helloworld并了解该服务正在运行。 因为用于下订单的Web服务必须将有关订单的信息发送到总线，所以仓库服务应该从总线接收此消息并进一步处理。 电子邮件分发服务应进一步处理此问题，依此类推。
相应地，我们在拨动每项服务时都无法理解这一切都是可行的。 因为我们有一条特定的总线，所有事物都通过该总线进行通信和交互。
因此，此阶段应指示测试服务以与其他服务进行交互的阶段。 监视了消息代理后，您将无法组织通信监视。 如果有发布数据的服务和接收数据的服务，那么在监视代理程序时，我们将仅看到往返飞行的数据。 即使我们设法以某种方式监视了内部数据的交互-一些生产者发布了数据，有人读取了该数据，该流继续进入Kafka-如果一项服务在一个版本中提供了消息，它仍然不会提供信息，但是另一个服务没有该版本，因此跳过了该版本。 我们不会发现这一点，因为服务会告诉我们一切正常。
正如我建议做的那样：
- 对于同步通信：端点执行对相关服务的请求。 即 我们使用该端点，将脚本拉入服务内部，脚本指向所有内容，并说“我可以拉到那里，然后拉到那里，我可以拉到……”
- 对于异步通信：传入消息-端点检查总线上的测试消息并显示处理状态。
- 对于异步通信：传出消息-端点将测试消息发送到总线。
通常会发生这样的情况：我们有一项服务可将数据发送到总线上。 我们来到这项服务，并请您谈谈其集成状况。 而且，如果该服务需要在其他地方（WebApp）出售一些消息，则它将生成此测试消息。 如果我们在OrderProcessing端拉服务，它首先发布它可以独立发布的内容，如果有任何依赖的东西，则它从总线读取一组测试消息，了解它可以处理它们，报告并，如有必要，将其进一步发布，关于此，他说-一切正常，我还活着。
我们经常听到一个问题：“我们如何才能在战斗数据上对此进行测试？” 例如，我们正在谈论相同的订单服务。 订单将消息发送到注销货物的仓库：我们无法在作战数据上对此进行测试，因为“我的货物将被注销！” 退出：在初始阶段，计划整个测试。 您有做模拟的单元测试。 因此，请在更深层次上进行操作，您将拥有一个不会损害业务的沟通渠道。
基础设施级别
基础架构监视是长期以来一直被视为监视自身的工具。
- 基础结构监视可以并且应该作为单独的过程启动。
- 即使您确实愿意，也不应从监视正在运行的项目的基础结构开始。 这对所有开发者来说都是一个痛处。 “首先，我监视集群，然后监视基础架构”-即 首先，它将监视下面的内容，但不会爬入应用程序。 因为对于devopa来说，应用程序是一件不可理解的事情。 他们把它泄漏给他，他不知道它是如何工作的。 他了解基础架构并从此开始。 但是，不，您始终需要首先监视应用程序。
- . , , - . on-call, , « ». .
-
:
- ELK. . - , .
- APM. APM (NewRelic, BlackFire, Datadog). , - , .
- Tracing. , . , tracing — . – ! . Jaeger/Zipkin
- : . Grafana. PagerDuty. (, …). ,
- : ( , ). Oncall : , , , — ( — , : , ). , — (« — »), .
- « » workflow : , , . , — ; .
, :
- — Prometheus + Grafana;
- — ELK;
- APM Tracing — Jaeger (Zipkin).
. , , , . , . , , , — .
, :
Prometheus Kubernetes — ?! , ? , , — , .
. . , Promtheus, , , . ? , , .
结论
- — , . 98% — . , , , --.
- : 30% , .
- , , - , — . , — .
- ( ) — .
- , , « » — , .
Saint Highload++.UPD ( ):
1. , , , «, , , ». , : DevOps , — , , , .
2.他们说，我并不是要暗示，“到处都不好，但是我们可以在这里进行监视-来到ITSumma。” 否，如果启动了该项目，则不能由第三方公司进行监视。当然，我们也有业务目标，我们真正想做的是引入咨询以在项目的开发过程中为其提供支持，以传达如何正确进行开发的监视部分。如果您对我的想法和想法等等感兴趣，那么可以
阅读 :-)