关键在于分层设计和职责分离：日志采集轻量可靠，指标收集细粒度可扩展，告警规则精准克制，可视化聚焦业务上下文；各层需按场景选型、统一标准、集中管理、分级归档。
Linux 环境下的日志自动化监控与指标分析，关键不在堆工具，而在分层设计和职责分离：日志采集要轻量可靠，指标收集要细粒度可扩展，告警规则要精准克制，可视化要聚焦业务上下文。
日志采集层：按场景选型，避免单点依赖
系统级日志（如 /var/log/messages、journalctl 输出）优先用 Filebeat 或 Fluentd，它们资源占用低、支持 TLS 加密传输、失败自动重试；容器环境则直接对接 cAdvisor + Prometheus Pushgateway，避免日志文件落地带来的 I/O 压力。不建议用 Logstash 做边缘采集——它 JVM 重、内存开销大，仅适合中心节点做结构化清洗。若使用 rsyslog，务必启用 `imfile` 模块并配置 `startmsg.regex` 防止多行日志截断。
指标采集层：主机+容器+应用三线并进
主机指标靠 Node Exporter（暴露 9100 端口），容器指标靠 cAdvisor（8080），两者都输出标准 Prometheus 格式；应用指标需在代码中埋点（如 Java 的 Micrometer、Go 的 Prometheus client），通过 HTTP `/metrics` 暴露。所有指标统一由 Prometheus Server 抓取，避免手动轮询或代理转发。注意：对高频率指标（如每秒请求数），建议用直采而非聚合计算，减少延迟失真。
告警与分析层：规则驱动，而非阈值硬编码
告警逻辑应基于 PromQL 表达式，例如：rate(http_requests_total{job="api"}[5m]) 判断服务停摆，<br><code>avg_over_time(node_load1[1h]) > 0.8 * count by (instance) (node_cpu_seconds_total{mode="idle"}) 识别长期过载。所有规则集中存于 Git 仓库，通过 Prometheus Operator 或 relabel_configs 动态加载。避免在 Kibana 或 Grafana 中设置“页面刷新触发告警”，那属于伪实时，且易漏报。
可视化与归档层：查得快，看得懂，留得住
Kibana 专注日志上下文钻取（比如点击某条错误日志，自动跳转到对应时间窗口的 CPU/内存曲线）；Grafana 负责指标趋势与 SLO 对齐（如“99% 请求延迟 ≤ 200ms”达成率仪表盘）。归档策略按数据价值分级：原始日志保留 7 天（ES hot 节点），解析后结构化字段保留 90 天（warm 节点），聚合指标保留 2 年（冷存储或对象存储）。删除动作必须通过 curator 或 ILM 策略自动执行，禁止人工 rm -rf。
