根本原因是 node_memory_memfree_bytes 仅表示内核未使用的物理内存，不含可回收缓存（如 pagecache、slab），而 free -h 的 available 字段包含可快速回收的缓存；应改用 node_memory_memavailable_bytes 或计算 node_memory_memfree_bytes + node_memory_cached_bytes + node_memory_buffers_bytes。
用 Grafana 展示 Prometheus 数据时，为什么 localhost:9090 能连通但图表一直显示 “No data”
根本原因通常是数据源配置里没填对 http://prometheus:9090 这类容器内可解析的地址，或 Grafana 容器没和 Prometheus 在同一网络。本地浏览器访问 localhost:9090 成功，不代表 Grafana 容器能访问它——Docker 默认网络是隔离的。
- 如果 Prometheus 和 Grafana 都用 Docker 运行，
data source URL必须填容器名（如http://prometheus:9090），不能填localhost或127.0.0.1 - 启动时加
--network=monitoring并让两个容器加入同一自定义网络，比用bridge默认网更可靠 - 在 Grafana UI 的
Data Sources → Prometheus → Save & Test失败时，点右上角Inspect查看真实错误：常见是connection refused或timeout，不是查询语法问题
写 Prometheus 查询语句时，rate() 和 irate() 该选哪个
多数监控场景下优先用 rate()；irate() 只适合看“最近一次变化趋势”，比如突发流量尖峰，但它对样本抖动极度敏感，容易误报。
-
rate(http_requests_total[5m])计算 5 分钟窗口内每秒平均请求数，平滑、稳定，适合做告警和长期趋势图 -
irate(http_requests_total[5m])只取最近两个样本点算瞬时速率，若采集间隔不稳（如因负载高漏采），结果会跳变甚至为负 - 在 Grafana 面板中直接写
sum(rate(...))比先sum(...) then rate(...)更安全，避免聚合后无法计算速率
Grafana 中添加 Node Exporter 主机指标时，为什么 node_memory_MemFree_bytes 显示值远低于 free -h
这是 Linux 内存管理机制导致的正常现象：node_memory_MemFree_bytes 是内核视角的“完全空闲内存”，不含 page cache、buffers 等可回收部分；而 free -h 的 available 列才接近实际可用量。
- 真正反映内存压力的是
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 - 不要用
MemFree做告警阈值，它常年偏低，容易触发误告 - Node Exporter v1.0+ 已默认暴露
node_memory_MemAvailable_bytes，旧版本需确认是否启用--collector.meminfo
用 curl 手动触发 Alertmanager 告警测试时，收不到通知
Alertmanager 不接收原始指标，只收符合其 API 格式的告警请求；直接 curl -X POST http://alert:9093/api/v2/alerts 发 raw JSON 很可能被静默丢弃，因为缺少必要字段或时间戳格式错。
- 必须带
startsAt字段，且格式为 RFC3339（如"2024-05-20T10:00:00Z"），不能是时间戳数字或本地时间字符串 - 至少包含
labels（如{"alertname": "TestHighCPU", "instance": "localhost:9100"}）和annotations（如{"summary": "manual test"}） - 检查 Alertmanager 日志：
level=warn msg="Bad alert" err="start time is in the future"这类提示说明时间字段有问题
Grafana 图表背后依赖的数据链路很短，但每个环节（Prometheus 抓取、Exporter 暴露、Grafana 查询、Alertmanager 路由）都有明确的“契约”要求。最容易卡住的地方不是功能不会用，而是默认假设了网络通、时间对、字段存在——而这些恰恰在跨容器、跨版本、跨时区时最不可靠。
