共计 3642 个字符，预计需要花费 10 分钟才能阅读完成。
简介：OPLG 体系领有成熟且富裕生机的开源社区生态，同时也通过了大量企业生产环境的实际测验，是当下建设新一代云原生对立可观测平台的热门抉择。然而，OPLG 只是提供了一个技术体系，如何灵活运用，解决理论问题，积淀出通用行业或场景的最佳实际，还须要大家一起来摸索。
作者：夏明（涯海）
OPLG 是什么
随着云原生架构的衰亡，可观测的边界与分工被从新定义，传统的容器 / 利用 / 业务分层监控边界被突破，Dev、Ops、Sec 的分工逐步含糊。大家意识到 IT 零碎作为一个有机的整体，对 IT 零碎状态的监测与诊断也须要一体化的计划。通过近几年的摸索与实际，基于 OPLG 的新一代云原生可观测体系，逐渐成为了社区与企业的热门抉择。
OPLG 是指将 (O)penTelemetry Traces、(P)rometheus Metrics、(L)oki Logs 通过 (G)rafana Dashboards 进行对立展现，满足企业级监控与剖析的大部分场景，如下图所示（图片来源于 Youtobe Grafana Labs）。基于 OPLG 体系能够疾速构建一套笼罩云原生利用全栈的对立可观测平台，全面监测基础设施、容器、中间件、利用及终端用户体验，将链路、指标、日志、事件有机整合，更高效的达成稳定性运维与商业化剖析指标。
OPLG 自建计划
小明退出了一家潮牌买手公司，专门帮忙年轻人寻找优质潮牌好货。随着业务规模的不断扩大，零碎稳定性及商业化剖析对全局可观测的要求也“水涨船高”，底层系统故障间接了影响业务营收与客户满意度。为此，小明所在的 IT 部门通过 OPLG 体系构建了一套全新的可观测平台，具备“疾速接入、灵便扩大、无缝迁徙、异构交融”等劣势。
OPLG 劣势
疾速接入：因为 OpenTelemetry 和 Prometheus 社区提供的大量成熟的开源 SDK/Agent/Exporter，无需大量代码革新，即可疾速接入支流组件与框架的链路追踪与指标监控。
灵便扩大：基于 PromQL/LogQL 灵便的查问语法，与 Grafana 丰盛的大盘定制性能，能够满足各个业务线或运维团队的个性化可观测需要。
无缝迁徙：思考到数据安全性及将来海内业务倒退布局，可观测平台积淀的组件埋点、自定义大盘可能在不同云服务商之间无缝迁徙。相比于商业化大盘深度锁定用户，Grafana 能够集成多种数据源，真正实现“端到端迁徙自在”。
异构交融：Java、Go、Node.js 等不同语言的利用，以及多云环境的可观测数据可能互联互通，对立展现。
OPLG 挑战
尽管 OPLG 体系具备多种劣势，然而企业自建也会面临多重挑战，特地是在深度应用的过程中，许多规模化运维、性能、老本等非功能性问题将逐步凸显。
组件规模化降级与配置：客户端探针的规模化治理简直是运维团队的“梦魇”，探针异样引发的各种故障也是不足为奇。此外，动静配置下推与性能降级这类“保命大招”，通常也须要企业自建配置核心，自行开发与治理。
Traces 全量采集与存储老本：中大型企业生产零碎的日均调用量能够达到上亿级别，调用链全量上报和存储的老本是个不小的开销，对哪些链路进行采样老本最优？链路采样导致的指标监控与告警不准问题又该如何解决？
Metrics 大体量查问性能：一次查问扫描的指标数越多，查问性能越差。当查问工夫范畴超过一周或者一个月时，常常会遇到查询卡顿甚至于无奈查问出后果。此外，APM Metrics 还会常常遇到 URL / SQL 发散导致的指标线过多，打爆存储与查问层。
海量告警调度时延与性能：每一条告警规定都代表着一个定期轮询工作，当告警规定超过千级别，甚至万级别时，常常会遇到告警提早发送，甚至无奈发送的状况，错失了故障排查的最佳时机。
组件容灾能力弱：多地区 / 可用区容灾，是保障服务高可用的重要伎俩。然而，因为容灾能力建设，须要技术与资源的双重投入，很多企业自建零碎都不具备容灾能力。
上述问题都是企业自建可观测体系过程中会遇到的经典问题，这些因为规模带来的性能及可用性问题，须要投入大量研发和工夫进行积淀，大幅减少了企业运维老本。因而，越来越多的企业抉择将可观测服务端托管给云服务商，在享受开源计划技术红利的同时，也能失去继续、稳固的服务保障。
OPLG 托管计划
为了升高运维老本，更稳固的提供可观测服务，小明所在的 IT 部门决定采纳由阿里云 ARMS 提供的 OPLG 托管计划，该计划在保留开源计划劣势的根底上，提供了高性能、高可用、免运维的后端服务，帮忙小明团队解决了海量数据场景下的规模化运维难题。此外，通过 eBPF 网络探测、Satellite 边缘计算和 Insights 智能诊断，进一步晋升了可观测数据的覆盖度和集成度，如下图所示。
高性能：反对无损统计，数据压缩，连贯优化，发散指标主动收敛，DownSample 等技术，大幅升高海量数据场景下的性能开销。
高可用：客户端反对资源限额与主动限流爱护，保障低压场景下的集群稳定性；后端服务反对弹性程度扩容，多地区 / 多可用区容灾，尽最大可能保障服务可用性。
灵便易用：JavaAgent、OT Collector、Grafana Dashboard Template 托管降级，主动适配更新，无需用户治理；反对动静配置下推，实时调整流量开关，调用链采样率，接口过滤与收敛规定等参数。
网络探测：通过 eBPF 无侵入地剖析网络申请，主动解析网络协议，构建网络拓扑，展现特定容器之间或容器与特定云产品实例之间的网络性能。
边缘计算：通过 Satellite（OpenTelemetry Collector）实现了可观测数据在用户集群内的边缘采集与计算能力，标准数据格式，对立数据标签，无效晋升 Trace/Metrics/Logs 数据之间的关联度。
智能诊断：联合多年积淀的畛域知识库和算法模型，对常见线上故障问题（如慢 SQL、流量不均）进行定期巡检，主动给出具体的根因剖析与倡议。
ARMS for OpenTelemetry Satellite
近两年 OpenTelemetry 和 SkyWalking 等社区都在鼎力研发边缘采集与计算 Satellite 计划。ARMS for OpenTelemetry Satellite（简称 ARMS Satellite）是一套基于 OpenTelemetry Collector 开发的可观测数据（Traces、Metrics、Logs）边缘侧对立采集与解决平台，具备平安、牢靠、易用等个性，适宜生产环境接入。
ARMS Satellite 通过边缘侧的数据采集、解决、缓存与路由，能够实现多源异构数据的标准化；加强 Traces、Metrics、Logs 可观测数据间的关联性；反对无损统计，升高数据上报和长久化存储老本等。
实用场景一：全景监控数据一键采集与剖析（容器环境）
ARMS Satellite 在容器服务 ACK 环境下，深度集成了阿里云 Kubernetes 监控组件与 Prometheus 监控组件，一键装置实现后，会主动采集 Kubernetes 容器资源层和网络性能数据。联合用户上报的应用层数据（只需批改 Endpoint，无代码革新）与主动预聚合指标，全副上报至全托管的服务端数据中心，再通过 Grafana 进行对立展现。最终实现笼罩利用、容器、网络、云组件的全景监控数据采集与剖析。
实用场景二：多云 / 混合云网络，异构 Tracing 框架数据关联与对立展现
在多云 / 混合云架构下，不同集群或利用间的链路追踪技术选型可能存在差别，比方 A 采纳了 Jaeger，B 采纳了 Zipkin，不同链路追踪协定上报的数据格式互不兼容，无奈串联，大幅升高了全链路诊断效率。
通过 ARMS Satellite 能够将不同起源的链路对立转化为 OpenTelemetry Trace 格局，并上报至对立的服务端进行解决和存储，用户能够轻松实现跨网络或异构链路框架的联结数据查问与剖析。
实用场景三：链路采样 + 无损统计，低成本实现利用监控告警精准统计
生产零碎的日均调用量能够达到亿级别，调用链全量上报和存储的老本是个不小的开销，对调用链执行采样存储是个不错的抉择。然而，传统的链路采样会导致链路统计指标的准确性大幅降落，比方一百万次实在调用通过 10% 采样后保留的十万次调用，对其统计失去的后果会产生显著的“样本歪斜”，最终导致监控告警误报率过高，根本处于不可用状态。
ARMS Satellite 反对 Trace 数据无损统计，对接管到的 Trace 数据主动进行本地预聚合，失去精准的统计后果后再执行链路采样上报，这样在升高网络开销和长久化存储老本的同时，保障了利用监控与告警指标的准确性。默认集成的 Satellite APM Dashboard 如下图所示。
总结
OPLG 体系领有成熟且富裕生机的开源社区生态，同时也通过了大量企业生产环境的实际测验，是当下建设新一代云原生对立可观测平台的热门抉择。然而，OPLG 只是提供了一个技术体系，如何灵活运用，解决理论问题，积淀出通用行业或场景的最佳实际，还须要大家一起来摸索。
原文链接
本文为阿里云原创内容，未经容许不得转载。
