Meta Description: 全面掌握阿里云国际版ACK可观测性体系：ARMS Prometheus监控、SLS日志采集分析、分布式链路追踪、Grafana可视化大盘。从零搭建生产级ACK监控告警平台。

> 关键词：阿里云ACK可观测性、ARMS Prometheus监控、SLS日志服务、ACK链路追踪、Grafana大盘、Kubernetes监控、ACK告警配置

前言

在云原生时代，可观测性（Observability） 已经从"锦上添花"变成了"生存必备"。当你的ACK集群上跑着几十个微服务、上百个Pod时，没有一套完整的监控-日志-追踪体系，故障排查就像在黑暗中摸索。

阿里云国际版为ACK提供了全套托管的可观测性产品矩阵：ARMS Prometheus（托管Prometheus监控）、SLS日志服务（集中式日志管理）、链路追踪Tracing Analysis（分布式调用链分析）以及Grafana托管服务（可视化大盘）。本文将逐一拆解每个组件的配置与最佳实践。

ACK可观测性产品矩阵全景图

在深入配置之前，先了解阿里云ACK可观测性生态的全貌：

| 产品 | 对标开源 | 核心能力 | 计费方式 | 推荐场景 | |------|----------|----------|----------|----------| | ARMS Prometheus | Prometheus + Thanos | 指标采集、存储、查询、告警 | 按指标数据量/节点数 | 生产级指标监控 | | SLS日志服务 | Elasticsearch + Logstash | 日志采集、索引、分析、可视化 | 按写入量/存储量 | 集中式日志管理 | | 链路追踪 | Jaeger / Zipkin | 分布式调用链分析、依赖拓扑 | 按Span数量 | 微服务调用链诊断 | | Grafana托管 | Grafana | 统一可视化大盘 | 免费（托管） | 多数据源统一展示 | | ACK控制台监控 | Kubernetes Dashboard | 集群/节点/Pod基础指标 | 免费 | 基础资源监控 | | 云监控CMS | — | ECS/SLB/RDS等云资源监控 | 免费（基础） | 云产品资源监控 |

> 核心思路：ARMS Prometheus 管指标（Metrics），SLS 管日志（Logs），链路追踪管调用链（Traces）——三者组成可观测性"三柱"。

一、ARMS Prometheus：ACK指标监控的生产级方案

1.1 为什么不用自建Prometheus？

很多团队习惯在ACK集群里自建Prometheus Operator，但生产环境会遇到三个致命问题：

| 问题 | 自建Prometheus | ARMS Prometheus | |------|---------------|-----------------| | 数据持久化 | 需要自己配置PVC/远程存储，Pod漂移可能丢数据 | 全托管存储，数据90天自动保留 | | 高可用 | 需要部署Thanos/Cortex，配置复杂 | 开箱即用，SLA 99.9% | | 大规模集群 | 单机Prometheus内存OOM是常态 | 自动分片，支持万级节点集群 | | 告警管理 | 自建Alertmanager，无ACK事件集成 | 内置告警模板，支持ACK事件、钉钉/企业微信通知 |

1.2 开启ARMS Prometheus监控

通过阿里云控制台操作（或CLI/API）：

`bash

方式一：控制台操作

ACK控制台 → 集群列表 → 选择目标集群 → 运维管理 → Prometheus监控 → 开启

方式二：aliyun CLI（国际版）

aliyun cs MODIFY_CLUSTER_CONFIG \ --ClusterId <cluster-id> \ --region ap-southeast-1 \ --body '{ "arms_prometheus": { "enabled": true, "retention_days": 90 } }' `

开启后，ARMS会自动部署 arms-prom 组件到集群中（DaemonSet + Deployment形式），无需手动管理。

1.3 关键指标速查表

ARMS Prometheus预置了大量ACK专属指标和控制台大盘。以下是生产环境最常用的一组PromQL查询：

| 监控场景 | PromQL查询 | 告警阈值建议 | |----------|-----------|-------------| | 节点CPU | 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) | > 80% | | 节点内存 | (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 | > 85% | | Pod CPU限流 | rate(container_cpu_cfs_throttled_seconds_total[5m]) | > 0.1 | | Pod重启次数 | rate(kube_pod_container_status_restarts_total[15m]) > 0 | > 0 | | Deployment副本不足 | kube_deployment_spec_replicas - kube_deployment_status_replicas_available | > 0 | | PVC使用率 | kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes * 100 | > 80% | | API Server延迟 | histogram_quantile(0.99, rate(apiserver_request_duration_seconds_bucket[5m])) | > 1s (P99) |

1.4 配置ACK专属告警规则

ARMS Prometheus自带ACK场景化告警模板，建议第一时间启用以下告警：

`yaml

通过ARMS控制台 → 告警规则 → 创建Prometheus告警

或通过Terraform/Pulumi等IaC方式管理

示例：节点不可用告警

apiVersion: monitoring.aliyun.com/v1 kind: PrometheusRule metadata: name: ack-node-alerts namespace: arms-prom spec: groups: - name: node.rules rules: - alert: NodeNotReady expr: kube_node_status_condition{condition="Ready",status="true"} == 0 for: 5m labels: severity: critical annotations: summary: "节点 {{ $labels.node }} 已不可用超过5分钟" - alert: NodeDiskPressure expr: kube_node_status_condition{condition="DiskPressure",status="true"} == 1 for: 1m labels: severity: warning annotations: summary: "节点 {{ $labels.node }} 磁盘空间不足"

- alert: HighPodRestartRate expr: rate(kube_pod_container_status_restarts_total[15m]) > 0.05 for: 5m labels: severity: warning annotations: summary: "Pod {{ $labels.pod }} 频繁重启，速率: {{ $value }}次/秒" `

二、SLS日志服务：ACK日志的集中式管理

2.1 Logtail采集架构

阿里云ACK通过 Logtail 组件采集容器日志，架构如下：

` ┌────────────────────────────────────────────────────────────┐ │ ACK 集群 │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Pod A │ │ Pod B │ │ │ │ stdout/stderr │ │ /var/log/app/* │ │ │ └──────┬───────────┘ └────────┬─────────┘ │ │ │ │ │ │ ┌──────▼───────────────────────▼──────────┐ │ │ │ Logtail DaemonSet │ │ │ │ (每个节点一个Pod，自动采集容器日志) │ │ │ └────────────────────┬────────────────────┘ │ └───────────────────────┼─────────────────────────────────────┘ │ ┌─────────▼─────────┐ │ SLS Logstore │ │ (日志存储+索引) │ └─────────┬─────────┘ │ ┌─────────────┼─────────────┐ │ │ │ ┌────▼────┐ ┌─────▼────┐ ┌─────▼─────┐ │ 查询分析 │ │ 可视化 │ │ 告警通知 │ │ (SQL) │ │ (图表) │ │ (钉钉等) │ └─────────┘ └──────────┘ └───────────┘ `

2.2 安装Logtail并配置采集

Logtail通过ACK组件管理安装：

`bash

方式一：ACK控制台 → 运维管理 → 组件管理 → 安装 logtail-ds

方式二：aliyun CLI

aliyun cs INSTALL_ADDON \ --ClusterId <cluster-id> \ --name logtail-ds \ --region ap-southeast-1 `

安装后，在SLS控制台创建Logtail采集配置。以下是生产级配置示例——采集Spring Boot应用JSON日志：

`yaml

Logtail采集配置（通过SLS控制台操作）

关键配置项：

inputType: container_stdout # 采集标准输出 inputDetail: IncludeLabel: app: spring-boot-api # 只采集带此标签的Pod ExcludeLabel: env: test # 排除测试环境 processorType: processor_parse_json # 解析JSON日志 processorDetail: SourceKey: content KeepSource: false # 解析后丢弃原始字段

索引配置（加速查询）

index: keys: level: text # 日志级别（INFO/WARN/ERROR） traceId: text # 链路追踪ID message: text # 日志内容 timestamp: long # 时间戳 ttl: 30 # 日志保留30天 `

2.3 SLS查询与分析实战

SLS支持类SQL的查询语法，比 kubectl logs 强大得多：

`sql -- 1. 查询最近1小时ERROR级别日志 * | SELECT "timestamp", "message" WHERE "level" = 'ERROR' AND __time__ > now() - 3600 ORDER BY __time__ DESC LIMIT 100

-- 2. 按服务统计错误率（日志分析） * | SELECT "app_name", COUNT(*) as total, COUNT_IF("level" = 'ERROR') as errors, ROUND(COUNT_IF("level" = 'ERROR') 100.0 / COUNT(), 2) as error_rate WHERE __time__ > now() - 3600 GROUP BY "app_name" HAVING errors > 0 ORDER BY error_rate DESC

-- 3. 通过traceId串联一次请求的所有日志 * | SELECT "timestamp", "service", "message" WHERE "traceId" = 'a1b2c3d4e5f6' ORDER BY "timestamp" ASC

-- 4. P99响应时间分析（需要日志中包含duration字段） * | SELECT approx_percentile("duration_ms", 0.50) as p50, approx_percentile("duration_ms", 0.95) as p95, approx_percentile("duration_ms", 0.99) as p99 WHERE __time__ > now() - 3600 `

2.4 SLS告警配置

基于日志内容配置告警，比指标告警更细粒度：

| 告警场景 | SLS查询条件 | 通知渠道 | |----------|------------|----------| | 应用异常 | level = 'ERROR' 出现频率 > 10次/分钟 | 钉钉群 + 短信 | | 认证失败 | message like '%Authentication failed%' | 钉钉群 | | 慢请求 | duration_ms > 3000 | 邮件 | | 磁盘日志暴涨 | Logstore写入速率突增 > 3倍 | 钉钉群 |

三、分布式链路追踪：打通微服务调用链

3.1 ACK链路追踪方案对比

阿里云ACK支持两种链路追踪方案：

| 方案 | 原理 | 侵入性 | 适用场景 | |------|------|--------|----------| | ARMS Tracing（推荐） | 自动注入Java Agent，无需改代码 | 零侵入 | Java应用（Spring Boot/Dubbo等） | | OpenTelemetry SDK | 在代码中手动集成OTel SDK | 需改代码 | 多语言（Go/Python/Node.js等） | | Jaeger Operator | 在ACK自建Jaeger | 需改代码 | 自建方案，完全控制 |

3.2 零侵入接入ARMS链路追踪（Java）

Java应用接入ARMS链路追踪只需两步——在Deployment中加上ARMS Agent的InitContainer和JVM参数：

`yaml apiVersion: apps/v1 kind: Deployment metadata: name: order-service spec: template: metadata: labels: app: order-service spec: # 关键：共享Volume传递Agent文件 volumes: - name: arms-agent emptyDir: {} initContainers: - name: arms-agent-init image: registry.ap-southeast-1.aliyuncs.com/arms/arms-agent:latest command: ['cp', '-r', '/arms-agent/.', '/arms-agent-dir/'] volumeMounts: - name: arms-agent mountPath: /arms-agent-dir containers: - name: app image: your-registry/order-service:latest env: # 关键JVM参数：加载ARMS Agent - name: JAVA_TOOL_OPTIONS value: >- -javaagent:/arms-agent/arms-bootstrap.jar -Darms.licenseKey=<your-arms-key> -Darms.appName=order-service -Darms.env=production -Darms.region=ap-southeast-1 volumeMounts: - name: arms-agent mountPath: /arms-agent `

接入后，ARMS控制台会自动展示服务拓扑、调用链瀑布图、接口耗时分析。

3.3 Go应用接入OpenTelemetry

对于Go/Python等非JVM语言，推荐使用OpenTelemetry SDK：

`go // Go应用接入OpenTelemetry示例 package main

import ( "context" "net/http" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc" "go.opentelemetry.io/otel/sdk/trace" "go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp" )

func initTracer() (*trace.TracerProvider, error) { // 通过OTLP协议上报到ARMS exporter, err := otlptracegrpc.New( context.Background(), otlptracegrpc.WithEndpoint("tracing-analysis-dc.ap-southeast-1.aliyuncs.com:8090"), otlptracegrpc.WithInsecure(), ) if err != nil { return nil, err } tp := trace.NewTracerProvider( trace.WithBatcher(exporter), trace.WithResource(resource.NewWithAttributes( semconv.ServiceNameKey.String("order-service"), )), ) otel.SetTracerProvider(tp) return tp, nil }

func main() { tp, _ := initTracer() defer tp.Shutdown(context.Background()) // 自动注入HTTP tracing http.Handle("/api/orders", otelhttp.NewHandler(orderHandler, "CreateOrder")) http.ListenAndServe(":8080", nil) } `

四、Grafana统一可视化大盘

4.1 创建ACK专用Grafana大盘

阿里云提供了Grafana托管工作区，支持一键导入ACK监控大盘模板：

`bash

在ACK控制台 → 运维管理 → Grafana → 创建工作区

或使用aliyun CLI创建

导入ACK预置大盘模板（Dashboard ID）：

- 节点监控大盘：12884

- Pod资源大盘：15757

- API Server监控：12006

- CoreDNS监控：14981

`

创建完成后，Grafana可以同时接入ARMS Prometheus（指标）、SLS（日志）、CloudMonitor（云资源）三个数据源，在一个页面中实现从指标异常 → 日志上下文 → 调用链追踪的完整排查路径。

4.2 核心大盘JSON配置要点

`json { "panels": [ { "title": "集群Pod状态概览", "targets": [ { "expr": "sum(kube_pod_status_phase{phase='Running'}) by (namespace)", "legendFormat": "{{ namespace }}" } ] }, { "title": "节点资源水位", "targets": [ { "expr": "100 - (avg by(node) (rate(node_cpu_seconds_total{mode='idle'}[5m])) * 100)", "legendFormat": "CPU: {{ node }}" }, { "expr": "(1 - node_memory_MemAvailable_bytes/node_memory_MemTotal_bytes) * 100", "legendFormat": "Memory: {{ node }}" } ] } ] } `

五、生产环境可观测性Checklist

在ACK集群投产前，逐项确认以下配置：

| 检查项 | 配置要求 | 验证命令/方法 | |--------|---------|-------------| | ✅ ARMS Prometheus已开启 | 所有节点的指标正常上报 | ARMS控制台 → 指标探索 → up 查询 | | ✅ 四大核心告警已配置 | 节点不可用、Pod重启、磁盘压力、CPU过载 | ARMS → 告警规则列表 | | ✅ 告警通知渠道已打通 | 钉钉群/企业微信/邮件至少一个 | 触发测试告警验证 | | ✅ Logtail已安装并采集 | 应用日志正常流入SLS | SLS控制台 → Logstore → 数据预览 | | ✅ SLS日志索引已配置 | 关键字段（level/traceId/message）可查 | SLS查询 | SELECT LIMIT 1 | | ✅ 链路追踪已接入 | 服务拓扑可见，调用链可查 | ARMS → 应用列表 → 调用链查询 | | ✅ Grafana大盘已创建 | 核心指标面板正常渲染 | Grafana工作区URL可访问 | | ✅ 日志保留策略已设定 | SLS Logstore TTL已设（建议30-90天） | SLS控制台 → Logstore属性 |

六、常见问题 FAQ

Q: ARMS Prometheus和ACK自带的监控有什么区别？

A: ACK控制台的监控只提供基础的CPU/内存/网络指标，数据保留时间短（通常7天），无法自定义告警和PromQL查询。ARMS Prometheus是完整的托管Prometheus服务，支持自定义指标、持久化存储、多维度告警和大盘。

Q: 自建Prometheus迁移到ARMS需要改动多少配置？

A: 几乎零改动。ARMS Prometheus完全兼容PromQL和Prometheus配置格式。已有的PrometheusRule、ServiceMonitor、PodMonitor可以直接迁移，只需把数据写入地址改为ARMS的Remote Write endpoint。

Q: SLS日志服务的成本怎么控制？

A: 三招控成本：（1）合理设置Logstore的TTL（不必永久保留）；（2）使用数据加工过滤掉DEBUG级别日志；（3）低频查询的日志降低索引字段数量。通常可以降低40%-60%费用。

Q: 链路追踪对应用性能有影响吗？

A: ARMS Java Agent采用采样机制（默认10%采样率，可调），对应用CPU开销通常在1-3%以内。如果使用全量采集可能有一定影响，建议生产环境保持10%-20%采样率。

Q: 跨账号/跨地域的ACK集群能做到统一可观测性吗？

A: 可以。同一个ARMS工作区可以接入多个ACK集群（不同账号通过RAM角色授权），SLS支持跨地域日志汇集（通过日志服务数据加工），Grafana工作区可以连接所有集群的数据源。建议在管理账号集中搭建全局可观测性平台。

总结

阿里云国际版ACK的可观测性体系已经相当成熟——ARMS Prometheus负责指标监控，SLS负责日志管理，链路追踪负责调用链分析，三者通过Grafana统一呈现，形成完整的"Metrics + Logs + Traces"三角矩阵。

对于刚上ACK的团队，建议按照以下顺序逐步建设：先开ARMS + 配置4大核心告警（1天）→ 安装Logtail采集日志（半天）→ 接入链路追踪（1天）→ 搭建Grafana大盘（半天）。全部配置完成通常不超过3个工作日，但带来的故障排查效率提升是数量级的——从"翻几百行kubectl logs"变成"一条追踪ID看全程"。

--- > 本文由 chengzicloud.cloud 提供，点击访问首页了解更多