下一篇【第63篇】监控SkyWalking本身——别让你的APM成为盲点上一篇【第65篇】Service Mesh数据的采集监控——Mixer与ALS模式的监控差异与排查指南一、Trace数据在OAP内部的旅行一条Trace从Agent发出到最终写入存储在OAP内部要经过怎样的旅程------------------------------------------------------------------ | Trace数据在OAP内部的处理管道 | ------------------------------------------------------------------ | | | Agent发送 | | │ | | ↓ | | ┌─────────────────┐ | | │ ① 数据接收层 │ ← gRPC Server / Kafka Consumer | | │ ● 连接数 │ 指标: 接收速率、连接数、序列化耗时 | | │ ● 接收速率 │ | | └────────┬────────┘ | | │ | | ↓ | | ┌─────────────────┐ | | │ ② SegmentParser │ ← 反序列化 基础校验 | | │ ● 解析速率 │ 指标: 解析耗时、数据格式错误率 | | │ ● 错误率 │ | | └────────┬────────┘ | | │ | | ↓ | | ┌─────────────────┐ | | │ ③ TraceAnalyser │ ← 核心分析引擎 | | │ ├── 调用链构建 │ 指标: 分析延迟、Segment处理速率 | | │ ├── OAL计算 │ 指标: OAL表达式执行耗时 | | │ └── 拓扑推断 │ 指标: 拓扑更新频率 | | └────────┬────────┘ | | │ | | ↓ | | ┌─────────────────┐ | | │ ④ Metrics聚合 │ ← 收集所有计算结果 | | │ ● 聚合窗口 │ 指标: 聚合延迟、聚合队列大小 | | └────────┬────────┘ | | │ | | ↓ | | ┌─────────────────┐ | | │ ⑤ 存储写入 │ ← Elasticsearch / MySQL / BanyanDB | | │ ● Bulk操作 │ 指标: 写入延迟、批量大小、失败重试次数 | | │ ● 重试逻辑 │ | | └─────────────────┘ | | | ------------------------------------------------------------------这条管道中任何一个环节出问题都会导致数据丢失或查询异常。让我们逐一分析每个环节的监控要点。二、数据接收模块的监控指标数据接收层是Trace的第一道门。门如果倒了后面的所有分析都无从谈起。2.1 gRPC接收端指标# gRPC Server核心指标 grpc_server_connections_total # 总连接数含历史 grpc_server_connections_active # 当前活跃连接数 grpc_server_messages_received_rate # 消息接收速率条/秒 grpc_server_bytes_received_rate # 字节接收速率MB/秒 grpc_server_rpc_duration_seconds_bucket # RPC处理耗时分布 # 关键关联 活跃连接数 ≈ Agent实例数 × 每个Agent的gRPC连接数 # 告警参考 # 连接数突然大幅下降 → 大量Agent掉线 # 接收速率突然大幅上升 → 可能有流量洪峰2.2 Kafka消费端指标# Kafka Consumer核心指标 kafka_consumer_fetch_rate # 消费速率 kafka_consumer_records_lag # 消费延迟Lag kafka_consumer_records_lag_max # 最大Lag kafka_consumer_fetch_latency_avg # Fetch延迟 # 关键Consumer Lag # Lag 10000 且持续增长 → 消费能力跟不上生产需要扩容 # Lag 0 → 当前消费正常2.3 数据格式校验# 数据质量指标 segment_parse_error_rate # Segment解析错误率 segment_invalid_format_rate # 格式非法率 segment_missing_fields_rate # 字段缺失率 # 告警 # parse_error_rate 1% → Agent版本可能不兼容 # missing_fields_rate 5% → 插件可能有问题三、OAL计算模块的性能指标OALObservability Analysis Language是SkyWalking的指标计算引擎。它用一套类似SQL的声明式语言定义指标计算规则。3.1 OAL是什么// oal/core.oal 中的典型规则 // 服务级别的CALL指标 endpoint_cpm from(Endpoint.avg) endpoint_avg from(Endpoint.latency).longAvg() // 服务实例的JVM指标 instance_jvm_young_gc_count from(InstanceJvmOldGC.time) instance_jvm_old_gc_count from(InstanceJvmOldGC.time) // 服务关系的指标 service_relation_client_cpm from(ServiceRelation.*) service_relation_server_cpm from(ServiceRelation.*)3.2 OAL性能指标# OAL引擎的核心指标 oal_engine_metrics_count # 当前活跃的指标数量 oal_engine_rules_count # 当前加载的OAL规则数 oal_engine_execution_duration_seconds # OAL规则执行耗时 oal_engine_execution_rate # OAL规则执行速率 # 关键信号 oal_engine_execution_duration 100ms → OAL引擎可能成为瓶颈 # 原因OAL规则太多或某个指标的数据量太大3.3 自定义OAL指标# 添加自定义OAL指标用于监控 # 例如监控特定端点的慢请求比例 # my-monitoring.oal slow_requests_ratio from(Endpoint.latency) .filter(latency 1000) # 耗时1s .count() / from(Endpoint.*).count()四、存储写入的批量操作监控存储是OAP最重要的下游依赖。存储层的性能直接影响OAP的数据处理能力。4.1 Bulk操作的生命周期------------------------------------------------------------------ ES Bulk写入的详细流程 ------------------------------------------------------------------ | | | ① 数据累积 | | ┌────────────────────────────────┐ │ | │ L1 Buffer: 内存队列 │ │ | │ 容量: bulkActions (默认5000) │ │ | │ 触发条件: 队列满 或 定时刷新 │ │ | └────────────┬───────────────────┘ │ | │ | | ↓ | | ② Bulk组装 | | ┌────────────────────────────────┐ │ | │ 将多条记录组装为BulkRequest │ │ | │ Index: trace_segment-20260702 │ │ | │ Actions: [index, index, ...] │ │ | └────────────┬───────────────────┘ │ | │ | | ↓ | | ③ 网络传输 | | ┌────────────────────────────────┐ │ | │ HTTP POST → ES /_bulk │ │ | │ Body: NDJSON格式 │ │ | └────────────┬───────────────────┘ │ | │ | | ↓ | | ④ ES处理 | | ┌────────────────────────────────┐ │ | │ ES协调节点分发到数据节点 │ │ | │ 写入Translog 内存Buffer │ │ | │ 定期Refresh到Segment │ │ | │ 定期Flush到磁盘 │ │ | └────────────┬───────────────────┘ │ | │ | | ↓ | | ⑤ 响应返回 | | ┌────────────────────────────────┐ │ | │ 200 OK 每个操作的执行结果 │ │ | │ { items: [{index: {status:201}}│ │ | │ {index: {status: 429}} ...] │ ← 注意429 太忙 │ | └────────────────────────────────┘ │ | | ------------------------------------------------------------------4.2 Bulk写入的关键指标# 写入性能指标 es_bulk_write_total # Bulk写入总次数 es_bulk_write_duration_seconds # Bulk写入总耗时 es_bulk_write_size_bytes # 每次Bulk的大小 es_bulk_write_actions_count # 每次Bulk包含的Action数 # 写入错误指标 es_bulk_write_error_total # Bulk写入失败次数 es_bulk_write_retry_total # Bulk重试次数 es_bulk_write_error_rate # 写入失败率 # 队列指标 es_bulk_pending_queue_size # 待处理Bulk队列大小 # 告警规则 # error_rate 1% → ES可能有问题 # pending_queue_size 100 → OAP处理速度跟不上 # p99 write_duration 2s → ES性能瓶颈4.3 Bulk写入的配置调优# application.yml - 存储配置storage:elasticsearch:# Bulk写入配置 bulkActions:${SW_STORAGE_ES_BULK_ACTIONS:5000}# 单次Bulk的最大Action数bulkSize:${SW_STORAGE_ES_BULK_SIZE:20}# 单次Bulk的最大大小(MB)flushInterval:${SW_STORAGE_ES_FLUSH_INTERVAL:10}# 刷新间隔(秒)concurrentRequests:${SW_STORAGE_ES_CONCURRENT_REQUESTS:2}# 并发Bulk请求数# 高级配置 syncBulkActions:${SW_STORAGE_ES_SYNC_BULK_ACTIONS:5000}# 同步Bulk的Action数indexRefreshInterval:${SW_STORAGE_ES_INDEX_REFRESH_INTERVAL:5}# 索引刷新间隔# 重试配置 maxRetries:${SW_STORAGE_ES_MAX_RETRIES:3}# 最大重试次数retryBackoff:${SW_STORAGE_ES_RETRY_BACKOFF:100}# 重试退避(ms)五、Backpressure —— 数据积压的监控与处理5.1 为什么会产生Backpressure------------------------------------------------------------------ Backpressure产生的典型场景 ------------------------------------------------------------------ | | | 正常状态: | | 生产速率 1000 segments/s | | 消费速率 2000 segments/s ✓ | | 队列大小 ≈ 0 | | | | Backpressure产生: | | 生产速率 3000 segments/s (双11流量洪峰) | | 消费速率 2000 segments/s (OAP处理能力上限) | | 队列大小 → 持续增长 → 最终OOM或数据丢弃 | | | | 常见原因: | | ┌──────────────────────────────────────────┐ │ | │ 1. 流量洪峰业务高峰、大促 │ │ | │ 2. OAP处理能力不足CPU/内存瓶颈 │ │ | │ 3. ES写入慢索引太多、磁盘IO瓶颈 │ │ | │ 4. 网络波动跨机房延迟高 │ │ | │ 5. OAP实例宕机剩下实例压力增大 │ │ | └──────────────────────────────────────────┘ │ | | ------------------------------------------------------------------5.2 Backpressure的监控指标# 队列深度指标 # 处理队列大小 analysis_queue_size # 分析队列大小 metrics_queue_size # 指标队列大小 bulk_queue_size # 存储写入队列大小 # 积压速率指标 # queue_size 的增长率 rate(oap_thread_pool_queue_size[1m]) # 队列增长速率 # 丢弃指标 segment_drop_count # 丢弃的Segment数量 segment_drop_rate # 丢弃率 # 告警 # queue增长速率 0 且持续5分钟 → 需要扩容 # drop_rate 1% → 数据质量报警5.3 处理Backpressure的策略策略1: 横向扩展OAP 增加OAP实例数 → 分摊处理压力 策略2: 纵向扩容OAP 增加单台OAP的CPU/内存 → 提高单个实例的处理能力 策略3: 启用Kafka缓冲 如果还没用Kafka → 引入Kafka做削峰 策略4: 增加Kafka Partition 如果已经用了Kafka → 增加Partition增加消费者 策略5: 优化ES - 增加ES节点 - 优化Bulk配置增大bulkActions减少Bulk频率 - 使用SSD磁盘 - 预热索引 策略6: 采样降级 临时降低采样率减少数据量 agent.sample_n_per_3_secs: 100 → 50六、OAP资源的综合监控面板推荐的Grafana面板布局 ------------------------------------------------------------------ | Row 1: 概览 | | ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ | | │ 活跃OAP数量│ │ Segment │ │ 总队列大小 │ │ ES写入 │ | | │ │ │ 接收速率 │ │ │ │ 延迟P99 │ | | └───────────┘ └───────────┘ └───────────┘ └───────────┘ | | | | Row 2: 处理能力 | | ┌─────────────────────────────┐ ┌─────────────────────────────┐ │ | │ Trace处理速率 │ │ 各队列大小时间线 │ │ | │ (折线图) │ │ (堆叠面积图) │ │ | └─────────────────────────────┘ └─────────────────────────────┘ │ | | | Row 3: 存储 | | ┌─────────────────────────────┐ ┌─────────────────────────────┐ │ | │ ES Bulk写入延迟分布 │ │ ES写入错误率 │ │ | │ (热力图) │ │ (折线图) │ │ | └─────────────────────────────┘ └─────────────────────────────┘ │ | | | Row 4: JVM | | ┌─────────────────────────────┐ ┌─────────────────────────────┐ │ | │ Heap使用率 GC │ │ CPU使用率 │ │ | │ (面积图 圆点) │ │ (折线图) │ │ | └─────────────────────────────┘ └─────────────────────────────┘ │ | | ------------------------------------------------------------------七、总结Trace数据处理管道中每个环节的可观测性都至关重要环节核心指标告警阈值数据接收接收速率、连接数连接数骤降数据解析解析速率、错误率错误率1%OAL计算执行耗时耗时100ms指标聚合聚合延迟、队列大小队列持续增长存储写入Bulk延迟、错误率P992sBackpressure队列深度queue_size100下一篇我们将关注Service Mesh场景下的数据监控。下一篇【第63篇】监控SkyWalking本身——别让你的APM成为盲点上一篇【第65篇】Service Mesh数据的采集监控——Mixer与ALS模式的监控差异与排查指南