ELK 7.x 接入 Java 应用需确保日志格式、协议、版本兼容：Java 端用 logback-spring.xml 配 Socket/HttpAppender 发结构化 JSON，Logstash 对应配 tcp/http 插件+json codec，ES 提前建索引模板设 traceId 等为 keyword，禁用 Logstash 默认 HTTPS 输出，调小 pipeline.batch.size 和 delay 降低延迟。
ELK 7.x 在 Java 应用里怎么接通，不卡在 Logstash 启动失败
Java 应用日志进 ELK，最常卡在 Logstash 启动报错或收不到数据，根本原因不是配置写得不对，而是 Java 端没发对格式、Logstash 没配对输入插件类型，或者 Elasticsearch 版本和 Logstash 插件不兼容。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- Java 应用侧优先用
logback-spring.xml配置SocketAppender或HttpAppender，别用FileAppender + Logstash file input—— 文件轮转和偏移量管理在生产环境极难同步，容易丢日志 - Logstash 输入端必须匹配 Java 发送协议：如果 Java 用
HttpAppender发 JSON，Logstash 就得用http插件，并设codec => json；如果用SocketAppender（TCP），Logstash 就得用tcp插件 +codec => json_lines - Elasticsearch 7.10+ 默认关闭
xpack.security.enabled，但 Logstash 7.17+ 的elasticsearch输出插件会默认尝试走 HTTPS 和认证 —— 如果没开安全模块，要显式加ssl_enabled => false和user => "" - 验证链路是否通：先用
curl -X POST http://localhost:8080 -H 'Content-Type: application/json' -d '{"level":"INFO","message":"test"}'模拟 Java 日志，看 Logstash 控制台有没有输出，再查 ES 的_cat/indices
Java 日志字段怎么映射到 ES 的 keyword/text，避免 Kibana 搜不到
Java 日志进 ES 后，message 字段搜不到、traceId 无法聚合，90% 是因为 ES 自动 mapping 把字段建成了 text 类型却没配 keyword 子字段，或者用了动态模板但没覆盖到自定义字段名。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 不要依赖 ES 自动 infer：在 Logstash 的
filter段用mutate { add_field => { "[@metadata][index]" => "java-app-logs-%{+YYYY.MM.dd}" } }，然后在 ES 里提前建好索引模板，指定traceId、spanId、serviceName全部为keyword - Java 端打日志时，确保结构化字段是顶层 key，别嵌套太深。例如
{"traceId":"abc","log":{"msg":"start","level":"INFO"}}中的log.msg默认不会被 ES 自动提升，要用 Logstash 的ruby或dissect提上来 - ES 7.x 起废弃了
string类型，text用于全文检索，keyword用于排序/聚合/精确匹配 —— Kibana 的「筛选器」和「可视化分组」只认keyword，这点不能妥协
Logstash filter 里怎么提取 MDC 和 Spring Boot Actuator 的 traceId
Spring Cloud Sleuth 或 Micrometer 自动生成的 traceId 通常存在 MDC（Mapped Diagnostic Context）里，但 Logstash 默认收不到 MDC 内容，除非 Java 端主动把 MDC 字段序列化进日志 event。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- Logback 配置里必须启用
%mdc，且在encoder中显式写出字段，例如：%replace(%msg){'\n','\\n'}+%mdc{traceId:-NONE}，否则 Logstash 收到的只是原始字符串，没有结构化字段 - 如果用
logstash-logback-encoder，直接配<includecontext>true</includecontext>和<customfields>{"app":"my-java-service"}</customfields>，它会自动把 MDC 打平成 JSON 字段 - Logstash filter 不要用
grok解析带 traceId 的 message 字符串 —— 性能差、易出错。优先用jsoncodec +dissect或kv（如果日志是 key=value 格式） - 注意 MDC 是线程绑定的，异步线程（如
@Async、线程池）默认不继承 MDC，要用logbook-spring-boot-starter或手动 copy，否则 traceId 为空
为什么 Kibana 看到的日志时间比 Java 应用打印的晚 5–10 秒
不是网络延迟，也不是 ES 写入慢，而是 Logstash 默认启用了 pipeline.workers 并行处理 + pipeline.batch.size 批量缓冲，再加上 JVM GC 导致的事件积压，让日志从 Java 打印到 Kibana 可见之间出现可观测延迟。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 调低 Logstash 的
pipeline.batch.size（默认 125）到 10–25，同时设pipeline.batch.delay≤ 50（毫秒），牺牲少量吞吐换响应速度 - Java 端避免高频打 INFO 日志（比如循环内打），改用
logger.debug("msg: {}, detail: {}", a, b)形式，靠 SLF4J 的 lazy evaluation 减少字符串拼接开销 - 检查 Logstash 的
jvm.options：堆内存别设超过 4G（ES 官方建议），否则 GC 停顿明显；用top -H -p $(pgrep -f logstash)看线程 CPU 占用，确认没被filter中的正则或 Ruby 脚本拖慢 - 真正的时间基准应以
@timestamp字段为准 —— 它由 Logstash 接收事件时生成，不是 Java 的System.currentTimeMillis()。如果需要原始时间，Java 必须显式写入"@timestamp"字段并用 Logstash 的datefilter 覆盖
ES 的 dynamic mapping 和 Logstash 的 pipeline 缓冲机制是隐蔽的性能开关，调参前先用 logstash -t 验证配置，再用 --log.level=debug 看单条日志完整流转路径 —— 很多问题其实就卡在某一级 codec 解码失败，但错误日志被默认吞掉了。
