openEuler 上的监控与告警实战：别再用“盯着终端”当运维了

今天咱聊点能直接上手的：openEuler 的监控与告警实践。别想太学术，我把思路、落地组件、常见坑和实战代码都往里放，方便你复制粘贴上手。

为什么要重做监控告警？先说痛点

现实里很多运维环境是这样：监控有，但告警“要么炸屏要么瞎沉默”。指标零散、日志分散、追因慢、告警噪声大——事情发生时，往往人还没反应过来，业务已经受影响了。openEuler 在云、边缘、服务器这些场景都有用户，指标来源多、异构设备多，这更考验监控体系的可观测能力与告警策略。openEuler 社区也在推进面向云原生、基于 eBPF 的观测项目，以降低采集成本并提升诊断深度。

推荐的技术栈（实战可落地）

我的建议是分层落地，既要用成熟组件，也要留空间给 openEuler 社区能力（比如 eBPF 探针）：

• 指标采集：node_exporter, 各类 exporter（数据库、中间件），K8s 用 prometheus-operator。在 openEuler 上很多同学直接用 Prometheus + node_exporter 做主机与服务监控的落地示例。
• 时序存储与告警：Prometheus + Alertmanager（规则、路由、抑制、通知）。告警策略在 Prometheus 侧定义，Alertmanager 负责降噪与通知路由。
• 可视化：Grafana（Dashboard、报警面板、图表书签）。
• 日志与追踪：Fluentd/Fluent Bit 或 Loki + Grafana，分布式追踪可接 Jaeger/Zipkin/OpenTelemetry。
• 深度可观测：openEuler 社区的 eBPF 探针（gala-gopher）可做低开销的网络/性能/全栈观测，能把内核态与应用态事件拉到上层分析平台。

openEuler 社区针对运维有专门的运维专区、工具链和示例文档（比如 OSMind 等），建议把这些生态资源纳入团队运维目录。

简单架构图（文字版）

[Host/node] -> node_exporter -> Prometheus (scrape)
[App logs] -> Fluentd -> Loki/Elasticsearch
[Tracing] -> OpenTelemetry -> Jaeger
Prometheus rules -> Alertmanager -> WeChat/Email/DingTalk/PagerDuty
Grafana <- Prometheus/Loki/Jaeger (dashboards)
eBPF probes -> gala-gopher -> metrics/traces (补充采集)

落地代码示例（常用片段，openEuler 上可直接跑）

1. 在 openEuler 上用 systemd 启动 node_exporter（简洁版）：

# /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
After=network.target

[Service]
User=nodeusr
ExecStart=/usr/local/bin/node_exporter --web.listen-address=":9100"
Restart=on-failure

[Install]
WantedBy=multi-user.target

2. Prometheus 抓取配置（prometheus.yml 简化）：

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['10.0.0.1:9100','10.0.0.2:9100']

3. 常见 PromQL（5 分钟内平均 CPU 利用率）：

100 * (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))

4. 简单的告警规则（rules.yml）：

groups:
- name: host.rules
  rules:
  - alert: HighCPUUsage
    expr: 100 * (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))) > 85
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Instance {{ $labels.instance }} CPU usage high"
      description: "CPU > 85% for 5 minutes"

5. Alertmanager 路由（alertmanager.yml 精简）：

route:
  group_by: ['alertname', 'instance']
  receiver: 'oncall'
receivers:
- name: 'oncall'
  email_configs:
  - to: 'ops@example.com'
    from: 'alertmanager@example.com'
    smarthost: 'smtp.example.com:587'

实战小技巧（写给运维人的“必做清单”）

1. 先把基础面做对：资产清单、指标白名单、关键业务SLO/SLI 明确。
2. 分层告警：先报警“趋势”再报警“临界”，避免瞬时抖动引发告警风暴；使用 for: 延迟、使用 Alertmanager 抑制规则。
3. 数据留存策略：Prometheus 本地只留短期（如15天），长期指标走 remote_write 到 Thanos/Cortex 做聚合存储。
4. 演练告警链路：每次变更告警配置前做 dry-run；定期演练 on-call 流程。
5. 结合 eBPF 做深度诊断：遇到内核/网络性能问题，eBPF 探针能在不重启业务的情况下抓到内核层面线索（openEuler 社区有相关实践和项目）。

常见坑（别踩）

• 把所有指标都抓回 Prometheus：会很快耗光磁盘，请筛选关键指标并做下采样/远程写入。
• 告警规则写得太多太细：先聚焦影响业务的 Top-N 指标。
• 忽视日志与追踪：只有指标还原不了复杂故障链路，日志/trace 是必需品。

小结：技术要实用，运维要能用

openEuler 社区在可观测方向投入了社区工程（比如基于 eBPF 的 gala-gopher），这为运维在低开销、高上下文的场景里做诊断提供了契机；而 Prometheus + Alertmanager + Grafana 依然是最稳妥的指标+告警+可视化组合。关键不在于你用什么“品牌”，而在于你能把告警从“嘈杂的闹钟”变成“有意义的告警”——这需要技术、流程和演练三管齐下。