滴滴可观测架构演进与可观测性实践

如何获得讲师PPT：

扫码关注公众号，后台回复「1026」即可获得讲师PPT哟～

还能一键订阅后续精彩活动内容～

Q&A环节答疑：

滴滴是否有专门的技术团队去维护可观测架构？ Prometheus 的横向扩展能力相对有限。influxdb具有有哪些问题？

滴滴像可观测架构，是我这边负责，有专门团队做架构。Prometheus横向扩展能力有限，当时有用其他技术去支持扩展能力，扩展Prometheus单机的相关能力。设计定位如此，不算缺点。influxdb问题在于，服务指标存很多曲线或tag较多，查询时召回的曲线非常多，数据相时极可能发生OM，单机处理能力有限。该查询可能是导致OM的主要问题，还有其他问题，如每天八点持续查询等。

不发通知怎么知道这个告警中断了？

简单来说，产生报警策略会生成内部事件，是否发送短信或IM通知由内部逻辑决定。相同机器一分钟前已发送通知，无需再次发送，避免短信或IM通知轰炸。当事件源源不断产生时，可判断整个端是否通畅。

Prometheus是单独部署么？与业务服务器隔离么？

我们没有去部署Prometheus，而是使用了victoriametrics 这样一个开源模块来实现。

如何及时发现未被监控的指标项，避免未被观测的指标突变引发故障？

现在业界有两种做法，大家可以参考一下。第一种是尽可能监控或覆盖所有指标。有人认为覆盖率越高越好。另一种是在所有指标中，针对服务角度，选择更能代表服务健康或性能的指标。这是两种不同的解决思路。要实现及时发现，可以关注覆盖率问题。对于一些通用指标，如端口检查或炭火检查要求，都要监控和配置报警。这样就可以有一个治理的目标，可以使用一些手段去扫描和计算。

如何去度量一个架构的可观测性？有什么建议吗？

如果实现了共性，比如系统可以从外部观察内部状态，就达到了目标。这是最简单的度量方式，但不一定是量化的，比如达到某一条并不一定意味着百分之百。

APP性能监控用的是同一套吗？

对的。但我们会采用不同的采集方式来收集各种指标，比如通过SDK或agent来进行采集，这些方法因指标类型而异。

metric的时效性有必要做到秒级吗？

不同的团队和场景有不同的应用，有些场景需要实现秒级处理，但也可以与业务协商，例如，虽然可以实现秒级处理，但成本相对较高，因此需要根据不同场景进行区分。

移动端监控是怎么做的呢？

移动端监控有专门团队负责，除了上报数据，我们使用A技术采集基础指标，EBF在我们这边也有应用，但目前没有采集指标类数据，后续会有相关计划。

老师好，接口偶发性超时，调用链只能看到超时接口名称，看不到内部方法，无法定位根因，也难以复现，怎么办？

你可以尝试使用EBF进行持续采集。这个过程属于排障阶段。如果使用metrics采集，因为其抽象程度较高，可能在整个过程中不会有太大帮助，所以可以尝试使用 EBF 尝试一下。

滴滴的可观测性平台包含哪些能力？基础监控、日志、巡检、告警、trace分析、性能分析？

我们的应用和产品比较多，体量也比较大，这些都包含的。

滴滴的可观测性平台有和混沌平台打通做一些事嘛？

目前还没有明确的计划。

滴滴的可观测性看板是自己画的还是引用的grafana？如果自己画可观测性看板的话，人力投入怎样呢？

我们有自己看板的产品。然后还有一些同学会比较喜欢用grafana。我们基于我们这个存储给用户开放了一些grafana的能力。这两个可以说同时在使用。

时序数据库适合存储不允许丢的数据吗？

具体要看场景和数据情况，如果数据不允许丢失，可能需要使用实际税库并采取双副本等措施。通常情况下，我们认为可观测性的数据是可以丢失的，因为我们需要的是最新的数据，对于历史数据，如果出现故障或其他问题，是可以丢失的。当然，具体场景需要具体分析。