可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载本文以 OneUptime 仓库中的 Proxmox Monitor 文档为主线完整讲解如何监控 Proxmox VE 集群的节点、QEMU 虚拟机、LXC 容器、存储、HA 状态、备份任务覆盖与存储复制并深入 agent 的 OpenTelemetry Collector 配置与pve_*指标体系。读完本文你将掌握 Proxmox Monitor 的创建流程、指标查询与公式配置、内置告警模板的原理以及部署 Proxmox Agent 和排查问题的完整实战方案。概述Proxmox 监控能做什么OneUptime 的 Proxmox 监控能力让你可以透视整个 Proxmox VE 集群的虚拟化工作负载。监控数据由OneUptime Proxmox Agent一个预配置的 OpenTelemetry Collector负责采集再根据你在 OneUptime 中配置的指标标准进行评估。它能带来以下几类核心能力监控集群、节点以及每个 guest虚拟机/容器的健康状态跨节点与 guest 追踪 CPU、内存、磁盘和网络的用量及时发现离线节点与已停止的虚拟机/容器观察接近容量上限的存储卷对 HA 降级状态、未被任何备份任务覆盖的 guest、以及失败的存储复制发出告警数据链路可以概括为Proxmox VE API→prometheus-pve-exporter把 API 翻译成pve_*Prometheus 指标→Proxmox AgentOTel Collector 抓取并打上集群身份标签→OTLP上报 OneUptime。创建 Proxmox Monitor在 OneUptime Dashboard 中创建 Proxmox 监控的步骤如下进入Monitors监控器页面点击Create Monitor创建监控器监控类型选择Proxmox选择要监控的 Proxmox 集群配置指标查询与聚合方式按需配置监控判定标准criteria集群本身无需手动创建——集群会在 Proxmox Agent 第一次向其上报遥测数据时自动注册注册的键是资源属性proxmox.cluster.name见后文 agent 配置。因此在创建监控之前请先确保 Agent 已经部署并开始上报详见本文「部署 Proxmox Agent」一节。配置选项详解Proxmox 集群选择在选择器中挑选要监控的集群即可。集群的自动注册机制由 Agent 的resource处理器实现——在 otel-collector-config.yaml 中每个指标批次都会被写入proxmox.cluster.name属性resource: attributes: - key: proxmox.cluster.name value: ${env:PROXMOX_CLUSTER_NAME} action: upsert配置中特别强调保持该值稳定不要随意修改否则会注册出一个全新的集群与旧集群的数据割裂也会影响按集群的保留期设置。指标查询Metric Queries每个监控可以配置一个或多个指标查询每个查询需要指定指标名称Metric name——要查询的 Proxmox 指标即pve_*系列聚合Aggregation——指标值的聚合方式平均值、总和、最大值、最小值过滤器Filters——基于属性过滤可以直接过滤原始id标签也可以过滤派生的pve.scope/pve.type/pve.id属性见下节Group By分组——可选地按id标签分组使每个节点、guest、存储卷或复制任务被独立评估——每个受影响资源各产生一个事件还可以创建公式formulas用数学表达式组合多个指标查询例如用pve_memory_usage_bytes / pve_memory_size_bytes计算内存使用百分比。id标签与派生属性Agent 采集的每个指标都携带一个id数据点标签用于标识该数据点所属的 Proxmox 资源。取值规则如下id值资源node/name集群节点例如node/pve1qemu/vmidQEMU 虚拟机例如qemu/100lxc/vmidLXC 容器例如lxc/101storage/node/storage某节点上的存储卷例如storage/pve1/local两个例外情况复制系列指标pve_replication_*在id中携带的是复制任务的 id例如100-0而集群级别的pve_not_backed_up_total则根本没有id标签。由于监控判定标准和属性过滤器都按相等equality而非前缀匹配Agent 额外把id拆分成三个可用相等匹配过滤的数据点属性内置告警模板正是依赖它们属性取值qemu/100示例pve.scopenode、guest、storage、clusterqemu和lxc都映射为guestguestpve.typenode、qemu、lxc、storageqemupve.idid中第一个/之后的部分pve1、100、pve1/local100这个拆分动作由 otel-collector-config.yaml 中的transform/pve-identity处理器完成其核心逻辑是若干条set语句例如- set(attributes[pve.scope], guest) where attributes[id] ! nil and IsMatch(attributes[id], ^qemu/) - set(attributes[pve.type], qemu) where attributes[id] ! nil and IsMatch(attributes[id], ^qemu/) - set(attributes[pve.id], attributes[id]) where attributes[id] ! nil and IsMatch(attributes[id], /) - replace_pattern(attributes[pve.id], ^[^/]/, ) where attributes[pve.id] ! nil配置中的注释明确警告不要移除这个处理器内置的 Proxmox 告警模板都依赖这些属性做过滤。原始的id标签会被原样保留供 Group By 页面和细分视图使用。使用建议用pve.scope或pve.type过滤把查询限定到某一类资源用pve.id或id过滤把查询限定到某一个具体资源按id分组则每个资源被独立评估。滚动时间窗口指标评估的时间窗口可选过去 1 分钟过去 5 分钟过去 10 分钟过去 15 分钟过去 30 分钟过去 60 分钟采集的指标全集Proxmox Agent 每30 秒抓取一次 prometheus-pve-exporter同时启用 cluster 与 node 两类采集器——这同时也覆盖了 exporter 默认开启的backup-info集群级与replication节点级采集器。抓取配置见 otel-collector-config.yamlscrape_configs: - job_name: oneuptime-proxmox metrics_path: /pve params: target: [${env:PVE_HOST}] cluster: [1] node: [1] scrape_interval: 30s static_configs: - targets: [${env:PVE_EXPORTER_URL}]配置注释说明了 30 秒间隔的取舍pve-exporter 每次抓取都会对 Proxmox VE API 做一次实时往返30 秒可以把 pveproxy 上的负载控制在可忽略的水平。可用性指标说明pve_up节点或 guest 在线/运行时为 1否则为 0pve_uptime_seconds节点或 guest 的运行时长秒pve_version_info元数据系列在 version/release 标签中携带 Proxmox VE 版本值恒为 1节点指标说明pve_node_info节点元数据值恒为 1——对它求和即可统计集群中上报节点的数量pve_cpu_usage_ratioCPU 使用率为可用 CPU 的 0–1 比率pve_cpu_usage_limit可用 CPU单位为核对 guest 而言即分配的 vCPU 数pve_memory_usage_bytes已用内存字节pve_memory_size_bytes总内存字节Guest虚拟机 / LXC 容器指标说明pve_guest_infoguest 元数据name、node、type 为qemu或lxc以标签形式存在值恒为 1pve_network_receive_bytesguest 累计接收字节数——要以速率形式绘制才能看到吞吐量pve_network_transmit_bytesguest 累计发送字节数——同样建议以速率绘制pve_disk_read_bytesguest 累计磁盘读取字节数——按速率绘制pve_disk_write_bytesguest 累计磁盘写入字节数——按速率绘制pve_onboot_statusguest 配置为开机自启时为 1——一个onboot1却处于停止状态的 guest通常意味着非预期的停机CPU 与内存系列pve_cpu_usage_ratio、pve_memory_usage_bytes等也会在每个 guest 上以qemu/*和lxc/*的 id 发布。存储指标说明pve_disk_usage_bytes磁盘/存储已用字节。对于 QEMU guest除非安装了 QEMU guest agent否则读数为 0pve_disk_size_bytes磁盘/存储总大小字节pve_storage_info存储元数据值恒为 1——求和即可统计存储卷数量HA 高可用指标说明pve_ha_state高可用状态以枚举式系列呈现每个可能状态started、stopped、error等各有一条系列当前状态对应系列值为 1——按state标签过滤即可对特定状态告警备份覆盖来自 exporter 集群级的backup-info采集器默认启用。需要特别说明边界这些指标只报告备份任务的覆盖情况——pve-exporter 并不暴露备份最近是否运行或成功的信息指标说明pve_not_backed_up_total未被任何备份任务覆盖的 guest 数量。仅一条集群级系列无id标签pve_not_backed_up_info每个未覆盖的 guest 一条系列值恒为 1带 guest 的id标签。按id分组即可列出未覆盖的 guest——一旦 guest 加入某个备份任务该系列就会消失复制来自 exporter 节点级的replication采集器默认启用。各系列在id标签中携带复制任务id例如100-0指标说明pve_replication_failed_syncs任务连续失败的同步尝试次数——只要大于 0就说明副本正在变陈旧pve_replication_duration_seconds任务上次同步耗时pve_replication_last_sync_timestamp_seconds上次成功同步的 Unix 时间戳pve_replication_last_try_timestamp_seconds上次同步尝试的 Unix 时间戳——比 last-sync 更新说明最近一次尝试失败了pve_replication_next_sync_timestamp_seconds下次计划同步的 Unix 时间戳pve_replication_info任务元数据值恒为 1带 type、source、target、guest 标签重要限制判定引擎没有时钟运算wall-clock math因此无法直接对副本陈旧度当前时间 − 上次同步告警——Proxmox 集群的 Overview 页面是在客户端计算这一数值的。替代方案是对pve_replication_failed_syncs告警使用下文Replication Failing模板。监控判定标准Monitoring Criteria评估对象Proxmox 监控器始终评估 Metric Value——即所配置指标查询或公式的值。因此判定表单没有 Filter Type 选择器只显示Metric、Aggregation、Condition和Threshold。聚合类型聚合说明Average时间窗口内的平均值Sum所有值的总和Maximum Value时间窗口内的最高值Minimum Value时间窗口内的最低值All Values所有值都必须满足条件Any Value至少一个值满足条件条件静态阈值——与你输入的 Threshold 比较Greater Than、Less Than、Greater Than or Equal To、Less Than or Equal To、Equal To基线异常检测——无需阈值表单改为显示Sensitivity灵敏度和Baseline Window基线窗口将每个样本与基于该窗口构建的周内相同时段基线进行比较Anomalously High——值高于预期范围Anomalously Low——值低于预期范围Anomalous——值从任一方向偏离预期范围异常条件会停留在Learning学习状态直到积累了至少等于所设 Baseline Window 长度的指标历史在此之前不会产生任何告警。11 个内置告警模板OneUptime 为常见 Proxmox 监控场景内置了11 个模板。每个模板都会构建一个完整的监控器——包括指标查询、属性过滤器、分组、触发条件fire criteria与自动恢复条件auto-recover criteria应用后仍可编辑。阈值只是起点。模板默认评估过去 5 分钟除非表中另有说明且条件必须在其窗口内的每一分钟都成立才会触发模板严重级别监控内容触发条件Node Offline严重pve_up过滤到pve.scopenode按id取最小值任一节点上报低于 1。每个节点一条事件达到 ≥ 1 时恢复Guest Down警告pve_up与pve_onboot_status过滤到pve.scopeguest按id取最小值配置为开机自启pve_onboot_status 1的 guest 在整个窗口内pve_up低于 1。你故意停止的 guest 会被自动排除永远不会触发Cluster Quorum at Risk严重公式pve_up÷pve_node_info× 100两者都求和pve.scopenode 在线节点百分比在线节点 ≤ 50%——这是诚实的 quorum 代理因为 pve-exporter 不暴露任何 corosync 指标High Node CPU Usage警告pve_cpu_usage_ratio过滤到pve.scopenode按id取平均值 0.9节点 90% 的核被占用High Node Memory Usage警告公式pve_memory_usage_bytes÷pve_memory_size_bytes× 100pve.scopenode按id 节点 85% 的内存——真实的百分比无需为每个节点调整字节级阈值High Guest CPU Usage警告pve_cpu_usage_ratio过滤到pve.scopeguest按id取平均值过去 15 分钟15 分钟窗口内每一分钟都 0.9595% 的已分配 vCPU——guest 本应使用其分配的资源因此只有从不降载的 guest 才会触发Storage Near Full警告公式pve_disk_usage_bytes÷pve_disk_size_bytes× 100pve.scopestorage按id 卷容量的 85%Container Root Disk Near Full警告同样的磁盘比率公式过滤到pve.typelxc按id 90%。QEMU 虚拟机被排除——没有 QEMU guest agent 时其 guest 内磁盘用量读数为 0HA Resource in Error State严重pve_ha_state过滤到stateerror按id取最大值 0——HA 无法恢复该资源回落到 0 时恢复Guest Not Backed Up警告pve_not_backed_up_total取最大值仅一条集群级系列不做分组 0——至少一个 guest 不在任何备份任务中回落到 0 时恢复。将pve_not_backed_up_info按id分组即可列出这些 guest。仅覆盖任务成员关系——不反映备份是否运行或成功Replication Failing严重pve_replication_failed_syncs按id取最大值id 为复制任务 id 0——任务副本正在变陈旧回落到 0 时恢复模板背后的设计取舍模板中蕴含了几条值得借鉴的监控设计原则下线/离线类模板用 Min最小值单次下线抓取即可触发阈值而不会被资源仍然在线时的抓取值掩盖。Guest Down额外要求同一id上有pve_onboot_status因此故意停掉的 guest 永远不会打扰你。CPU 类模板用 Avg平均值pve_cpu_usage_ratio本身就是 0–1 的比率每分钟的平均值即持续利用率。状态类模板HA、备份、复制用 Max最大值一次坏抓取即可触发。比率公式两侧都用 Sum 聚合分子与分母来自同一次 exporter 抓取抓取倍数相互抵消结果才是真实百分比。模板均预先用pve.scope/pve.type过滤并按id分组因此每个受影响资源各自触发一条事件。部署 Proxmox Agent前置条件任意能访问你的 Proxmox VE API端口 8006的机器装有 Docker Engine 20.10 与 Docker Compose v2 插件一个拥有PVEAuditor只读角色的 Proxmox VE API Token一个OneUptime Telemetry Ingestion Key在Project Settings → Telemetry Ingestion Keys创建创建 Proxmox API Token两条命令在任意 PVE 节点上以 root 身份执行pveum user token add monitoringpam oneuptime --privsep 1 pveum acl modify / --roles PVEAuditor --tokens monitoringpam!oneuptime如果monitoringpam用户还不存在先执行pveum user add monitoringpam——API Token 自带独立密钥因此该用户无需密码或系统账户。关键要点ACL 必须挂在根路径/上因为 PVEAuditor 需要读取 exporter 遍历的每个节点、guest 和存储对象的权限——若授予更窄的路径集群其余部分会被隐藏并产生401/403 Permission check failed (/, Sys.Audit)错误。第一条命令只会打印一次 Token 密钥之后在.env中对应为PVE_API_TOKEN_IDmonitoringpam!oneuptime与PVE_API_TOKEN_SECRET打印出的密钥。也可以走 Proxmox Web UIDatacenter → Permissions → API Tokens记得在路径/上授予 PVEAuditor 角色并取消 Privilege Separation。部署位置建议Agent 通过网络查询 PVE API因此不必也不建议运行在集群节点上。最好放在能在节点故障时存活的机器上独立硬件上的小监控 VM、管理主机或者把PVE_HOST指向 VIP / round-robin DNS 而非单个节点地址——如果 Agent 的 API 目标正是刚宕掉的节点你的监控也会跟着一起死。唯一的例外是可选的 journald 日志管线它必须运行在 PVE 节点上。Docker Compose 快速启动从 agents/ProxmoxAgent 目录下载docker-compose.yml与otel-collector-config.yaml在同目录创建.envONEUPTIME_URLhttps://oneuptime.com ONEUPTIME_TELEMETRY_INGESTION_KEYyour-telemetry-ingestion-key PROXMOX_CLUSTER_NAMEmy-proxmox-cluster PVE_HOST192.168.1.10 PVE_API_TOKEN_IDoneuptimepve!exporter PVE_API_TOKEN_SECRETyour-token-secret COMPOSE_PROFILESpve-exporter启动pve-exporterprofile 会同时启动内置的 exporter 容器docker compose up -d集群会在一分钟左右自动出现在 OneUptime 的Proxmox区域。如果你已经在别处运行 pve-exporter可以去掉COMPOSE_PROFILES、PVE_API_TOKEN_ID、PVE_API_TOKEN_SECRET改用PVE_EXPORTER_URLyour-exporter-host:9221环境变量一览变量是否必需说明ONEUPTIME_URL是OneUptime 实例 URLONEUPTIME_TELEMETRY_INGESTION_KEY是遥测接入密钥Project Settings → Telemetry Ingestion KeysPROXMOX_CLUSTER_NAME是OneUptime 中显示的集群标识作为proxmox.cluster.name资源属性盖在每个指标上。保持稳定——修改它会注册新集群默认proxmox-clusterPVE_HOST是exporter 查询的 Proxmox VE API 主机集群任一节点例如192.168.1.10PVE_EXPORTER_URL否prometheus-pve-exporter 地址host:port无协议前缀。默认内置 exporterpve-exporter:9221PVE_API_TOKEN_ID仅内置 exporter完整 Proxmox API Token id例如oneuptimepve!exporterPVE_API_TOKEN_SECRET仅内置 exporterProxmox API Token 密钥PVE_VERIFY_SSL否是否校验 Proxmox API 的 TLS 证书默认false——PVE 默认签发自签名证书COMPOSE_PROFILES否设为pve-exporter以启动内置 exporter 容器关于 Token 的拆分docker-compose.yml 中有个实现细节prometheus-pve-exporter 要求 Token 拆成用户部分PVE_USER与 Token 名部分PVE_TOKEN_NAME而.env中保存的是 UI 显示的完整 iduserrealm!tokennamecompose 文件通过 shell 参数展开把它拆开export PVE_USER$${PVE_API_TOKEN_ID%%!*} PVE_TOKEN_NAME$${PVE_API_TOKEN_ID##*!} exec /usr/bin/pve_exporter$$用于屏蔽 docker compose 的插值exporter 会忽略其他未知的PVE_*变量。验证安装docker compose ps # 检查 agent 状态 docker logs -f oneuptime-proxmox-agent # 查看采集器日志日志中应看到Everything is ready. Begin running and processing data.一分钟后集群即可在 Dashboard 中出现。可选的日志上报Proxmox 服务日志默认 Agent 只上报指标Proxmox dashboard 的 Logs 页签需要额外启用日志接收器。PVE 控制面把日志写到 systemd journal 下的 8 个单元pveproxy、pvedaemon、pve-firewall、pve-ha-crm、pve-ha-lrm、pvescheduler、pvestatd、qmeventd。启用步骤详见 agents/ProxmoxAgent/README.md在 PVE 节点上运行 Agentjournal 按主机隔离远端 agent 读不到取消 otel-collector-config.yaml 中journald接收器与logs管线的注释在docker-compose.yml中挂载 journal 卷/var/log/journal与/etc/machine-id替换镜像官方otel/opentelemetry-collector-contrib镜像基于 scratch 构建没有journalctl二进制且以非 root 运行需换成包含 systemd 的包装镜像或在节点上直接运行otelcol-contrib的.deb包。不想换镜像也有备选在节点上安装 rsyslog用filelog接收器 tail/var/log/syslog挂载整个/var/log目录而非单个文件避免日志轮转钉住陈旧 inode代价是失去按单元的过滤能力。Proxmox VE 9 零安装替代方案Proxmox VE 9.0 可以通过内置的 OpenTelemetry 指标服务器直接向 OneUptime 推送指标Datacenter → Metric Server → Add → OpenTelemetry无需 Agent 与 exporterServer你的 OneUptime 主机Port443ProtocolhttpsPath/otlp/v1/metricsHeaders{x-oneuptime-token: your-telemetry-ingestion-key}两个需要注意的权衡集群发现Agent 路径之所以能驱动集群自动注册是因为它盖了proxmox.cluster.name资源属性。原生推送时需在 Resource Attributes 中设置proxmox.cluster.namemy-proxmox-cluster否则指标会入库但不会出现 Proxmox 集群指标名不同原生推送发出的是proxmox_node_*/proxmox_vm_*/proxmox_storage_*系列而 Agent 路径是 pve-exporter 的pve_*系列。OneUptime 内置的 Proxmox 监控目录与告警模板针对的是pve_*命名——因此本文的模板与指标目录适用于 Agent 路径。故障排查集群没有出现在监控器的集群选择器中集群靠 Agent 的遥测自动注册。请检查 Agent 是否在运行并在上报见上面的验证安装以及PROXMOX_CLUSTER_NAME是否已设置。docker logs oneuptime-proxmox-agent中的401表示接入密钥错误connection refused 表示ONEUPTIME_URL不对。缺少 guest 指标guest 系列来自 exporter 的集群采集器cluster1抓取参数随附配置已启用。如果你自定义过采集器配置请恢复它。High Node CPU Usage 不触发模板对按id标签分组的pve_cpu_usage_ratio取平均值每个节点独立检查。如果你改用了自定义查询务必按id分组——不加分组地对所有节点取平均值会被空闲节点稀释很难越过阈值。缺少备份或复制指标pve_not_backed_up_*来自 exporter 集群级backup-info采集器pve_replication_*来自节点级replication采集器——两者默认启用并受随附配置中cluster1/node1抓取参数覆盖。如果你自己运行 exporter检查是否禁用了这些采集器。另外pve_replication_*系列只在集群配置了存储复制任务时才存在。pve_network_receive_bytes等计数器只增不减网络与磁盘 I/O 系列是累计计数器。应针对其变化速率告警或对滚动窗口用公式计算速率而不是直接对原始值告警。深入阅读监控文档本主题packages/App/FeatureSet/Docs/Content/en/monitor/proxmox-monitor.mdAgent 安装与运维指南agents/ProxmoxAgent/README.mdAgent 的 OTLP Collector 配置含transform/pve-identity与抓取参数agents/ProxmoxAgent/otel-collector-config.yaml内置 exporter 的 Compose 编排agents/ProxmoxAgent/docker-compose.yml遥测接入文档Token 创建与安装细节packages/App/FeatureSet/Docs/Content/en/telemetry/proxmox.md赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime Docker Swarm 监控实战指南从 Agent 部署到按任务粒度告警OneUptime Docker Swarm 监控实战指南从 Agent 部署到按任务粒度告警 Docker Swarm 监控是 OneUptime 开源的监可观测性后端运维前端云原生微服务AI AgentOneUptime 服务器 / VM 监控实战基础设施 Agent 部署、指标采集与阈值告警全指南OneUptime 服务器 / VM 监控实战基础设施 Agent 部署、指标采集与阈值告警全指南 服务器与虚拟机VM监控是保障基础设施健康的第一道防线。可观测性后端运维前端云原生微服务AI AgentOneUptime Docker 监控完全指南从 Docker Agent 数据采集到告警模板实战OneUptime Docker 监控完全指南从 Docker Agent 数据采集到告警模板实战 本文是一份以 OneUptime Docker 监控Do可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime Proxmox 监控实战指南：从 Agent 部署到指标告警全解析
可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载本文以 OneUptime 仓库中的 Proxmox Monitor 文档为主线完整讲解如何监控 Proxmox VE 集群的节点、QEMU 虚拟机、LXC 容器、存储、HA 状态、备份任务覆盖与存储复制并深入 agent 的 OpenTelemetry Collector 配置与pve_*指标体系。读完本文你将掌握 Proxmox Monitor 的创建流程、指标查询与公式配置、内置告警模板的原理以及部署 Proxmox Agent 和排查问题的完整实战方案。概述Proxmox 监控能做什么OneUptime 的 Proxmox 监控能力让你可以透视整个 Proxmox VE 集群的虚拟化工作负载。监控数据由OneUptime Proxmox Agent一个预配置的 OpenTelemetry Collector负责采集再根据你在 OneUptime 中配置的指标标准进行评估。它能带来以下几类核心能力监控集群、节点以及每个 guest虚拟机/容器的健康状态跨节点与 guest 追踪 CPU、内存、磁盘和网络的用量及时发现离线节点与已停止的虚拟机/容器观察接近容量上限的存储卷对 HA 降级状态、未被任何备份任务覆盖的 guest、以及失败的存储复制发出告警数据链路可以概括为Proxmox VE API→prometheus-pve-exporter把 API 翻译成pve_*Prometheus 指标→Proxmox AgentOTel Collector 抓取并打上集群身份标签→OTLP上报 OneUptime。创建 Proxmox Monitor在 OneUptime Dashboard 中创建 Proxmox 监控的步骤如下进入Monitors监控器页面点击Create Monitor创建监控器监控类型选择Proxmox选择要监控的 Proxmox 集群配置指标查询与聚合方式按需配置监控判定标准criteria集群本身无需手动创建——集群会在 Proxmox Agent 第一次向其上报遥测数据时自动注册注册的键是资源属性proxmox.cluster.name见后文 agent 配置。因此在创建监控之前请先确保 Agent 已经部署并开始上报详见本文「部署 Proxmox Agent」一节。配置选项详解Proxmox 集群选择在选择器中挑选要监控的集群即可。集群的自动注册机制由 Agent 的resource处理器实现——在 otel-collector-config.yaml 中每个指标批次都会被写入proxmox.cluster.name属性resource: attributes: - key: proxmox.cluster.name value: ${env:PROXMOX_CLUSTER_NAME} action: upsert配置中特别强调保持该值稳定不要随意修改否则会注册出一个全新的集群与旧集群的数据割裂也会影响按集群的保留期设置。指标查询Metric Queries每个监控可以配置一个或多个指标查询每个查询需要指定指标名称Metric name——要查询的 Proxmox 指标即pve_*系列聚合Aggregation——指标值的聚合方式平均值、总和、最大值、最小值过滤器Filters——基于属性过滤可以直接过滤原始id标签也可以过滤派生的pve.scope/pve.type/pve.id属性见下节Group By分组——可选地按id标签分组使每个节点、guest、存储卷或复制任务被独立评估——每个受影响资源各产生一个事件还可以创建公式formulas用数学表达式组合多个指标查询例如用pve_memory_usage_bytes / pve_memory_size_bytes计算内存使用百分比。id标签与派生属性Agent 采集的每个指标都携带一个id数据点标签用于标识该数据点所属的 Proxmox 资源。取值规则如下id值资源node/name集群节点例如node/pve1qemu/vmidQEMU 虚拟机例如qemu/100lxc/vmidLXC 容器例如lxc/101storage/node/storage某节点上的存储卷例如storage/pve1/local两个例外情况复制系列指标pve_replication_*在id中携带的是复制任务的 id例如100-0而集群级别的pve_not_backed_up_total则根本没有id标签。由于监控判定标准和属性过滤器都按相等equality而非前缀匹配Agent 额外把id拆分成三个可用相等匹配过滤的数据点属性内置告警模板正是依赖它们属性取值qemu/100示例pve.scopenode、guest、storage、clusterqemu和lxc都映射为guestguestpve.typenode、qemu、lxc、storageqemupve.idid中第一个/之后的部分pve1、100、pve1/local100这个拆分动作由 otel-collector-config.yaml 中的transform/pve-identity处理器完成其核心逻辑是若干条set语句例如- set(attributes[pve.scope], guest) where attributes[id] ! nil and IsMatch(attributes[id], ^qemu/) - set(attributes[pve.type], qemu) where attributes[id] ! nil and IsMatch(attributes[id], ^qemu/) - set(attributes[pve.id], attributes[id]) where attributes[id] ! nil and IsMatch(attributes[id], /) - replace_pattern(attributes[pve.id], ^[^/]/, ) where attributes[pve.id] ! nil配置中的注释明确警告不要移除这个处理器内置的 Proxmox 告警模板都依赖这些属性做过滤。原始的id标签会被原样保留供 Group By 页面和细分视图使用。使用建议用pve.scope或pve.type过滤把查询限定到某一类资源用pve.id或id过滤把查询限定到某一个具体资源按id分组则每个资源被独立评估。滚动时间窗口指标评估的时间窗口可选过去 1 分钟过去 5 分钟过去 10 分钟过去 15 分钟过去 30 分钟过去 60 分钟采集的指标全集Proxmox Agent 每30 秒抓取一次 prometheus-pve-exporter同时启用 cluster 与 node 两类采集器——这同时也覆盖了 exporter 默认开启的backup-info集群级与replication节点级采集器。抓取配置见 otel-collector-config.yamlscrape_configs: - job_name: oneuptime-proxmox metrics_path: /pve params: target: [${env:PVE_HOST}] cluster: [1] node: [1] scrape_interval: 30s static_configs: - targets: [${env:PVE_EXPORTER_URL}]配置注释说明了 30 秒间隔的取舍pve-exporter 每次抓取都会对 Proxmox VE API 做一次实时往返30 秒可以把 pveproxy 上的负载控制在可忽略的水平。可用性指标说明pve_up节点或 guest 在线/运行时为 1否则为 0pve_uptime_seconds节点或 guest 的运行时长秒pve_version_info元数据系列在 version/release 标签中携带 Proxmox VE 版本值恒为 1节点指标说明pve_node_info节点元数据值恒为 1——对它求和即可统计集群中上报节点的数量pve_cpu_usage_ratioCPU 使用率为可用 CPU 的 0–1 比率pve_cpu_usage_limit可用 CPU单位为核对 guest 而言即分配的 vCPU 数pve_memory_usage_bytes已用内存字节pve_memory_size_bytes总内存字节Guest虚拟机 / LXC 容器指标说明pve_guest_infoguest 元数据name、node、type 为qemu或lxc以标签形式存在值恒为 1pve_network_receive_bytesguest 累计接收字节数——要以速率形式绘制才能看到吞吐量pve_network_transmit_bytesguest 累计发送字节数——同样建议以速率绘制pve_disk_read_bytesguest 累计磁盘读取字节数——按速率绘制pve_disk_write_bytesguest 累计磁盘写入字节数——按速率绘制pve_onboot_statusguest 配置为开机自启时为 1——一个onboot1却处于停止状态的 guest通常意味着非预期的停机CPU 与内存系列pve_cpu_usage_ratio、pve_memory_usage_bytes等也会在每个 guest 上以qemu/*和lxc/*的 id 发布。存储指标说明pve_disk_usage_bytes磁盘/存储已用字节。对于 QEMU guest除非安装了 QEMU guest agent否则读数为 0pve_disk_size_bytes磁盘/存储总大小字节pve_storage_info存储元数据值恒为 1——求和即可统计存储卷数量HA 高可用指标说明pve_ha_state高可用状态以枚举式系列呈现每个可能状态started、stopped、error等各有一条系列当前状态对应系列值为 1——按state标签过滤即可对特定状态告警备份覆盖来自 exporter 集群级的backup-info采集器默认启用。需要特别说明边界这些指标只报告备份任务的覆盖情况——pve-exporter 并不暴露备份最近是否运行或成功的信息指标说明pve_not_backed_up_total未被任何备份任务覆盖的 guest 数量。仅一条集群级系列无id标签pve_not_backed_up_info每个未覆盖的 guest 一条系列值恒为 1带 guest 的id标签。按id分组即可列出未覆盖的 guest——一旦 guest 加入某个备份任务该系列就会消失复制来自 exporter 节点级的replication采集器默认启用。各系列在id标签中携带复制任务id例如100-0指标说明pve_replication_failed_syncs任务连续失败的同步尝试次数——只要大于 0就说明副本正在变陈旧pve_replication_duration_seconds任务上次同步耗时pve_replication_last_sync_timestamp_seconds上次成功同步的 Unix 时间戳pve_replication_last_try_timestamp_seconds上次同步尝试的 Unix 时间戳——比 last-sync 更新说明最近一次尝试失败了pve_replication_next_sync_timestamp_seconds下次计划同步的 Unix 时间戳pve_replication_info任务元数据值恒为 1带 type、source、target、guest 标签重要限制判定引擎没有时钟运算wall-clock math因此无法直接对副本陈旧度当前时间 − 上次同步告警——Proxmox 集群的 Overview 页面是在客户端计算这一数值的。替代方案是对pve_replication_failed_syncs告警使用下文Replication Failing模板。监控判定标准Monitoring Criteria评估对象Proxmox 监控器始终评估 Metric Value——即所配置指标查询或公式的值。因此判定表单没有 Filter Type 选择器只显示Metric、Aggregation、Condition和Threshold。聚合类型聚合说明Average时间窗口内的平均值Sum所有值的总和Maximum Value时间窗口内的最高值Minimum Value时间窗口内的最低值All Values所有值都必须满足条件Any Value至少一个值满足条件条件静态阈值——与你输入的 Threshold 比较Greater Than、Less Than、Greater Than or Equal To、Less Than or Equal To、Equal To基线异常检测——无需阈值表单改为显示Sensitivity灵敏度和Baseline Window基线窗口将每个样本与基于该窗口构建的周内相同时段基线进行比较Anomalously High——值高于预期范围Anomalously Low——值低于预期范围Anomalous——值从任一方向偏离预期范围异常条件会停留在Learning学习状态直到积累了至少等于所设 Baseline Window 长度的指标历史在此之前不会产生任何告警。11 个内置告警模板OneUptime 为常见 Proxmox 监控场景内置了11 个模板。每个模板都会构建一个完整的监控器——包括指标查询、属性过滤器、分组、触发条件fire criteria与自动恢复条件auto-recover criteria应用后仍可编辑。阈值只是起点。模板默认评估过去 5 分钟除非表中另有说明且条件必须在其窗口内的每一分钟都成立才会触发模板严重级别监控内容触发条件Node Offline严重pve_up过滤到pve.scopenode按id取最小值任一节点上报低于 1。每个节点一条事件达到 ≥ 1 时恢复Guest Down警告pve_up与pve_onboot_status过滤到pve.scopeguest按id取最小值配置为开机自启pve_onboot_status 1的 guest 在整个窗口内pve_up低于 1。你故意停止的 guest 会被自动排除永远不会触发Cluster Quorum at Risk严重公式pve_up÷pve_node_info× 100两者都求和pve.scopenode 在线节点百分比在线节点 ≤ 50%——这是诚实的 quorum 代理因为 pve-exporter 不暴露任何 corosync 指标High Node CPU Usage警告pve_cpu_usage_ratio过滤到pve.scopenode按id取平均值 0.9节点 90% 的核被占用High Node Memory Usage警告公式pve_memory_usage_bytes÷pve_memory_size_bytes× 100pve.scopenode按id 节点 85% 的内存——真实的百分比无需为每个节点调整字节级阈值High Guest CPU Usage警告pve_cpu_usage_ratio过滤到pve.scopeguest按id取平均值过去 15 分钟15 分钟窗口内每一分钟都 0.9595% 的已分配 vCPU——guest 本应使用其分配的资源因此只有从不降载的 guest 才会触发Storage Near Full警告公式pve_disk_usage_bytes÷pve_disk_size_bytes× 100pve.scopestorage按id 卷容量的 85%Container Root Disk Near Full警告同样的磁盘比率公式过滤到pve.typelxc按id 90%。QEMU 虚拟机被排除——没有 QEMU guest agent 时其 guest 内磁盘用量读数为 0HA Resource in Error State严重pve_ha_state过滤到stateerror按id取最大值 0——HA 无法恢复该资源回落到 0 时恢复Guest Not Backed Up警告pve_not_backed_up_total取最大值仅一条集群级系列不做分组 0——至少一个 guest 不在任何备份任务中回落到 0 时恢复。将pve_not_backed_up_info按id分组即可列出这些 guest。仅覆盖任务成员关系——不反映备份是否运行或成功Replication Failing严重pve_replication_failed_syncs按id取最大值id 为复制任务 id 0——任务副本正在变陈旧回落到 0 时恢复模板背后的设计取舍模板中蕴含了几条值得借鉴的监控设计原则下线/离线类模板用 Min最小值单次下线抓取即可触发阈值而不会被资源仍然在线时的抓取值掩盖。Guest Down额外要求同一id上有pve_onboot_status因此故意停掉的 guest 永远不会打扰你。CPU 类模板用 Avg平均值pve_cpu_usage_ratio本身就是 0–1 的比率每分钟的平均值即持续利用率。状态类模板HA、备份、复制用 Max最大值一次坏抓取即可触发。比率公式两侧都用 Sum 聚合分子与分母来自同一次 exporter 抓取抓取倍数相互抵消结果才是真实百分比。模板均预先用pve.scope/pve.type过滤并按id分组因此每个受影响资源各自触发一条事件。部署 Proxmox Agent前置条件任意能访问你的 Proxmox VE API端口 8006的机器装有 Docker Engine 20.10 与 Docker Compose v2 插件一个拥有PVEAuditor只读角色的 Proxmox VE API Token一个OneUptime Telemetry Ingestion Key在Project Settings → Telemetry Ingestion Keys创建创建 Proxmox API Token两条命令在任意 PVE 节点上以 root 身份执行pveum user token add monitoringpam oneuptime --privsep 1 pveum acl modify / --roles PVEAuditor --tokens monitoringpam!oneuptime如果monitoringpam用户还不存在先执行pveum user add monitoringpam——API Token 自带独立密钥因此该用户无需密码或系统账户。关键要点ACL 必须挂在根路径/上因为 PVEAuditor 需要读取 exporter 遍历的每个节点、guest 和存储对象的权限——若授予更窄的路径集群其余部分会被隐藏并产生401/403 Permission check failed (/, Sys.Audit)错误。第一条命令只会打印一次 Token 密钥之后在.env中对应为PVE_API_TOKEN_IDmonitoringpam!oneuptime与PVE_API_TOKEN_SECRET打印出的密钥。也可以走 Proxmox Web UIDatacenter → Permissions → API Tokens记得在路径/上授予 PVEAuditor 角色并取消 Privilege Separation。部署位置建议Agent 通过网络查询 PVE API因此不必也不建议运行在集群节点上。最好放在能在节点故障时存活的机器上独立硬件上的小监控 VM、管理主机或者把PVE_HOST指向 VIP / round-robin DNS 而非单个节点地址——如果 Agent 的 API 目标正是刚宕掉的节点你的监控也会跟着一起死。唯一的例外是可选的 journald 日志管线它必须运行在 PVE 节点上。Docker Compose 快速启动从 agents/ProxmoxAgent 目录下载docker-compose.yml与otel-collector-config.yaml在同目录创建.envONEUPTIME_URLhttps://oneuptime.com ONEUPTIME_TELEMETRY_INGESTION_KEYyour-telemetry-ingestion-key PROXMOX_CLUSTER_NAMEmy-proxmox-cluster PVE_HOST192.168.1.10 PVE_API_TOKEN_IDoneuptimepve!exporter PVE_API_TOKEN_SECRETyour-token-secret COMPOSE_PROFILESpve-exporter启动pve-exporterprofile 会同时启动内置的 exporter 容器docker compose up -d集群会在一分钟左右自动出现在 OneUptime 的Proxmox区域。如果你已经在别处运行 pve-exporter可以去掉COMPOSE_PROFILES、PVE_API_TOKEN_ID、PVE_API_TOKEN_SECRET改用PVE_EXPORTER_URLyour-exporter-host:9221环境变量一览变量是否必需说明ONEUPTIME_URL是OneUptime 实例 URLONEUPTIME_TELEMETRY_INGESTION_KEY是遥测接入密钥Project Settings → Telemetry Ingestion KeysPROXMOX_CLUSTER_NAME是OneUptime 中显示的集群标识作为proxmox.cluster.name资源属性盖在每个指标上。保持稳定——修改它会注册新集群默认proxmox-clusterPVE_HOST是exporter 查询的 Proxmox VE API 主机集群任一节点例如192.168.1.10PVE_EXPORTER_URL否prometheus-pve-exporter 地址host:port无协议前缀。默认内置 exporterpve-exporter:9221PVE_API_TOKEN_ID仅内置 exporter完整 Proxmox API Token id例如oneuptimepve!exporterPVE_API_TOKEN_SECRET仅内置 exporterProxmox API Token 密钥PVE_VERIFY_SSL否是否校验 Proxmox API 的 TLS 证书默认false——PVE 默认签发自签名证书COMPOSE_PROFILES否设为pve-exporter以启动内置 exporter 容器关于 Token 的拆分docker-compose.yml 中有个实现细节prometheus-pve-exporter 要求 Token 拆成用户部分PVE_USER与 Token 名部分PVE_TOKEN_NAME而.env中保存的是 UI 显示的完整 iduserrealm!tokennamecompose 文件通过 shell 参数展开把它拆开export PVE_USER$${PVE_API_TOKEN_ID%%!*} PVE_TOKEN_NAME$${PVE_API_TOKEN_ID##*!} exec /usr/bin/pve_exporter$$用于屏蔽 docker compose 的插值exporter 会忽略其他未知的PVE_*变量。验证安装docker compose ps # 检查 agent 状态 docker logs -f oneuptime-proxmox-agent # 查看采集器日志日志中应看到Everything is ready. Begin running and processing data.一分钟后集群即可在 Dashboard 中出现。可选的日志上报Proxmox 服务日志默认 Agent 只上报指标Proxmox dashboard 的 Logs 页签需要额外启用日志接收器。PVE 控制面把日志写到 systemd journal 下的 8 个单元pveproxy、pvedaemon、pve-firewall、pve-ha-crm、pve-ha-lrm、pvescheduler、pvestatd、qmeventd。启用步骤详见 agents/ProxmoxAgent/README.md在 PVE 节点上运行 Agentjournal 按主机隔离远端 agent 读不到取消 otel-collector-config.yaml 中journald接收器与logs管线的注释在docker-compose.yml中挂载 journal 卷/var/log/journal与/etc/machine-id替换镜像官方otel/opentelemetry-collector-contrib镜像基于 scratch 构建没有journalctl二进制且以非 root 运行需换成包含 systemd 的包装镜像或在节点上直接运行otelcol-contrib的.deb包。不想换镜像也有备选在节点上安装 rsyslog用filelog接收器 tail/var/log/syslog挂载整个/var/log目录而非单个文件避免日志轮转钉住陈旧 inode代价是失去按单元的过滤能力。Proxmox VE 9 零安装替代方案Proxmox VE 9.0 可以通过内置的 OpenTelemetry 指标服务器直接向 OneUptime 推送指标Datacenter → Metric Server → Add → OpenTelemetry无需 Agent 与 exporterServer你的 OneUptime 主机Port443ProtocolhttpsPath/otlp/v1/metricsHeaders{x-oneuptime-token: your-telemetry-ingestion-key}两个需要注意的权衡集群发现Agent 路径之所以能驱动集群自动注册是因为它盖了proxmox.cluster.name资源属性。原生推送时需在 Resource Attributes 中设置proxmox.cluster.namemy-proxmox-cluster否则指标会入库但不会出现 Proxmox 集群指标名不同原生推送发出的是proxmox_node_*/proxmox_vm_*/proxmox_storage_*系列而 Agent 路径是 pve-exporter 的pve_*系列。OneUptime 内置的 Proxmox 监控目录与告警模板针对的是pve_*命名——因此本文的模板与指标目录适用于 Agent 路径。故障排查集群没有出现在监控器的集群选择器中集群靠 Agent 的遥测自动注册。请检查 Agent 是否在运行并在上报见上面的验证安装以及PROXMOX_CLUSTER_NAME是否已设置。docker logs oneuptime-proxmox-agent中的401表示接入密钥错误connection refused 表示ONEUPTIME_URL不对。缺少 guest 指标guest 系列来自 exporter 的集群采集器cluster1抓取参数随附配置已启用。如果你自定义过采集器配置请恢复它。High Node CPU Usage 不触发模板对按id标签分组的pve_cpu_usage_ratio取平均值每个节点独立检查。如果你改用了自定义查询务必按id分组——不加分组地对所有节点取平均值会被空闲节点稀释很难越过阈值。缺少备份或复制指标pve_not_backed_up_*来自 exporter 集群级backup-info采集器pve_replication_*来自节点级replication采集器——两者默认启用并受随附配置中cluster1/node1抓取参数覆盖。如果你自己运行 exporter检查是否禁用了这些采集器。另外pve_replication_*系列只在集群配置了存储复制任务时才存在。pve_network_receive_bytes等计数器只增不减网络与磁盘 I/O 系列是累计计数器。应针对其变化速率告警或对滚动窗口用公式计算速率而不是直接对原始值告警。深入阅读监控文档本主题packages/App/FeatureSet/Docs/Content/en/monitor/proxmox-monitor.mdAgent 安装与运维指南agents/ProxmoxAgent/README.mdAgent 的 OTLP Collector 配置含transform/pve-identity与抓取参数agents/ProxmoxAgent/otel-collector-config.yaml内置 exporter 的 Compose 编排agents/ProxmoxAgent/docker-compose.yml遥测接入文档Token 创建与安装细节packages/App/FeatureSet/Docs/Content/en/telemetry/proxmox.md赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime Docker Swarm 监控实战指南从 Agent 部署到按任务粒度告警OneUptime Docker Swarm 监控实战指南从 Agent 部署到按任务粒度告警 Docker Swarm 监控是 OneUptime 开源的监可观测性后端运维前端云原生微服务AI AgentOneUptime 服务器 / VM 监控实战基础设施 Agent 部署、指标采集与阈值告警全指南OneUptime 服务器 / VM 监控实战基础设施 Agent 部署、指标采集与阈值告警全指南 服务器与虚拟机VM监控是保障基础设施健康的第一道防线。可观测性后端运维前端云原生微服务AI AgentOneUptime Docker 监控完全指南从 Docker Agent 数据采集到告警模板实战OneUptime Docker 监控完全指南从 Docker Agent 数据采集到告警模板实战 本文是一份以 OneUptime Docker 监控Do可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考