企业官网建设流程全解析

• 存储
• 分布式文件系统
• 缓存
• 大数据

导读

本文聚焦于 Alluxio 以 Kubernetes 方式部署时的指标（Metrics）采集与监控配置，系统讲解两类主流 Sink（HTTP JSON Sink 与 Prometheus Sink）在集群环境中的启用方法：如何通过kubectl exec直接抓取各组件指标快照、如何借助 Helm Chart 一次性开启 Prometheus 指标暴露端点，以及如何编写prometheus.yml的 Kubernetes 服务发现规则完成对 Master、Worker、Job Master、Job Worker 与 Fuse 进程的分组件采集。读完本文，你将掌握在 Kubernetes Pod 内定位各组件 Web 端口、验证指标端点、并让 Prometheus 自动发现并抓取 Alluxio 指标的一套可落地操作流程。

本文以仓库文档 Metrics-On-Kubernetes.md 为主体，并结合 Metrics-System.md、Helm Chart 模板与核心源码（如 PrometheusMetricsServlet.java、WebServer.java）进行深度佐证。

Alluxio 指标系统在 Kubernetes 上的基本认知

Alluxio 的指标系统基于 Coda Hale Metrics Library 构建：source 产生指标，sink 消费指标，系统周期性地把指标记录投递给已配置的 sink。指标按组件划分为不同实例，在 Kubernetes 场景下，我们关心的是运行在 Pod 中的各类进程：

• Master：Alluxio master 进程（含 Job Master 进程）；
• Worker：Alluxio worker 进程（含 Job Worker 进程）；
• Fuse：独立的 Alluxio Fuse 进程（若单独部署）。

每个实例都可以配置多个 sink，本仓库支持的 sink 包括PrometheusMetricsServlet、ConsoleSink、CsvSink、JmxSink、GraphiteSink、MetricsServlet（JSON）等，完整的 sink 清单与配置模板见 conf/metrics.properties.template。

在深入具体 Sink 之前，建议先通读 Metrics-System.md 了解指标类型（Gauge、Meter、Counter、Timer）与通用配置方式；部署 Alluxio 到 Kubernetes 的完整步骤见 Running-Alluxio-On-Kubernetes.md。

在 Kubernetes 环境中，指标配置的载体与传统裸机部署不同：裸机下我们直接编辑${ALLUXIO_HOME}/conf/metrics.properties，而 Helm Chart 部署时则通过values.yaml中的metrics段生成 metrics 配置文件并挂载进各组件容器。下面分别介绍两种 Sink 的落地方式。

HTTP JSON Sink：开箱即用的指标快照

端口开启前置条件

HTTP JSON Sink 依靠各组件自带的 Web 服务暴露指标，核心前提只有一个——Web 端口可用：

• Alluxio master 与 worker 的 Web 端口默认开启，无需额外配置；
• Alluxio 独立 Fuse 进程的 Web 端口默认不开启，需要先在alluxio-site.properties（或 Helm 的properties配置）中设置alluxio.fuse.web.enabled=true再启动 Fuse 进程。

从源码可以印证这一设计：WebServer.java 中默认挂载了MetricsServlet（对应/metrics/json路径）与PrometheusMetricsServlet（对应/metrics/prometheus路径），而 Fuse 的 Web 端口开关则对应配置项alluxio.fuse.web.enabled（见 PropertyKey.java 中的FUSE_WEB_ENABLED定义）。

通过 kubectl exec 获取 JSON 指标快照

在 Pod 内直接向本进程的 Web 端口发起 HTTP 请求，即可拿到一份 JSON 格式的完整指标快照。通用命令模板：

$ kubectl exec <COMPONENT_HOSTNAME> -c <CONTAINER_NAME> -- curl 127.0.0.1:<COMPONENT_WEB_PORT>/metrics/json/

各组件对应的容器名、默认 Web 端口与请求示例如下（注意同一 Pod 内可能同时运行多个容器，需要用-c指定）：

# 获取主 master 的指标（默认 Web 端口 19999） $ kubectl exec <alluxio-master-x> -c alluxio-master -- curl 127.0.0.1:19999/metrics/json/ # 获取 worker 的指标（默认 Web 端口 30000） $ kubectl exec <alluxio-worker-xxxxx> -c alluxio-worker -- curl 127.0.0.1:30000/metrics/json/ # 获取 job master 的指标（默认 Web 端口 20002） $ kubectl exec <alluxio-master-x> -c alluxio-job-master -- curl 127.0.0.1:20002/metrics/json/ # 获取 job worker 的指标（默认 Web 端口 30003） $ kubectl exec <alluxio-worker-xxxxx> -c alluxio-job-worker -- curl 127.0.0.1:30003/metrics/json/ # 获取 fuse 进程的指标（默认 Web 端口 49999，需已开启 fuse Web） $ kubectl exec <alluxio-fuse-xxxxx> -- curl 127.0.0.1:49999/metrics/json/

各默认端口均可在源码中得到佐证，例如 master Web 端口在 PropertyKey.java 中MASTER_WEB_PORT的默认值为19999。

源码视角：/metrics/json 端点从何而来

从实现上看，MetricsServlet 同目录下的alluxio.metrics.sink.MetricsServlet负责将MetricsSystem.METRIC_REGISTRY中的指标以 JSON 形式序列化输出；在 WebServer.java 中，该 Servlet 的 handler 与主 ServletContextHandler 一并注册进 Jetty 的 Handler 链，从而对外提供/metrics/json路径。也就是说，只要组件 Web 服务在运行，JSON 指标端点就天然可用，无需任何 metrics 配置文件。

Master Web UI 可视化：把原始指标变成可读趋势

除了通过 servlet 或自定义 metrics 配置拿到原始指标，还可以在 Alluxio 主 master 的 Web 界面中，以更直观的图表方式跟踪集群关键性能指标。

该页面（对应文档中的screenshot_generalMetrics.png）展示的核心内容包括：

• Alluxio 空间与根 UFS 空间百分比使用情况的时间序列；
• 集群聚合吞吐量的时间序列，是判断 Alluxio 缓存有效性的关键指标；
• 集群累计的 RPC 调用次数与操作数；
• 按挂载点统计的累计 API 调用次数，可用于量化命名空间虚拟化带来的延迟与成本收益。

其中“Local Alluxio (Short-circuit) Read/Write”“Remote Alluxio Read/Write”“Under Filesystem Read/Write”等图表分别对应Cluster.BytesReadLocal、Cluster.BytesWrittenLocal、Cluster.BytesReadRemote、Cluster.BytesWrittenRemote、Cluster.BytesReadUfsAll、Cluster.BytesWrittenUfsAll等原始指标，完整的指标释义可查阅 Metrics-List.md。

访问 Web UI：kubectl port-forward

Pod 内的端口默认不对集群外部开放，需要先把物理机端口转发到 master 的 Web 端口。假设主 master 运行在 Podalluxio-master-0中，希望在节点master-node-1上用 8080 端口对外提供 master Web UI，可在控制平面执行：

$ kubectl port-forward <CONTROL_PLANE_HOSTNAME> pods/alluxio-master-0 8080:19999

转发完成后，即可在浏览器访问：

http://<leading_master_node_hostname>:<forwared_port>/metrics

例如http://master-node-1:8080/metrics。关于 Web UI 访问的更详细说明，参见 Running-Alluxio-On-Kubernetes.md 的 “Access the Web UI” 一节。

Prometheus Sink：将 Alluxio 接入标准监控体系

Prometheus 是广泛使用的监控与告警工具，通过抓取（scrape）HTTP 端点来持续采集指标变化。相比 JSON 快照的一次性查看，Prometheus 接入适合长期、自动化的集群监控。

第一步：Helm Chart 中开启 Prometheus 指标

Prometheus 格式的指标输出依赖PrometheusMetricsServlet被启用。在 Helm Chart 的value.yaml（即 values.yaml）中，通过metrics段配置：

metrics: enabled: true PrometheusMetricsServlet: true podAnnotations: prometheus.io/scrape: "true" prometheus.io/masterWebPort: "<MASTER_WEB_PORT>" prometheus.io/jobMasterWebPort: "<JOB_MASTER_WEB_PORT>" prometheus.io/workerWebPort: "<WORKER_WEB_PORT>" prometheus.io/jobWorkerWebPort: "<JOB_WORKER_WEB_PORT>" prometheus.io/fuseWebPort: "<FUSE_WEB_PORT>" prometheus.io/path: "/metrics/prometheus/"

其中<MASTER_WEB_PORT>、<WORKER_WEB_PORT>等占位符应替换为实际端口（如 19999、30000），并保持与 values.yaml 中注释示例（prometheus.io/port: "19999"、prometheus.io/jobPort: "20002"、prometheus.io/workerPort: "30000"、prometheus.io/path: "/metrics/prometheus/"）一致。

与 HTTP JSON Sink 相同，若需要采集Fuse进程的 Prometheus 指标，同样必须先把alluxio.fuse.web.enabled设置为true打开 Fuse Web 端口。

Helm 模板如何把配置落到 Pod

从 Chart 模板可以看出这套配置的完整流转链路：

• alluxio-metrics.yaml：当metrics.enabled=true时生成名为<release>-metrics的 ConfigMap，其metrics.properties数据段中，PrometheusMetricsServlet.enabled为 true 时会写入sink.prometheus.class=alluxio.metrics.sink.PrometheusMetricsServlet；其他如 ConsoleSink、CsvSink、JmxSink、GraphiteSink、Slf4jSink 也在此按开关生成对应配置行；
• alluxio-conf.yaml：当metrics.enabled=true时向 JVM 启动参数追加-Dalluxio.metrics.conf.file=/config/metrics/metrics.properties，让组件读取上述 metrics 配置文件；
• statefulset.yaml 与 daemonset.yaml：将-metrics-volume挂载到容器/config/metrics路径，并把metrics.podAnnotations合并进 Pod 注解。

注意 values.yaml 中metrics.enabled默认是false，即默认不启用任何指标采集，需要显式开启。

源码视角：PrometheusMetricsServlet 的实现

PrometheusMetricsServlet.java 的实现非常直接：

• 常量SERVLET_PATH = "/metrics/prometheus"定义了暴露路径；
• 构造函数将 Alluxio 的MetricRegistry通过DropwizardExports注册到 Prometheus 的CollectorRegistry，从而把 Dropwizard 指标转换为 Prometheus 格式；
• getHandler()返回一个 JettyServletContextHandler，其 context path 为/metrics/prometheus，并挂载 Prometheus 官方的MetricsServlet处理抓取请求。

在 WebServer.java 中，PrometheusMetricsServlet的 handler 与MetricsServlet（JSON）、主 ServletContextHandler 一起被设置进 Jetty 的 Handler 链，这就是各组件同时支持/metrics/json/与/metrics/prometheus/两个端点的原因。

第二步：配置 Prometheus 客户端（prometheus.yml）

开启PrometheusMetricsServlet只解决了“端点可用”的问题，要让 Prometheus 服务器真正抓取指标，还需要在客户端配置prometheus.yml。Kubernetes 部署通常使用Pod 角色（role: pod）的服务发现，配合注解与 relabel 规则筛选目标。下面是读取 master 指标的标准配置：

scrape_configs: - job_name: 'alluxio master' kubernetes_sd_configs: - role: pod namespaces: names: - alluxio # Only look at pods in namespace named `alluxio` relabel_configs: # Only check the pods with role `alluxio-master` - source_labels: [__meta_kubernetes_pod_label_role] action: keep regex: alluxio-master # Only check the pods with annotation prometheus.io/scrape is true - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true # Use the value of prometheus.io/path in podAnnotation for endpoint - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.+) # Use the value of prometheus.io/masterWebPort in podAnnotation for port - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_masterWebPort] action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 target_label: __address__ - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - source_labels: [__meta_kubernetes_namespace] action: replace target_label: namespace - source_labels: [__meta_kubernetes_pod_name] action: replace target_label: pod_name - source_labels: [__meta_kubernetes_pod_node_name] action: replace target_label: node - source_labels: [__meta_kubernetes_pod_label_release] action: replace target_label: cluster_name

这段配置的 relabel 逻辑值得逐条理解：

1. 筛选目标：先按 Pod 标签role=alluxio-master（keep+regex: alluxio-master）只保留 master Pod；再按注解prometheus.io/scrape=true过滤掉未开启采集的 Pod。Pod 上的role标签来自 Chart 模板——例如 statefulset.yaml 中 master 的标签是role: alluxio-master，daemonset.yaml 中 worker 的标签是role: alluxio-worker；
2. 改写抓取地址：用 Pod 注解中的prometheus.io/path覆盖默认的__metrics_path__（即/metrics/prometheus/），并用prometheus.io/masterWebPort注解中的端口号拼接到__address__上（regex: ([^:]+)(?::\d+)?;(\d+)、replacement: $1:$2将 “地址;端口” 重组为 “地址:端口”）；
3. 附加标签：把 Pod 标签、命名空间、Pod 名、节点名、release 标签分别映射为namespace、pod_name、node、cluster_name等标签，便于后续在 Prometheus/Grafana 中按维度聚合。

Worker 指标配置

读取 worker 指标时，只需把role标签改为alluxio-worker，端口注解改为prometheus.io/workerWebPort：

scrape_configs: - job_name: 'alluxio worker' kubernetes_sd_configs: - role: pod namespaces: names: - alluxio # Only look at pods in namespace named `alluxio` relabel_configs: # Only look at the pods with role `alluxio-worker` - source_labels: [__meta_kubernetes_pod_label_role] action: keep regex: alluxio-worker # Only check the pods with annotation prometheus.io/scrape is true - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true # Use the value of prometheus.io/path in podAnnotation for endpoint - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.+) # Use the value of prometheus.io/workerWebPort in podAnnotation for port - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_workerWebPort] action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 target_label: __address__ - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - source_labels: [__meta_kubernetes_namespace] action: replace target_label: namespace - source_labels: [__meta_kubernetes_pod_name] action: replace target_label: pod_name - source_labels: [__meta_kubernetes_pod_node_name] action: replace target_label: node - source_labels: [__meta_kubernetes_pod_label_release] action: replace target_label: cluster_name

Job Master 指标配置

Job Master 进程与 Master 进程运行在同一个 master Pod 内，因此按role=alluxio-master筛选，但端口使用prometheus.io/jobMasterWebPort注解（默认 20002）：

scrape_configs: - job_name: 'alluxio job master' kubernetes_sd_configs: - role: pod namespaces: names: - alluxio # Only look at pods in namespace named `alluxio` relabel_configs: # Only look at the pods with role `alluxio-master` - source_labels: [__meta_kubernetes_pod_label_role] action: keep regex: alluxio-master # Only check the pods with annotation prometheus.io/scrape is true - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true # Use the value of prometheus.io/path in podAnnotation for endpoint - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.+) # Use the value of prometheus.io/jobMasterWebPort in podAnnotation for port - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_jobMasterWebPort] action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 target_label: __address__ - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - source_labels: [__meta_kubernetes_namespace] action: replace target_label: namespace - source_labels: [__meta_kubernetes_pod_name] action: replace target_label: pod_name - source_labels: [__meta_kubernetes_pod_node_name] action: replace target_label: node - source_labels: [__meta_kubernetes_pod_label_release] action: replace target_label: cluster_name

Job Worker 指标配置

Job Worker 进程与 Worker 进程运行在同一个 worker Pod 内，因此按role=alluxio-worker筛选，但端口使用prometheus.io/jobWorkerWebPort注解（默认 30003）：

scrape_configs: - job_name: 'alluxio job worker' kubernetes_sd_configs: - role: pod namespaces: names: - alluxio # Only look at pods in namespace named `alluxio` relabel_configs: # Only look at the pods with role `alluxio-worker` - source_labels: [__meta_kubernetes_pod_label_role] action: keep regex: alluxio-worker # Only check the pods with annotation prometheus.io/scrape is true - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: true # Use the value of prometheus.io/path in podAnnotation for endpoint - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] action: replace target_label: __metrics_path__ regex: (.+) # Use the value of prometheus.io/jobWorkerWebPort in podAnnotation for port - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_jobWorkerWebPort] action: replace regex: ([^:]+)(?::\d+)?;(\d+) replacement: $1:$2 target_label: __address__ - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - source_labels: [__meta_kubernetes_namespace] action: replace target_label: namespace - source_labels: [__meta_kubernetes_pod_name] action: replace target_label: pod_name - source_labels: [__meta_kubernetes_pod_node_name] action: replace target_label: node - source_labels: [__meta_kubernetes_pod_label_release] action: replace target_label: cluster_name

读取其他组件指标时，只需要相应地替换role 标签值与Web 端口注解名（如masterWebPort、workerWebPort、jobMasterWebPort、jobWorkerWebPort、fuseWebPort），其余 relabel 规则可完全复用。

第三步：验证 Prometheus 端点快照

配置完成后，可在 Pod 内直接向 Prometheus 端点发起请求，验证指标是否以 Prometheus 文本格式正常输出：

$ kubectl exec <COMPONENT_HOSTNAME> -c <CONTAINER_NAME> -- curl 127.0.0.1:<COMPONEMT_WEB_PORT>/metrics/prometheus/ # 例如，获取主 master 的 Prometheus 格式指标（默认 Web 端口 19999） $ kubectl exec <alluxio-master-x> -c alluxio-master -- curl 127.0.0.1:19999/metrics/prometheus/ # 获取 worker 的指标（默认 Web 端口 30000） $ kubectl exec <alluxio-worker-xxxxx> -c alluxio-worker -- curl 127.0.0.1:30000/metrics/prometheus/ # 获取 job master 的指标（默认 Web 端口 20002） $ kubectl exec <alluxio-master-x> -c alluxio-job-master -- curl 127.0.0.1:20002/metrics/prometheus/ # 获取 job worker 的指标（默认 Web 端口 30003） $ kubectl exec <alluxio-worker-xxxxx> -c alluxio-job-worker -- curl 127.0.0.1:30003/metrics/prometheus/ # 获取 fuse 进程的指标（默认 Web 端口 49999） $ kubectl exec <alluxio-fuse-xxxxx> -- curl 127.0.0.1:49999/metrics/prometheus/

端点验证通过后，即可在 Grafana、Datadog 等可视化平台中将这些端点配置为 Prometheus 数据源；非 Kubernetes 环境下的静态 targets 配置方式可参考 Metrics-System.md 中的prometheus.yml示例（metrics_path: '/metrics/prometheus/'+static_configs）。

实践要点与注意事项

1. Fuse 端口默认关闭：无论 JSON 还是 Prometheus 方式，采集 Fuse 指标都必须先设置alluxio.fuse.web.enabled=true。这一约束在 PropertyKey.java 的FUSE_WEB_ENABLED与 Metrics-System.md 中均有明确说明。
2. master 与 job master 共用 Pod：二者通过-c指定不同容器（alluxio-master/alluxio-job-master）来区分；Prometheus 抓取时则依靠不同端口注解（masterWebPort/jobMasterWebPort）区分，因为两者的 Pod role 标签相同。
3. 指标名的变形：Prometheus 处理指标名时会做转换，通常把.替换为_，有时还会追加后缀。建议先用上面的curl命令查看端点输出的原始指标名，再在 Prometheus/Grafana 中引用，避免因名称变形而查询不到。
4. HA 集群的备 master：默认情况下备 master 不提供指标服务，如需备 master 也输出指标，可在配置中启用alluxio.standby.master.metrics.sink.enabled=true（详见 Metrics-System.md）。
5. 版本适用前提：以上配置针对当前仓库对应版本编写，端口默认值（master 19999、job master 20002、worker 30000、job worker 30003、fuse 49999）来自本文关联文档与 PropertyKey.java；如使用其他版本，请以实际部署版本的默认配置为准。

通过以上步骤，你可以在 Kubernetes 集群中同时拥有两种监控手段：用 JSON 端点做临时排障的快照查看，用 Prometheus 端点做持续采集与可视化，并借助 Helm Chart 的metrics配置把整套指标体系随集群一起部署。更多 Alluxio 指标项的完整释义，可查阅 Metrics-List.md。

• 存储
• 分布式文件系统
• 缓存
• 大数据