系统越复杂，随着各种警报的增长就越多。 并且需要响应这些非常警报，将它们汇总并可视化。 我认为许多人在紧张之前就已经熟悉了这种情况。
讨论的决定并不是最意外的，但是搜索并没有得出有关该主题的完整文章。
因此，我决定分享FunCorp的经验，并讨论如何建立值班流程，谁在打电话，为什么以及如何看待这一切。
什么是PagerDuty？
因此，为了解决所有这些问题，我们开始寻找一种方便的工具。 经过短暂搜索，我们选择了PagerDuty。 PD对我们来说似乎是一个相当完整和简洁的解决方案，具有许多集成和设置。 她是什么样的人？
简而言之，PagerDuty是一个事件处理平台，可以通过各种集成来处理传入的事件，调整值班顺序，然后根据事件的级别来警告值班工程师（高级别-呼叫，低级别-来自应用程序/ SMS的推送） 。
谁是值班人员？
这可能是开始设置PD的第一件事。
与其他公司一样，FunCorp在职务上也享有荣誉职位。 它每天在工程师之间传输一次。 对PagerDuty的警报有所谓的第一和第二响应行。 假设到达高优先级警报，并且如果从第一行打给服务员的呼叫后10分钟没有对他的反应（即他没有转移到确认或已解决的状态），则呼叫转到第二位值班工程师。 这是通过升级策略在PagerDuty本身中配置的。
如果第二个服务员没有响应，则通知会返回给
主要服务员。
因此，任何传入的高优先级警报都无法保持未处理状态。
现在，让我们看看事件可能来自何处。
我们使用什么集成？
来自各种服务的许多各种事件被注入PD。 现在，我们大约有25种这样的服务，对于它们的处理，我们使用一些现成的集成。
主要的指标收集系统是Prometheus。 关于Habré的文章很多，我只是说我们有几种针对不同环境的工具：一种是从虚拟机和docker收集指标，另一种是从Amazon服务收集指标，第三种是从“铁器”收集信息。 Telegraf主要用作度量标准的导出器。
在这里，我也认为名字很清楚。 此集成用于从在表冠上执行的某些脚本发送通知。 PD给您发送信件的特定地址。 使用这种集成创建服务时，您可以设置优先级，以什么顺序处理传入事件，如何创建警报（对于每个传入字母，一个传入字母+某个规则等）。
我认为这是一个非常有趣的整合。 有时会发生某些事情，但事件并未涵盖。 因此，我们添加了Slack的集成来创建事件。 也就是说，在公司Slack中，您可以编写
/ calloftyty，一切都会变慢，很快就会崩溃 ，PD会对此进行处理并将事件发送给值班工程师。
我们做：
我们看到：
HTTP集成。 实际上，这里没有什么特别有趣的，只是带有JSON格式主体的POST请求。 例如，从一个有趣的例子开始：我们使用
https://www.statuscake.com/将它用于外部监视。 这项服务会检查我们在世界各地的站点的可用性。 在我们收到不可接受的响应代码（例如502）的情况下，将创建一个事件，然后一切都沿着上述链条进行。 StatusCake本身具有监视内部URL，SSL证书或域到期的能力。
这是另一个监视系统，有关更多信息，请参
见其网站
https://www.librenms.org/ 。 借助其帮助，我们可以从服务器监视网络接口和iDRAC。
也有诸如Datadog，CloudWatch之类的集成。 关于它们的更多信息可以在
这里找到。
可视化
主要的事件报告系统是Slack。 所有进入PD的事件都将写入一个特殊的聊天中，并且如果它们的状态发生变化，该事件也会显示在聊天中。
当可以在天花板下的显示器的屏幕上显示有用的数据时，我们突然意识到我们（在devops部门中）没有任何可显示的内容。 有一个很棒的Grafana，但是无法覆盖，员工会响应警报，而不是图表。
在GitHub上进行了全面但不成功的搜索后，找到了PD的简明扼要的“公告板”，我们决定编写自己的文件-仅使用所需的内容。 尽管起初有一种显示PD接口本身的想法，但看起来更加不便。
要编写它，您所需要做的就是获得具有只读权限的PD密钥。
这是我们得到的：
屏幕显示当前的未解决事件，所选计划中的现任值班工程师的姓名以及没有高优先级事件的时间（具有高优先级事件的面板将以红色突出显示）。
请在此处查看此实现的源代码 。
结果，我们有了一个方便的仪表板来查看所有事件。 如果您能从我们的经验中受益，我将感到非常高兴。