简介Apache SkyWalking 8.5.0 的 Elasticsearch 7 适配发行包tar.gz面向 Java 微服务架构的开发与运维人员用于搭建分布式链路追踪、性能指标采集与服务拓扑可视化解决微服务环境下调用链过长、故障难以定位的问题。压缩包共 508 个文件以 365 个 jar 为运行核心涵盖 OAP 服务端、Web UI 与 Java agent 探针同时提供 yml/yaml 配置便于调整 Elasticsearch 等存储参数sh/bat 脚本用于快速启停oal 文件用于定义监控告警规则txt 文档辅助查阅说明整体约 176.25MB。资源已内置 Elasticsearch 7.x 存储支持可快速接入 Spring Cloud 等微服务场景实现跨服务调用链分析、性能瓶颈定位与异常告警减少自行适配 ES 版本的工作量开箱即用。目前已有 369 人学习适合需要落地 SkyWalking 的中高级 Java 工程师和运维人员参考使用。 做可观测性这几年APM 选型几乎是每个后端团队都绕不开的环节。SkyWalking 因为上手快、协议开放、接入成本低一直是中小团队的首选而 apache-skywalking-apm-es7-8.5.0.tar 这个包我实际部署过很多次。它对应 8.5.0 版本的 Apache SkyWalking后端存储走 Elasticsearch 7 协议整个分发结构通过 tar 打包发布。官网文档把概念讲得很细但真正落地的时候坑都在细节里。这里就聊聊这个 tar 包放在手边该怎么用、怎么配、哪些地方容易踩坑。如果你正在做微服务链路追踪或者刚接手一台要装 APM 的服务器这篇内容可以直接当成操作手册参考。1. 版本与存储选型es7 后缀到底意味着什么1.1 包名里的版本关系先厘清一个重要概念。apache-skywalking-apm-es7-8.5.0.tar 里的 8.5.0指的是 Apache SkyWalking 本身的版本不是 Elasticsearch 的版本。es7 这个后缀是官方发布时做的存储客户端区分表示这个包编译时选用的是 Elasticsearch 7 的 REST 客户端。整个发行包同时包含 OAP 服务端、Java Agent 和 Web UI属于一套完整的 APM 分发产物。SkyWalking 8.5.0 这个版本虽然现在已经不是最新但仍然是很多生产环境在用的稳定版本特别是在 Elasticsearch 7 盛行的时期它几乎成了标配。很多团队在初次接触 APM 时拿到的也就是这个包。理解清楚“es7”是指向后端存储协议而不是指 SkyWalking 版本能省掉后面排查问题时的不少弯路。1.2 为什么官方要单独发 es7 发行包可能有人会问为什么官方不把 7 和 8 的支持打到一个包里原因在于 Elasticsearch 7 和 8 在存储协议、索引模板、认证机制和客户端调用方式上有不少差异。SkyWalking 的 OAP 通过 storage.selector 切换存储实现但不同版本的 ES 客户端依赖体积大、启动时还会互相影响。官方直接把编译产物拆开让使用者根据自己的集群选对应的包反而能减少很多“运行时版本冲突”的问题。所以在下载时一定要看清后缀。如果你后面的 Elasticsearch 是 7.x 集群就选 es7 包如果已经升级到 Elasticsearch 8就要去找 apache-skywalking-apm-es8 对应版本。拿 es7 的包硬连 ES8 集群初始化阶段就会失败日志里通常会出现索引模板创建异常或者连接版本协商不一致。2. 解压、目录结构与 tar 命令实操2.1 tar 解压基础参数大部分场景下我们从 Apache 官方下载页面拿到的实际文件是 .tar.gz 后缀比如 apache-skywalking-apm-es7-8.5.0.tar.gz。标题里的 .tar 只是省略 gz 后缀的说法。解压时直接用tar -zxvf apache-skywalking-apm-es7-8.5.0.tar.gz如果拿到的文件确实没有 gz 压缩去掉参数里的 z 即可tar -xvf apache-skywalking-apm-es7-8.5.0.tar这里简单解释一下参数z 表示用 gzip 解压x 表示解包v 表示列出解压过程f 指定文件名。f 必须放在最后因为后面跟的是要操作的文件名。很多新手习惯把 f 放在前面比如 tar -fxz这种写法会报错因为 f 后面期望的是文件名结果吃到了后面的参数。2.2 发行包目录功能对照解压后会生成 apache-skywalking-apm-es7-8.5.0/ 目录。里面几个关键子目录的功能如下目录功能说明bin启动、停止脚本包括 oapService.sh、webappService.sh、startup.sh 等configOAP 核心配置 application.yml以及 log4j2 组件日志配置oap_libsOAP 运行依赖的 jar 包不需要手动修改webappSkyWalking UI内部是内嵌容器运行配置在 webapp/webapp.ymlagentJava Agent 探针目录skywalking-agent.jar 在这里面licenses各类组件的许可证文件我在很多团队见过一种错误做法直接把整个目录拷贝到生产服务器然后用 root 用户启动。这样 OAP 在写日志或临时文件时会产生权限问题还容易被安全扫描标记出来。建议单独建一个系统用户再把目录属主改过去sudo useradd -r -s /sbin/nologin skywalking sudo chown -R skywalking:skywalking /opt/apache-skywalking-apm-es7-8.5.02.3 实用 tar 技巧排除、组合与批量解压tar 命令本身在运维场景里经常要配合其他功能用。比如备份整个 SkyWalking 目录时想排除日志和临时文件可以这么写tar -zcvf skywalking-backup.tar.gz --excludelogs --exclude*.pid /opt/apache-skywalking-apm-es7-8.5.0这个 --exclude 参数在写脚本时特别有用不然日志文件滚几天就能把 tar 包撑到好几 GB。另外用管道把 tar 和 xargs 组合可以快速处理一批包。比如批量解压多个发行包ls *.tar.gz | xargs -I {} tar -zxvf {}这条命令在批量部署多个 SkyWalking 节点时很省事能避免反复敲解压命令。还有一点注意纯 tar 和 gzip 压缩的 tar 可以互相转换迁移时不建议用 gzip 压缩级别太高以免消耗太多 CPU默认级别就够了。3. 让 OAP 对接 Elasticsearch 7 存储3.1 storage.selector 与核心参数OAP 的存储配置在 config/application.yml 里。改配置前先看里面最常见的几个关键项storage: selector: ${SW_STORAGE:elasticsearch7} elasticsearch7: nameSpace: ${SW_NAMESPACE:} clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200} protocol: ${SW_STORAGE_ES_PROTOCOL:http} indexShardsNumber: ${SW_STORAGE_ES_INDEX_SHARDS_NUMBER:2} indexReplicasNumber: ${SW_STORAGE_ES_INDEX_REPLICAS_NUMBER:0} user: ${SW_STORAGE_ES_USER:} password: ${SW_STORAGE_ES_PASSWORD:}storage.selector 是存储实现的选择开关。在 es7 发行包里这里必须填 elasticsearch7。如果你填 elasticsearch 或者 elasticsearch8启动时大概率会报找不到对应存储客户端或者直接因为初始化失败退出。clusterNodes 配的是 Elasticsearch 的访问地址。如果 ES 开了认证还要填 user 和 password。这里我踩过一个坑ES 前面如果挂了网关或者安全产品做了额外的鉴权转发OAP 连接时可能会看到 401但业务侧看起来 ES 又是好的。排查时先绕过网关直连 ES确认 OAP 到 ES 这条链路本身就是通的再逐步往上加安全组件。3.2 JVM 参数与端口设置OAP 默认监听两个端口gRPC 是 11800HTTP 是 12800。这两个端口分别在 application.yml 的 core 段里core: gRPCPort: ${SW_GRPC_PORT:11800} restPort: ${SW_HTTP_PORT:12800}JVM 参数在 bin/oapService.sh 里通过 JAVA_OPTS 设置。生产环境我一般会固定堆内存避免动态扩容带来抖动JAVA_OPTS-Xms2g -Xmx2g -Dmodeno_debug之所以把 Xms 和 Xmx 设成一样是因为 JVM 默认会先申请较小的堆再逐步扩容。对 OAP 这种长期运行的服务来说内存扩容过程会触发 Full GC反而影响写入性能。堆大小看业务量中小规模 2g 到 4g 基本够用如果每天 Trace 量很大可以提到 8g但要确保物理机内存充足。3.3 Web UI 配置与整体启动SkyWalking UI 是 webapp 目录下的独立进程默认端口 8080。配置文件在 webapp/webapp.ymlserver: port: ${SW_WEBAPP_PORT:8080} collector: path: /graphql ribbon: listOfServers: ${SW_WEBAPP_OAP_ADDRESS:127.0.0.1:12800}如果 8080 被其他服务占用了改端口就行。还要确认 collector.ribbon.listOfServers 指向的是 OAP 的 HTTP 端口而不是 gRPC。很多人在这一步写成了 11800导致页面能打开但拿不到任何链路数据。整体启动可以直接执行cd apache-skywalking-apm-es7-8.5.0 bin/startup.sh这个脚本会同时拉起 OAP 和 webapp。日志在 logs/ 目录下OAP 的日志文件是 skywalking-oap-server.log第一次启动如果 ES 连接正常能看到类似“elasticsearch7 storage boot success”的日志。3.4 用 systemd 托管 OAP 服务生产环境我很少直接靠 nohup 启动脚本因为进程挂了没人管。用 systemd 托管更省心。先建一个 service 文件[Unit] DescriptionSkyWalking OAP Afternetwork.target elasticsearch.service [Service] Typeforking Userskywalking Groupskywalking ExecStart/opt/apache-skywalking-apm-es7-8.5.0/bin/oapService.sh ExecStop/opt/apache-skywalking-apm-es7-8.5.0/bin/oapServiceStop.sh Restarton-failure RestartSec10 [Install] WantedBymulti-user.target这里 Typeforking 是因为 oapService.sh 会后台运行脚本本身在前台退出。如果是用 oapServiceNoDebug.sh 或者直接 java -jar 方式跑Type 就要改成 simple。很多人 systemd 起服务失败就是因为 Type 设错了systemd 认为进程还没起来过几秒就重复启动最后反而把资源耗尽。4. 日常排障与实战避坑4.1 存储初始化卡住或者 ES 版本不匹配OAP 启动后如果日志一直停留在创建索引模板或者报 version conflict先检查 Elasticsearch 版本。es7 发行包对应的是 Elasticsearch 7.x最稳妥的是 7.10 到 7.16 这个区间。如果后端是 Elasticsearch 8.x这个包在连接阶段可能不会立刻报错但初始化索引模板时大概率失败因为 8.x 移除了部分 7.x 的 mapping 写法。反过来如果你手头是 es8 发行包连 ES7 也可能因为 client 版本和集群版本协商不一致而失败。总之包后缀和后端版本一定要对齐。4.2 JDK 模块读保护与 jlink 精简 JDK 问题一些团队会把 JDK 用 jlink 裁成最小运行环境想减少容器镜像体积。这一点对普通 Spring Boot 应用可能没问题但跑 SkyWalking OAP 时经常翻车。OAP 底层依赖不少 Java 内置模块比如 java.management、java.naming、jdk.unsupported。用 jlink 裁剪后的 JDK 如果没带上这些模块启动时会报 module read 或者 ClassNotFound。我在一次部署中遇到的是 “java.lang.AssertionError: java.lang.module.FindException: Module java.naming not found”最后排查了一圈才发现是镜像里的 JDK 被裁剪过。所以官方推荐直接用完整 JDK 8 或 JDK 11 跑 OAP实在要裁剪也要保证把上面的模块加回来。4.3 Agent 版本不匹配与埋点数据缺失Java Agent 所在的 agent 目录在部署时要拷到业务机器上。启动业务应用时通过 -javaagent 参数加载JAVA_OPTS-javaagent:/opt/skywalking-agent/skywalking-agent.jar -Dskywalking.agent.service_nameorder-service -Dskywalking.collector.backend_serviceoap-host:11800这里的 backend_service 走的是 gRPC 11800 端口。如果你不小心写成了 12800Agent 网络层会一直重连日志里全是 connection refused但业务功能不会受影响所以很容易被忽略。版本匹配方面Agent 和 OAP 最好保持同版本。Agent 比 OAP 高一个版本短时间可能没问题但跨多个版本后Segment 里新增的字段 OAP 解析不了会出现链路数据丢失、部分 Trace 查不到的诡异现象。这类问题排查起来最耗时间因为业务系统看起来完全正常只有监控数据在缺。4.4 索引保留与磁盘清理SkyWalking 在 Elasticsearch 里默认按天建索引名称格式类似 skywalking_log-20210901 和 skywalking_segment-20210901。如果不管它索引会一直膨胀磁盘很快被占满。我在生产环境一般写一个 cron 脚本删除 N 天前的索引。比如只保留 7 天#!/bin/bash curl -u elastic:password -s http://localhost:9200/_cat/indices/skywalking_*?hindex | while read index; do date_part$(echo $index | sed s/.*-//) if [[ $date_part $(date -d -7 days %Y%m%d) ]]; then curl -u elastic:password -X DELETE http://localhost:9200/$index fi done这里用索引名里的日期字符串和当前日期比较能精准控制删除范围。注意别用 _all 或者宽泛通配符直接删避免误删数据。另外如果 indexShardsNumber 设置过大会导致 ES 分片数量膨胀反而增加集群压力。小规模场景 2 个分片、0 个副本就够了副本数可以在 config 里通过 indexReplicasNumber 调。5. 部署后的体验与扩展5.1 验证链路完整性的标准流程装完这套 SkyWalking 之后我最常做的验证方式是启动一个 Spring Boot 示例服务加上 Agent然后随便请求几个接口到 UI 里看“服务拓扑”和“链路追踪”两张图。正常情况下几分钟内就能看到服务节点和调用关系。第一次调试时如果看不到数据我的排查顺序是先看 Agent 日志确认 collector 地址是否通再看 OAP 日志确认有没有收到 Trace 数据最后看 ES 里有没有生成 skywalking_segment 索引。按照这个顺序排除大多数问题都能定位到网络层或者端口配错。5.2 生产环境还能怎么调对于微服务排查来说最有用的不是看平均耗时而是点进一条具体 Trace看看哪个环节的 SQL 查询或者 Redis 调用拖慢了整体耗时。我在实际使用中还会顺手调整几个小地方一是把 OAP 的 GC 日志打开方便排查内存问题二是把 UI 的登录放在网关后面通过统一认证控制访问避免 SkyWalking 页面直接暴露在公网。这个包的完整流程从解压到配好 ES 存储再到 Agent 接入业务应用整个链路大约半小时就能走通。如果你用的是 Elasticsearch 7 集群apache-skywalking-apm-es7-8.5.0.tar 至今仍然是一个稳定且能直接用的方案。真要说还有什么值得扩展的那就是数据量大之后可以把存储切到 BanyanDB 或者 TiDB但那是另一个话题了先把 ES7 这条链路跑稳再说。本文还有配套的精品资源点击获取