yii2对接elk需两层打通：一是输出结构化json日志（含timestamp、level、category等字段），二是通过filebeat→kafka/logstash→es分层传输；logstash解析补全元数据，kibana构建错误率、top异常、慢请求等sre视图并配置告警。
Yii2 日志组件本身轻量灵活，但要对接 ELK 栈实现集中化、可分析、可告警的运维监控能力，不能只靠默认文件写入。关键在于两层打通：一是让 Yii2 输出结构化、带上下文的 JSON 日志；二是让日志能稳定、低损、可追溯地流入 ELK 流水线。
Yii2 端：输出结构化日志
默认 FileTarget 输出的是纯文本，不利于 Logstash 解析。需改造为 JSON 格式，并注入关键运维字段：
- 在 config/web.php 或 config/main.php 的 log 组件中，替换 FileTarget 为自定义 JSON 目标类（或直接使用第三方扩展如
yii2-log-json） - 确保每条日志包含：timestamp（ISO8601）、level（error/warning/info）、category（如 'app.api'、'app.db'）、message、trace_id（配合 MDC 或中间件生成）、user_id（登录态可选）、request_id
- 禁用 traceLevel 过高（如生产环境设为 0），避免冗余调试日志污染管道
- 若用 DbTarget，务必关闭自动建表和 schema 检查，改由 DBA 统一管理
system_log表结构，字段需与 ES mapping 对齐（如log_time设为 date 类型）
传输层：可靠采集与缓冲
不建议 Yii2 直连 Logstash 或 ES —— 网络抖动、目标不可用会导致日志丢失。推荐分层传输：
- Yii2 → 写本地 JSON 文件（按天轮转，如
app-2026-07-08.json） - Filebeat 部署在应用服务器，监控该目录，启用
close_inactive和clean_inactive防止句柄泄漏 - Filebeat 输出走 Kafka（非必须，但高吞吐/多消费者场景强烈推荐），再由 Logstash 消费；若无 Kafka，则直连 Logstash 的 beats input（端口 5044）
- Filebeat 配置中开启
processors添加 host.name、env、app.version 等静态字段，便于 Kibana 多维筛选
Logstash：精准解析与 enrichment
核心是把 JSON 日志“展开”并补全元数据，避免后期在 Kibana 做复杂脚本处理：
- Input 使用
beats插件接收 Filebeat 数据 - Filter 中无需 Grok（因已是 JSON），重点做：date 插件解析
timestamp字段并覆盖 @timestamp；dissect 或 mutate 提取嵌套字段（如[context][user_id]）；geoip 补充客户端 IP 地理位置（如有需要） - Output 发往 Elasticsearch，index 名建议按天动态生成（如
yii2-app-%{+YYYY.MM.dd}），便于生命周期管理
Kibana：运维可观测性落地
不是简单看日志，而是构建面向 SRE 的视图：
- 创建 Index Pattern 匹配
yii2-app-*，确认 timestamp 字段被识别为时间字段 - Dashboard 至少包含：错误率趋势图（error / total）、Top 5 异常 category、慢请求分布（含 trace_id 关联）、按 user_id 统计异常频次
- 设置 Alert：当 5 分钟内 error 数 > 50 或 warning 持续上升时，通过 Email 或 Webhook 通知值班群
- 利用 Lens 或 TSVB 快速下钻——点击某条 error 日志，自动跳转到该 trace_id 在 APM 中的完整调用链（需提前集成 Elastic APM Agent）
