可观测平台：滴滴可观测性的实现

可观测性（Observability）是近年来备受关注的话题。那什么是可观测性？别急，让我们先从一个常见的场景开始：

你是一个一线开发同学，在某天上班路上收到了一个电话报警，提示某个接口的错误数超过了阈值 30。得益于公司监控团队做的所谓 chatops，几经周折后，你终于在 IM 中打开了对应的监控图表，发现当前的错误数似乎比之前多了一些。

作为服务开发者的你，昨天晚上部署了一个新版本，并且依赖的服务好像也做了变更。你开始猜测这个报警是否与你昨晚的上线有关，但怎么也回忆不起来昨晚依赖服务的变更内容了。

你的组长打电话过来询问报警的情况。搞不清状况的你只能回答”我需要看一下”。你打开电脑连上热点并登录上了机器，tail -f xxx.log | grep -E 'error|timeout|code=9527'。一通猛如虎的操作，你发现了问题所在，是你依赖的另一个服务延迟过高导致。和你的上线无关，和昨晚变更的依赖服务也无关。

上述这个场景，很多同学都遇到过。我们从中会发现一些问题：

• 缺乏进一步分解和深入分析的能力：得到监控产出的图表后，无法进行进一步的分解，我们不得不跳出当前上下文，使用如 tail、grep、tcpdump、strace 等工具进行问题追查。

• 复杂的微服务架构难以定位问题来源：因为复杂的微服务架构，无法确定问题源自哪里，是服务自身还是依赖的服务出现问题。

• 难以确定合理的报警规则：