处理复杂依赖项时监视和警报数据问题的方法

Question

在这个假设的例子中，我们有一个跨电子商务公司的多个工程团队的数据流。这些团队在流程的不同点交付服务、生成数据和使用数据。

例如；

• “'Team”维护订单数据库和接口
• “团队流量”生成网络流量数据
• ‘'Team’维护数据仓库
• “团队流量”依赖于“Team”服务来检索订单数据并将其与web流量相关联
• “Team Warehouse”依赖于“团队流量数据构建DW表”

想象一下，“Team”会碰到db问题(load，延迟等等)--他们的监控系统会提醒一个工程师，他会开始调查db问题。

与此同时，“团队交通部”也收到了警告，因为他们看到了糟糕反应的激增。他们开始调查，并迅速意识到问题是‘团队订单的服务，并提出了一张罚单’团队秩序‘

在所有这些数据的下游，“Team”正在接收不良数据。他们的DW监控提醒他们注意这一差异，因此他们开始寻找根本原因。

问题是，我们现在至少有三名工程师在调查同一个问题，他们甚至可能不知道其他团队在做同样的事情。

重要的一点是，这三个团队都在使用不同的监视和警报系统；teams正在监视db服务器问题，而teams则在寻找记录计数中的差异。

还有其他方法:仅在管道顶部发出警报(阻止下游升级)，或在管道底部报警上游系统。

是否有任何最佳实践，白皮书或工程解决方案，我可以研究，以了解不同的方式警告和升级数据问题跨多个英语/支持小组？

Answer 1

强烈推荐云系统管理的实践，详细介绍其中的一些内容。这里我们有三个级别的监控

1. 一分为二(哦，废话，出了点问题)
2. 每个服务/ API (噢，SQL集群的糟糕成员被关闭了，API响应缓慢，或者使用200/300 HTTP代码以外的其他东西)
3. APM -什么代码等是慢的，错误率为特定的服务等。

这些日志给了我们大部分我们需要知道发生了什么的东西，一般来说，我们只有一个人负责确保问题是固定的--协调修复，但是他们不做技术工作，这是给别人的。协调者的工作是确保我们不会踩到对方的脚尖来解决问题。