1. 信也监控可观测性实践

2.

3. 自我介绍 信也科技基础组件团队负责人，技术架构研究员，十多年互联网研发工 作经验，多年微服务及中间件体系建设及落地经验；目前负责公司中间件相关 产品的规划、架构、演进和落地，主导并建设了谛听可观测性平台及大规模推 广落地，目前专注于提升分布式系统的可观测性和稳定性及云原生架构方面的 研究。 09

4. 目录  信也架构及可观测能力演进  Metrics, Tracing, Logging(event), Profiler  信也应用可观测性场景化  信也可观测系统实现  可观测性实践总结 课件标题 | 副标题：副标题副标题 09

5. 信也架构及可观测能力演进 Service Mesh架构 分布式架构 Metric+Tracing+Logging Basic Metric、Logging 远古-2013 单体架构 Log files 课件标题 | 副标题：副标题副标题 2017- 2020 2014- 2016 容器化微服务架构 Metric、Tracing、Logging 2021- 2022 09

6. 遇到的挑战 规模化接入难 数据治理难 • 框架不统一，业务对升级比较排斥 • 系统复杂性高，实例数量多，调用关系复杂 • 业务对无浸入接入有强烈诉求 • 容器动态的生命周期，软件迭代速度快； • 海量数据处理与分析 发现问题难 运营分析难 • 监控误报及漏报多 • 数据孤岛，公司内部监控/运维系统繁多 • 缺少主动发现问题的能力 • 采集，展示及报警等数据分散在各团队、独立 监控、独立展示和告警 定位根因难 • 部门间监控工具不统一，数据未打通 • 对Go、Python语言监控比较薄弱 • 定位问题数据源单一，缺少综合根因定位方法 课件标题 | 副标题：副标题副标题 推广使用难 • 一般开发运维对平台使用有一定门槛 • 开发对接入的稳定性担忧 • 可观测性理念转化难 09

7. 如何解决 - 可观测一体化 业务层 （用户/订单） 分而治之 应用层 （JVM/线程池/DB调用 /Redis调用/错误等） PaaS 层 （Redis/PMQ/Kafka/Mysql/Job/ES 等） IaaS层 建设思路和目标 • 接入无侵入，简化架构，部署及运维友好； • 将数据收集、计算、存储及展示统一； • IaaS/PaaS/应用等各层监控数据标准化； • 将各层数据串联起来，具备上下钻取联动能力； • 将端到端监控数据打通串联； • 提供一站式观测平台覆盖所有监控； • 提供中心化配置管控； • 开放自定义能力，满足不同场景的需求； • 与公司内其它系统良好集成； （物理机、虚机、网络、存储、路由器等） 课件标题 | 副标题：副标题副标题 09

8. 如何解决 – 从监控向可观测性转变 告警 ALERTING 概况 OVERVIEW 排错 DEBUGGING 剖析 PROFILING 依赖分析 DEPENDENCY ANALYSIS 监控 Monitoring Ops “主动发现” 排错（Debugging），即运用数据和信息去诊断故障 出现的原因； 剖析（Profiling）, 即运用数据和信息进行性能分析； 可观测性 Observability Dev 依赖分析（Dependency Analysis），即运用数据信 息厘清系统之间的模块，并进行关联分析。 “监控告诉我们系统的哪些部分是不工作的。可观测性告 诉我们那里为什么不工作了。” - Baron SchSchwarz CTO of VividCortex 课件标题 | 副标题：副标题副标题 09

9. 如何解决 – 可观测性主要支柱转化与关联 发现异常 Detect Metric 指标 衡量应用系统当前的状态，可通过添加维度来添加额 外信息，相同维度之间的指标可聚合(累加、平均)， 通过指标告警可以快速发现异常； 定位问题 Troubleshoot O11y Tracing 链路 一个请求从接收到处理完毕整个生命周期跟踪路径， 相比指标多了请求相关的信息，通过排查链路可以快 速定位问题； Loggin 日志 Continuous Profiling Event 排除故障 Pinpoint 课件标题 | 副标题：副标题副标题 https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html 应用运行产生的事件或程序执行过程中产生的日志数 据，可以详细的解释系统运行的过程，通过应用的日 志来排除故障； 09

10. 目录  信也架构及可观测能力演进  Metrics, Tracing, Logging(event), Profiler  信也应用可观测性场景化  信也可观测系统实现  可观测性实践总结 课件标题 | 副标题：副标题副标题 09

11. 如何解决 – 以链路为核心的可观测性 指标 DB Gatewa y 链路 Traceid;c9c61.. SpanId; 1 Service Traceid;c9c61.. SpanId; 2 . 61. c9c ; d i e Trac Id; 4 n Spa Traceid;c9c61.. SpanId; 3 Traceid; c9 SpanId; c61.. 5 Redis 日志 课件标题 | 副标题：副标题副标题 09

12. Logging - 构造可关联分析高维度结构化日志 2022-09-12 10:41:17,141 [e5ecb819-b128-4434-a3fb-69534e6c4a9f] ERROR java.net.SocketTimeoutException: Read timed out • 什么时候发生？ timestamp • 日志信息是什么？ level Error messag e java.net.SocketTimeoutException: Read timed out • 是什么服务？ appid 1000001 service 1.0 commit Wireless- gateway w23s1d • 运行的是什么程序？ version 2022-09-12 10:41:17,141 • 程序运行在哪里？ region wanguo ip • 谁受到了影响？ userID 32444 orderID • 链路标识是什么？ traceID E5ecb81 spanID • 其它信息？ resource xjob/SimpleJob/DataSyncJobHandler 课件标题 | 副标题：副标题副标题 10.14.5.6 1324332 2 09

13. Metrics – 构建多层多维指标体系 应用指标 系统指标 指标：CPU使用率，内存使用率， CPU 受限次数，网络丢包数，网络 发送接受字节数，TCP连接数及状 态，文件打开数等； 业务指标 指标：QPS，错误数，耗时，成功 率，失败率等，GC次数，GC耗时， 堆内存，堆外内存，类加载数，线 程数等； 技术实践 指标：用户注册数，转化率，订单 量，交易额，渠道放款率，新客数， 新客转化率，放款时长，通过率等 相关问题 • 指标维度统一化增强，可钻取，与链路及日志关联 • 应用调用URL发散严重（例如/user/342343）； • 应用指标收集、处理、计算界面配置化 • 限制高基数，差的细粒度的调试（例如:userID） • 客户端预聚合，准确度高，低成本实现精准统计 • 应用OOM，GC时间变长（定时任务清理内存中无效指标， • 支持配置的自动 Rollup，分->小时->天 • 高基数->低基数 （例如：SQL Pattern） 课件标题 | 副标题：副标题副标题 设置阀值限制，添加监控等） • 维度太多查询慢，太分散（降维，不建议对长尾数据分析） 09

14. Tracing - 构建多维立体式链路真实还原现场 问题定位 • 真实还原用户行为路径 • 支持业务标识搜索，细粒度还原现场 • 丰富语义标签，降低使用成本 关联分析 • 丰富标签多维度钻取关联相关指标与日志等； Trace关联日志，组件关联服务端，ip关联主机 指标，Span关联业务指标等；快速发现问题根 因； 赋能业务 • 构建生产运行故障态势大盘，依赖拓扑分析， 感知影响源及故障根源 • 服务冶理，构建机器/应用/业务等关联关系 • 为精准测试提供数据支撑，辅助生成测试用例， 高效圈定测试范围 • 课件标题 | 副标题：副标题副标题 为接口自动化/压力测试提供数据支撑 09

15. Profiling – 线程指标化，快速定位异常线程 线程诊断 • 代替top + jstack，定位CPU问题效率更高； • 线程分组，名称模式化，每分钟上报； • threadMXBean.getAllThreadIds/getThreadCpu Time （或内核文件/proc/[pid]/task）收集数 据； • 类方法切分，使用字典表压缩存储，发散字段 过滤及模式化（lambda等），提升接口查询和 页面性能50%+； • 高基数问题，自监控发现，通用线程收敛模式 +单应用线程动态配置； https://github.com/uber-common/jvm-profiler 09

16. Profiling – 细粒度精准剖析程序代码问题 Continuous Profiling • 支持CPU/Alloc/Lock三种火焰图模式； • 低开销，默认采集分辨率100ms，分钟 级数据上报； • 配置参数动态下发，中心化管控； • 支持按实例及时间火焰图数据对比； • 字典表压缩整体性能提升60%+； • 加速模式（过滤低分辨率毛刺数据），提 升展示性能50%+； https://ieeexplore.ieee.org/abstract/document/5551002 https://github.com/pyroscope-io/pyroscope https://github.com/jvm-profiling-tools/async-profiler 09

17. 目录  信也架构及可观测能力演进  Metrics, Tracing, Logging(event), Profiler  信也应用可观测性场景化  信也可观测系统实现  可观测性实践总结 课件标题 | 副标题：副标题副标题 09

18. 场景一 - 以错误为中心的应用异常大屏 课件标题 | 副标题：副标题副标题 09

19. 场景二 - 指标+链路+日志融合，定位根因 traceId 关联日志 traceId userId url等 Spring-data-redis低版本bug https://github.com/spring-projects/spring-data-redis/issues/1221 ip 关联Redis 09

20. 场景 - 事件+指标+剖析融合，代码级根因定位 线程指标 告警事件 课件标题 | 副标题：副标题副标题 状态筛选+堆栈采样 09

21. 场景四 - 以应用为中心的根因分析（拓扑+层次关系） 入口调用 RPC HTTP JOB MQ App 调用类型 RPC调用 Nosql调用 HTTP调用 DB调用 本地调用 MQ调用 异常 基于链路中生成指标，先定界再定位，多维度指标下钻（分组），找出故障曲线对应的维度，结合链路日志定位根因 课件标题 | 副标题：副标题副标题 09

22. 场景五 - 提供基础能力（透传、隔离、路由等）赋能业务 多环境隔离 • 构建不同的“泳道”，开发/测试/验收每个环境有不 同环境标签，流量路由中发现同环境标路由到项目环 境，否则回归到基础环境，逻辑隔离，大大降低成本； • 通过字节码增强，植入入中间件埋点，提供数据透传 染色、隔离等基础能力； • 通过增强响应标识，链路打标，展示增强，提升全链 路排障能力； 类似场景：全链路灰度、全链路压测、双活同机房优先路由等； 课件标题 | 副标题：副标题副标题 09

23. 目录  信也架构及可观测能力演进  Metrics, Tracing, Logging(Event), Profiler  信也应用可观测性场景化  信也可观测系统实现  可观测性实践总结 课件标题 | 副标题：副标题副标题 09

24. 观测平台产品架构 数据应用场景 监控报表 监控大屏 平台赋能业务 统一告警 多维链路查询 多维性能分析 链路/日志/指标 关联查询 拓扑分析 业务主键查询 慢查询分析 应用性能报表 异常大屏 多渠道触达 告警统计报表 自定义大屏 Alarmbox 移动端 告警管理 应用健康报表 拓扑大屏 告警策略管理 链路多视图展示 错误分析 告警抑制静默 链路报文展示 流量分析 混沌平台 星云多环境 同城双活 PT全链路压测 RR 日志 精准用例推荐 发布部署 自动扩缩容 系统集成 基础设施数据 集成 体验端数据集 成 K8S等数据集 成 应用诊断 线程诊断 堆内存诊断 链路监控 链路与指标关联 业务与链路关联 链路与日志关联 链路与中 间件关联 数据隔离 数据透传 事件监控 日志监控 指标监控 JVM监控 组件监控 性能监控 主机监控 数据库监 控 上下游监控 异常监控 缓存监控 外部调用监控 错误监控 容器监控 指标库 Ng/Mesh日志 关键词 监控 应用日志 中间件日志 日志聚 类 容器事件 主机事件 应用事件 机器事件 火焰图 环境配置 依赖组件 异常诊断 巡检事件 中间件事件 智能诊断 自监控 数据收集 主机数据 Agent 采集 中间件数据 Agent 采集 链路数据 Agent 采集 事件数据 集成 日志数据 SDK/Agent/集成 Promethues 数据 集成 其它数据源 Cmdb等 Server监控 Agent监控 03

25. 观测平台整体架构 接入端 计算/存储端 Otel Collector OTel Collector AlertManager Agent Service 实时告警 平台端 Dashboard 大屏 Metrics 指标查询 Metrics Java Agent SkyWalking Flink Logs 实时计算 Go SDK SkyWalking Python SDK SkyWalking 其它数据源 变更事件等 课件标题 | 副标题：副标题副标题 TSDB/DW Traces Kafka Trace 链路检索 Logging 日志检索 Diting Server Elastic Search Alert Config 告警管理 Config Center 配置管理 09

26. 观测数据实时计算处理 Flink 处理规则 计算编排 User Configuration Console Web UI Stream Cluster pipeline processor Flink Cluster receiver exporter Agent Cluster 处理流程 Server 侧 数据聚合 Kafka Agent 链路转指标 Traces Agent 侧 数据预聚合 Flink Flink Flink Kafka Consumer Aggregator Exporter TSDB Trace Trace Trace Consumer Flatter Aggregation Metrics Metric/Log Data Data Data Collection Receiver Processor Export 应用侧预聚合，成本低，数据准确度高，结合服务端聚合满足不同场景需求； { "ruleId": "1000", "source":{"type":"kafka","bootstrapServers":"1.1.1.1:9092","t opic":"diting_perf_metric"}, "sink":{"type":"kafka","bootstrapServers":"1.1.1.1:9092","topi c":"diting_perf_metric_aggretation"}, "aggregator": [{ "aggregatorFunctionType": "sum", "aliasName": "sum_durations", "datasource": "perf.server.out_call.duration","window": 2, "computeColumn": "durations", "filters": {"type": "selector","key": "host","operator": "in","value": "12.18.1.1"}, "groupingKeyNames": ["host"] }, { "aggregatorFunctionType": "sum", "aliasName": "sum_counts", "computeColumn": "counts", "datasource": "perf.server.out_call.count","window": 2, "filters": {"type": "or","fields": [{"type": "selector","key": "host","operator": "=","value": "12.18.1.1"}]}, "groupingNames": ["host"] }], "filters": {"env":"pro"}, "postaggregator": [{ "aliasName": "load.1min.max.total", "fields": [{"feildName": "sum_durations"},{"feildName": "sum_counts"}], "operator": "/" 09 }], }

27. 观测数据统一告警/事件处理 告警数据源 Kafka 谛听应用告警 静默规则 告警数据判定 业务告警 告警网关 次数规则 间隔规则 规则管理 元数据管理 统计分析 告警大屏 通知渠道 告警级别判定 邮件 通知方式判定 短信 电话 企微 webhook 依赖服务 告警反馈 告警认领 告警SDK告警 时间规则 其它规则.. Prometheus 告警 自定义指标告警 告警管理平台 告警数据聚合（基于规则） Grafana 告警 CAT 告警 告警引擎 告警缓冲与处理 告警静默 告警详情 CMDB 短信/电话服务 组/人员服务 通道服务 09

28. 观测平台部署及多机房容灾 ShangHai （备） ShangHai（主） 部署及容灾 谛听观测平台 谛听观测平台 • Agent 通过 InitContainer 容器方式实现探针自动注入， 镜像与应用分离，版本单独维度与更新； Philippines Indonesia • ShangHai 异地机房单元化部署，数据写入单独计算与存储，不跨 机房通信； TSDB/Log/Trace TSDB/Log/Trace TSDB/Log/Trace • 单机房数据多副本，故障隔离；观测平台数据查询不受 故障机房影响； server flink flink app agent server flink app agent • 观测平台部署在国内，通过专线与国外机房互联，主机 房宕机或断网时，切换到备机房继续服务。 kafka kafka kafka agent server app 09

29.

30. 可观测性实践总结 开发过程中一些坑及经验总结 1. Kafka插件，低版本Kafka不支持header导致broker解析数据异常； 2. Header 大小写及Python等驼峰式问题组件读取支持参次不齐，读写header 须小心; 3. 输入流只能读取一次问题， 影响业务数据获取导致调用异常；- 被动读流代替Wrapper方式； 4. Agent 多版本集中化管控，配置灰度，动态下发，降级开关等；大版本迭代尽量上线前测试环境全量重启回归； 5. 做好自监控，具备插件错误感知能力，例如：插件日志集中化及配置指标告警； 6. 应用依赖组件包与agent冲突，引起类加载问题，建议shading处理； 7. 高基数问题导致时序数据库压力大，iowait高，经常性timeout；-规则过滤、指标数限制、定理清理及监控等； 8. 适当采样及过滤无效链路数据（死循环、心跳、jpg请求等）； 9. Pipeline 处理数据流，计算与存储分离； 10. 自动化自愈尝试，根据预设的事件处理策略，自动执行自动故障处理； 11. 系统要考虑用户体验及用户使用习惯，尽早让用户参与反馈及改进，多宣导及分享最佳实践； 12. 建立应用健康度量评价标准，定期应用健康报告，推动业务应用进行优化； 09