下一篇【第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-oap'scrape_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或优化ES

3.5 JVM核心指标

# === JVM内存 === jvm_memory_bytes_used{area="heap"} # 堆内存使用 jvm_memory_bytes_used{area="nonheap"} # 非堆内存使用 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{job="skywalking-oap"}== 0for:1mlabels:severity:criticalannotations:summary:"OAP instance {{ $labels.instance }} is down"description:"OAP has been down for more than 1 minute"# === 规则2: JVM堆内存过高 ===-alert:OAPHighHeapUsageexpr:|(jvm_memory_bytes_used{area="heap"} / jvm_memory_bytes_max{area="heap"}) > 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 > 500ms"description:"P99 latency = {{ $value }}s for {{ $labels.instance }}"# === 规则4: 数据积压 ===-alert:OAPDataBackpressureexpr:oap_thread_pool_queue_size>100for:5mlabels:severity:criticalannotations:summary:"OAP has data backpressure"description:"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 frequent"description:"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本身不是"过度设计"，而是生产环境必备的安全网。核心要点：

1. 启用Telemetry模块：让OAP暴露Prometheus指标
2. 关注四大指标：线程池状态、存储延迟、处理吞吐、JVM健康
3. 建立告警规则：OAP宕机、数据积压、内存过高必须告警
4. 搭建监控面板：Grafana可视化让你一眼看到全局状态
5. 分层监控：从基础设施到业务应用，层层覆盖

下一个要深入的方向是：Trace数据的采集与指标监控。

下一篇【第62篇】通信扩展最佳实践——gRPC/HTTP/Kafka全景对比与选型决策
上一篇【第64篇】Trace数据的采集与指标监控——OAL计算、批量操作与数据积压全面监控