行业资讯
06 云上运维监控：node-exporter + Prometheus + Grafana 全栈可观测
06 云上运维监控node-exporter Prometheus Grafana 全栈可观测本篇是「基于华为云 FlexusX 四节点集群的云计算全栈实操」系列第 6 篇。前面我们打通了网络和高可用入口但看不见系统状态的集群等于盲飞。本篇用 node-exporter Prometheus Grafana 把四节点node1~node4的运行状态全部可视化。所有数据与踩坑均来自真实实测results/07_prometheus.txt、08_grafana.txt、scripts/grafana_verify.py。1. 引子没有监控的系统出事后你只能靠猜。一次 CPU 飙到 100%、一次磁盘写满、一次某节点悄悄失联——如果没有指标你连发生了什么、在哪台、从几点开始都答不上来。我在四节点上搭了一套经典监控栈每台跑 node-exporter 采集主机指标 → node1 的 Prometheus 统一拉取scrape→ Grafana 出图。全程 Docker 化并接入华为云镜像加速。实测 4 个节点 target 全up端到端up查询 5 个实例全为 1。2. 背景与理论对照《深入浅出云计算》课程里把可观测性Observability拆成三支柱本篇是地基Metrics指标数值型时间序列如 CPU%、内存、磁盘、网络。Prometheus 是事实标准。→ 本篇主角。Logging日志离散事件文本。ELK / Loki 负责。Tracing链路一次请求跨服务的调用链。Jaeger / Tempo 负责。三支柱不是互斥而是互补。本期先把 Metrics 这一柱立起来——它最便宜、覆盖最广是告警的第一来源。Prometheus 工作模型是拉pull中心节点按scrape_interval主动去各target的/metrics端点抓取而不是 agent 主动推。好处是中心可控、target 无状态坏处是中心要能访问到所有 target所以上篇强调必须走内网。3. 环境与准备节点弹性公网 IP私有 IP监控角色node1113.47.6.41192.168.0.252Prometheus:9090 Grafana:3000 node-exporter:9100node2124.70.93.52192.168.0.64node-exporter:9100node31.94.220.182192.168.0.241node-exporter:9100node4124.70.102.139192.168.0.150node-exporter:9100规格均为 8vCPU/16GiB、Ubuntu 24.04.4 LTS同 VPC 同子网内网互通。镜像加速华为云 SWR 加速器拉prom/node-exporter等官方镜像更快# 配置 Docker 镜像加速华为云sudomkdir-p/etc/dockersudotee/etc/docker/daemon.jsonJSON { registry-mirrors: [https://mirror.huaweicloud.com] } JSONsudosystemctl restartdocker4. 实操步骤与完整配置4.1 架构node2/3/4:9100 node-exporter ┐ node1:9100 node-exporter ├─(内网 pull /metrics)─► node1:9090 Prometheus ─► node1:3000 Grafana node1:9090 prometheus 自身 ┘4.2 各节点启动 node-exporter# 四台都跑用私有 IP 暴露仅内网可达dockerrun-d--namenode-exporter\--restartunless-stopped\-p9100:9100\prom/node-exporter:latest4.3 node1 上的 prometheus.yml# /opt/prometheus/prometheus.ymlglobal:scrape_interval:15sevaluation_interval:15sscrape_configs:-job_name:nodestatic_configs:-targets:-192.168.0.252:9100# node1-192.168.0.64:9100# node2-192.168.0.241:9100# node3-192.168.0.150:9100# node4labels:group:flexusx-cluster-job_name:prometheusstatic_configs:-targets:[127.0.0.1:9090]4.4 启动 Prometheusnode1dockerrun-d--nameprometheus\--restartunless-stopped\-p9090:9090\-v/opt/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml\prom/prometheus:latest4.5 启动 Grafananode1dockerrun-d--namegrafana\--restartunless-stopped\-p3000:3000\-eGF_SECURITY_ADMIN_USERadmin\-eGF_SECURITY_ADMIN_PASSWORDAdmin2026\grafana/grafana:latest注意密码用Admin2026无特殊字符。早期我用了含的密码踩了大坑见第 7 节。5. 真实输出实测数据未篡改5.1 Prometheus Targets 全部 up Targets health node1-ecs-0001 - up node2-ecs-0002 - up node3-ecs-0003 - up node4-ecs-0004 - up 127.0.0.1:9090 - up5.2 PromQL各节点 CPU 核数与内存 PromQL: 各节点CPU核数 None 8 cores PromQL: 各节点内存总量(GiB) node2-ecs-0002 14.78 GiB node1-ecs-0001 14.78 GiB node3-ecs-0003 14.78 GiB node4-ecs-0004 14.78 GiB4 个节点均为 8 核、14.78 GiB 内存16GiB 扣除内核预留后的可用量与购买规格一致。5.3 Grafana 端到端验证数据源: Prometheus uidbft95tx1xnocgb urlhttp://192.168.0.252:9090 端到端 up 查询: [node2-ecs-00021, 127.0.0.1:90901, node1-ecs-00011, node3-ecs-00031, node4-ecs-00041] 各节点 load1: [(node2-ecs-0002, 0.0), (node1-ecs-0001, 0.09), (node3-ecs-0003, 0.0), (node4-ecs-0004, 0.01)] 仪表盘导入: Node Exporter Full | url: /d/rYdddlPWk/node-exporter-full证明Grafana 通过数据源代理查询 Prometheus5 个实例up全为 1集群健康各节点 1 分钟负载极低空闲态Node Exporter Full 仪表盘dashboard id1860成功导入。6. 深度解读重点6.1 监控架构为什么这样画node-exporter 放每台它只暴露主机指标无状态、资源占用极小几 MB适合铺满所有节点。Prometheus 只在 node1pull 模型下中心化采集配一份static_configs即可无需每台装 agent。注意 scrape 地址用私有 IP既快又免费上篇实测内网 6.3 Gbps。Grafana 同机Grafana 只是 Prometheus 的前端数据源指向http://192.168.0.252:9090通过 Prometheus proxy 查询不直接碰 exporter。6.2 关键 PromQL 示例# 1) 实例存活1up0down告警核心 up # 2) 各节点 CPU 核数按 idle 核计数 count by (instance) (node_cpu_seconds_total{modeidle}) # 3) 各节点内存总量GiB node_memory_MemTotal_bytes / 1024 / 1024 / 1024 # 4) 各节点 1 分钟负载 node_load1 # 5) 内存使用率推荐上告警 1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) # 6) CPU 使用率1-空闲占比 1 - avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m]))6.3 Node Exporter Full 仪表盘直接导入官方 dashboard id1860Node Exporter Full它已封装了 CPU、内存、磁盘、网络、文件系统、温度等几十张面板开箱即用。导入时把数据源绑定到我们的Prometheus即可。实测导入后 URL 为/d/rYdddlPWk/node-exporter-full。6.4 可观测性三支柱与告警建议Metrics 到位后下一步补 LoggingLoki和 TracingTempo三者用同一个 Grafana 统一看板。告警Prometheus 配alerting Alertmanager或 Grafana 自带的告警。至少盯这 4 条up 0节点/实例掉线node_load1 核数 * 0.8过载内存使用率 85%磁盘使用率 85%node_filesystem_avail_bytes / node_filesystem_size_bytes把告警推到企业微信 / 钉钉 webhook做到故障先于用户投诉被发现。7. 踩坑与排障真实遇到的坑7.1 Grafana 密码含→ 401 鉴权失败最初给 Grafana 设的 admin 密码里带了特殊字符通过 API / curl 传-u admin:xxxyyy时被解析成 URL 的用户主机分隔符导致鉴权 401。两种解法# 解法 A用 grafana cli 重置容器内需进容器执行dockerexec-itgrafana grafana-cli admin reset-admin-password Admin2026# 解法 B更干脆——重建容器密码用不含特殊字符的串如 Admin2026dockerrm-fgrafanadockerrun-d--namegrafana-p3000:3000\-eGF_SECURITY_ADMIN_PASSWORDAdmin2026grafana/grafana:latest经验密码别用、:、/这类在 URL 里有语义的字符否则 Basic Auth、连接串、API 调用处处是雷。7.2UID是 bash 只读变量 → 脚本直接报错在 bash 里UID是只读内置变量当前用户数字 ID不能赋值。我在脚本里写UIDbft95tx1xnocgb想存数据源 uid结果bash: line 5: UID: readonly variable直接把变量改名即可DS_UIDbft95tx1xnocgb# 改用非保留名echouid$DS_UID经验脚本里永远别用UID、EUID、LINENO、RANDOM等 bash 保留/只读变量名。起名加前缀如DS_、MY_最稳妥。7.3 内联 Python 转义太复杂 → 改上传脚本最初想一行curl ... | python3 -c ...在 bash 里解析 Grafana 返回 JSON结果引号嵌套套套直接语法报错bash: -c: line 6: syntax error near unexpected token (与其跟 shell 转义死磕不如把逻辑写成独立 Python 文件grafana_verify.py上传执行干净可靠。脚本核心# scripts/grafana_verify.py节选importjson,urllib.request,base64 AUTHBasic base64.b64encode(badmin:Admin2026).decode()BASEhttp://127.0.0.1:3000defapi(path,dataNone):requrllib.request.Request(BASEpath,datajson.dumps(data).encode()ifdataelseNone,headers{Content-Type:application/json,Authorization:AUTH})returnjson.load(urllib.request.urlopen(req,timeout20))dsapi(/api/datasources)uidds[0][uid]qapi(f/api/datasources/proxy/uid/{uid}/api/v1/query?queryup)ups[r[metric].get(instance)r[value][1]forrinq[data][result]]print(端到端 up 查询:,ups)经验复杂 JSON 解析、多步 API 调用别塞进python3 -c单行。写成.py文件可读性、可维护性、可调试性全过来。这也是本系列所有复杂验证脚本的做法。8. 自建监控 vs 云厂商 AOM/云监控维度自建 PrometheusGrafana华为云 AOM / 云监控成本复用现有机器免费按指标量/存储收费灵活度任意 PromQL、自定义仪表盘受产品能力限制长期存储需外接 Thanos/Mimir 解决托管自带留存运维自己管高可用、容量全托管学习价值高理解监控原理低开箱即用我的建议学习 / 私有化 / 需要深度自定义 → 自建生产要省心、要跨 AZ 高可用、要告警闭环 → 用云厂商托管监控AOM或自建 Prometheus 做采集、远端写remote_write到托管 TSDB。本篇的价值在于——先自己搭一遍你才看得懂云厂商监控在卖什么。9. 小结本篇搭建了完整的轻量监控栈四节点各跑node-exporter:9100node1 的Prometheus:9090拉取 4 节点 自身targets全 up各节点实测8 核 / 14.78 GiB空闲 load1 接近 0集群健康Grafana 数据源uidbft95tx1xnocgb指向http://192.168.0.252:9090端到端up查询 5 实例全为 1导入 Node Exporter Fullid 1860三个真实坑密码含致 401重置/改密、UID是 bash 只读变量改名、内联 Python 转义翻车改上传grafana_verify.py给出 6 条核心 PromQL 与 4 条必配告警并对比了自建与云厂商监控的取舍。至此IaaS 篇网络 → 负载均衡 → 监控三篇收官。集群已经通了、稳了、看得见——下一系列将进入 PaaS/应用层把真实业务跑上去。脚本参考../scripts/grafana_verify.py端到端数据源/up/load1 校验与仪表盘导入。
郑州网站建设
网页设计
企业官网
