30分钟搭好Web应用监控Prometheus与Apache指标抓取告警完整教程【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheusPrometheus 是一个开源的监控系统与时间序列数据库本文用 Prometheus 搭配 Apache Exporter为你搭建一套完整的 Web 应用监控自动采集 Apache 服务器的请求、连接与进程指标在异常时发出告警让响应变慢、连接打满这类问题在几分钟内就能定位到实例和原因。最终会搭出什么先说结论这套系统由三层组成采集层Apache Exporter 部署在能访问 Apache 的机器上定时读取server-status输出把请求数、连接数、worker 进程状态转换成 Prometheus 格式暴露在 9117 端口。存储与查询层Prometheus 按 15 秒一次的频率抓取这些指标写入本地 TSDB并支持 PromQL 查询与告警规则评估。通知层告警触发后Prometheus 把事件推给 Alertmanager由其按路由规则通知到值班渠道。这套架构里Prometheus 自己也是被监控对象之一抓取自己 9090 端口的指标后面配抓取时顺带加上即可。采什么三类 Apache 指标别漏Exporter 暴露的指标很多做 Web 应用监控先盯住这三类就够了请求速率——apache_requests_total是累计请求总数配合rate(apache_requests_total[5m])得到每秒请求量用于发现流量突增或请求突然消失往往是服务不可用的前兆。连接状态——apache_connections表示当前活跃连接apache_connections_idle表示空闲连接。活跃连接逼近上限、空闲连接长期为 0通常意味着请求在排队是响应变慢的直接信号。进程状态——apache_currently_busy_workers与apache_max_workers的比值反映 worker 利用率apache_process_cpu_user与apache_process_rss则能解释CPU 突增、内存爬升到底是计算密集还是内存泄漏。这三类指标互相配合连接数涨 请求速率跌多半是服务被拖住worker 打满 CPU 高多半是负载真实增长。怎么采三步配好抓取第一步部署 Apache Exporter。在能连通 Apache 的机器上运行它它通过server-status端点如http://apache:80/server-status?auto拉取原始状态数据自身无需额外依赖。第二步写抓取配置。在 Prometheus 配置文件中追加一个抓取 job最小可用版本如下global: scrape_interval: 15s scrape_timeout: 10s scrape_configs: - job_name: apache static_configs: - targets: [apache-exporter:9117] labels: env: productionstatic_configs换成你的实际地址多实例直接在 targets 里加行。配置字段详解可参考 docs/configuration/configuration.md。改完配置发送SIGHUP或调用/-/reload即可热加载无需重启进程。第三步验证目标是否健康。打开 Prometheus 的 Targets 页面或跑一次promtool check config prometheus.yml源码在 cmd/promtool/确认 apache job 状态为 UP且能看到up{jobapache}这条序列说明抓取链路已打通。如果目标不是固定 IP比如容器环境频繁漂移可以把static_configs换成文件、Kubernetes 等服务发现方式实现代码在 discovery/HTTP 服务发现的用法见 docs/http_sd.md。怎么告警三条规则覆盖主要故障在规则文件里定义告警思路是每条规则对应一类你愿意半夜被叫醒的故障groups: - name: apache rules: - alert: ApacheInstanceDown expr: up{jobapache} 0 for: 5m labels: severity: critical annotations: summary: Apache 指标实例 {{ $labels.instance }} 已 5 分钟不可达 - alert: ApacheWorkersSaturated expr: apache_currently_busy_workers / apache_max_workers 0.9 for: 10m annotations: summary: {{ $labels.instance }} worker 使用率超过 90% - alert: ApacheRequestRateDrop expr: rate(apache_requests_total[5m]) 1 for: 15m annotations: summary: {{ $labels.instance }} 请求速率异常偏低疑似服务不可用三条规则的分工up 0兜底所有采集断了的场景必须最先配worker 饱和率是 Apache 特有的瓶颈指标请求速率骤降则能抓住那些进程还活着、但已经不在干活的隐蔽故障。for字段是防抖动的关键——持续 10 分钟才告警可以过滤掉瞬时毛刺。规则的完整语法templating、keep_firing_for等见 docs/configuration/alerting_rules.mdPrometheus 评估规则后通知的发送由 notifier/ 模块对接 Alertmanager 完成在配置的alerting:段填上 Alertmanager 地址即可。怎么看指标上线后的验证查询配置完成后用 PromQL 回答这套监控到底看到了什么。语法速查在 docs/querying/basics.md下面四个查询建议存进你的查询收藏夹# 各实例每秒请求速率流量趋势一目了然 rate(apache_requests_total[5m]) # 非空闲连接数活跃连接近似值 apache_connections - apache_connections_idle # 当前请求量 Top 5 实例定位流量倾斜 topk(5, rate(apache_requests_total[5m])) # worker 利用率饱和度告警的原始数据 apache_currently_busy_workers / apache_max_workers把它们拖进 Prometheus 的 Graph 页面和告警时间点对照看就能验证规则阈值是否合理——如果阈值长期贴着实际值波动说明该调整了。注意事项与调优建议抓取间隔别盲目调小15s 对大多数 Web 场景足够。间隔越小Prometheus 的内存与磁盘占用越高Exporter 侧拉取server-status的频率也随之上升。加上防过载保护在抓取配置中设置sample_limit、body_size_limit避免某个异常实例把整个抓取打爆字段定义见 docs/configuration/configuration.md。告警分级而不是全量 pagecritical实例 down、worker 打满走电话/IM 强提醒warning 级速率波动、内存缓涨进日报即可否则阈值疲劳会让真告警被忽略。保留周期匹配排查习惯--storage.tsdb.retention.time至少保留两周方便和上周同期对比流量曲线数据量大时可加retention.size双保险机制说明在 docs/storage.md。先采全再裁剪Exporter 指标较多先全量抓几天用count by(__name__)({jobapache})看看序列规模再决定用metric_relabel_configs丢弃哪些。照着上面的顺序做完你手里就有了一套能回答Apache 现在忙不忙、卡在哪、哪台实例在拖后腿的 Web 应用监控。后续想扩展把同样的三步Exporter → 抓取 → 规则复制到 Nginx、MySQL 等其他 Exporter 上即可。【免费下载链接】prometheusThe Prometheus monitoring system and time series database.项目地址: https://gitcode.com/GitHub_Trending/pr/prometheus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考