Apache SkyWalking 在 Kubernetes 上部署 OAP 后端与 UI 的完整指南【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking在 Kubernetes 环境中部署 Apache SkyWalking 的 OAP 后端与 UI是生产环境落地 APM 观测能力的标准路径。本指南以 SkyWalking 官方 Helm Chartapache/skywalking-helm为主线系统讲解基于环境变量驱动的配置模型、存储与集群协调器选型、Init 初始化模式以及部署后的验证方法。读完本文你将掌握如何在 Kubernetes 集群中完成 OAP 与 UI 的部署、配置与扩展。说明阅读本指南前建议先通读 backend-setup.md后端安装与启动与 advanced-deployment.md高级部署模式以便理解 OAP 的目录结构、端口约定与集群角色设计。部署方式总览官方 Helm ChartApache SkyWalking 提供独立的 Helm Chart 仓库apache/skywalking-helm用于将 OAP 后端与 UI 一次性部署到 Kubernetes 集群。Helm Chart 内部封装了 Deployment、Service、ConfigMap 等 Kubernetes 资源的编排细节用户无需手写 YAML 清单即可完成部署。核心配置理念在使用 Helm 部署时绝大多数 SkyWalking OAP 设置通过系统环境变量进行控制。OAP 的配置框架config/application.yml本身大量使用${SW_XXX:default}形式的环境变量占位符因此 Helm 部署只需把环境变量注入 OAP 容器即可完成存储、集群、告警、接收器等全部模块的定制无需修改配置文件。以官方 Chart 的方式部署时整体流程为添加并更新 Chart 仓库准备values.yaml按 Chart README 中的参数说明填写在目标命名空间执行helm install同时通过--set或-f values.yaml注入 OAP 环境变量如SW_STORAGE、SW_CLUSTER与 UI 配置等待 OAP 与 UI Pod 就绪通过 Service/Ingress 暴露端口配置存储与集群协调器见下文并部署 Java、Python、Go 等语言 Agent 上报数据。详细的 Chart 安装命令、参数表与升级方式请以apache/skywalking-helm仓库的 README 为准本文档原始指引即指向该仓库。下面从配置模型、存储、集群、初始化四个维度展开说明 Kubernetes 部署中必须掌握的技术要点。环境变量驱动的配置模型理解 OAP 的配置模型是进行 Kubernetes 部署的前提。OAP 后端的行为完全由config/application.yml驱动其设计核心是纯模块化架构用户可以根据需求自由切换或组装后端功能模块。在 backend-setup.md 中application.yml被描述为三层结构Level 1模块名声明该模块在运行模式下处于激活状态Level 2Provider 列表与选择器列出可用的 Provider并通过selector指定实际生效的 Provider若只有一个 Providerselector可省略Level 3被选中 Provider 的设置该 Provider 的具体配置项。以存储模块为例其配置结构如下摘自 backend-setup.mdstorage: selector: banyandb # the banyandb storage will actually be activated. mysql: properties: jdbcUrl: ${SW_JDBC_URL:jdbc:mysql://localhost:3306/swtest?allowMultiQueriestrue} dataSource.user: ${SW_DATA_SOURCE_USER:root} dataSource.password: ${SW_DATA_SOURCE_PASSWORD:root1234} dataSource.cachePrepStmts: ${SW_DATA_SOURCE_CACHE_PREP_STMTS:true} dataSource.prepStmtCacheSize: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_SIZE:250} dataSource.prepStmtCacheSqlLimit: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_LIMIT:2048} dataSource.useServerPrepStmts: ${SW_DATA_SOURCE_USE_SERVER_PREP_STMTS:true} metadataQueryMaxSize: ${SW_STORAGE_MYSQL_QUERY_MAX_SIZE:5000} banyandb: targets: ${SW_STORAGE_BANYANDB_TARGETS:127.0.0.1:17912} maxBulkSize: ${SW_STORAGE_BANYANDB_MAX_BULK_SIZE:10000} flushInterval: ${SW_STORAGE_BANYANDB_FLUSH_INTERVAL:15} flushTimeout: ${SW_STORAGE_BANYANDB_FLUSH_TIMEOUT:10}在这个示例中storage是模块名selector从下方列出的多个 Provider 中选定一个生效未选中的 Provider 等同于被删除、不产生任何效果mysql/banyandb是模块的 Provider实现者各properties项是 Provider 的具体设置且全部支持SW_前缀的环境变量覆盖。这一设计对 Kubernetes 部署意义重大Helm 部署时无需修改任何 YAML 配置文件只需在 OAP 容器的 env 中设置对应的SW_环境变量例如设置SW_STORAGEbanyandb、SW_STORAGE_BANYANDB_TARGETS...即可切换存储后端。需要特别注意的是模块的两种类型必需模块与可选模块。必需模块Core、Cluster、Storage、Query、Receiver/Fetcher构成后端骨架移除它们没有意义可选模块中有部分提供名为none的 Provider如 telemetry它只提供空壳、不包含实际逻辑。若将selector设为-则整个模块在运行时被排除。Docker 镜像中的配置注入机制从镜像实现看OAP 容器提供了两种扩展注入途径见 docker/oap/docker-entrypoint.shext-config目录镜像启动脚本会将/skywalking/ext-config/*中的文件复制覆盖到config/目录可用于覆盖application.yml、log4j2.xml等配置文件Kubernetes 中通常以 ConfigMap/Secret 挂载到该目录实现ext-libs目录/skywalking/ext-libs/*.jar会被追加到 CLASSPATH用于加载自定义扩展库。启动脚本最终执行java ${JAVA_OPTS} -classpath ... org.apache.skywalking.oap.server.starter.OAPServerStartUp $其中JAVA_OPTS可通过环境变量注入 JVM 参数例如在 Helm values 中设置JAVA_OPTS: -Xms2G -Xmx4G。镜像默认基础镜像为eclipse-temurin:25-jre见 docker/oap/Dockerfile 中的ARG BASE_IMAGE官方同时发布-java11/-java17/-java21标签变体OAP 二进制要求Java 11、17、21 或 25以 11 为最低运行版本编译Kubernetes 部署时应按集群实际环境选择匹配的镜像 tag。存储准备BanyanDB 与存储模块选择在启动后端之前需要先准备好数据库。官方推荐使用BanyanDB作为存储后端在 Kubernetes 场景下可通过 Helm 或 Operator 部署 BanyanDB 集群并将 OAP 的SW_STORAGE_BANYANDB_TARGETS指向其 gRPC 地址默认端口17912本地单机模式同时暴露17913。若希望使用其他数据库MySQL、PostgreSQL、Elasticsearch 等请阅读 backend-storage.md 中的存储选型说明。两个版本兼容性要点OAP 兼容的BanyanDB API 版本号定义在发布包的config/bydb.yml中对应占位符SW_STORAGE_BANYANDB_COMPATIBLE_SERVER_API_VERSIONS部署 BanyanDB 时应选择与 OAP 兼容的 Server 版本BanyanDB 官方文档提供 API 版本映射表。在 Kubernetes 中为 OAP 配置 BanyanDB 存储的最小环境变量集合如下通过 Helm values 注入# values.yaml 片段示意参数名以 Chart README 为准 oap: env: SW_STORAGE: banyandb SW_STORAGE_BANYANDB_TARGETS: banyandb:17912 # BanyanDB 集群服务地址 SW_STORAGE_BANYANDB_MAX_BULK_SIZE: 10000 # 批量写入上限 SW_STORAGE_BANYANDB_FLUSH_INTERVAL: 15 # 刷盘间隔秒 SW_STORAGE_BANYANDB_FLUSH_TIMEOUT: 10 # 刷盘超时秒集群模式Kubernetes 原生协调器生产环境必须启用集群管理Cluster Management以支持分布式聚合、高吞吐与高可用否则会面临指标不准确的问题。在 Kubernetes 部署中最自然的方案是使用Kubernetes 原生协调器Cloud Native 模式它借助 K8s 原生 API 完成 OAP 实例的发现与注册。在application.yml中启用 Kubernetes 协调器的方式见 backend-cluster.mdcluster: selector: ${SW_CLUSTER:kubernetes} # other configurations对应地在 Helm 部署中设置环境变量SW_CLUSTERkubernetes即可。与此同时OAP 集群要求将Pod 的 UID位于metadata.uid作为系统环境变量SKYWALKING_COLLECTOR_UID注入容器作为当前 OAP 节点在集群中的唯一标识containers: # Original configurations of OAP container - name: {{ .Values.oap.name }} image: {{ .Values.oap.image.repository }}:{{ required oap.image.tag is required .Values.oap.image.tag }} # ... env: # Add metadata.uid as the system environment variable, SKYWALKING_COLLECTOR_UID - name: SKYWALKING_COLLECTOR_UID valueFrom: fieldRef: fieldPath: metadata.uid该配置已在官方 Helm Chart 的oap-deployment.yaml模板中内置请查阅 Chart 源码确认。除 Kubernetes 协调器外OAP 还支持 Zookeeper、Consul、Etcd、Nacos 等传统协调器通过SW_CLUSTER切换 selector但这些方式要求oap.internal.comm.host:oap.internal.comm.port在每个节点上唯一注册默认的0.0.0.0主机在集群模式下并不适用除非使用 Kubernetes 部署。Kubernetes 协调器恰恰通过 Pod UID 天然解决了节点标识唯一性问题。两点提醒同样适用于 Helm 部署集群管理不提供Agent/Probe 的服务发现机制官方建议 Agent 通过网关或负载均衡器访问 OAP 集群部署后应使用 Query Cluster Nodes API 核对集群节点列表节点数与预期不符说明集群未正常工作可能导致指标不准确、告警无法正确触发。节点角色分离可选从源码结构看OAP 支持三种运行角色Mixed默认接收聚合持久化告警一体、Receiver仅接收与 L1 聚合、AggregatorL2 聚合持久化告警详见 advanced-deployment.md。若在 Kubernetes 中按角色拆分部署需要为每种角色分别创建 Deployment例如一个 receiver OAP Deployment、一个 aggregator OAP Deployment并为 Aggregator 角色选择规则配置labelSelector以便根据标签选取正确的 OAP Deployment。该模式适合对安全策略与网络策略有复杂要求的场景。Init 模式规避并发初始化问题在 Kubernetes 等容器管理平台上多个 OAP 实例可能同时启动并并发初始化存储例如多个 Elasticsearch 索引同时创建、ES API 被阻塞且不报异常从而引发意外故障。为此 OAP 提供了Init 模式见 backend-init-mode.md在其余实例启动前只允许单个实例以 Init 模式运行该实例完成所有初始化步骤后优雅退出传统部署中使用bin/oapServiceInit.sh或.bat启动成功日志形如OAP starts up in init mode successfully, exit now...Kubernetes 场景下Init 模式已包含在官方 Kubernetes 脚本与 Helm Chart 中通常以 Job/InitContainer 形式执行存储初始化无需手工干预。端口、外部访问与部署后验证端口约定OAP 与 UI 的默认端口约定详见 backend-setup.md镜像同时暴露 12800/11800/1234见 docker/oap/Dockerfile端口用途11800gRPC接收 Agent/Probe 上报数据oap.external.grpc.host:port也用于 OTEL 等遥测数据上报12800HTTP数据上报JSON 格式与查询入口GraphQL/UI、PromQL、LogQL即oap.external.http.host:port8080UIwebappUI 前端页面向后端12800发起 GraphQL 查询Kubernetes 部署中通常为 OAP 创建 ClusterIP Service 暴露 11800/12800为 UI 创建 Service 并通过 Ingress/LoadBalancer 对外暴露 8080。若需要将接收端口与查询端口分开暴露例如仅内部网络开放接收端口可参考 backend-expose.md 的外部通道配置说明。通过启动日志验证关键参数OAP 启动完成后会在日志中列出全部关键运行参数Key Booting Parameters可用于核对 Kubernetes 环境变量是否生效。示例输出摘自 backend-setup.mdRunning Mode | null TTL.metrics | 7 TTL.record | 3 Version | 9.7.0-SNAPSHOT-92af797 module.agent-analyzer.provider | default module.cluster.provider | standalone module.configuration.provider | none module.core.provider | default module.query.provider | graphql module.storage.provider | h2 module.telemetry.provider | none oap.external.grpc.host | 0.0.0.0 oap.external.grpc.port | 11800 oap.external.http.host | 0.0.0.0 oap.external.http.port | 12800 oap.internal.comm.host | 0.0.0.0 oap.internal.comm.port | 11800其中oap.external.grpc.host:portAgent 与 OTEL 通过 gRPC 上报数据的通道oap.external.http.host:portHTTP 上报与查询通道GraphQL/UI、PromQL、LogQLoap.internal.comm.host:portOAP 集群内部 gRPC/HTTP2 通信通道默认主机0.0.0.0不适用于传统集群模式但 Kubernetes 部署场景除外由 K8s 协调器管理。Java、.NET、Node.js 与 Istio 等 Agent/Probe 上报数据时应把 gRPC 服务地址设置为 OAP 的ip/host:11800在 Kubernetes 中即 OAP Service 的 DNS 名称与端口。部署后的下一步OAP 与 UI 成功部署到 Kubernetes 之后可以浏览 Marketplace 发现所有开箱即用的监控能力包括各类语言 Agent、Service Mesh 可观测性、Kubernetes 集群监控Pod 指标、网络画像、基础设施监控Linux/Windows、云服务AWS EKS/S3/DynamoDB 等、网关Nginx/APISIX/Kong、数据库MySQL/PostgreSQL/Redis/Elasticsearch/MongoDB/ClickHouse、消息队列Kafka/RabbitMQ/Pulsar/RocketMQ/ActiveMQ、浏览器 RUM 以及 GenAI 监控等。对应的可视化Dashboard、Marketplace UI由 Horizon UI 独立发布与 OAP 后端的数据面配合使用。在此基础上还可以进一步探索通过 dynamic-config.md 接入 ConfigMap 等动态配置中心实现在线调整通过 backend-telemetry.md 开启 Prometheus 遥测监控 OAP 自身健康状态结合 backend-alarm.md 配置告警规则形成完整的观测闭环。【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Apache SkyWalking 在 Kubernetes 上部署 OAP 后端与 UI 的完整指南
Apache SkyWalking 在 Kubernetes 上部署 OAP 后端与 UI 的完整指南【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking在 Kubernetes 环境中部署 Apache SkyWalking 的 OAP 后端与 UI是生产环境落地 APM 观测能力的标准路径。本指南以 SkyWalking 官方 Helm Chartapache/skywalking-helm为主线系统讲解基于环境变量驱动的配置模型、存储与集群协调器选型、Init 初始化模式以及部署后的验证方法。读完本文你将掌握如何在 Kubernetes 集群中完成 OAP 与 UI 的部署、配置与扩展。说明阅读本指南前建议先通读 backend-setup.md后端安装与启动与 advanced-deployment.md高级部署模式以便理解 OAP 的目录结构、端口约定与集群角色设计。部署方式总览官方 Helm ChartApache SkyWalking 提供独立的 Helm Chart 仓库apache/skywalking-helm用于将 OAP 后端与 UI 一次性部署到 Kubernetes 集群。Helm Chart 内部封装了 Deployment、Service、ConfigMap 等 Kubernetes 资源的编排细节用户无需手写 YAML 清单即可完成部署。核心配置理念在使用 Helm 部署时绝大多数 SkyWalking OAP 设置通过系统环境变量进行控制。OAP 的配置框架config/application.yml本身大量使用${SW_XXX:default}形式的环境变量占位符因此 Helm 部署只需把环境变量注入 OAP 容器即可完成存储、集群、告警、接收器等全部模块的定制无需修改配置文件。以官方 Chart 的方式部署时整体流程为添加并更新 Chart 仓库准备values.yaml按 Chart README 中的参数说明填写在目标命名空间执行helm install同时通过--set或-f values.yaml注入 OAP 环境变量如SW_STORAGE、SW_CLUSTER与 UI 配置等待 OAP 与 UI Pod 就绪通过 Service/Ingress 暴露端口配置存储与集群协调器见下文并部署 Java、Python、Go 等语言 Agent 上报数据。详细的 Chart 安装命令、参数表与升级方式请以apache/skywalking-helm仓库的 README 为准本文档原始指引即指向该仓库。下面从配置模型、存储、集群、初始化四个维度展开说明 Kubernetes 部署中必须掌握的技术要点。环境变量驱动的配置模型理解 OAP 的配置模型是进行 Kubernetes 部署的前提。OAP 后端的行为完全由config/application.yml驱动其设计核心是纯模块化架构用户可以根据需求自由切换或组装后端功能模块。在 backend-setup.md 中application.yml被描述为三层结构Level 1模块名声明该模块在运行模式下处于激活状态Level 2Provider 列表与选择器列出可用的 Provider并通过selector指定实际生效的 Provider若只有一个 Providerselector可省略Level 3被选中 Provider 的设置该 Provider 的具体配置项。以存储模块为例其配置结构如下摘自 backend-setup.mdstorage: selector: banyandb # the banyandb storage will actually be activated. mysql: properties: jdbcUrl: ${SW_JDBC_URL:jdbc:mysql://localhost:3306/swtest?allowMultiQueriestrue} dataSource.user: ${SW_DATA_SOURCE_USER:root} dataSource.password: ${SW_DATA_SOURCE_PASSWORD:root1234} dataSource.cachePrepStmts: ${SW_DATA_SOURCE_CACHE_PREP_STMTS:true} dataSource.prepStmtCacheSize: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_SIZE:250} dataSource.prepStmtCacheSqlLimit: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_LIMIT:2048} dataSource.useServerPrepStmts: ${SW_DATA_SOURCE_USE_SERVER_PREP_STMTS:true} metadataQueryMaxSize: ${SW_STORAGE_MYSQL_QUERY_MAX_SIZE:5000} banyandb: targets: ${SW_STORAGE_BANYANDB_TARGETS:127.0.0.1:17912} maxBulkSize: ${SW_STORAGE_BANYANDB_MAX_BULK_SIZE:10000} flushInterval: ${SW_STORAGE_BANYANDB_FLUSH_INTERVAL:15} flushTimeout: ${SW_STORAGE_BANYANDB_FLUSH_TIMEOUT:10}在这个示例中storage是模块名selector从下方列出的多个 Provider 中选定一个生效未选中的 Provider 等同于被删除、不产生任何效果mysql/banyandb是模块的 Provider实现者各properties项是 Provider 的具体设置且全部支持SW_前缀的环境变量覆盖。这一设计对 Kubernetes 部署意义重大Helm 部署时无需修改任何 YAML 配置文件只需在 OAP 容器的 env 中设置对应的SW_环境变量例如设置SW_STORAGEbanyandb、SW_STORAGE_BANYANDB_TARGETS...即可切换存储后端。需要特别注意的是模块的两种类型必需模块与可选模块。必需模块Core、Cluster、Storage、Query、Receiver/Fetcher构成后端骨架移除它们没有意义可选模块中有部分提供名为none的 Provider如 telemetry它只提供空壳、不包含实际逻辑。若将selector设为-则整个模块在运行时被排除。Docker 镜像中的配置注入机制从镜像实现看OAP 容器提供了两种扩展注入途径见 docker/oap/docker-entrypoint.shext-config目录镜像启动脚本会将/skywalking/ext-config/*中的文件复制覆盖到config/目录可用于覆盖application.yml、log4j2.xml等配置文件Kubernetes 中通常以 ConfigMap/Secret 挂载到该目录实现ext-libs目录/skywalking/ext-libs/*.jar会被追加到 CLASSPATH用于加载自定义扩展库。启动脚本最终执行java ${JAVA_OPTS} -classpath ... org.apache.skywalking.oap.server.starter.OAPServerStartUp $其中JAVA_OPTS可通过环境变量注入 JVM 参数例如在 Helm values 中设置JAVA_OPTS: -Xms2G -Xmx4G。镜像默认基础镜像为eclipse-temurin:25-jre见 docker/oap/Dockerfile 中的ARG BASE_IMAGE官方同时发布-java11/-java17/-java21标签变体OAP 二进制要求Java 11、17、21 或 25以 11 为最低运行版本编译Kubernetes 部署时应按集群实际环境选择匹配的镜像 tag。存储准备BanyanDB 与存储模块选择在启动后端之前需要先准备好数据库。官方推荐使用BanyanDB作为存储后端在 Kubernetes 场景下可通过 Helm 或 Operator 部署 BanyanDB 集群并将 OAP 的SW_STORAGE_BANYANDB_TARGETS指向其 gRPC 地址默认端口17912本地单机模式同时暴露17913。若希望使用其他数据库MySQL、PostgreSQL、Elasticsearch 等请阅读 backend-storage.md 中的存储选型说明。两个版本兼容性要点OAP 兼容的BanyanDB API 版本号定义在发布包的config/bydb.yml中对应占位符SW_STORAGE_BANYANDB_COMPATIBLE_SERVER_API_VERSIONS部署 BanyanDB 时应选择与 OAP 兼容的 Server 版本BanyanDB 官方文档提供 API 版本映射表。在 Kubernetes 中为 OAP 配置 BanyanDB 存储的最小环境变量集合如下通过 Helm values 注入# values.yaml 片段示意参数名以 Chart README 为准 oap: env: SW_STORAGE: banyandb SW_STORAGE_BANYANDB_TARGETS: banyandb:17912 # BanyanDB 集群服务地址 SW_STORAGE_BANYANDB_MAX_BULK_SIZE: 10000 # 批量写入上限 SW_STORAGE_BANYANDB_FLUSH_INTERVAL: 15 # 刷盘间隔秒 SW_STORAGE_BANYANDB_FLUSH_TIMEOUT: 10 # 刷盘超时秒集群模式Kubernetes 原生协调器生产环境必须启用集群管理Cluster Management以支持分布式聚合、高吞吐与高可用否则会面临指标不准确的问题。在 Kubernetes 部署中最自然的方案是使用Kubernetes 原生协调器Cloud Native 模式它借助 K8s 原生 API 完成 OAP 实例的发现与注册。在application.yml中启用 Kubernetes 协调器的方式见 backend-cluster.mdcluster: selector: ${SW_CLUSTER:kubernetes} # other configurations对应地在 Helm 部署中设置环境变量SW_CLUSTERkubernetes即可。与此同时OAP 集群要求将Pod 的 UID位于metadata.uid作为系统环境变量SKYWALKING_COLLECTOR_UID注入容器作为当前 OAP 节点在集群中的唯一标识containers: # Original configurations of OAP container - name: {{ .Values.oap.name }} image: {{ .Values.oap.image.repository }}:{{ required oap.image.tag is required .Values.oap.image.tag }} # ... env: # Add metadata.uid as the system environment variable, SKYWALKING_COLLECTOR_UID - name: SKYWALKING_COLLECTOR_UID valueFrom: fieldRef: fieldPath: metadata.uid该配置已在官方 Helm Chart 的oap-deployment.yaml模板中内置请查阅 Chart 源码确认。除 Kubernetes 协调器外OAP 还支持 Zookeeper、Consul、Etcd、Nacos 等传统协调器通过SW_CLUSTER切换 selector但这些方式要求oap.internal.comm.host:oap.internal.comm.port在每个节点上唯一注册默认的0.0.0.0主机在集群模式下并不适用除非使用 Kubernetes 部署。Kubernetes 协调器恰恰通过 Pod UID 天然解决了节点标识唯一性问题。两点提醒同样适用于 Helm 部署集群管理不提供Agent/Probe 的服务发现机制官方建议 Agent 通过网关或负载均衡器访问 OAP 集群部署后应使用 Query Cluster Nodes API 核对集群节点列表节点数与预期不符说明集群未正常工作可能导致指标不准确、告警无法正确触发。节点角色分离可选从源码结构看OAP 支持三种运行角色Mixed默认接收聚合持久化告警一体、Receiver仅接收与 L1 聚合、AggregatorL2 聚合持久化告警详见 advanced-deployment.md。若在 Kubernetes 中按角色拆分部署需要为每种角色分别创建 Deployment例如一个 receiver OAP Deployment、一个 aggregator OAP Deployment并为 Aggregator 角色选择规则配置labelSelector以便根据标签选取正确的 OAP Deployment。该模式适合对安全策略与网络策略有复杂要求的场景。Init 模式规避并发初始化问题在 Kubernetes 等容器管理平台上多个 OAP 实例可能同时启动并并发初始化存储例如多个 Elasticsearch 索引同时创建、ES API 被阻塞且不报异常从而引发意外故障。为此 OAP 提供了Init 模式见 backend-init-mode.md在其余实例启动前只允许单个实例以 Init 模式运行该实例完成所有初始化步骤后优雅退出传统部署中使用bin/oapServiceInit.sh或.bat启动成功日志形如OAP starts up in init mode successfully, exit now...Kubernetes 场景下Init 模式已包含在官方 Kubernetes 脚本与 Helm Chart 中通常以 Job/InitContainer 形式执行存储初始化无需手工干预。端口、外部访问与部署后验证端口约定OAP 与 UI 的默认端口约定详见 backend-setup.md镜像同时暴露 12800/11800/1234见 docker/oap/Dockerfile端口用途11800gRPC接收 Agent/Probe 上报数据oap.external.grpc.host:port也用于 OTEL 等遥测数据上报12800HTTP数据上报JSON 格式与查询入口GraphQL/UI、PromQL、LogQL即oap.external.http.host:port8080UIwebappUI 前端页面向后端12800发起 GraphQL 查询Kubernetes 部署中通常为 OAP 创建 ClusterIP Service 暴露 11800/12800为 UI 创建 Service 并通过 Ingress/LoadBalancer 对外暴露 8080。若需要将接收端口与查询端口分开暴露例如仅内部网络开放接收端口可参考 backend-expose.md 的外部通道配置说明。通过启动日志验证关键参数OAP 启动完成后会在日志中列出全部关键运行参数Key Booting Parameters可用于核对 Kubernetes 环境变量是否生效。示例输出摘自 backend-setup.mdRunning Mode | null TTL.metrics | 7 TTL.record | 3 Version | 9.7.0-SNAPSHOT-92af797 module.agent-analyzer.provider | default module.cluster.provider | standalone module.configuration.provider | none module.core.provider | default module.query.provider | graphql module.storage.provider | h2 module.telemetry.provider | none oap.external.grpc.host | 0.0.0.0 oap.external.grpc.port | 11800 oap.external.http.host | 0.0.0.0 oap.external.http.port | 12800 oap.internal.comm.host | 0.0.0.0 oap.internal.comm.port | 11800其中oap.external.grpc.host:portAgent 与 OTEL 通过 gRPC 上报数据的通道oap.external.http.host:portHTTP 上报与查询通道GraphQL/UI、PromQL、LogQLoap.internal.comm.host:portOAP 集群内部 gRPC/HTTP2 通信通道默认主机0.0.0.0不适用于传统集群模式但 Kubernetes 部署场景除外由 K8s 协调器管理。Java、.NET、Node.js 与 Istio 等 Agent/Probe 上报数据时应把 gRPC 服务地址设置为 OAP 的ip/host:11800在 Kubernetes 中即 OAP Service 的 DNS 名称与端口。部署后的下一步OAP 与 UI 成功部署到 Kubernetes 之后可以浏览 Marketplace 发现所有开箱即用的监控能力包括各类语言 Agent、Service Mesh 可观测性、Kubernetes 集群监控Pod 指标、网络画像、基础设施监控Linux/Windows、云服务AWS EKS/S3/DynamoDB 等、网关Nginx/APISIX/Kong、数据库MySQL/PostgreSQL/Redis/Elasticsearch/MongoDB/ClickHouse、消息队列Kafka/RabbitMQ/Pulsar/RocketMQ/ActiveMQ、浏览器 RUM 以及 GenAI 监控等。对应的可视化Dashboard、Marketplace UI由 Horizon UI 独立发布与 OAP 后端的数据面配合使用。在此基础上还可以进一步探索通过 dynamic-config.md 接入 ConfigMap 等动态配置中心实现在线调整通过 backend-telemetry.md 开启 Prometheus 遥测监控 OAP 自身健康状态结合 backend-alarm.md 配置告警规则形成完整的观测闭环。【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考