企业官网建设流程全解析

• 可观测性
• APM
• 链路追踪
• 指标监控
• 日志分析
• 微服务

本篇指南以 SkyWalking 仓库中 dashboards-so11y-satellite.md 为骨架，完整讲解如何将 SkyWalking Satellite（卫星采集器）自身的运行状态指标接入 SkyWalking OAP，并通过自可观测性仪表盘进行可视化。读完本文，你将掌握 Satellite 指标的数据流链路、Telemetry Exporter 与 OpenTelemetry receiver 的开启方式、全部 8 个satellite_service_*核心指标的含义，以及如何基于仓库中的 MAL 规则与测试用例做自定义扩展。

Satellite 自可观测性仪表盘是什么

SkyWalking Satellite 在内部采集自身的运行指标后，既以 Prometheus 格式暴露指标，也以 SkyWalking metrics service protobuf 格式导出，供下游消费。与此同时，SkyWalking 为其提供了一套自可观测性（self observability）仪表盘，用于可视化这些 Satellite 指标——这正是本指南对应的SO11Y_SATELLITE自可观测性场景，与 OAP 自身的自可观测性仪表盘（SO11Y_OAP）互为姊妹篇。

数据流（Data flow）

Satellite 自可观测性指标从采集到落库共经过两步：

1. Satellite 采集并推送：SkyWalking Satellite 在内部采集自身的指标数据，并将指标推送给 SkyWalking OAP Server。
2. OAP 解析并存储：SkyWalking OAP Server 使用 MAL（Meter Analysis Language） 解析指标表达式，对指标进行过滤（filter）、计算（calculate）、聚合（aggregate），最终将结果写入存储。

MAL 是 OAP meter system 提供的函数式分析语言，负责把 Prometheus/OpenTelemetry 等来源的原始指标转换为 SkyWalking 统一建模的指标实体。Satellite 指标正是经由 MAL 规则文件完成这一转换（详见下文“MAL 规则源码”小节）。

设置步骤（Set up）

启用 Satellite 自可观测性监控需要完成两步配置：

1. 配置 SkyWalking Satellite Telemetry Exporter：在 Satellite 侧开启 Telemetry Exporter，使其将内部指标导出到 SkyWalking OAP。该 Exporter 的完整安装示例位于 Apache SkyWalking Satellite 项目的docs/en/setup/examples/feature/telemetry-exporter/README.md（独立于本仓库，请前往对应项目查看）。
2. 配置 SkyWalking OpenTelemetry receiver：在 OAP 侧启用 OpenTelemetry receiver，用于接收 Satellite 通过 OTLP gRPC 推送的指标。

关于第 2 步，仓库文档 opentelemetry-receiver.md 给出了明确约定：receiver-otel仅支持group、defaultMetricLevel与metricsRules节点（因其为 push 模式），并需通过系统环境变量或配置项激活 receiver：

receiver-otel: selector: ${SW_OTEL_RECEIVER:default} default: enabledHandlers: ${SW_OTEL_RECEIVER_ENABLED_HANDLERS:"otlp-metrics"} enabledOtelMetricsRules: ${SW_OTEL_RECEIVER_ENABLED_OTEL_METRICS_RULES:"istio-controlplane"}

同时，该文档说明 OAP 会在启动时加载规则配置（位于$CLASSPATH/otel-rules、$CLASSPATH/meter-analyzer-config等目录），若配置格式不合法，OAP 将启动失败——因此修改 Satellite 相关规则文件后务必保证 YAML 与 MAL 表达式语法正确。

自可观测性监控（Self observability monitoring）

自可观测性监控用于监控 OAP 服务自身的状态与资源。在本场景中，Satellite 作为一个 OAP 中的Service存在，并落在Layer: SO11Y_SATELLITE上。

从源码看，SO11Y_SATELLITE是 OAP 内置的 Layer 之一，定义于 Layer.java：

public static final Layer SO11Y_SATELLITE = register("SO11Y_SATELLITE", 12, true);

自可观测性指标（Self observability metrics）

原文档给出以下 7 个监控面板指标（单位、指标名、描述与数据源如下）：

MAL 规则源码：指标如何被计算

上述仪表盘指标并非 Satellite 直接上报的原始指标，而是由 OAP 中的 MAL 规则文件实时计算得出。对应的规则文件为 meter-analyzer-config/satellite.yaml（位于server-starter模块资源目录，打包后即$CLASSPATH/meter-analyzer-config/satellite.yaml），完整内容如下：

expSuffix: service(['service'], Layer.SO11Y_SATELLITE) metricPrefix: satellite metricsRules: - name: service_receive_event_count exp: sw_stl_gatherer_receive_count.sum(["pipe", "status", "service"]).increase("PT1M") - name: service_fetch_event_count exp: sw_stl_gatherer_fetch_count.sum(["pipe", "status", "service"]).increase("PT1M") - name: service_queue_input_count exp: sw_stl_queue_output_count.sum(["pipe", "status", "service"]).increase("PT1M") - name: service_send_event_count exp: sw_stl_sender_output_count.sum(["pipe", "status", "service"]).increase("PT1M") - name: service_queue_total_capacity exp: sw_stl_pipeline_queue_total_capacity.sum(["pipeline", "service"]) - name: service_queue_used_count exp: sw_stl_pipeline_queue_partition_size.sum(["pipeline", "service"]) - name: service_server_cpu_utilization exp: sw_stl_grpc_server_cpu_gauge - name: service_grpc_connect_count exp: sw_stl_grpc_server_connection_count

结合 MAL 语言文档 可以解读出以下设计要点：

• expSuffix全局后缀：service(['service'], Layer.SO11Y_SATELLITE)是一条服务级（service level）函数——从指标标签中提取service标签作为服务名，并声明该指标属于SO11Y_SATELLITE层。所有规则均自动附加此后缀。
• metricPrefix前缀拼接：规则名会与satellite前缀拼接为最终指标名<metricPrefix>_<rule_name>，因此service_receive_event_count在存储与查询中即为satellite_service_receive_event_count，与仪表盘面板中的指标名一一对应。
• 聚合与增量：sw_stl_gatherer_receive_count.sum(["pipe", "status", "service"]).increase("PT1M")表示按pipe、status、service三个标签维度求和，再计算 1 分钟（PT1M）时间窗口内的增量，得到每分钟的事件接收增量。
• Gauge 直读：CPU 利用率与 gRPC 连接数（sw_stl_grpc_server_cpu_gauge、sw_stl_grpc_server_connection_count）为瞬时值型指标，直接透传，无需聚合与增量计算。
• 队列容量与占用：sw_stl_pipeline_queue_total_capacity与sw_stl_pipeline_queue_partition_size分别反映 pipeline 队列的总容量与实际已用分区大小，按pipeline、service维度聚合，可用于评估 Satellite 管道积压情况。

测试用例印证

仓库在 meter-analyzer-scripts-test 模块 提供了该规则文件的完整 MAL 测试用例：给定sw_stl_gatherer_receive_count等 8 个原始指标的模拟输入（带pipe、status、service等标签），断言输出为satellite_service_receive_event_count等指标，实体（entities）均为scope: SERVICE、layer: SO11Y_SATELLITE。例如对sw_stl_gatherer_receive_count输入 100.0，经.increase("PT1M")计算后期望输出 50.0。该测试直接验证了上述规则的聚合逻辑与 Layer 归属。

此外，仓库还提供了satellite-tag-prefix.yaml变体规则（见 satellite-tag-prefix.yaml），通过expSuffix: tag({tags -> tags.service = 'satellite::' + tags.service}).service(['service'], Layer.SO11Y_SATELLITE)为服务名添加satellite::前缀，用于多实例部署时区分命名空间，配套测试 satellite-tag-prefix.data.yaml 断言服务名变为satellite::test-service。这一模式可作为区分不同来源同名服务的参考实现。

自定义（Customizations）

你可以完全自定义自己的指标、表达式与仪表盘面板，扩展方向包括：

• 自定义指标：仿照satellite.yaml在$CLASSPATH/meter-analyzer-config/下新增或修改规则文件，利用 MAL 的标签过滤（tagEqual/tagMatch）、值过滤、聚合（sum/avg/min/max/count）、函数（increase/rate/irate/tag）等能力构建适合自身场景的派生指标；
• 自定义表达式：调整exp中的聚合维度（如保留pipe维度按管道分别查看）或时间窗口（如将PT1M改为PT5M以观察 5 分钟增量）；
• 自定义仪表盘面板：需要说明的是，自可观测性仪表盘的面板配置随 SkyWalking Horizon UI 前端包（apache/skywalking-horizon-ui）一起发布，OAP 后端已不再托管 UI 仪表盘 JSON 文件——因此面板层面的定制需在 Horizon UI 侧完成，OAP 侧只负责指标的定义、计算与存储。

小结

SkyWalking Satellite 的自可观测性能力由“Satellite 内部指标采集 → Telemetry Exporter 推送 → OAP OpenTelemetry receiver 接收 → MAL 规则计算 →SO11Y_SATELLITE服务级指标落库 → Horizon UI 仪表盘展示”构成。核心指标集中在事件接收/拉取/入队/发送计数、pipeline 队列容量与占用、CPU 利用率与 gRPC 连接数等维度，均可在 satellite.yaml 中溯源，并通过仓库自带的 MAL 测试用例验证计算逻辑。若要深入理解 MAL 表达式的全部语法（标签操作、聚合、函数、downsampling 等），可继续阅读 MAL 语言文档；若需对比 OAP 自身的自可观测性指标（SO11Y_OAP），可参考 dashboards-so11y.md。

• 可观测性
• APM
• 链路追踪
• 指标监控
• 日志分析
• 微服务