RepoSiliconFlowSiliconFlowpublished Jul 20, 2026seen 5d

siliconflow/silinex-monitor

Shell

Open original ↗

Captured source

source ↗
published Jul 20, 2026seen 5dcaptured 5dhttp 200method plain

siliconflow/silinex-monitor

Language: Shell

Stars: 0

Forks: 0

Open issues: 0

Created: 2026-07-20T11:00:36Z

Pushed: 2026-07-20T11:16:55Z

Default branch: main

Fork: no

Archived: no

README:

Kafka 监控说明

这套配置在当前工作区本地运行。kafka_exporter 连接测试环境的单节点 Kafka,Prometheus 采集指标并计算告警,Alertmanager 接收告警,Grafana 展示监控数据。

启动本地整体环境

先在仓库根目录启动当前工作区的中间件和业务服务:

./dev/bin/srdev setup

setup 会重置 dev 专用数据并执行构建、初始化和启动。已有可用数据且不需要重新构建时,可以执行:

./dev/bin/srdev start

然后启动监控:

docker compose --env-file kafka-monitoring/.env -f kafka-monitoring/docker-compose.yml up -d --pull never

当前 Kafka Broker 地址为 10.60.30.2:19702,使用无认证连接。地址在 kafka-monitoring/.envKAFKA_BROKER 中配置。Grafana 使用 3001 端口,避免和本地前端的 3000 端口冲突。

验证

docker compose --env-file kafka-monitoring/.env -f kafka-monitoring/docker-compose.yml ps
curl -s http://127.0.0.1:9308/metrics
curl -s http://127.0.0.1:9090/-/healthy
curl -s http://127.0.0.1:9093/-/healthy

测试环境预期可发现 1 个 Broker。Grafana 地址为 http://localhost:3001,Prometheus 地址为 http://127.0.0.1:9090,Alertmanager 地址为 http://127.0.0.1:9093

消费积压由 kafka:consumer_group_lag:sum 预计算指标统一处理:把无有效位点产生的负值按 0 计算,并排除 runtime-checkruntime-count 测试消费组。看板和告警共同使用该指标,避免统计口径不一致。

生产速率和消费速率根据最近 5 分钟位点变化计算,单位为条/秒。生产速率按 Topic 汇总,消费速率按消费组和 Topic 汇总,测试消费组不参与消费速率统计。

执行配置和告警规则测试:

bash kafka-monitoring/tests/config-test.sh
docker run --rm --pull never --entrypoint promtool \
-v "$PWD/kafka-monitoring:/work:ro" -w /work/tests \
prom/prometheus:v3.5.0 test rules kafka-alerts.test.yml

通知渠道

alertmanager/alertmanager.yml 当前使用空的 operations 接收器,只验证告警生成、送达和解除,不会发送外部通知。需要外部通知时,再按实际渠道配置 Webhook、邮件或转换服务;令牌和密钥不要提交到版本库。

飞书自定义机器人

飞书通知使用 XUJiahua/alertmanager-webhook-feishu v0.1.11 适配器。该项目的官方镜像只有 linux/amd64 架构,Apple Silicon 本地环境会通过容器模拟运行。

1. 在飞书群中添加自定义机器人,安全设置至少配置关键词 Kafka 或出口 IP 白名单。该适配器不支持飞书签名校验,不建议直接用于正式环境。 2. 根据示例创建受保护的配置:

cp kafka-monitoring/feishu/config.example.yml kafka-monitoring/secrets/feishu.yml

REPLACE_WITH_FEISHU_BOT_WEBHOOK 替换为真实机器人 Webhook。secrets/ 已被 Git 忽略,不要把地址写入其他配置文件。

3. 需要先准备适配器镜像:

docker pull --platform linux/amd64 johnxu1989/alertmanager-webhook-feishu:v0.1.11

4. 使用飞书覆盖配置启动:

FEISHU_CONFIG_FILE="$PWD/kafka-monitoring/secrets/feishu.yml" \
docker compose \
--env-file kafka-monitoring/.env \
-f kafka-monitoring/docker-compose.yml \
-f kafka-monitoring/docker-compose.feishu.yml \
up -d --pull never

启动飞书通知时必须同时加载两个 Compose 文件。只使用基础配置启动会让 feishu-webhook 变成孤立容器,同时 Alertmanager 仍使用空接收器,不会发送飞书消息。

已经启动过基础配置时,使用下面的命令重建 Alertmanager 和飞书适配器:

FEISHU_CONFIG_FILE="$PWD/kafka-monitoring/secrets/feishu.yml" \
docker compose \
--env-file kafka-monitoring/.env \
-f kafka-monitoring/docker-compose.yml \
-f kafka-monitoring/docker-compose.feishu.yml \
up -d --pull never --force-recreate alertmanager feishu-webhook

适配器接收 Alertmanager 原始消息,转换为飞书消息卡片,并分别发送告警触发和解除通知。排查时查看 feishu-webhookalertmanager 两个服务的日志。

飞书卡片使用 feishu/templates/kafka-card.tmpl 自定义模板,集中显示告警状态、严重级别、环境、Kafka 集群、消费组、Topic、详情和北京时间,并提供本地 Grafana 看板按钮。看板地址由飞书配置中的 metadata.dashboard_url 控制。修改模板或飞书配置后需要重启 feishu-webhook 服务才能生效。