下一篇【第62篇】通信扩展最佳实践——gRPC/HTTP/Kafka全景对比与选型决策上一篇【第64篇】Trace数据的采集与指标监控——OAL计算、批量操作与数据积压全面监控一、医者不自医的困境每个运维人员都遇到过这种噩梦凌晨3点手机响了生产系统出问题了。你揉着眼睛打开SkyWalking UI想看看到底哪个服务挂了。结果发现——SkyWalking OAP自己崩了或者ES集群CPU 100%或者OAP所在的机器内存被吃光了。你无法看到任何Trace、任何指标、任何告警。你变成了盲人——明明装了APM却在关键时刻什么都看不见。这就是医者不自医的问题。SkyWalking作为APM系统负责监控你的整个微服务体系。但SkyWalking本身——OAP Server、存储集群、网络连接——它们也是需要被监控的。------------------------------------------------------------------ | APM监控的盲区 | ------------------------------------------------------------------ | | | ┌─────────────────────────────────────────┐ │ | │ ✅ 微服务可观测 │ │ | │ ✅ Trace链路可见 │ │ | │ ✅ 指标图表正常 │ │ | │ ✅ 告警规则生效 │ │ | └─────────────────────────────────────────┘ | | | | ┌─────────────────────────────────────────┐ │ | │ ❌ SkyWalking自身的状态 │ │ | │ ❌ OAP Server的CPU/内存 │ │ | │ ❌ ES集群的查询延迟 │ │ | │ ❌ 数据是否有积压 │ │ | │ ❌ 网络连接是否正常 │ │ | └─────────────────────────────────────────┘ | | | | 如果不监控这些你的APM系统就是一个定时炸弹 | | | ------------------------------------------------------------------二、SkyWalking内置的自监控能力好消息是SkyWalking 8.x版本已经内置了自监控能力。OAP Server会暴露自己的指标你可以通过Prometheus来采集。2.1 自监控架构------------------------------------------------------------------ | SkyWalking自监控架构 | ------------------------------------------------------------------ | | | ┌────────────────────────────────────────────┐ │ | │ OAP Server │ │ | │ │ │ | │ ┌──────────────────────────────────────┐ │ │ | │ │ Self-Observability │ │ │ | │ │ │ │ │ | │ │ ┌──────────┐ ┌──────────┐ │ │ │ | │ │ │ Metrics │ │ Health │ │ │ │ | │ │ │ Collector│ │ Check │ │ │ │ | │ │ └─────┬────┘ └─────┬────┘ │ │ │ | │ │ │ │ │ │ │ | │ │ ┌─────▼─────────────▼────────┐ │ │ │ | │ │ │ Telemetry Module │ │ │ │ | │ │ │ 指标聚合 暴露 │ │ │ │ | │ │ └─────────────┬──────────────┘ │ │ │ | │ └────────────────┼───────────────────┘ │ │ | │ │ │ │ | └───────────────────┼──────────────────────┘ │ | │ │ | ┌──────────┼──────────┐ │ | │ │ │ │ | ↓ ↓ ↓ │ | ┌───────────┐ ┌──────────┐ ┌───────────────┐ │ | │Prometheus │ │ Grafana │ │ 告警系统 │ │ | │ 采集指标 │ │ 可视化 │ │ (AlertManager)│ │ | └───────────┘ └──────────┘ └───────────────┘ │ | | ------------------------------------------------------------------2.2 启用自监控# oap-server/config/application.yml# 启用Telemetry模块telemetry:selector:${SW_TELEMETRY:prometheus}# Prometheus配置prometheus:host:${SW_TELEMETRY_PROMETHEUS_HOST:0.0.0.0}port:${SW_TELEMETRY_PROMETHEUS_PORT:1234}# SSL配置如果需要sslEnabled:${SW_TELEMETRY_PROMETHEUS_SSL_ENABLED:false}sslKeyPath:${SW_TELEMETRY_PROMETHEUS_SSL_KEY_PATH:}sslCertChainPath:${SW_TELEMETRY_PROMETHEUS_SSL_CERT_CHAIN_PATH:}# Prometheus 采集配置 (prometheus.yml)scrape_configs:-job_name:skywalking-oapscrape_interval:15sstatic_configs:-targets:-oap-server-1:1234-oap-server-2:1234-oap-server-3:1234三、关键监控指标全解3.1 处理线程池状态OAP使用了多个线程池来处理不同阶段的数据。线程池的状态直接反映了OAP的处理能力。# 关键指标 # JVM指标 jvm_threads_live # 活跃线程数 jvm_threads_daemon # 守护线程数 jvm_threads_peak # 峰值线程数 # 自定义线程池指标 # OAP内部的线程池 oap_thread_pool_active_count # 活跃线程数 oap_thread_pool_queue_size # 等待队列大小⚠ 如果0说明有积压 oap_thread_pool_pool_size # 线程池大小 oap_thread_pool_largest_pool_size # 历史最大线程数 oap_thread_pool_completed_task_count # 已完成任务数 # 告警规则 # oap_thread_pool_queue_size 100 → 处理能力不足需要扩容 # oap_thread_pool_active_count / oap_thread_pool_pool_size 0.9 → 线程接近饱和3.2 网络连接数# gRPC连接指标Agent ↔ OAP grpc_server_connections_total # gRPC总连接数 grpc_server_messages_received_total # 接收消息总数 grpc_server_messages_sent_total # 发送消息总数 # HTTP连接指标如果启用了HTTP扩展 http_server_requests_seconds_count # HTTP请求总数 http_server_requests_seconds_sum # HTTP请求总耗时3.3 存储延迟存储Elasticsearch/MySQL等是OAP最重要的下游依赖。存储慢整个链路的处理都会慢。# Elasticsearch指标 # Bulk写入 es_bulk_write_latency_seconds_bucket # Bulk写入延迟分布 es_bulk_write_latency_seconds_count # Bulk写入次数 es_bulk_write_latency_seconds_sum # Bulk写入总耗时 # 查询延迟 es_query_latency_seconds_bucket # 查询延迟分布 es_query_latency_seconds_count # 查询次数 # 告警规则 # P99 es_bulk_write_latency 500ms → ES写入慢可能需要扩容 # P99 es_query_latency 1000ms → ES查询慢检查索引和查询性能3.4 Trace处理吞吐# Analyzer处理指标 # Trace处理吞吐 trace_segment_analysis_latency_seconds_bucket # 分析延迟 trace_segment_count_total # 处理总数 # 指标聚合 metrics_aggregation_latency_seconds_bucket # 聚合延迟 # 数据积压 # 如果 trace_segment_count_rate ES bulk写入速率 # → 数据积压需要扩容OAP或优化ES3.5 JVM核心指标# JVM内存 jvm_memory_bytes_used{areaheap} # 堆内存使用 jvm_memory_bytes_used{areanonheap} # 非堆内存使用 jvm_memory_bytes_committed # 已提交内存 jvm_memory_bytes_max # 最大内存 # JVM GC jvm_gc_collection_seconds_count # GC次数 jvm_gc_collection_seconds_sum # GC总耗时 # 告警规则 # heap_used / heap_max 0.85 → 堆内存即将耗尽 # P99 GC_time 1s → GC压力过大四、Prometheus告警规则# skywalking-oap-alerts.ymlgroups:-name:skywalking_oap_alertsrules:# 规则1: OAP实例宕机 -alert:OAPInstanceDownexpr:up{jobskywalking-oap} 0for:1mlabels:severity:criticalannotations:summary:OAP instance {{ $labels.instance }} is downdescription:OAP has been down for more than 1 minute# 规则2: JVM堆内存过高 -alert:OAPHighHeapUsageexpr:|(jvm_memory_bytes_used{areaheap} / jvm_memory_bytes_max{areaheap}) 0.85for:5mlabels:severity:warningannotations:summary:OAP heap usage 85%description:{{ $labels.instance }} heap usage {{ $value | humanizePercentage }}# 规则3: ES写入延迟高 -alert:OAPHighESWriteLatencyexpr:|histogram_quantile(0.99, rate(es_bulk_write_latency_seconds_bucket[5m]) ) 0.5for:5mlabels:severity:warningannotations:summary:ES bulk write P99 500msdescription:P99 latency {{ $value }}s for {{ $labels.instance }}# 规则4: 数据积压 -alert:OAPDataBackpressureexpr:oap_thread_pool_queue_size100for:5mlabels:severity:criticalannotations:summary:OAP has data backpressuredescription:Queue size {{ $value }} on {{ $labels.instance }}# 规则5: GC频繁 -alert:OAPFrequentGCexpr:rate(jvm_gc_collection_seconds_count[5m])10for:5mlabels:severity:warningannotations:summary:OAP GC is too frequentdescription:GC rate {{ $value }}/s on {{ $labels.instance }}五、Grafana仪表盘5.1 OAP概览面板{dashboard:{title:SkyWalking OAP Overview,panels:[{title:OAP Instances,targets:[{expr:count(up{job\skywalking-oap\} 1)}]},{title:Trace Processing Throughput,targets:[{expr:rate(trace_segment_count_total[1m])}]},{title:JVM Heap Usage,targets:[{expr:jvm_memory_bytes_used{area\heap\} / jvm_memory_bytes_max{area\heap\} * 100}]},{title:ES Write Latency P99,targets:[{expr:histogram_quantile(0.99, rate(es_bulk_write_latency_seconds_bucket[5m]))}]}]}}六、多层监控体系的搭建建议------------------------------------------------------------------ 多层监控体系 ------------------------------------------------------------------ | | | Layer 1: 基础设施监控 | | ┌────────────────────────────────────────────────────────────┐ │ | │ 服务器指标: CPU, Memory, Disk, Network │ │ | │ 使用: Prometheus Node Exporter, CAdvisor │ │ | └────────────────────────────────────────────────────────────┘ │ | ↓ 发现异常 ↓ │ | Layer 2: 中间件监控 | | ┌────────────────────────────────────────────────────────────┐ │ | │ ES集群: Search Rate, Indexing Rate, Cluster Health │ │ | │ Kafka: Consumer Lag, Broker Throughput │ │ | │ 使用: ES Exporter, Kafka Exporter │ │ | └────────────────────────────────────────────────────────────┘ │ | ↓ 发现异常 ↓ │ | Layer 3: SkyWalking自监控 | | ┌────────────────────────────────────────────────────────────┐ │ | │ OAP: 处理吞吐, 队列大小, JVM, 连接数 │ │ | │ Agent: 上报成功率, 连接状态 │ │ | │ 使用: SkyWalking Telemetry Prometheus │ │ | └────────────────────────────────────────────────────────────┘ │ | ↓ 发现异常 ↓ │ | Layer 4: 业务应用监控 | | ┌────────────────────────────────────────────────────────────┐ │ | │ 微服务: Trace, Metrics, Topology │ │ | │ 使用: SkyWalking 本身! │ │ | └────────────────────────────────────────────────────────────┘ │ | | | 监控的黄金法则永远从最底层开始排查 | | 基础设施 → 中间件 → APM自身 → 业务应用 | | | ------------------------------------------------------------------七、总结监控SkyWalking本身不是过度设计而是生产环境必备的安全网。核心要点启用Telemetry模块让OAP暴露Prometheus指标关注四大指标线程池状态、存储延迟、处理吞吐、JVM健康建立告警规则OAP宕机、数据积压、内存过高必须告警搭建监控面板Grafana可视化让你一眼看到全局状态分层监控从基础设施到业务应用层层覆盖下一个要深入的方向是Trace数据的采集与指标监控。下一篇【第62篇】通信扩展最佳实践——gRPC/HTTP/Kafka全景对比与选型决策上一篇【第64篇】Trace数据的采集与指标监控——OAL计算、批量操作与数据积压全面监控