Logstash需先用ruby安全解析JSON日志并标记is_json字段，再分流处理；对Java堆栈须用multiline codec合并非时间戳行；grok性能优化需前置条件判断、调整规则顺序；date过滤器必须置于所有message修改操作之前。
Logstash 怎么用 grok 解析带嵌套结构的 JSON 日志
如果应用日志是 JSON 格式但混着非 JSON 行（比如启动日志、异常堆栈），json 过滤器会直接失败并丢弃整条事件。必须先用 if 判断字段是否合法，再分流处理。
- 用
mutate { add_field => { "is_json" => "%{message}" } }预埋字段，再用ruby插件尝试解析，成功则设is_json => true - 后续用
if [is_json] { json { source => "message" } }安全解析，避免json parse error导致 pipeline stall - 对非 JSON 行（如
Exception in thread "main"），用grok { match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} %{JAVACLASS:class} - %{GREEDYDATA:msg}" } }单独捕获
如何处理多行 Java 异常堆栈（stack trace）
Logstash 默认按换行切分事件，Java 异常的 Caused by: 和 at com.example... 会被拆成多条，丢失上下文。必须用 multiline 编码器在输入层合并。
- 在
file输入中启用codec => multiline，关键不是匹配“开头”，而是匹配“非开头”：用negate => true+pattern => "^%{TIMESTAMP_ISO8601}"，把不以时间戳开头的行都合并到上一条 - 避免用
what => "previous"，它依赖前一条事件存在；高并发下可能错位，改用what => "next"更稳 - 合并后
message字段会变长，记得在 filter 中用mutate { split => { "message" => "\n" } }拆成数组，再用ruby提取首行做 level，末几行做 stack_trace
grok 匹配失败时怎么快速定位是哪条规则拖慢性能
写了一堆 grok 规则后吞吐骤降，不是因为正则慢，往往是因为某条 match 在每条日志上都尝试全部 pattern，而多数根本不会命中。
- 用
if提前判断特征字段，比如if [app_name] == "payment-service" { grok { ... } }，避免通用规则扫所有日志 - 把最可能命中的
grok放在前面，把带%{GREEDYDATA}的放最后——它会吃掉整行再回溯，最耗 CPU - 临时加
ruby { code => 'puts event.to_hash' }到 pipeline 中间，配合logstash -t测试配置时看实际字段值，比猜 pattern 更快
为什么 filter 里用了 mutate + gsub 后 timestamp 字段乱了
mutate { gsub => [ "message", "\r", "" ] } 看似安全，但如果原始日志里有 \r\n 换行符，且 date 过滤器还没运行，gsub 会破坏 message 结构，导致 date { match => [ "message", "..."] } 找不到时间字符串。
- 永远把
date过滤器放在所有修改message的操作之前 - 不要用
mutate { gsub => ... }处理含时间戳的原始字段；改用dissect或kv提取后再清理 - 如果必须清洗，先
clone { clones => ["cleaned"] }分支处理，主流程保留原始message给date用
复杂日志的真实难点不在语法，而在字段生命周期管理：谁生成、谁消费、谁修改、谁依赖——漏掉一个时序，整条 pipeline 就开始“幻读”。
