信也监控可观测性实践总结
信也架构及可观测能力演进
信也科技经历了从单体架构到分布式架构、容器化、微服务架构及Service Mesh架构的演进过程,其可观测能力也随之从基础的日志、指标、追踪发展到综合性的可观测性平台。早期面临规模化接入难、问题发现难、运营分析难、数据治理难、定位根因难及推广使用难等挑战,主要原因是部门间监控工具不统一、对特定语言监控薄弱、数据源单一、监控误报漏报多、缺少主动发现问题能力、框架不统一、业务对无侵入接入有诉求、系统复杂性高、平台使用门槛高等。
如何解决 - 可观测一体化
信也提出建设可观测一体化平台,目标包括接入无侵入、数据收集计算存储展示统一、各层数据标准化、数据串联联动、端到端监控打通、一站式观测平台、中心化配置管控、开放自定义能力及良好系统集成。通过从监控向可观测性转变,实现告警、排错、剖析、依赖分析等能力,核心是转化与关联发现异常、定位问题、排除故障、精准定位。
可观测性主要支柱
可观测性主要依赖指标(Metrics)、追踪(Tracing)、日志(Logging)、剖析(Profiler)四大支柱。指标用于衡量系统状态,追踪还原请求路径,日志解释系统运行过程,剖析进行性能分析。
如何解决 – 以链路为核心的可观测性
信也构建以链路为核心的可观测性体系,整合指标、链路、日志,实现多维度关联分析。
Logging - 构造可关联分析高维度结构化日志
通过结构化日志,包含时间戳、级别、消息、服务、版本、区域、用户ID、trace ID、span ID、资源、作业、提交、应用ID、订单ID等信息,实现高维度关联分析。
Metrics – 构建多层多维指标体系
构建系统指标、应用指标、业务指标三层多维指标体系,通过指标维度统一化、应用指标收集配置化、客户端预聚合、支持配置自动 Rollup 等技术实践,解决应用调用 URL 发散、应用 OOM、GC 时间长、维度过多查询慢等问题。
Tracing - 构建多维立体式链路
通过真实还原用户行为路径、支持业务标识搜索、丰富语义标签、多维度钻取关联指标与日志,快速发现问题根因,构建故障态势大盘,赋能业务问题定位关联分析。
Profiling – 线程指标化,快速定位异常线程
通过线程指标化替代 top + jstack,定位 CPU 问题效率更高;线程分组、名称模式化、分钟级上报;类方法切分、字典表压缩存储,提升查询和页面性能。
Profiling – 细粒度精准剖析程序代码问题
支持 CPU/Alloc/Lock 三种火焰图模式,低开销,分钟级数据上报,配置参数动态下发,支持按实例及时间火焰图数据对比,字典表压缩提升性能。
信也应用可观测性场景化
信也通过多个场景展示可观测性应用:
- 错误为中心的应用异常大屏
- 指标+链路+日志融合,定位根因
- 事件+指标+剖析融合,代码级根因定位
- 以应用为中心的根因分析(拓扑+层次关系)
- 提供基础能力(透传、隔离、路由等)赋能业务
信也可观测系统实现
信也观测平台整体架构包括接入端(OTel Collector、Agent)、计算/存储端(TSDB、Elastic Search、Flink)、平台端(Diting Server、Config Center、AlertManager)及数据集成(Prometheus、CMDB 等)。平台通过 Flink 进行实时计算处理,统一告警/事件处理,并支持部署及多机房容灾。
可观测性实践总结
信也在实践中遇到 Kafka 插件低版本兼容性、Header 大小写问题、输入流读取限制、Agent 多版本管控、自监控能力、应用依赖冲突、高基数问题、链路数据采样过滤、Pipeline 数据流处理、自动化自愈、用户体验及最佳实践宣导、应用健康度量评价标准等挑战,并总结出相应的解决方案和经验。