1. 环境准备：ARM架构下的基础搭建
第一次在国产化麒麟系统上部署Prometheus时，我踩过不少坑。华为鲲鹏ARM架构和常见的x86环境差异比想象中更大，光是找齐兼容的安装包就花了半天时间。这里分享下我的实战经验，帮你避开那些"暗礁"。
Go语言环境是首要门槛。Prometheus是用Go编写的，所以需要先配置ARM版的Go环境。我推荐使用1.19以上版本，太老的版本可能会遇到奇怪的兼容性问题。下载时注意选择linux-arm64后缀的压缩包，这是关键：
wget https://dl.google.com/go/go1.19.3.linux-arm64.tar.gz解压时建议直接放到/usr/local目录，这是Linux系统的标准做法。记得配置环境变量时要用绝对路径，我遇到过因为路径错误导致go version命令失效的情况：
export PATH=$PATH:/usr/local/go/bin验证环节很多人会忽略。正确的版本输出应该明确显示linux/arm64平台标识，如果看到amd64那肯定是下错包了。有个小技巧：用file命令检查二进制文件属性会更可靠：
file $(which go) # 应该显示：ELF 64-bit LSB executable, ARM aarch64系统依赖项检查也很重要。麒麟系统默认可能缺少一些库，建议提前安装这些基础组件：
yum install -y tar wget curl libcap遇到过最头疼的问题是动态链接库缺失。可以用ldd命令预检Prometheus二进制文件：
ldd prometheus # 确保所有库显示为"found"2. Prometheus核心组件部署
当Go环境就绪后，真正的挑战才开始。Prometheus的ARM版安装包在GitHub releases页面很容易被忽略，下载时要注意版本匹配。我习惯用2.40.x稳定版，太新的版本在ARM架构上可能有未知问题。
解压后的目录结构很有讲究。建议建立专门的/opt/prometheus目录，这样既符合Linux文件系统规范，又方便后期维护。实测发现直接运行二进制文件可能会报权限错误，需要先执行：
chmod +x prometheus配置文件调优是影响性能的关键。默认的prometheus.yml需要针对ARM做这些调整：
global: scrape_interval: 30s evaluation_interval: 30s鲲鹏处理器虽然性能强劲，但建议拉取间隔不要小于15秒。我在测试中发现高频采集会导致内存占用飙升。
服务化部署比直接运行更可靠。创建systemd服务单元时，这些参数对ARM平台特别重要：
[Service] LimitNOFILE=65536 Environment="GOMAXPROCS=8"记得设置正确的数据存储路径。ARM平台的IO性能与x86不同，建议单独挂载SSD分区给Prometheus：
--storage.tsdb.path=/data/prometheus启动后验证服务状态时，别只看端口是否监听。更可靠的方法是检查metrics接口：
curl http://localhost:9090/metrics | head3. 客户端监控配置实战
Node Exporter的ARM版部署有讲究。很多人卡在服务启动失败，其实问题常出在动态库依赖。推荐使用静态编译版本，下载时认准linux-arm64标签：
wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-arm64.tar.gz采集器选择直接影响资源消耗。在鲲鹏CPU上，这些采集器性价比最高：
--collector.cpu --collector.meminfo --collector.diskstats避免启用--collector.netdev这类高频采集器，它们在ARM架构上容易引发上下文切换问题。
服务配置模板需要特别注意权限问题。麒麟系统的SELinux策略较严格，建议这样配置：
[Unit] After=network-online.target Wants=network-online.target [Service] User=node_exporter Group=node_exporter防火墙规则设置是个易错点。除了开放9100端口，还需要允许Prometheus服务器的IP访问：
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="9100" accept'指标验证阶段容易被忽视。正确的测试方法是：
curl -s http://localhost:9100/metrics | grep -i 'node_cpu_seconds_total'4. 告警规则与可视化配置
告警规则在ARM平台需要特别优化。由于指令集差异，同样的表达式可能比x86消耗更多资源。这是我验证过的几个高效规则：
- alert: HighCPU expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100) > 80 for: 3m内存计算方式需要调整。麒麟系统的内存管理有些特殊，这个表达式更准确：
expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 85磁盘规则要处理挂载点差异。华为设备常有特殊分区，需要过滤：
expr: 100 - (node_filesystem_avail_bytes{fstype=~"ext4|xfs",mountpoint!~"/boot|/tmp"} / node_filesystem_size_bytes{fstype=~"ext4|xfs",mountpoint!~"/boot|/tmp"} * 100) > 90告警分级策略很关键。建议设置多级阈值，比如：
labels: severity: warning annotations: summary: "{{ $labels.instance }} CPU高负载({{ $value }}%)"看板配置时要注意ARM的指标特性。Grafana中这些模板最实用：
- 节点概览：1860
- 主机监控：11074
- 磁盘性能：11800
最后提醒下，所有配置变更后，不要直接用kill重启服务。正确的方式是：
systemctl reload prometheus在实际生产环境中，这套配置已经稳定运行了半年多。最关键的经验是：ARM平台的监控数据间隔要适当放大，压缩存储周期建议设置为2小时而不是默认的1小时，这对SSD寿命更友好。遇到性能问题时，先检查/var/log/messages中的OOM日志，适当调整Go的GC参数会有奇效。
