接上篇：
https://developer.aliyun.com/article/1223030?spm=a2c6h.13148508.setting.29.4f394f0em1x0Jq
为了解决上述问题，我们在生产环境中逐渐沉淀下较为可行的方案，即基于OPLG建设统一可观测平台。此方案主要有以下几点优势：
• 开源开放：全开源技术栈，借助社区共建合力，比如可以借助OpenTelemetry的Traces埋点，Prometheus指标的Metrics Exporters，无需过多开发，即可保障大部分通用组件数据的采集生成上报，降低了接入成本；
• 统一目标：开源且基于统一的一套规范，可以很轻松地实现内部各个子系统甚至是和外部三方系统之间的打通和关联分析；
• 自由灵活：基于OPLG特别是Grafana一些比较好的设计，可以非常灵活地组织可观测数据，能够灵活地定制每一个场景下需要的大盘图表，满足自定义的需求；
• 边缘计算：基于OpeTelemetry Collector技术，可以将数据处理“左移”到用户集群内。通过边缘计算的技术，能够提前提炼数据价值，并将提炼好的数据再发送到服务端，降低公网传输的成本以及服务端的存储成本。
OPLG主要由以下四个模块构成：
• 端侧数据生成与上报：通过OpenTelemetry完成Traces数据的生成，通过Prometheus完成指标类的数据，通过Loki的方式完成日志采用；
• 边缘侧数据统一处理与路由：所有数据采集完成之后，可以通过OpenTelemetry Collector完成数据统一的边缘处理和路由转发；
• 全托管服务端：能够提供更好的性能和更稳定的服务，而且不会绑定技术栈，迁移的自由度和灵活度高；
• 统一可视化：可以通过Grafana完成统一的自定义灵活监控，也可以采用云服务商比如ARMS在特定的精细化交互场景提供精细化的交互大盘，提高查询体验。此外，如若有自己的需求，也可以通过开源的数据格式或开放的OpenAPI建设自己的控制台。
OpenTelemetry Collector首先会完成统一的数据采集，任何数据类型都可以进行数据采集，然后做通用的处理，比如格式化、数据的标签打标，还可以进行一些指标的预聚合动作，最常见的比如调用链，可以根据service IP等粒度先将数据聚合再进行采样，可以保证指标的精准度，而且上传到服务端也可以降低成本。
OpenTelemetry Collector还可提供本地存储的能力，可以将一部分最近的数据先临时缓存，然后进行比如最近10分钟的全量查询、错慢全采等，可以更好地利用边缘的存储能力。
针对处理好的数据，OpenTelemetry Collector提供了非常灵活的转发方式，可以支持不同的协议，比如Prometheus协议、OTLP协议等，也可以支持多数据源的转发，可以发送到云服务端，也可以转存到边缘存储，更加灵活。
基于ARMS的托管服务端针对海量的数据场景做了很多查询性能优化加速的技术，比如通过算子下推的方式，在70%以上的场景下查询性能相对于开源提升了10倍以上；而针对7-10天等的长周期查询，通过降采样技术又进一步地提升了一个数量级的查询性能；针对URL等发散维度，通过自动收敛的技术很好地解决了热点导致的查询卡顿问题；针对链路数据，做了对应用和Traces ID两级的路由扫描，针对链路查询的使用特征做了相应的优化。
除了海量数据的查询性能优化外，我们在HA侧也做了体系化的建设，比如默认支持全球部署、多可用区的容灾，避免了单个region或AZ不可用的风险；其次业务经常会遇到突发的流量或用户快速增长，如果是自建机房则需要考虑容量问题，而使用ARMS可以根据流量自适应地做扩充，无需担心突发流量带来的性能瓶颈；极端情况下，也可以通过动态配置下推或自动流控降级保障核心功能的可用性；最后，提供了全链路SLA监控和预警的建设，有7*24小时的应急响应，可及时发现可用性问题并快速恢复。
此外，基于Grafana+ARMS提供了灵活、精细的可视化体验。
Grafana丰富的仪表盘插件和广泛的数据源支持，可以将各种数据都集成在一个大盘里。而且通过PromQL、LogQL等灵活的查询语法，不需要前端介入。后端的研发，测试，SRE等可以通过低代码的形式快速构建自己的场景大盘，提升可观测的效率。
得益于Grafana的开源属性，如果想从自建机房迁移到云上，或在云之间互相迁移，整个可视化平台都能够通过JSON文件或其他方式快速拷贝，轻松完成端到端的迁移，不会被特定的厂商强绑定。
但是Grafana也存在缺陷，比如它在交互场景的体验不够好，因此ARMS在调用链的关联分析、在线诊断、配置管理等强交互的场景提供了更精细化的交互页面。ARMS还会进一步增强Grafana的图表插件，提供新的图表插件以提升托管版Grafana的可视化能力。
