应用埋点与告警闭环 —— 从业务异常感知到底层根因系列博客第 6 篇终。用 Flask Demo 演示 RED 方法埋点串起指标 → 告警 → 事件 → 闭环全链路。一、应用监控的两种姿势方式原理适用埋点Metrics代码里主动打点黄金指标、业务指标日志Logs采集日志做告警异常堆栈、审计本文用埋点为主日志为辅。二、Demo 应用的 RED 埋点Demo 是一个 Flask 订单服务按RED 方法埋了 5 个指标# 1. 请求计数Rate Errorshttp_requests_totalCounter(http_requests_total,...,[method,endpoint,status])# 2. 请求耗时Duration直方图自动算 P50/P90/P99http_request_duration_secondsHistogram(http_request_duration_seconds,...,[endpoint])# 3. 活跃连接饱和度active_connectionsGauge(active_connections,...)# 4. 业务订单数业务指标business_orders_totalCounter(business_orders_total,...,[status])# 5. 订单金额业务指标直方图business_order_valueHistogram(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{statussuccess} / (business_orders_total{statussuccess} business_orders_total{statusfailed}) # 业务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 查询{jobdemo-app} | ERROR | json七、总结建立完整监控认知经过 6 篇实战我们打通了四层监控┌─────────────────────────────────────────────┐ │ 业务层 订单量/GMV/转化率 (business_*) │ ← 本文 ├─────────────────────────────────────────────┤ │ 应用层 RED 指标 / /metrics 埋点 │ ← 本文 ├─────────────────────────────────────────────┤ │ 组件层 MySQL/Redis/Kafka/ES (Exporter) │ ← 第5篇 ├─────────────────────────────────────────────┤ │ 资源层 CPU/内存/磁盘/网络 (Node Exporter) │ ← 第4篇 └─────────────────────────────────────────────┘ │ │ │ Prometheus ──► Grafana ──► Nightingale(告警闭环)核心收获用黄金指标统一思考任何监控对象用RED 方法做应用埋点用Prometheus 采 Nightingale 管补齐告警闭环从业务异常感知 → 逐层下钻 → 定位根因系列完结篇主题关键产出1架构与选型方案横评、4节点规划2Prometheus 搭建prometheus.yml、PromQL 实战3Nightingale 部署告警增强、事件闭环4机器与网络Node Exporter、Categraf5中间件监控MySQL/Redis/Kafka/ES6应用与告警本文RED 埋点、闭环演示所有代码、配置、脚本已开源https://gitee.com/LiaCin/monitoring-observability-practice本文为《运维监控实战》系列第 6 篇终。感谢阅读欢迎在 Gitee 提 Issue 交流。