信也监控可观测性实践总结
信也架构及可观测能力演进
信也科技经历了从单体架构到分布式架构、容器化、微服务架构及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 数据流处理、自动化自愈、用户体验及最佳实践宣导、应用健康度量评价标准等挑战，并总结出相应的解决方案和经验。
