香港服务器全链路监控实战：我如何用 Prometheus 3.4 + Grafana 11.6 打通可观测、可视化与告警闭环

三个月前，我接手一家在港交所上市的 SaaS 金融平台。凌晨 2 点，我们突然收到客户电话——所有下单接口 500 错误，但监控面板一片绿色。最终排查发现，是网关层到后端 MySQL 的 p99 延迟飙升，却被早年仅用 CPU % 的“心跳监控”完全忽略。那晚我痛下决心：必须在香港机房落地一套真正的全链路可观测平台，覆盖基础设施、网络、服务、业务四个维度，并能在 30 秒内给到明确告警与根因线索。

下文就是我在 3 周内 完成从零到全量上线的完整过程，所有配置均在 A5 数据九龙湾机房的裸金属上实测通过。

1 | 目标与挑战

维度	SLA 目标	关键指标	采集方式
基础设施	99.99 % 可用	CPU/内存/磁盘 I/O	node_exporter
网络链路	< 50 ms 延迟	TCP RTT p95、丢包率	blackbox_exporter + iPerf 自动任务
服务层	p95 < 200 ms	HTTP 2xx/5xx、错误码	Go/OpenTelemetry SDK
业务层	每分钟 < 2 失败交易	自定义交易成功率	PushGateway

挑战：跨境网络 jitter 大；高频写入导致 TSDB 膨胀；合规要求强制本地机房存储。

2 | 总体架构设计

┌─────────┐  ┌──────────┐
│ A5 BGP  │  │ 负载均衡 │
└──┬──────┘  └─────┬────┘
   │                │
┌──▼──node_exporter └─────┐
│  Core service Pods   │
│  (otel-sdk)          │
└──┬────────────────────┘
   │ Remote Write
┌──▼──────────────┐
│ Prometheus HA   │  <─── Alertmanager HA (双活)
│ 3.4.1 x 3 节点  │
└──┬──────────────┘
   │ sidecar gRPC
┌──▼──────────────┐
│ Thanos Store +  │  – 对象存储：MinIO OSS
│ Memcached Cache │
└──┬──────────────┘
   │
┌──▼──────────┐
│ Grafana 11.6 │
└──────────────┘

三层 HA：节点 → Prometheus → Thanos，对象存储落在同机房分钟复制。

3 | 环境准备

# OS: AlmaLinux 9.4 （5.14 内核）
dnf install -y firewalld chrony wget gcc
systemctl enable --now chronyd firewalld
timedatectl set-timezone Asia/Hong_Kong

Prometheus 3.4.1（2025-05-31 发布）

Grafana 11.6（2025-03-26 发布）

我用三台 c32m128 裸机组成监控集群，NVMe RAID-1 做 WAL，10 Gbps 私网做远程写入。

4 | Prometheus 3.4 安装与全链路采集

4.1 二进制部署与系统服务

useradd -rs /bin/false prometheus
tar -xzf prometheus-3.4.1.linux-amd64.tar.gz -C /usr/local
ln -s /usr/local/prometheus-3.4.1 /usr/local/prom
cat >/etc/systemd/system/prometheus.service <<'EOF'
[Unit]
Description=Prometheus TSDB
After=network-online.target

[Service]
User=prometheus
ExecStart=/usr/local/prom/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.retention.time=45d \
  --storage.tsdb.wal-compression \
  --web.enable-lifecycle \
  --web.enable-remote-write-receiver \
  --enable-feature=exemplar-storage
Restart=on-failure
LimitNOFILE=131072

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload && systemctl enable --now prometheus

4.2 采集配置片段

# /etc/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 30s

scrape_configs:
- job_name: node
  static_configs:
  - targets:
    - 10.0.6.11:9100
    - 10.0.6.12:9100

- job_name: blackbox_icmp
  metrics_path: /probe
  params:
    module: [icmp]
  static_configs:
  - targets:
    - 8.8.8.8
    - 1.1.1.1
  relabel_configs:
  - source_labels: [__address__]
    target_label: instance
  - target_label: __param_target
    source_labels: [__address__]
  - replacement: blackbox:9115
    target_label: __address__

- job_name: otel_apps
  honor_labels: true
  scrape_interval: 5s
  kubernetes_sd_configs:
  - role: pod
    namespaces: { names: [prod] }
  relabel_configs:
  - source_labels: [__meta_kubernetes_pod_label_prometheus_io_scrape]
    action: keep
    regex: "true"

4.3 PushGateway 用于低频业务指标

docker run -d --restart unless-stopped \
-p 9091:9091 prom/pushgateway:v1.7.0

在支付服务里推送：

push.New("http://10.0.6.10:9091", "txn_job").
    Collector(successGauge).
    Grouping("channel", "fps").
    Push()

5 | 高可用与长期存储：Thanos

docker run -d \
  -e MINIO_ROOT_USER=thanos -e MINIO_ROOT_PASSWORD=changeit \
  -v /data/minio:/data \
  -p 9000:9000 quay.io/minio/minio server /data --console-address ":9001"

• 启动 thanos sidecar 于每个 Prometheus 节点，开启 –objstore.config-file.
• thanos query 实现联邦查询；thanos ruler 复用 PromQL Rule 文件。
• 冷数据自动转入对象存储，生产压测写入 1 M samples/s，CPU 使用率 < 40 %。

6 | Grafana 11.6 可视化与统一告警

6.1 安装

wget https://dl.grafana.com/oss/release/grafana-11.6.0-1.x86_64.rpm
dnf install grafana-11.6.0-1.x86_64.rpm -y
systemctl enable --now grafana-server

6.2 接入数据源

• Prometheus：URL 指向 http://thanos-query:9090，开启 Exemplars。
• Loki（可选）：聚合应用日志。
• Tempo（可选）：链路追踪，与 OTLP 协议无缝对接。

6.3 场景化仪表盘

Grafana 11 新增 Scenes API，支持将 网关 ➜ 核心服务 ➜ DB 的链路拓扑渲染为交互式视图；同时支持 LBAC 将特定团队隔离在 namespace 级别。

实战技巧：使用 transform: labels to fields 把 method、status 打平后即可直观做漏斗图。

6.4 统一告警

Grafana 11 引入 Unified Alerting 2.0，可直接在 Dashboard 上设阈值，生成与 Alertmanager 同步的规则；我保留了 Prometheus 规则文件做 HA fallback：

# rules/latency-alert.yml
groups:
- name: api-latency
  rules:
  - alert: APIHighLatencyP95
    expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket{job="api"}[5m])) > 0.2
    for: 2m
    labels:
      severity: critical
      product: trade
    annotations:
      summary: "API p95 延迟 > 200ms"
      description: "{{ $value }}s on {{ $labels.instance }}"

Alertmanager 路由到 DingTalk、PagerDuty、带 抑制/静默 策略，确保部署窗口不打扰 on-call。

7 | 典型故障排查案例

症状：某日上午 10:17，上海用户大量投诉下单失败。

• Grafana 世界地图面板高亮华东地区丢包率 > 5 %。
• Drill-down 到 blackbox_icmp，RTT p99 从 45 ms 飙升到 380 ms。
• 进一步查看 border_router_exporter，发现 egress BGP peer flap，错过了三条最佳路由。
• 自动触发的 Playbook 脚本调用 FortiOS API 重启 bgpd；5 分钟恢复。

根因、影响面、处理时长自动写入 CMDB，方便复盘。

8 | 运营与成本优化

策略	效果
Prometheus --storage.tsdb.retention.time=45d + Thanos 归档 180 d	本地 SSD 空间削减 62 %
Remote-write batch=512kB	写放大下降 37 %
Grafana images renderer on-demand	避免高并发快照 OOM
fanout_storage 读缓冲 512 MiB	大盘切换延迟 < 1 s

9 | 运维自动化脚本片段

#!/usr/bin/env bash
# upgrade-prom.sh
set -e
VER="$1"
curl -sL https://github.com/prometheus/prometheus/releases/download/v${VER}/prometheus-${VER}.linux-amd64.tar.gz \
 | tar -xz -C /usr/local
ln -sf /usr/local/prometheus-${VER}.linux-amd64 /usr/local/prom
systemctl restart prometheus
echo "Prometheus upgraded to ${VER}"

结合 Ansible 把 VER 作为变量即可一键灰度。

• 实施后 30 天内，我们实现：
• P0 事故平均恢复时间 从 32 min → 7 min
• 链路可观测覆盖率 95 % → 100 %
• DB 慢查询占比 降低 43 %（依赖直观 p99 面板驱动优化）

这套以 Prometheus 3.4 + Grafana 11.6 为核心、辅以 Thanos、Loki、Tempo 的全链路监控体系，满足了香港服务器跨境业务对高可用、灵活可视化、秒级告警的严格要求。希望我的实战记录能帮你少走弯路，如果在落地过程中遇到任何细节问题，欢迎随时交流！