telegraf适合多源指标采集，node exporter专精linux系统指标且与prometheus天然对齐；告警逻辑写在prometheus，alertmanager只负责通知；grafana中prometheus查指标、loki查日志、tempo查链路；高可用场景thanos更轻量，但指标生命周期管理比组件选型更关键。
监控数据采集层该用 Telegraf 还是 Prometheus Node Exporter
Telegraf 更适合统一采集多源指标（数据库、API、日志），Node Exporter 专精于 Linux 系统级指标，且与 Prometheus 生态天然对齐。选错会导致指标语义混乱、relabel 规则爆炸。
- 如果你只监控主机 CPU/内存/磁盘/网络，
node_exporter是默认选择：轻量、稳定、指标命名规范（如node_cpu_seconds_total），Prometheus 直接 scrape 即可 - 若需同时拉取 MySQL 的
mysql_global_status_threads_connected、Nginx 日志中的 5xx 计数、或自定义 shell 脚本输出，telegraf的插件机制更可控，但必须手动配置outputs.prometheus_client暴露端口，否则无法被 Prometheus 抓取 - 常见坑：
telegraf默认不开启prometheus_client输出；node_exporter在容器中运行时若未加--privileged或挂载/proc//sys，会大量报no such file or directory
告警规则写在 Prometheus 还是 Alertmanager
规则逻辑（“什么条件触发告警”）必须写在 Prometheus 的 alert.rules.yml，Alertmanager 只负责“怎么通知”和“谁来处理”。混用会导致静默失效、重复告警或规则不生效。
-
prometheus.yml中的rule_files指向的是告警判断逻辑，例如：expr: 100 * (node_memory_MemTotal_bytes - node_memory_MemFree_bytes) / node_memory_MemTotal_bytes > 90 -
alertmanager.yml里配的是路由树（route）、静默（inhibit_rules）、通知方式（email_configs、webhook_configs），它不解析 PromQL - 容易踩的坑：把阈值判断写进 Alertmanager 的
inhibit_rules—— 它只支持匹配标签，不能做数值计算；改了alert.rules.yml必须curl -X POST http://localhost:9090/-/reload或重启 Prometheus，否则规则不加载
Grafana 面板数据源选 Prometheus 还是 Loki + Tempo
Prometheus 用来查指标趋势（“CPU 用了多少”），Loki 查日志原文（“报错堆栈在哪一行”），Tempo 查链路追踪（“请求卡在哪个服务”）。三者不能互相替代，但常被误当成同一类数据源配置。
同徽B2C电子商务软件系统
下载
开发语言：java，支持数据库：Mysql 5，系统架构：J2EE，操作系统：linux/Windows1. 引言 32. 系统的结构 32.1 系统概述 33. 功能模块设计说明 43.1 商品管理 43.1.1 添加商品功能模块 53.1.2 商品列表功能模块 83.1.3 商品关联功能模块 93.
- 看 CPU 使用率、HTTP 请求数、GC 次数，必须用 Prometheus 数据源，用
rate(http_requests_total[5m])这类聚合函数 - 定位一次超时请求的具体错误日志，得切到 Loki 数据源，用
{job="api-server"} |= "timeout"过滤，再点开某条日志下钻到 Tempo 查 trace_id - 关键细节：Grafana 的变量（
$instance）在 Prometheus 数据源里能自动补全，在 Loki 里默认不支持 label 查询补全，需手动配置loki的derivedFields或用explore模式临时查
监控系统高可用绕不开 Thanos 或 Cortex 吗
单 Prometheus 实例扛不住 10 万以上时间序列或跨机房查询时，Thanos 是目前最轻量、侵入性最小的方案；Cortex 更重，适合已深度绑定 Kubernetes 和对象存储的团队。
- Thanos 只需在现有 Prometheus 上加一个
thanos-sidecar，再起thanos-query和thanos-store，就能实现全局视图、长期存储（对接 S3/MinIO）、降采样——不用改采集逻辑 - Cortex 要求所有组件（distributor、ingester、querier）全部部署，且指标必须走 Cortex 自己的
/api/v1/push接口，原有scrape配置基本作废 - 真实陷阱：Thanos 的
objstore.s3配置里，bucket名写错或权限没开，thanos-store会静默失败，日志只打印failed to get object，得盯紧thanos-tools bucket ls命令是否能列出文件
架构里最易被忽略的不是组件选型，而是指标生命周期管理：旧指标不清除，TSDB 就会膨胀；label 设计不合理（比如把请求 URL 当 label），一个接口带参数就生成几百个 series，压垮 Prometheus。这比选什么工具都致命。
