| Linux企业级运维架构工程师 Prometheus+Docker+Jenkins+ZB+NG+keepalived+lvs+Kafka |

从监控混沌到可观测性稳态：基于Prometheus与LVS的亿级指标高可用架构设计

作者：资深运维架构师
标签：#监控 #高可用 #DevOps #架构设计

引言：当监控本身成为瓶颈

（关注简介学习更多）
在云原生时代，我们习惯用Prometheus解决一切监控问题，但在日吞吐量亿级的指标规模下，单点Prometheus会成为宕机木桶中最短的那块板。本文将展示我们如何利用 LVS + Keepalived 构建Prometheus网关层，结合 Kafka 做异步解耦，并联动 Jenkins + Docker 实现监控配置的CI/CD，最终配合 Zabbix 处理传统网络设备的最后一公里监控，构建一套无单点、可扩展、自修复的运维观测体系。

第一章 架构设计的困局与破局

1.1 为何抛弃“All in One”的Zabbix？

在很多传统企业中，Zabbix依然是网络监控的王者。但对于Kubernetes动态节点和微服务指标，Zabbix的宏变量和自动发现机制显得笨重。因此，我们的策略是：

• Zabbix 负责：物理机硬件、交换机SNMP、中间件端口存活。

• Prometheus 负责：应用性能（RED方法）、Kubernetes容器、业务埋点。

1.2 业务痛点与解决路径

第二章 流量入口：LVS + Keepalived 的高可用网关

在Prometheus高可用方案中，我们摒弃了Nginx反向代理，原因在于Nginx需要额外的健康检查脚本且故障切换存在秒级延迟。我们采用 LVS DR模式 + Keepalived 构建四层负载均衡。

2.1 架构设计

• VIP: 192.168.100.100

• Master LVS: 192.168.100.11

• Backup LVS: 192.168.100.12

• RealServer: Prometheus主节点A、主节点B (Federation模式)

Keepalived核心配置（非抢占式）

text

vrrp_instance VI_1 {
state BACKUP # 双主互备，均设为BACKUP配合nopreempt
interface eth0
virtual_router_id 51
priority 150 # Master为150，Backup为100
nopreempt
advert_int 1
authentication {
auth_type PASS
auth_pass 1234
}
virtual_ipaddress {
192.168.100.100/24 dev eth0 label eth0:1
}
}

2.2 为什么不用Nginx做四层？

踩坑教训：Nginx的stream模块在长连接场景下内存泄漏明显，且reload时会有短暂连接断开。LVS工作在内核态，转发效率是Nginx的3倍以上，且对RS的健康检查通过keepalived的check脚本实现，故障剔除毫秒级。

第三章 配置即代码：Jenkins + Docker 实现Prometheus动态下发

生产环境中，每新增一个微服务就需要手动修改prometheus.yml，这违反SRE原则。我们设计了一套基于Jenkins Pipeline的自动化配置发布系统。

3.1 目录结构标准化

text

prometheus-config/
├── targets/
│ ├── kafka.json
│ └── app_java.json
├── rules/
│ ├── alert_rules.yml
│ └── recording_rules.yml
└── prometheus.yml

3.2 Dockerfile 构建监控镜像

text

FROM prom/prometheus:v2.45.0
COPY prometheus.yml /etc/prometheus/
COPY targets/ /etc/prometheus/targets/
COPY rules/ /etc/prometheus/rules/
CMD [“–config.file=/etc/prometheus/prometheus.yml”,
“–storage.tsdb.retention.time=15d”,
“–web.enable-lifecycle”] # 开启热加载接口

3.3 Jenkins Pipeline关键步骤

groovy

stage(‘Config Validate’) {
sh ‘promtool check config prometheus.yml’
}
stage(‘Rollout’) {
sh ‘docker build -t prometheus-config:${BUILD_ID} .’
sh ‘docker push registry.local/prometheus-config:${BUILD_ID}’
// 触发容器滚动重启，或调用 POST /-/reload
sh ‘curl -X POST prometheus-vip:9090/-/reload'
}

关键技巧：务必在Pod中挂载/etc/prometheus为emptyDir，通过sidecar容器拉取最新配置并cp覆盖，实现配置热更新零中断。

第四章 削峰填谷：Kafka 作为Prometheus的“前置缓冲”

Prometheus默认Pull模型在遇到网络抖动或目标Pod重启时，容易导致scrape_timeout。对于Kafka消费者延迟这类突发性指标，Pull模型显得被动。我们引入 Kafka Exporter + Prometheus Pushgateway 变种方案。

4.1 为什么Kafka不是存储，而是桥梁？

• 业务侧将指标（JSON格式）发送至Kafka Topic metrics_raw。

• 开发 Metric Gateway Consumer（Go语言），消费Kafka后将指标转换成Prometheus的Exposition格式，暴露给Prometheus抓取。

• 收益：解耦业务埋点与监控系统的网络抖动。

4.2 实战：Zabbix与Prometheus通过Kafka握手

我们不再使用Zabbix的AlertScripts直接发告警，而是让Zabbix将异常事件（如CPU > 90%）序列化推送到Kafka，由Prometheus的Alertmanager统一进行告警路由。这实现了传统监控与云原生监控的事件融合。

第五章 传统运维的最后防线：Zabbix 7.0 与 Prometheus 的远程读写

物理机宕机、交换机光衰是Prometheus无法覆盖的。我们的设计是将Zabbix纳入Prometheus生态。

5.1 Zabbix 开启 Prometheus 指标导出

Zabbix 7.0原生支持/prometheus接口，可以导出所有Item数据。

text

Zabbix Server配置

ListenIP=0.0.0.0
ListenPort=10051
StartHTTPAgents=10

5.2 Prometheus 配置 remote_read

yaml

remote_read:

• url: “http://zabbix-server:10051/prometheus"
  read_recent: true
  basic_auth:
  username: prometheus
  password: zabbix

避坑指南：Zabbix导出的指标带有大量宏变量标签（如{#FSNAME}），会导致Prometheus高基数问题。务必在metric_relabel_configs中通过正则过滤掉动态卷挂载点，仅保留核心系统指标。

第六章 整体链路可视化与告警自愈

6.1 Grafana 接入多数据源

• 展示 LVS 连接数（通过ipvsadm exporter）。

• 展示 Kafka 消费Lag（通过Burrow exporter）。

• 展示 Zabbix 主机存活状态。

6.2 告警路由设计

Alertmanager配置路由树：

1. 严重级（节点Down）：直接触发电话告警，并发给值班长。

2. 警告级（CPU > 80%）：发送至钉钉，并自动触发Jenkins Job执行扩容脚本。

第七章 生产环境避坑总结

1. Prometheus 内存爆炸：开启TSDB块压缩，配合--storage.tsdb.retention.size=100GB限制磁盘，防止mmap内存溢出。

2. LVS 会话保持问题：DR模式需确保RS内核参数arp_ignore=1且arp_announce=2，否则VIP回包异常。

3. Jenkins 频繁热加载卡死：Prometheus热加载时会阻塞/metrics拉取，建议在凌晨低峰期触发CI/CD发布。

4. Nginx 与 Keepalived 并存：如果Nginx做七层，Keepalived必须配置track_script检测Nginx进程，防止Nginx挂掉而VIP未漂移。

结语

这套架构在我们实际生产环境中支撑了日均 1.2亿 的时间序列写入，故障恢复时间（MTTR）从原来的15分钟降低至 2分钟。运维架构的核心不在于使用多新的技术，而在于如何将 Zabbix（稳定）、Prometheus（敏捷）、Kafka（缓冲）、LVS（性能） 融合成符合企业现状的有机体。

希望本文能帮助你在从传统运维向云原生转型的迷雾中，找到那条兼顾现实与未来的路径。

互动话题：你在融合传统监控（Zabbix）和云原生监控（Prometheus）时，遇到的最大标签冲突问题是什么？欢迎评论区讨论。

本作品采用《CC 协议》，转载必须注明作者和本文链接