企业官网建设流程全解析

应用埋点与告警闭环 —— 从业务异常感知到底层根因

系列博客第 6 篇（终）。用 Flask Demo 演示 RED 方法埋点，串起"指标 → 告警 → 事件 → 闭环"全链路。

一、应用监控的两种姿势

本文用埋点为主，日志为辅。

二、Demo 应用的 RED 埋点

Demo 是一个 Flask 订单服务，按RED 方法埋了 5 个指标：

# 1. 请求计数（Rate + Errors）http_requests_total=Counter('http_requests_total','...',['method','endpoint','status'])# 2. 请求耗时（Duration，直方图自动算 P50/P90/P99）http_request_duration_seconds=Histogram('http_request_duration_seconds','...',['endpoint'])# 3. 活跃连接（饱和度）active_connections=Gauge('active_connections','...')# 4. 业务订单数（业务指标）business_orders_total=Counter('business_orders_total','...',['status'])# 5. 订单金额（业务指标，直方图）business_order_value=Histogram('business_order_value','...',['category'])

2.1 /metrics 端点

Flask 暴露标准 Prometheus 端点：

@app.route('/metrics')defmetrics():returngenerate_latest(),200,{'Content-Type':CONTENT_TYPE_LATEST}

Prometheus 抓取113.44.133.102:8080/metrics即可。

2.2 流量生成

用 5 个线程持续打请求（含 5% 失败率），让指标"活"起来：

systemctlenable--nowtraffic-gen

三、用 PromQL 看应用健康

# 请求速率 (Rate) sum(rate(http_requests_total[5m])) by (endpoint) # 错误率 (Errors) sum(rate(http_requests_total{status=~"5.."}[5m])) by (endpoint) / sum(rate(http_requests_total[5m])) by (endpoint) # P99 延迟 (Duration) histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) # 业务：订单成功率 business_orders_total{status="success"} / (business_orders_total{status="success"} + business_orders_total{status="failed"}) # 业务：GMV（订单金额直方图求和） sum(business_order_value_sum) by (category)

四、告警规则设计

# 错误率 > 5% 持续 3 分钟 → 严重-alert:AppHighErrorRateexpr:|sum(rate(http_requests_total{status=~"5.."}[5m])) by (endpoint) / sum(rate(http_requests_total[5m])) by (endpoint) > 0.05for:3mlabels:{severity:critical,category:application}# P99 延迟 > 500ms-alert:AppHighLatencyexpr:histogram_quantile(0.99,rate(http_request_duration_seconds_bucket[5m]))>0.5for:5mlabels:{severity:warning,category:application}

五、完整闭环：从指标到事件

┌─────────────────────────────────┐ Demo App │ Nightingale 夜莺 │ /metrics ───────► │ │ (埋点) │ 1. 规则评估(PromQL) │ │ 2. 事件产生(告警) │ Prometheus ◄───── │ 3. 聚合收敛(同endpoint合并) │ (TSDB) │ 4. 订阅分发(钉钉/邮件) │ │ 5. 认领 → 处理 → 关闭 │ │ 6. 自愈(ibex脚本自动重启) │ └─────────────────────────────────┘ │ 工程师/值班

5.1 实战演示

故意让 Demo App 失败率飙到 5% 以上 → Nightingale 事件中心产生AppHighErrorRate告警 → 钉钉通知 → 工程师认领 → 优化代码/扩容 → 指标恢复 → 关闭事件。

全程在夜莺事件中心可回溯：谁什么时候处理的、用了多久、怎么恢复的。

六、日志监控补充

除了埋点，异常日志也是重要信号。用Loki + Promtail或ELK采集日志：

# Promtail 采集 Demo App 日志scrape_configs:-job_name:flaskstatic_configs:-targets:['localhost']labels:job:demo-app__path__:/var/log/demo-app/*.log

在 Grafana 中用 LogQL 查询：

{job="demo-app"} |= "ERROR" | json

七、总结：建立完整监控认知

经过 6 篇实战，我们打通了四层监控：

┌─────────────────────────────────────────────┐ │ 业务层 订单量/GMV/转化率 (business_*) │ ← 本文 ├─────────────────────────────────────────────┤ │ 应用层 RED 指标 / /metrics 埋点 │ ← 本文 ├─────────────────────────────────────────────┤ │ 组件层 MySQL/Redis/Kafka/ES (Exporter) │ ← 第5篇 ├─────────────────────────────────────────────┤ │ 资源层 CPU/内存/磁盘/网络 (Node Exporter) │ ← 第4篇 └─────────────────────────────────────────────┘ │ │ │ Prometheus ──► Grafana ──► Nightingale(告警闭环)

核心收获：

1. 用黄金指标统一思考任何监控对象
2. 用RED 方法做应用埋点
3. 用Prometheus 采 + Nightingale 管补齐告警闭环
4. 从业务异常感知 → 逐层下钻 → 定位根因

系列完结

所有代码、配置、脚本已开源：https://gitee.com/LiaCin/monitoring-observability-practice

本文为《运维监控实战》系列第 6 篇（终）。感谢阅读，欢迎在 Gitee 提 Issue 交流。