InfluxDB无法直接监控Composer镜像流量，必须通过Nginx日志→Telegraf解析→Flux查询→通知规则的链路实现；核心在于确保日志采集正确、数据写入目标bucket、Flux逻辑区分异常模式，并验证权限与时间同步。
InfluxDB 本身不直接支持 Composer 镜像流量监控，必须靠外部采集 + Flux 检查逻辑实现报警 —— 这是前提，不是配置漏了就能绕过去的。
为什么不能直接用 InfluxDB 自带的 CHECKS 监控 Composer 流量
InfluxDB 的 CHECKS 只能读取它已有的数据，而 Composer 镜像（如 packagist.org 或私有镜像）的下载请求根本不会自动写入 InfluxDB。你看到的“报警系统”实际是三段拼起来的：Nginx/Apache 日志 → Telegraf 解析并写入 → Flux 脚本定时查 bucket → 触发 NOTIFICATION RULES。
常见错误现象：
- 在 Web UI 里新建一个
CHECK，选了 bucket 和 measurement，但始终没信号输出 —— 数据压根没进来 - 写了 Flux 查询，
from(bucket: "mirror") |> range(start: -5m)返回空表 —— 不是语法错，是 Telegraf 根本没把 access log 解析进去
所以第一步不是配 CHECK，而是确认日志是否落地为时序点：检查 telegraf.conf 中 [[inputs.tail]] 是否监听了 Nginx 的 access.log，且 data_format = "grok" 的 pattern 能正确提取 status、bytes_sent、request_time 等字段。
Telegraf 抓取 Nginx 日志的关键配置项
Composer 镜像服务通常跑在 Nginx 上，流量异常本质是 HTTP 请求突增/失败率飙升/大包下载集中。Telegraf 必须从 access.log 提取结构化指标，而不是靠 http_response 插件去轮询 —— 那样只能测连通性，测不了真实流量。
实操建议：
- 确保 Nginx
log_format包含$status、$body_bytes_sent、$request_time、$request_uri（用于识别/downloads/类路径） - 在
telegraf.conf中启用[[inputs.tail]]，files = ["/var/log/nginx/access.log"]，grok_patterns = ["%{COMMON_LOG_FORMAT} %{NUMBER:request_time:float}"] - 用
measurement_name = "composer_mirror_requests"显式命名，避免默认的tail表名造成混淆 - 加
[[outputs.influxdb_v2]]，bucket = "mirror-traffic"，确保写入目标 bucket 存在且 token 有写权限
验证方式：执行 telegraf --config telegraf.conf --test | head -n 5，看输出是否含 composer_mirror_requests,host=...,status=200 request_time=0.012345i 1718684231000000000 这类行。
Flux 报警脚本里必须区分“突增”和“绝对值超标”
单纯查 status == 200 并设阈值没意义 —— Composer 安装本来就是短时密集行为。真正要捕获的是异常模式，比如：
- 5 分钟内 5xx 错误率 > 5%（说明镜像服务崩了）
- 单 IP 每分钟请求数 > 100（可能是爬虫或恶意刷量）
- 平均
request_time突增 3 倍且持续 2 分钟（后端存储或 CDN 故障）
示例 Flux 片段（用于 CRIT 级别）：
import "influxdata/influxdb/monitor"
import "experimental"
data = from(bucket: "mirror-traffic")
|> range(start: -5m)
|> filter(fn: (r) => r._measurement == "composer_mirror_requests")
|> filter(fn: (r) => r.status =~ /^5../)
errors = data
|> count()
|> findRecord(fn: (key) => true, idx: 0)
total = data
|> limit(n: 1)
|> count()
rate = if errors._value != 0 and total._value != 0 then float(v: errors._value) / float(v: total._value) else 0.0
if rate > 0.05 then monitor.notify(
data: { _time: now(), _level: "CRIT", _message: "5xx error rate > 5%" },
endpoint: endpoint
) else { _time: now(), _level: "OK" }
注意：monitor.notify() 的 endpoint 必须提前在 UI 里配好 NOTIFICATION ENDPOINTS，比如指向一个接收 POST 的钉钉机器人；range(start: -5m) 是硬编码窗口，生产环境建议用 task.every 控制执行频率，避免重复触发。
容易被忽略的权限与路径陷阱
即使脚本逻辑全对，以下两点仍会导致 CHECK 一直显示 “No data”：
-
INFLUXD_ENGINE_PATH和INFLUXD_BOLT_PATH混用同一目录 —— 启动报failed to open bolt DB，但日志里不提示具体路径冲突，只卡在初始化阶段 - Telegraf 写入时用的 token 权限不足：必须包含
Write权限到目标 bucket，且 org 名称与 token 绑定的 org 一致（InfluxDB 2.x 强绑定 org/bucket，不能跨 org 查） - Flux 脚本里用了
system.time()或now()，但服务器时区与 InfluxDB 系统时间不同步 —— 导致range()查不到刚写入的数据（差几秒就查空）
最稳妥的调试顺序：先用 influx query CLI 手动跑 Flux 查数据是否存在 → 再确认 CHECK 关联的 Flux 脚本内容是否和 CLI 里一致 → 最后检查 notification rule 是否绑定了正确的 check 和 endpoint。中间任何一环断开，报警就静默失效。
