日志监控是将原始日志转化为可查、可算、可告警、可决策的数据资产，核心要求采集不丢、格式统一、存得稳、查得快、分析准、告得及时。
日志监控不是单纯“看日志”，而是把原始日志变成可查、可算、可告警、可决策的数据资产。核心在于：采集不丢、格式统一、存得稳、查得快、分析准、告得及时。
日志采集与标准化
源头决定质量。应用、Nginx、数据库等各组件必须输出结构化日志，推荐JSON格式，至少包含：
• 时间戳（ISO 8601，带时区）
• 日志级别（INFO/WARN/ERROR）
• 请求ID（用于全链路追踪）
• 用户标识（如user_id或anon_id）
• 关键业务字段（如order_id、payment_status）
• 性能字段（如response_time_ms、db_query_time_ms）
避免在日志里写模糊描述（如“系统出错了”），而应记录具体异常类名、SQL语句片段、HTTP状态码等。
集中存储与高效索引
本地文件日志只适合开发调试。生产环境必须集中管理：
• 小中型系统：用Filebeat + Elasticsearch + Kibana（EFK）组合，部署轻、上手快
• 高吞吐/长周期场景：Elasticsearch按天建索引 + ILM策略自动滚动、归档、删除；或改用ClickHouse做指标聚合存储
• 存储前务必做字段解析：用Logstash的grok或Fluentd的parser插件，把非结构化日志拆成结构化字段，比如从"GET /api/order?id=123 HTTP/1.1" 200 456中提取method、path、status、bytes_sent
• 敏感字段（如手机号、身份证号）必须在采集层脱敏，不能依赖后端过滤。
关键指标提取与实时分析
日志本身不是指标，需要转化：
• 响应时间P95 > 1200ms → 每分钟统计一次，触发阈值告警
• 4xx/5xx错误率连续3分钟 > 3% → 实时计算窗口内错误请求数 / 总请求数
• 慢查询（db_query_time_ms > 500）每分钟超10次 → 关联trace_id定位服务节点
• 登录失败IP 5分钟内≥5次 → 触发安全告警并联动防火墙封禁
这些计算可通过Elasticsearch的Transform、Grafana Loki的LogQL，或Flink实时流处理实现。不要等“人工翻日志”才发现问题。
可视化+告警+闭环响应
监控的价值在“被看见”和“被处理”：
• 在Grafana中搭建核心仪表盘：首页展示QPS、错误率、平均响应时间、TOP5慢接口、异常IP地理分布
• 告警分级：ERROR级日志直接企微/钉钉推送；WARN级汇总为日报；DEBUG级仅存档供追溯
• 告警必须带上下文：不只是“错误率升高”，还要附带最近3条典型错误日志、对应trace_id、影响的服务名
• 推荐配置静默期（如同一错误10分钟内不重复通知）和升级机制（20分钟未响应转给二线）
• 最终闭环：每次告警应关联到工单系统，记录根因和修复动作，形成知识沉淀。
基本上就这些。流程不复杂，但容易忽略的是日志规范落地和告警有效性验证——上线前用模拟流量跑一遍全链路，确认从日志产生→采集→解析→存储→查得到→算得对→告得准，才算真正跑通。
