OneUptime 服务器 / VM 监控实战基础设施 Agent 部署、指标采集与阈值告警全指南【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime服务器与虚拟机VM监控是保障基础设施健康的第一道防线。OneUptime 通过一个轻量级、基于 Go 编写的基础设施 Agent将服务器上的系统指标持续上报到平台帮助你实时掌握服务器的可用性、CPU / 内存 / 磁盘使用率、运行中的进程状态并在资源阈值被突破前发出告警。本篇指南以官方文档fr/monitor/server-monitor.md英文版见 en/monitor/server-monitor.md为主线并结合仓库源码逐层拆解读完你既能独立完成从创建监控、安装 Agent 到配置告警判定条件的完整闭环也能理解 Agent 每 30 秒采集与上报的底层实现。服务器 / VM 监控概述服务器 / VM 监控通过在目标服务器上安装一个轻量级 Agent 来工作。该 Agent 负责采集系统指标并上报给 OneUptime从而帮助你实现监控服务器的可用性与正常运行时间uptime跟踪 CPU、内存与磁盘的使用情况监控服务器上正在运行的进程基于资源使用率阈值设置告警在基础设施问题影响业务服务之前提前发现风险。从架构上看这是一套探针外置模型Agent 主动采集、平台负责存储与判定。Agent 侧的核心实现在 agents/InfrastructureAgent 目录服务端接收与在线状态判定的实现在packages/App/FeatureSet/Telemetry与packages/App/FeatureSet/Workers后文会逐一对应。创建服务器 / VM 监控在 OneUptime Dashboard 中创建服务器监控的完整步骤如下进入仪表盘中的监控Monitors页面点击创建监控Create Monitor选择服务器 / VMServer / VM作为监控类型系统会为该监控生成一个密钥Secret Key——后续配置 Agent 时必须使用按照安装指引在服务器上完成 Agent 的配置与启动。其中第 4 步生成的密钥是 Agent 与平台之间的身份凭证。服务端通过它完成两件事一是启动前的密钥校验Agent 启动时调用GET /server-monitor/secret-key/verify/:secretkey验证密钥是否有效对应源码 ServerMonitor.ts校验逻辑见 agent.go二是指标上报时通过POST /server-monitor/response/ingest/:secretkey定位到具体监控见 ServerMonitor.ts。因此密钥一旦泄露攻击者即可伪造该服务器的指标数据务必妥善保管。基础设施 Agent基于 Go 的轻量守护进程OneUptime 基础设施 Agent 是一个基于 Go 的轻量守护进程daemon每 30 秒采集一次系统指标并上报给 OneUptime支持 Linux、macOS 与 Windows 三大平台。从源码看30 秒的采集周期由gocron调度器实现启动时会立即执行一次采集任务此后按固定周期循环// agents/InfrastructureAgent/agent.go job, err : scheduler.NewJob(gocron.DurationJob(30*time.Second), gocron.NewTask(collectMetricsJob, ag.SecretKey, ag.OneUptimeURL, ag.ProxyURL))每次采集任务会依次获取内存、CPU、磁盘、网络、负载load average、主机与进程数据并封装为ServerMonitorReport上报见 agent.go 与 server_monitor_report.go。上报数据中同时携带RequestReceivedAt时间戳服务端正是依据该时间戳判断服务器是否在线详见文末在线状态判定一节。Agent 的安装与配置还支持以下环境特性来自 config.go配置文件默认保存在系统目录Unix 下为/etc/oneuptime-infrastructure-agent/config.jsonWindows 下为%PROGRAMDATA%\oneuptime-infrastructure-agent\config.json若系统目录不可写例如非特权用户会自动回退到$HOME/.oneuptime-infrastructure-agent/可通过环境变量ONEUPTIME_AGENT_CONFIG_PATH显式指定配置文件路径便于容器化等场景。Linux / macOS 安装官方安装脚本位于仓库 packages/App/FeatureSet/Docs/Static/scripts/infrastructure-agent/install.sh。该脚本会自动完成平台与架构检测支持amd64、arm64、arm覆盖 Linux / macOS / FreeBSD / OpenBSD 等系统从发布源拉取最新版本并解压到指定目录默认$HOME/bin可用-b参数覆盖随后将二进制加入 shell 的PATH。安装完成后再依次执行配置与启动# 安装 Agent脚本会检测 OS 与架构并安装最新版本 sudo bash install.sh # 配置 Agent填入监控密钥与 OneUptime 实例地址 sudo oneuptime-infrastructure-agent configure --secret-keyYOUR_SECRET_KEY --oneuptime-urlhttps://oneuptime.com # 启动 Agent sudo oneuptime-infrastructure-agent start命令中的YOUR_SECRET_KEY需要替换为监控设置中显示的密钥如果你自托管 OneUptime请将https://oneuptime.com替换为你自己的实例 URL。configure命令在保存配置的同时还会把 Agent 注册为系统服务service.New源码见 main.go。Windows 安装Windows 上通过官方发布包安装下载最新版 Agent选择对应架构的 zip 包oneuptime-infrastructure-agent_windows_amd64.zip—— 适用于 x64 系统oneuptime-infrastructure-agent_windows_arm64.zip—— 适用于 ARM64 系统解压 zip 包以管理员身份打开命令提示符执行# 配置 Agent oneuptime-infrastructure-agent configure --secret-keyYOUR_SECRET_KEY --oneuptime-urlhttps://oneuptime.com # 启动 Agent oneuptime-infrastructure-agent start代理Proxy支持如果服务器需要通过 HTTP 代理访问外网可以在configure时通过--proxy-url参数指定代理地址sudo oneuptime-infrastructure-agent configure --secret-keyYOUR_SECRET_KEY --oneuptime-urlhttps://oneuptime.com --proxy-urlhttp://proxy.example.com:8080源码层面代理会在发起请求前被解析并装配到 HTTP 客户端传输层上http.Transport{Proxy: http.ProxyURL(proxyURL)}密钥校验与指标上报两个请求都会使用该代理见 agent.go。需要注意代理配置是全局生效的请确保代理本身允许访问你的 OneUptime 实例地址。Agent 命令速查Agent 提供以下管理命令由 main.go 实现run为服务内部命令命令说明configure使用密钥与 OneUptime URL 配置 Agent并注册为系统服务start启动 Agent 服务stop停止 Agent 服务restart重启 Agent 服务status显示当前服务状态运行中 / 已停止 / 未知logs查看 Agent 日志-n指定行数-f实时跟踪类似tail -funinstall卸载 Agent 服务同时删除配置文件help显示帮助信息其中logs -n 50表示显示最近 50 行日志默认 100 行logs -f进入实时跟踪模式见 main.go。在排障时logs -n 50也恰好覆盖约 25 分钟每 30 秒一行的日志窗口。需要提醒的是Agent 在日志与错误信息中会对密钥做脱敏处理MaskSecret/RedactSecret避免密钥随日志泄露对应实现见 agent.go 与 utils/redact.go。Agent 采集的指标详解Agent 采集的指标分为四类与文档中的列表一一对应同时我补充了源码中可验证的实现细节CPUCPU 使用率%—— CPU 整体使用百分比CPU 核心数—— CPU 逻辑核心数量。实现上采集逻辑会先获取每个核心的使用率再求平均cpu.go因此使用率代表所有核心的平均负载。除此之外Agent 还会计算 CPU 时间分解用户态、系统态、空闲、I/O 等待、Steal、Nice、IRQ、SoftIRQ 的百分比其中的I/O 等待iowait正是监控判定标准中CPU IO Wait数据来源cpu.go。内存总内存Total Memory—— 可用内存总量已用内存Used Memory—— 当前已使用内存空闲内存Free Memory—— 当前空闲内存内存使用率%—— 内存使用百分比。采集自 gopsutil 的VirtualMemory()同时还会附带Available可用内存、Buffers、Cached等字段memory.go。此外 Agent 还会采集Swap 交换分区的总量、已用、空闲与使用率memory.go为Swap 使用率判定项提供数据。磁盘对每个已挂载的磁盘 / 卷磁盘总空间Total Disk Space—— 磁盘总容量已用空间Used Disk Space—— 当前已使用空间可用空间Free Disk Space—— 当前可用空间磁盘使用率%—— 磁盘使用百分比磁盘路径Disk Path—— 磁盘挂载路径。磁盘采集按分区逐一进行disk.go。值得关注的两个工程细节一是分区枚举设置了 20 秒超时diskPartitionTimeout 20 * time.Second避免 Windows 上无响应的网络驱动器卡死整个采集任务disk.go二是会同步采集每个分区的 I/O 计数器读写字节数、读写次数、I/O 时间以便按设备维度分析磁盘 I/O 压力disk.go。进程进程名Process Name—— 正在运行的进程名称进程 IDPID—— 进程标识符进程命令Process Command—— 启动该进程的完整命令行。进程列表通过 gopsutil 的process.Processes()获取procs.go并对每个进程尽力补充 CPU 使用率、内存占用RSS 字节数与百分比、运行状态、线程数、创建时间与所属用户等附加字段——这些字段采集失败时自动回退为零值不影响主流程。补充负载与网络除了文档列出的四类指标Agent 还会采集 1 / 5 / 15 分钟系统负载平均值load.Avg()见 load.go以及网络指标utils/network.go。负载平均值对应判定标准中的Load Average (1/5/15 minute)检查项。监控判定标准Criteria你可以为服务器监控配置一组判定标准criteria用于确定服务器在何时被判定为在线online、降级degraded或离线offline。判定项的类型定义在 CriteriaFilter.ts 的CheckOn枚举中。可用的检查类型检查类型说明在线Is Online服务器 Agent 是否在持续上报基于心跳信号CPU 使用率%当前 CPU 使用百分比内存使用率%当前内存使用百分比磁盘使用率%当前磁盘使用百分比针对指定磁盘路径Swap 使用率%当前 Swap 使用百分比CPU I/O 等待%CPU 花费在等待 I/O 上的时间百分比负载均值1 分钟最近 1 分钟的系统负载均值负载均值5 分钟最近 5 分钟的系统负载均值负载均值15 分钟最近 15 分钟的系统负载均值服务器进程名检查是否存在指定名称的进程服务器进程命令检查是否存在指定启动命令的进程服务器进程 PID检查是否存在指定 PID 的进程磁盘类检查需要额外指定diskPath如/对应数据结构中的ServerMonitorOptions.diskPath字段见 CriteriaFilter.ts。过滤条件Filter Conditions对于数值型指标CPU、内存、磁盘、Swap、I/O 等待、负载均值大于Greater Than—— 数值超过某阈值小于Less Than—— 数值低于某阈值大于等于Greater Than or Equal To—— 数值达到或超过某阈值小于等于Less Than or Equal To—— 数值处于或低于某阈值。对于进程类检查正在运行Is Executing—— 进程当前正在运行未在运行Is Not Executing—— 进程当前未运行。对应的比较操作符枚举定义见 CriteriaFilter.ts 的FilterType。按时间段评估Evaluate Over Time在一段时间内评估此条件Evaluate this criteria over a period of time是判定表单中的一个独立复选框而非过滤条件。开启后平台不再对比最新一次检查的瞬时值而是对比一段时间窗口内的聚合值聚合方式在Evaluate下拉框中选择平均值Average总和Sum最大值Maximum Value最小值Minimum Value所有值All Values任意值Any Value聚合窗口由最近分钟For the last (in minutes)设置可选窗口从 2 分钟到 60 分钟EvaluateOverTimeMinutes枚举见 CriteriaFilter.ts。几个需要理解的语义细节对应 CriteriaFilter.tsAll Values只有在窗口内确实被数据完整覆盖时才会匹配。一个刚创建的监控、或检查记录已中断的监控没有足够的历史数据来支撑最近 N 分钟的判定此时该条件会等待而不是用仅有的单次读数去匹配。Any Value用于只要单次检查一越界就立刻告诉我的场景它会立即触发。If No Data无数据时控制窗口无法支撑判定时如何处理Ignore忽略默认—— 该条件不匹配。适用于常规阈值告警Trigger触发—— 把数据缺失本身当作问题。适用于心跳型检查——沉默本身就是故障Treat As Zero按零处理—— 将整个窗口视为单个零值。适用于计数器类指标——没有事件确实意味着零。需要说明的是文档法语版中关于时间段评估的描述较为简略上述 All Values / Any Value 语义与 If No Data 策略的完整说明以英文版文档 en/monitor/server-monitor.md 为准并已在 CriteriaFilter.ts 的NoDataPolicy枚举中得到印证。判定示例以下示例覆盖了最常见的几种场景可直接在判定表单中按字段逐项填写示例一Agent 停止上报时标记服务器为离线检查类型Check On在线Is Online过滤条件Filter ConditionFalse示例二CPU 使用率超过 90% 时告警检查类型CPU 使用率%过滤条件大于数值90示例三磁盘使用率超过 85% 时告警检查类型磁盘使用率%磁盘路径/过滤条件大于数值85示例四内存使用率超过 80% 时告警检查类型内存使用率%过滤条件大于数值80示例五关键进程停止时告警检查类型服务器进程名过滤条件未在运行Is Not Executing数值nginx排障指南Troubleshooting症状一Agent 不上报数据按以下顺序逐项排查确认 Agent 正在运行sudo oneuptime-infrastructure-agent status查看 Agent 日志sudo oneuptime-infrastructure-agent logs -n 50确认密钥Secret Key填写正确确认服务器能够访问你的 OneUptime 实例 URL检查防火墙规则是否放行了出站 HTTPS 连接。症状二Agent 资源占用过高Agent 被设计为轻量级。如果观察到资源占用异常升高重启 Agentsudo oneuptime-infrastructure-agent restart查看 Agent 日志排查是否有持续报错例如磁盘采集异常。值得一提的细节是磁盘采集模块内置了问题日志去重机制diskProblemLog同一问题每 10 分钟最多重复记录一次避免某个不可读分区让日志每 30 秒刷屏见 disk.go而磁盘分区枚举的超时上限为 20 秒低于 30 秒采集周期因此单个无响应驱动器不会拖垮整个上报任务。症状三代理相关故障确认代理 URL 与端口配置正确确保代理允许访问你的 OneUptime 实例重新配置代理sudo oneuptime-infrastructure-agent configure --proxy-urlhttp://proxy:port --secret-keyYOUR_KEY --oneuptime-urlYOUR_URL。服务端侧原理数据接收与在线状态判定理解了 Agent 侧之后再看服务端如何协同这部分是对文档内容由源码补充的深度延伸密钥校验Agent 每次启动时调用GET /server-monitor/secret-key/verify/:secretkey服务端查询匹配serverMonitorSecretKey且类型为 Server 的监控若不存在则返回错误ServerMonitor.ts指标接收Agent 调用POST /server-monitor/response/ingest/:secretkey上报指标服务端立即返回成功响应并将数据投递到TelemetryQueueService异步队列处理ServerMonitor.ts后续由 ProcessServerMonitorIngest.ts 消费在线状态判定Worker 中的 CheckOnlineStatus.ts 每分钟执行一次扫描凡是serverMonitorRequestReceivedAt距今超过 3 分钟仍未收到新上报的服务器监控就会被判定为离线——这就是文档中在线Is Online心跳判定的服务端依据。最佳实践设定有意义的阈值—— 降级与离线判定条件应贴合服务器正常工作区间避免把偶发抖动误判为故障监控关键进程—— 利用进程监控确保 Web 服务器、数据库等核心服务始终存活进程异常停止时第一时间告警主动监控磁盘使用率—— 磁盘空间耗尽往往引发应用级联故障务必在磁盘将满之前就设置告警例如使用示例三的 85% 阈值或结合业务情况调低善用按时间段评估—— 对 CPU 这类可能瞬时尖峰的指标开启时间段评估并使用聚合方式如平均值、任意值可有效避免误报保持 Agent 更新—— 定期升级基础设施 Agent及时获得性能改进与问题修复仓库内可关注 agents/InfrastructureAgent 目录的变更。以上五条同时被官方文档作为推荐基线见 fr/monitor/server-monitor.md。将 Agent 部署、判定条件与上述实践结合使用即可为服务器与虚拟机建立一套覆盖可用性—资源—进程三层的自动化监控体系。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime 服务器 / VM 监控实战：基础设施 Agent 部署、指标采集与阈值告警全指南
OneUptime 服务器 / VM 监控实战基础设施 Agent 部署、指标采集与阈值告警全指南【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime服务器与虚拟机VM监控是保障基础设施健康的第一道防线。OneUptime 通过一个轻量级、基于 Go 编写的基础设施 Agent将服务器上的系统指标持续上报到平台帮助你实时掌握服务器的可用性、CPU / 内存 / 磁盘使用率、运行中的进程状态并在资源阈值被突破前发出告警。本篇指南以官方文档fr/monitor/server-monitor.md英文版见 en/monitor/server-monitor.md为主线并结合仓库源码逐层拆解读完你既能独立完成从创建监控、安装 Agent 到配置告警判定条件的完整闭环也能理解 Agent 每 30 秒采集与上报的底层实现。服务器 / VM 监控概述服务器 / VM 监控通过在目标服务器上安装一个轻量级 Agent 来工作。该 Agent 负责采集系统指标并上报给 OneUptime从而帮助你实现监控服务器的可用性与正常运行时间uptime跟踪 CPU、内存与磁盘的使用情况监控服务器上正在运行的进程基于资源使用率阈值设置告警在基础设施问题影响业务服务之前提前发现风险。从架构上看这是一套探针外置模型Agent 主动采集、平台负责存储与判定。Agent 侧的核心实现在 agents/InfrastructureAgent 目录服务端接收与在线状态判定的实现在packages/App/FeatureSet/Telemetry与packages/App/FeatureSet/Workers后文会逐一对应。创建服务器 / VM 监控在 OneUptime Dashboard 中创建服务器监控的完整步骤如下进入仪表盘中的监控Monitors页面点击创建监控Create Monitor选择服务器 / VMServer / VM作为监控类型系统会为该监控生成一个密钥Secret Key——后续配置 Agent 时必须使用按照安装指引在服务器上完成 Agent 的配置与启动。其中第 4 步生成的密钥是 Agent 与平台之间的身份凭证。服务端通过它完成两件事一是启动前的密钥校验Agent 启动时调用GET /server-monitor/secret-key/verify/:secretkey验证密钥是否有效对应源码 ServerMonitor.ts校验逻辑见 agent.go二是指标上报时通过POST /server-monitor/response/ingest/:secretkey定位到具体监控见 ServerMonitor.ts。因此密钥一旦泄露攻击者即可伪造该服务器的指标数据务必妥善保管。基础设施 Agent基于 Go 的轻量守护进程OneUptime 基础设施 Agent 是一个基于 Go 的轻量守护进程daemon每 30 秒采集一次系统指标并上报给 OneUptime支持 Linux、macOS 与 Windows 三大平台。从源码看30 秒的采集周期由gocron调度器实现启动时会立即执行一次采集任务此后按固定周期循环// agents/InfrastructureAgent/agent.go job, err : scheduler.NewJob(gocron.DurationJob(30*time.Second), gocron.NewTask(collectMetricsJob, ag.SecretKey, ag.OneUptimeURL, ag.ProxyURL))每次采集任务会依次获取内存、CPU、磁盘、网络、负载load average、主机与进程数据并封装为ServerMonitorReport上报见 agent.go 与 server_monitor_report.go。上报数据中同时携带RequestReceivedAt时间戳服务端正是依据该时间戳判断服务器是否在线详见文末在线状态判定一节。Agent 的安装与配置还支持以下环境特性来自 config.go配置文件默认保存在系统目录Unix 下为/etc/oneuptime-infrastructure-agent/config.jsonWindows 下为%PROGRAMDATA%\oneuptime-infrastructure-agent\config.json若系统目录不可写例如非特权用户会自动回退到$HOME/.oneuptime-infrastructure-agent/可通过环境变量ONEUPTIME_AGENT_CONFIG_PATH显式指定配置文件路径便于容器化等场景。Linux / macOS 安装官方安装脚本位于仓库 packages/App/FeatureSet/Docs/Static/scripts/infrastructure-agent/install.sh。该脚本会自动完成平台与架构检测支持amd64、arm64、arm覆盖 Linux / macOS / FreeBSD / OpenBSD 等系统从发布源拉取最新版本并解压到指定目录默认$HOME/bin可用-b参数覆盖随后将二进制加入 shell 的PATH。安装完成后再依次执行配置与启动# 安装 Agent脚本会检测 OS 与架构并安装最新版本 sudo bash install.sh # 配置 Agent填入监控密钥与 OneUptime 实例地址 sudo oneuptime-infrastructure-agent configure --secret-keyYOUR_SECRET_KEY --oneuptime-urlhttps://oneuptime.com # 启动 Agent sudo oneuptime-infrastructure-agent start命令中的YOUR_SECRET_KEY需要替换为监控设置中显示的密钥如果你自托管 OneUptime请将https://oneuptime.com替换为你自己的实例 URL。configure命令在保存配置的同时还会把 Agent 注册为系统服务service.New源码见 main.go。Windows 安装Windows 上通过官方发布包安装下载最新版 Agent选择对应架构的 zip 包oneuptime-infrastructure-agent_windows_amd64.zip—— 适用于 x64 系统oneuptime-infrastructure-agent_windows_arm64.zip—— 适用于 ARM64 系统解压 zip 包以管理员身份打开命令提示符执行# 配置 Agent oneuptime-infrastructure-agent configure --secret-keyYOUR_SECRET_KEY --oneuptime-urlhttps://oneuptime.com # 启动 Agent oneuptime-infrastructure-agent start代理Proxy支持如果服务器需要通过 HTTP 代理访问外网可以在configure时通过--proxy-url参数指定代理地址sudo oneuptime-infrastructure-agent configure --secret-keyYOUR_SECRET_KEY --oneuptime-urlhttps://oneuptime.com --proxy-urlhttp://proxy.example.com:8080源码层面代理会在发起请求前被解析并装配到 HTTP 客户端传输层上http.Transport{Proxy: http.ProxyURL(proxyURL)}密钥校验与指标上报两个请求都会使用该代理见 agent.go。需要注意代理配置是全局生效的请确保代理本身允许访问你的 OneUptime 实例地址。Agent 命令速查Agent 提供以下管理命令由 main.go 实现run为服务内部命令命令说明configure使用密钥与 OneUptime URL 配置 Agent并注册为系统服务start启动 Agent 服务stop停止 Agent 服务restart重启 Agent 服务status显示当前服务状态运行中 / 已停止 / 未知logs查看 Agent 日志-n指定行数-f实时跟踪类似tail -funinstall卸载 Agent 服务同时删除配置文件help显示帮助信息其中logs -n 50表示显示最近 50 行日志默认 100 行logs -f进入实时跟踪模式见 main.go。在排障时logs -n 50也恰好覆盖约 25 分钟每 30 秒一行的日志窗口。需要提醒的是Agent 在日志与错误信息中会对密钥做脱敏处理MaskSecret/RedactSecret避免密钥随日志泄露对应实现见 agent.go 与 utils/redact.go。Agent 采集的指标详解Agent 采集的指标分为四类与文档中的列表一一对应同时我补充了源码中可验证的实现细节CPUCPU 使用率%—— CPU 整体使用百分比CPU 核心数—— CPU 逻辑核心数量。实现上采集逻辑会先获取每个核心的使用率再求平均cpu.go因此使用率代表所有核心的平均负载。除此之外Agent 还会计算 CPU 时间分解用户态、系统态、空闲、I/O 等待、Steal、Nice、IRQ、SoftIRQ 的百分比其中的I/O 等待iowait正是监控判定标准中CPU IO Wait数据来源cpu.go。内存总内存Total Memory—— 可用内存总量已用内存Used Memory—— 当前已使用内存空闲内存Free Memory—— 当前空闲内存内存使用率%—— 内存使用百分比。采集自 gopsutil 的VirtualMemory()同时还会附带Available可用内存、Buffers、Cached等字段memory.go。此外 Agent 还会采集Swap 交换分区的总量、已用、空闲与使用率memory.go为Swap 使用率判定项提供数据。磁盘对每个已挂载的磁盘 / 卷磁盘总空间Total Disk Space—— 磁盘总容量已用空间Used Disk Space—— 当前已使用空间可用空间Free Disk Space—— 当前可用空间磁盘使用率%—— 磁盘使用百分比磁盘路径Disk Path—— 磁盘挂载路径。磁盘采集按分区逐一进行disk.go。值得关注的两个工程细节一是分区枚举设置了 20 秒超时diskPartitionTimeout 20 * time.Second避免 Windows 上无响应的网络驱动器卡死整个采集任务disk.go二是会同步采集每个分区的 I/O 计数器读写字节数、读写次数、I/O 时间以便按设备维度分析磁盘 I/O 压力disk.go。进程进程名Process Name—— 正在运行的进程名称进程 IDPID—— 进程标识符进程命令Process Command—— 启动该进程的完整命令行。进程列表通过 gopsutil 的process.Processes()获取procs.go并对每个进程尽力补充 CPU 使用率、内存占用RSS 字节数与百分比、运行状态、线程数、创建时间与所属用户等附加字段——这些字段采集失败时自动回退为零值不影响主流程。补充负载与网络除了文档列出的四类指标Agent 还会采集 1 / 5 / 15 分钟系统负载平均值load.Avg()见 load.go以及网络指标utils/network.go。负载平均值对应判定标准中的Load Average (1/5/15 minute)检查项。监控判定标准Criteria你可以为服务器监控配置一组判定标准criteria用于确定服务器在何时被判定为在线online、降级degraded或离线offline。判定项的类型定义在 CriteriaFilter.ts 的CheckOn枚举中。可用的检查类型检查类型说明在线Is Online服务器 Agent 是否在持续上报基于心跳信号CPU 使用率%当前 CPU 使用百分比内存使用率%当前内存使用百分比磁盘使用率%当前磁盘使用百分比针对指定磁盘路径Swap 使用率%当前 Swap 使用百分比CPU I/O 等待%CPU 花费在等待 I/O 上的时间百分比负载均值1 分钟最近 1 分钟的系统负载均值负载均值5 分钟最近 5 分钟的系统负载均值负载均值15 分钟最近 15 分钟的系统负载均值服务器进程名检查是否存在指定名称的进程服务器进程命令检查是否存在指定启动命令的进程服务器进程 PID检查是否存在指定 PID 的进程磁盘类检查需要额外指定diskPath如/对应数据结构中的ServerMonitorOptions.diskPath字段见 CriteriaFilter.ts。过滤条件Filter Conditions对于数值型指标CPU、内存、磁盘、Swap、I/O 等待、负载均值大于Greater Than—— 数值超过某阈值小于Less Than—— 数值低于某阈值大于等于Greater Than or Equal To—— 数值达到或超过某阈值小于等于Less Than or Equal To—— 数值处于或低于某阈值。对于进程类检查正在运行Is Executing—— 进程当前正在运行未在运行Is Not Executing—— 进程当前未运行。对应的比较操作符枚举定义见 CriteriaFilter.ts 的FilterType。按时间段评估Evaluate Over Time在一段时间内评估此条件Evaluate this criteria over a period of time是判定表单中的一个独立复选框而非过滤条件。开启后平台不再对比最新一次检查的瞬时值而是对比一段时间窗口内的聚合值聚合方式在Evaluate下拉框中选择平均值Average总和Sum最大值Maximum Value最小值Minimum Value所有值All Values任意值Any Value聚合窗口由最近分钟For the last (in minutes)设置可选窗口从 2 分钟到 60 分钟EvaluateOverTimeMinutes枚举见 CriteriaFilter.ts。几个需要理解的语义细节对应 CriteriaFilter.tsAll Values只有在窗口内确实被数据完整覆盖时才会匹配。一个刚创建的监控、或检查记录已中断的监控没有足够的历史数据来支撑最近 N 分钟的判定此时该条件会等待而不是用仅有的单次读数去匹配。Any Value用于只要单次检查一越界就立刻告诉我的场景它会立即触发。If No Data无数据时控制窗口无法支撑判定时如何处理Ignore忽略默认—— 该条件不匹配。适用于常规阈值告警Trigger触发—— 把数据缺失本身当作问题。适用于心跳型检查——沉默本身就是故障Treat As Zero按零处理—— 将整个窗口视为单个零值。适用于计数器类指标——没有事件确实意味着零。需要说明的是文档法语版中关于时间段评估的描述较为简略上述 All Values / Any Value 语义与 If No Data 策略的完整说明以英文版文档 en/monitor/server-monitor.md 为准并已在 CriteriaFilter.ts 的NoDataPolicy枚举中得到印证。判定示例以下示例覆盖了最常见的几种场景可直接在判定表单中按字段逐项填写示例一Agent 停止上报时标记服务器为离线检查类型Check On在线Is Online过滤条件Filter ConditionFalse示例二CPU 使用率超过 90% 时告警检查类型CPU 使用率%过滤条件大于数值90示例三磁盘使用率超过 85% 时告警检查类型磁盘使用率%磁盘路径/过滤条件大于数值85示例四内存使用率超过 80% 时告警检查类型内存使用率%过滤条件大于数值80示例五关键进程停止时告警检查类型服务器进程名过滤条件未在运行Is Not Executing数值nginx排障指南Troubleshooting症状一Agent 不上报数据按以下顺序逐项排查确认 Agent 正在运行sudo oneuptime-infrastructure-agent status查看 Agent 日志sudo oneuptime-infrastructure-agent logs -n 50确认密钥Secret Key填写正确确认服务器能够访问你的 OneUptime 实例 URL检查防火墙规则是否放行了出站 HTTPS 连接。症状二Agent 资源占用过高Agent 被设计为轻量级。如果观察到资源占用异常升高重启 Agentsudo oneuptime-infrastructure-agent restart查看 Agent 日志排查是否有持续报错例如磁盘采集异常。值得一提的细节是磁盘采集模块内置了问题日志去重机制diskProblemLog同一问题每 10 分钟最多重复记录一次避免某个不可读分区让日志每 30 秒刷屏见 disk.go而磁盘分区枚举的超时上限为 20 秒低于 30 秒采集周期因此单个无响应驱动器不会拖垮整个上报任务。症状三代理相关故障确认代理 URL 与端口配置正确确保代理允许访问你的 OneUptime 实例重新配置代理sudo oneuptime-infrastructure-agent configure --proxy-urlhttp://proxy:port --secret-keyYOUR_KEY --oneuptime-urlYOUR_URL。服务端侧原理数据接收与在线状态判定理解了 Agent 侧之后再看服务端如何协同这部分是对文档内容由源码补充的深度延伸密钥校验Agent 每次启动时调用GET /server-monitor/secret-key/verify/:secretkey服务端查询匹配serverMonitorSecretKey且类型为 Server 的监控若不存在则返回错误ServerMonitor.ts指标接收Agent 调用POST /server-monitor/response/ingest/:secretkey上报指标服务端立即返回成功响应并将数据投递到TelemetryQueueService异步队列处理ServerMonitor.ts后续由 ProcessServerMonitorIngest.ts 消费在线状态判定Worker 中的 CheckOnlineStatus.ts 每分钟执行一次扫描凡是serverMonitorRequestReceivedAt距今超过 3 分钟仍未收到新上报的服务器监控就会被判定为离线——这就是文档中在线Is Online心跳判定的服务端依据。最佳实践设定有意义的阈值—— 降级与离线判定条件应贴合服务器正常工作区间避免把偶发抖动误判为故障监控关键进程—— 利用进程监控确保 Web 服务器、数据库等核心服务始终存活进程异常停止时第一时间告警主动监控磁盘使用率—— 磁盘空间耗尽往往引发应用级联故障务必在磁盘将满之前就设置告警例如使用示例三的 85% 阈值或结合业务情况调低善用按时间段评估—— 对 CPU 这类可能瞬时尖峰的指标开启时间段评估并使用聚合方式如平均值、任意值可有效避免误报保持 Agent 更新—— 定期升级基础设施 Agent及时获得性能改进与问题修复仓库内可关注 agents/InfrastructureAgent 目录的变更。以上五条同时被官方文档作为推荐基线见 fr/monitor/server-monitor.md。将 Agent 部署、判定条件与上述实践结合使用即可为服务器与虚拟机建立一套覆盖可用性—资源—进程三层的自动化监控体系。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考