一、前言：整合意义（承接前两篇技术栈）

在前两篇实战博文中，我们分别独立搭建了两套核心可观测组件：

1、ELK 8.x（Filebeat+Logstash+Elasticsearch）：实现全量 Nginx、业务日志统一采集、结构化清洗、存储检索，解决日志分散、无法统一查询的问题；

2、SkyWalking 10.x：实现微服务零侵入全链路追踪、服务拓扑、接口耗时监控、故障节点定位，解决微服务调用链路黑盒问题。

但两套组件独立运行存在致命断层：SkyWalking 能定位报错链路与耗时节点，但无详细业务日志佐证；ELK 能查询完整日志，但无法快速关联请求全链路。

本文跳过所有软件原理、组件介绍、重复安装步骤，专注核心整合实战，通过 TraceId 全局透传，打通 SkyWalking 链路数据与 ELK 日志数据，实现：点链路查日志、搜日志看链路的微服务可观测闭环，适配生产环境落地标准。

二、整体整合实战架构（最简生产链路）

基于已部署完成的 ELK8.15.x + SkyWalking10.x 环境，最终整合链路如下：

微服务业务请求 → SkyWalking Agent 生成全局唯一 TraceId → 业务日志打印 TraceId → Filebeat 采集带 TraceId 日志 → Logstash 结构化清洗 → ES 存储日志+链路标识 → SkyWalking 链路页面关联日志 → Kibana 通过 TraceId 回溯全链路日志

核心核心：TraceId 全链路透传，是两套技术栈打通的唯一关键。

三、第一步：微服务项目日志改造（核心实操）

所有 SpringBoot3.x 微服务无需改业务代码、无需调整框架，仅改造日志配置，实现 TraceId 自动打印。

3.1 引入SkyWalking日志适配依赖

所有微服务 pom.xml 统一引入依赖，适配 SkyWalking10.x 日志透传，兼容 Logback 默认日志框架：

<!-- SkyWalking 日志TraceId透传依赖 -->
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-logback-encoder</artifactId>
    <version>8.15.0</version>
</dependency>

版本无需严格匹配 Agent 版本，8.x 全系通用，兼容 SkyWalking10.x 探针。

3.2 Logback日志格式改造（关键配置）

修改项目 logback-spring.xml 日志模板，在日志格式中加入 %tid 占位符，该占位符由 SkyWalking Agent 自动填充全局链路ID，无链路时自动展示 N/A。

标准生产日志格式配置（可直接全覆盖）：

<configuration>
    <include resource="org/springframework/boot/defaults/default-logback.xml"/>

    <!-- 控制台输出格式：携带TraceId -->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.vnd.logback.TraceIdPatternLogbackLayout">
                <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level logger_name:%logger{36} - [TraceId:%tid] - %msg%n</Pattern>
            </layout>
        </encoder>
    </appender>

    <root level="INFO">
        <appender-ref ref="CONSOLE"/>
    </root>
</configuration>

配置说明：

1、使用 SkyWalking 专属布局类，自动识别链路上下文，注入 TraceId、SegmentId；

2、日志输出格式固定携带 TraceId:xxx 标识，方便后续 Logstash 精准解析；

3、无链路请求（定时任务、启动日志）自动展示 TraceId:N/A，不影响正常日志采集。

四、第二步：Logstash8.x 新增TraceId结构化解析（实战改造）

原有 ELK 架构仅清洗普通日志，现在需要改造 Logstash 过滤规则，精准提取日志中的 TraceId 字段，存入 ES 单独索引字段，用于后续检索关联。

打开上篇搭建的 Logstash Nginx+业务日志配置文件 nginx-log-pipeline.conf，新增自定义 Grok 解析规则。

4.1 新增TraceId解析过滤器

在 filter 模块中添加如下解析规则，适配上面定义的日志格式：

filter {
  # 原有Nginx日志解析规则保留不变
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }

  # 新增：解析微服务日志中的TraceId
  grok {
    match => { "message" => "\[TraceId:(?<traceId>[\w\-]+)\]" }
    tag_on_failure => []
  }

  # 时区修正（保留原有配置）
  date {
    match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
    target => "@timestamp"
    timezone => "Asia/Shanghai"
  }

  # 空值处理：无TraceId时填充默认值，避免字段缺失
  mutate {
    gsub =&gt; [ "traceId", "N/A", "" ]
  }
}

核心作用：将日志文本中的 TraceId 单独提取为 ES 结构化字段，后续可直接通过 traceId 精准检索整条链路所有日志。

4.2 重载Logstash配置

依托8.x自动重载特性，无需重启服务，生效配置：

# 查看配置重载状态
tail -f /opt/logstash/logs/logstash-plain.log

出现 reload success 即为配置生效。

五、第三步：SkyWalking Agent 联动配置（极简微调）

基于已部署的 SkyWalking10.x Agent，仅开启日志透传开关，无需修改服务端配置。

编辑 agent.config 确保以下配置开启（默认已开启，核对即可）：

# 开启日志链路追踪透传
plugin.log.logback.enable=true
# 输出SQL详情，辅助问题排查
plugin.jdbc.trace_sql_parameters=true

关键操作：重启所有挂载 Agent 的微服务，让日志格式与 TraceId 注入规则生效。

六、第四步：全链路联调实战（验证闭环）

所有配置修改完成后，按以下步骤实操验证，确保链路、日志完全打通。

6.1 模拟业务请求生成数据

通过 Postman/前端发起跨服务业务请求（如下单、查询订单），触发网关、订单、库存、用户服务联动调用。

6.2 验证1：微服务日志携带TraceId

查看服务本地日志，确认日志格式正常输出 TraceId：

2026-08-09 15:20:00.123 [http-nio-8080-exec-1] INFO - [TraceId:TID_N1234567890abcdef] - 订单创建成功

6.3 验证2：ELK成功采集结构化TraceId字段

登录 Kibana 数据视图，查询当日业务日志，查看日志字段：

可看到独立结构化字段 traceId，非文本嵌套，支持精准检索、过滤、聚合。

ES检索测试命令：

# 精准查询某一条链路的所有跨服务日志
curl --cacert /opt/elasticsearch-8.15.0/config/certs/http_ca.crt \
-u elastic:你的ES密码 \
-X GET "https://localhost:9200/nginx-access-log-*/_search" \
-H "Content-Type: application/json" -d'
{
  "query": {
    "term": {
      "traceId": "TID_N1234567890abcdef"
    }
  }
}'

6.4 验证3：SkyWalking与ELK双向溯源（核心实战）

场景1：通过链路查日志（线上最常用）

1. SkyWalking UI 进入 Trace 列表，找到超时、报错的请求链路；

2. 复制该链路唯一 TraceId；

3. 打开 Kibana，通过 traceId 字段检索；

4. 一键获取该请求贯穿所有微服务的完整日志，精准定位代码异常、参数错误、SQL报错。

场景2：通过日志查链路

1. Kibana 检索到异常日志，复制日志中的 TraceId；

2. SkyWalking UI 搜索 TraceId；

3. 查看该请求完整调用拓扑、各节点耗时、依赖服务状态，判断是代码问题还是服务调用超时。

七、生产环境整合优化实战（避坑配置）

结合 ELK8.x+SkyWalking10.x 双栈特性，整理生产专属优化实操方案，解决整合后常见性能、数据冗余、检索卡顿问题。

7.1 日志数据过滤优化

Logstash 新增过滤规则，过滤无效日志、N/A空链路日志，减少ES存储压力：

filter {
  # 过滤无链路的无效日志（可选，按需开启）
  if [traceId] == "" {
    drop { }
  }
}

7.2 采样率联动优化

生产高并发场景，SkyWalking 采样率与 ELK 日志采集联动适配：

• 普通业务：链路采样率0.2，全量采集错误日志，正常日志抽样采集；

• 核心业务：全链路全日志采集，保证故障可完整复盘；

• 异常自动扩容：检测到接口异常率飙升，临时开启全量采样。

7.3 ES索引生命周期统一管理

将 SkyWalking 链路索引、ELK 日志索引统一配置 ILM 生命周期策略：

• 热数据7天可检索、可修改；

• 7天后自动转为温数据，降低存储开销；

• 30天自动过期删除，避免磁盘爆满。

7.4 权限与安全优化

• ELK、SkyWalking 共用 ES 集群，统一配置账号最小权限；

• 日志脱敏（完整落地配置）：Logstash 新增全局脱敏过滤规则，自动脱敏手机号、身份证、银行卡、密钥、支付密码等敏感信息，满足等保合规要求，下方附可直接上线的完整配置；

• 全链路开启 TLS 加密，Filebeat→Logstash、SkyWalking Agent→OAP 传输加密。

7.5 日志脱敏完整 Logstash 实战配置（生产直接可用）

在原有 Logstash filter 模块末尾追加如下脱敏规则，无需改动原有TraceId解析、Nginx日志解析、时区配置，实现敏感数据自动掩码脱敏，适配微服务业务日志、接口入参日志、SQL日志。

脱敏规则说明：手机号、身份证、银行卡中间位掩码隐藏；密码、token、密钥整段替换为 ******，杜绝敏感数据明文落盘ES。

# ========== 新增：生产日志敏感数据脱敏配置 ==========
filter {
  # 1. 手机号脱敏：11位手机号 138****1234
  mutate {
    gsub => [
      "message", "(1[3-9]\d)(\d{4})(\d{4})", "\1****\3"
    ]
  }

  # 2. 身份证脱敏：18位身份证 110101********1234
  mutate {
    gsub => [
      "message", "(\d{6})(\d{8})(\d{4})", "\1********\3"
    ]
  }

  # 3. 银行卡号脱敏：保留前6后4
  mutate {
    gsub => [
      "message", "(\d{6})(\d+)(\d{4})", "\1*****\3"
    ]
  }

  # 4. 密码/密钥类字段全局脱敏
  mutate {
    gsub => [
      "message", "(password|pwd|secret|key|token|accessKey|privateKey)[:=]\".*?\"", "\1\":\"******\"",
      "message", "(password|pwd|secret|key|token|accessKey|privateKey)[:=]\S+", "\1=******"
    ]
  }

  # 5. 自定义业务敏感字段（可按需扩展）
  mutate {
    gsub => [
      "message", "(payPassword|verifyCode|smsCode)[:=]\S+", "\1=******"
    ]
  }
}

配置落地步骤：

1. 将上述脱敏脚本追加到现有 nginx-log-pipeline.conf 的 filter 节点最底部；

2. 无需重启Logstash，等待自动重载配置生效；

3. 模拟携带手机号、密码、验证码的业务请求，查看Kibana日志，验证敏感信息已自动掩码，无明文泄露。

扩展适配：如需脱敏邮箱、地址、公司信息，可直接在gsub规则中追加正则匹配，统一维护在当前过滤器中，运维极简。

八、整合后常见故障排错实战

8.1 日志无TraceId

• 排查：微服务未引入适配依赖、日志格式未配置 %tid、未挂载 SkyWalking Agent；

• 解决：补全依赖、修正 logback 配置、重启微服务。

8.2 日志有TraceId，但ES无结构化字段

• 排查：Logstash Grok 解析规则不匹配、配置未重载；

• 解决：核对日志格式与正则表达式，重启重载 Logstash 配置。

8.3 TraceId检索不到对应链路

• 排查：SkyWalking 采样率过低导致链路未采集、服务未上报；

• 解决：核心业务调高采样率，检查11800端口连通性。

8.4 整合后ES磁盘占用飙升

• 排查：全量采集无过滤、无生命周期清理策略；

• 解决：开启日志过滤、配置ILM自动清理、优化采样率。

九、整合总结（完整可观测体系闭环）

通过本文纯实战整合配置，彻底打通 ELK日志收集 + SkyWalking链路追踪 两大核心体系，摒弃传统日志、链路割裂的排查模式：

1、ELK 负责数据落地：全量结构化日志存储、检索、统计，留存故障细节；

2、SkyWalking 负责问题定位：快速锁定超时、报错、慢接口、异常服务节点；

3、TraceId 负责双向联动，实现「定位问题看链路，排查细节看日志」的生产级可观测闭环。

整套方案基于最新稳定版技术栈，无老旧兼容问题、零代码侵入、运维成本低，完全适配 SpringCloud3.x 云原生微服务架构，是企业微服务监控、故障排查、性能优化的标准落地方案。