云原生可观测性体系建设:从0到1搭Prometheus+Grafana+ELK+SkyWalking全家桶
云原生可观测性体系建设:从0到1搭Prometheus+Grafana+ELK+SkyWalking全家桶
大家好,我是迪哥。以前线上出问题,我们靠"猜";现在靠"看"——看指标、看日志、看链路。这套 Prometheus + Grafana + ELK + SkyWalking 组合拳,让我们的故障发现时间从小时级降到了秒级。今天聊聊如何从零搭建这套可观测性体系。
什么是可观测性?
三个支柱:
- 指标(Metrics):系统层面数据(CPU、内存、QPS)
- 日志(Logs):事件层面数据(请求、报错)
- 链路(Traces):请求层面数据(调用链路、耗时分布)
架构全景
┌─────────────────────────────────────────────────────────────────┐ │ Grafana (可视化) │ └────┬────────────────────────┬────────────────────────┬───────┘ │ │ │ ▼ ▼ ▼ ┌───────────────┐ ┌────────────────┐ ┌────────────────────┐ │ Prometheus │ │ Elasticsearch │ │ SkyWalking │ │ (指标存储) │ │ (日志存储) │ │ (链路存储) │ └───────┬───────┘ └────────┬───────┘ └───────────┬───────┘ │ │ │ └──────────┬──────────┴───────────┬───────────┘ │ │ ┌──────▼─────────┐ ┌──────▼─────────┐ │ Node Exporter│ │ Filebeat/Loki│ │ (系统指标) │ │ (日志收集) │ └──────┬─────────┘ └──────┬─────────┘ │ │ ┌──────▼─────────────────────▼─────────┐ │ K8s 应用集群 │ └──────────────────────────────────────┘一、指标:Prometheus + Grafana
安装 Prometheus
# prometheus.yml global: scrape_interval: 15s scrape_configs: - job_name: 'kubernetes-pods' kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true部署到 K8s
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm install prometheus prometheus-community/kube-prometheus-stack -n monitoring应用暴露指标(Micrometer)
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency>management: endpoints: web: exposure: include: 'prometheus,health,info,metrics'Grafana 仪表盘
推荐的 ID:
- 1860:Node Exporter(系统监控)
- 4701:JVM Micrometer
- 11378:Spring Boot 2.1+
二、日志:ELK Stack
架构
应用 → Filebeat → Elasticsearch → KibanaFilebeat 配置
filebeat.inputs: - type: container paths: - /var/log/containers/*.log processors: - add_kubernetes_metadata: ~ output.elasticsearch: hosts: ["elasticsearch:9200"]部署
helm install elk elastic/elastic-stack -n monitoringKibana 查询示例
# 查询错误日志 level: ERROR AND app: order-service AND @timestamp > now-1h # 查询慢请求 request_time > 3 AND app: order-service三、链路:SkyWalking
部署 OAP
apiVersion: apps/v1 kind: Deployment metadata: name: skywalking-oap spec: replicas: 2 template: spec: containers: - name: oap image: apache/skywalking-oap-server:9.4.0 env: - name: SW_STORAGE value: elasticsearch - name: SW_STORAGE_ES_CLUSTER_NODES value: elasticsearch:9200应用接入
java -javaagent:/path/to/skywalking-agent.jar \ -Dskywalking.agent.service_name=order-service \ -Dskywalking.collector.backend_service=skywalking-oap:11800 \ -jar order-service.jarSkyWalking 常用功能
- 拓扑图(Topology):一眼看出服务调用关系
- 追踪(Trace):找到慢/错误链路
- 性能剖析(Profile):代码级性能分析
- 告警(Alarm):异常及时通知
四、告警:Alertmanager + 钉钉/企业微信
alerting: alertmanagers: - static_configs: - targets: ['alertmanager:9093'] route: receiver: 'dingtalk' routes: - match: severity: critical receiver: 'dingtalk' receivers: - name: 'dingtalk' webhook_configs: - url: 'https://oapi.dingtalk.com/robot/send?access_token=xxx'告警规则示例
groups: - name: service_alerts rules: - alert: HighErrorRate expr: error_rate > 0.1 for: 5m labels: severity: critical annotations: summary: "服务 {{ $labels.app }} 错误率过高" description: "错误率为 {{ $value }}"可观测性成熟度模型
| 级别 | 指标 | 日志 | 链路 | 效果 |
|---|---|---|---|---|
| Level 0 | ❌ | ❌ | ❌ | 靠猜,线上出问题慌得一批 |
| Level 1 | ✅ 基础 | ❌ | ❌ | 知道系统挂了,但不知道为什么 |
| Level 2 | ✅ 完善 | ✅ 有 | ❌ | 能定位,但复杂问题不行 |
| Level 3 | ✅ 完善 | ✅ 完善 | ✅ 完善 | 全方位可观测,问题秒定位 |
成本建议
| 组件 | 资源建议 |
|---|---|
| Prometheus | 4C8G,保留 15 天 |
| Elasticsearch | 8C32G × 3 节点,保留 7-30 天 |
| SkyWalking OAP | 4C16G × 2 节点 |
| Grafana | 2C4G |
经验总结
- 不要追求完美!先把指标和日志搞起来,链路可以慢慢加
- 数据保留策略!不要无限期存,成本扛不住
- 告警要收敛!太多告警会导致告警疲劳
- 定期检查!有没有漏采集,有没有异常指标没人看
- 与业务结合!不仅看系统指标,更要看业务指标(下单量、支付成功率)
说到可观测性,我家那只叫 Docker 的哈士奇最近在监视我的零食柜,什么时候偷吃了,偷吃了什么,偷吃了多少,它门儿清,跟这套体系有的一拼 😂
我是迪哥,我们下期再见!
往期推荐:
- 《线上故障排查与应急响应实战》
- 《系统容量规划与压测实战》
