作者：夏明，阿里云-云原生可观测团队
在软件开发早期，单体应用架构因其结构简单，便于测试和部署，得到了广泛的应用，对应的监控诊断技术主要是基于日志和日志关键词的指标监控。随着软件复杂度的不断提升，单体应用架构逐步向分布式和微服务的架构演进，整体的调用环境也越来越复杂，仅靠日志和指标渐渐难以快速定位复杂环境下的问题。
因此，链路追踪技术应运而生。但早期的链路追踪技术和日志指标的结合比较简单，更多的是在应用层以APM软件的形式存在。
随着云计算和云原生理念的普及，从业务层到应用层，容器和基础设施之间的边界不断地被打破，研发、运维、安全等工种的职责也不断模糊，因此对于全栈可观测的诉求也变得越越强烈，Traces、Metrics和Logs的连接也愈发紧密。
典型的云原生架构往往是混合云的形态，出于安全或容灾等方面的考虑，可能会将一部分应用部署在公有云，另一部分部署在自建机房。而出于软件研发效率和性能的考虑，不同的应用又可能采用多种开发语言，因此可观测诉求可以被归纳为以下四点：
• 全栈立体化统一监控与告警：比如可以将业务层的交易量、支付量的业务指标和应用黄金3指标、基础设施的CPU利用率以及网络情况，放在一张大盘上做总体监控，这也是大促期间较为常用的方式；
• 前后端/多语言全链路追踪：用户请求从端上发起，一直到网关，再到后端的应用和云组件之间调用轨迹的追踪，可以快速定位用户请求在哪里有异常；
• 跨云数据统一可视化：将不同类型的数据、不同环境的数据进行统一可视化，需要有较强的可视化组件；
• 开源格式数据二次加工：出于业务自定义的需求，需要有二次加工与分析。如果能够基于开源的数据格式标准，很多工作实施起将会比较轻松，也可以复用很多现有的东西。
而传统的监控诊断平台往往存在以下几个痛点：
• 很多埋点插桩由用户自己实现，这种闭源实现会导致数据格式不统一，而且埋点在各个系统之间很难复用，接入成本非常高；
• Metrics指标孤立地分散在各个监控的子系统，比如有的在网络，有的在应用，有的在容器。排查全链路问题时，对开发使用人员的经验要求非常高，且效率非常低；
• Traces会由于埋点覆盖度不够或协议不统一而无法串联，导致经常出现断连；
• 日志或链路数据的明细数据全量上报到服务端，也会带非常高的成本，而且查询率较低，还会引发热点的性能瓶颈；
• 自建控制台的前端开发成本高，开发周期长，灵活性较差，很难跟上业务迭代的效率；
• 各个系统的可观测数据之间缺乏统一的标签管理，关联性较差，很难做综合性的分析。
接下篇：
https://developer.aliyun.com/article/1223028?groupCode=alisoftwaretech
