可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载Ping 监控是 OneUptime 中最基础的可用性检测手段它以固定周期向任意主机名或 IP 地址发送 ICMP echo 请求并据此判断目标是否在线、延迟是否劣化。读完本文你将掌握在 OneUptime Dashboard 中创建 Ping 监控的完整流程、全部监控条件过滤器的语义与配置方法并理解底层探针如何采集往返时间、丢包率、抖动等指标以及服务端如何对这些指标进行评估。Ping 监控能做什么Ping 监控通过向目标主机发送 ICMP ping 请求来测试基础的网络连通性。它可以让你监控主机的正常运行时间uptime与可用性跟踪网络延迟与响应时间的变化趋势在连接问题影响你的服务之前提前发现故障苗头验证服务器与网络设备是否真正可达。与 Website / API 监控不同Ping 监控不关心 HTTP 状态码与页面内容它只回答一个更底层的问题网络层面上这个目标还能不能 ping 通在 OneUptime 的监控类型体系中Ping 与 Website、API、IP、Port、SSL Certificate 等同属于 Basic Monitoring 类别官方对其定位是ICMP reachability and round trip time for a host主机的 ICMP 可达性与往返时间其检索关键词覆盖icmp、echo、reachable、latency、rtt、packet loss等参见 MonitorType.ts。创建 Ping 监控在 OneUptime Dashboard 中创建一个 Ping 监控只需几步在 OneUptime Dashboard 中进入Monitors点击Create Monitor创建监控在监控类型中选择Ping输入要监控的主机名或 IP 地址按需配置监控条件Monitoring Criteria。创建完成后OneUptime 会通过全球分布的探针Probe按你设定的监控间隔周期性执行检查。从源码结构看Ping 属于MonitorTypeHelper.isProbableMonitor()列出的可探测类型意味着它会被分发到探针执行而不是在服务器端运行。配置目标Ping 主机名或 IP 地址在配置表单中输入你想监控的目标主机名或 IP 地址即可例如example.com或192.168.1.1。主机名与 IP 地址都被接受。在探针端Ping 的实现位于 PingMonitor.ts它对目标做了一些约束与兼容处理如果传入的是Hostname类型且携带了端口会抛出BadDataException——Ping 监控不支持端口端口探测请使用 Port 监控同时支持 IPv4、IPv6 与主机名IPv6 目标会自动使用 IPv6 的 ping 二进制v6: truemacOS 上的ping6没有逐包等待与 deadline 参数代码会针对darwin平台做特殊处理避免 IPv6 目标被误判为离线生产环境的探针通常运行在 Linux 容器中不受此限制。配置监控条件Monitoring Criteria监控条件Criteria决定了你的主机在什么情况下被判定为在线、降级或离线。OneUptime 支持按以下过滤器类型进行判定。可用的过滤器类型过滤器类型说明Is Online是否在线主机是否响应 ping 请求Response Time (in ms)响应时间ping 请求的往返时间单位为毫秒Packet Loss (in %)丢包率未收到回应的 ICMP echo 请求所占百分比Jitter (in ms)抖动一次检查中所有发送包往返时间的标准差Is Request Timeout请求是否超时ping 请求是否发生超时这些过滤器类型在服务端有对应的枚举定义见 CriteriaFilter.ts 中的CheckOn枚举ResponseTime、PacketLossPercent、Jitter、IsOnline、IsRequestTimeout等。其中Packet Loss与Jitter两个指标来自多包探测。探针每次检查默认发送5 个ICMP echo 请求源码常量PING_PACKET_COUNT 5见 PingMonitor.ts并从结果中计算出完整的包级统计。返回结构定义在 PingMonitorResponse.tspacketsSent/packetsReceived发送与收到的包数packetLossPercent丢包百分比minRoundTripTimeInMs/maxRoundTripTimeInMs/avgRoundTripTimeInMs最小、最大与平均往返时间jitterInMs抖动即本次检查所有包往返时间的标准差。提示PingMonitorResponse仅在探针发送多个 echo 请求时才会填充对于旧版探针的单包 ping或当 ICMP 被防火墙阻断、探针回退到 TCP 端口检查时这些字段不会出现packetLossPercent、jitterInMs均为可选字段。过滤器条件Is Online 与 Is Request Timeout使用布尔条件True—— 条件为真False—— 条件为假。Response Time、Packet Loss 与 Jitter使用数值比较条件Greater Than大于—— 值超过阈值Less Than小于—— 值低于阈值Greater Than or Equal To大于或等于—— 值达到或超过阈值Less Than or Equal To小于或等于—— 值达到或低于阈值。服务端评估时APIRequestCriteria.ts见 packages/Common/Server/Utils/Monitor/Criteria/APIRequestCriteria.ts会按过滤器类型分别从探测结果中取值IsOnline取ProbeMonitorResponse.isOnlineIsRequestTimeout取isTimeoutResponseTime取responseTimeInMs而PacketLossPercent与Jitter则取自pingResponse.packetLossPercent与pingResponse.jitterInMs。当目标字段不存在例如旧探针没有多包统计时比较结果返回null表示该条件不参与判定。在时间周期上评估条件Evaluate this criteria over a period of time在一段时间内评估该条件是条件表单上一个独立的复选框而不是一个过滤器条件。开启后评估将不再使用最新一次检查的数值而是使用在指定时间窗口内聚合得到的数值。聚合方式通过Evaluate评估方式选择Average平均值、Sum总和、Maximum Value最大值、Minimum Value最小值、All Values所有值、Any Value任意值时间窗口通过For the last (in minutes)最近 N 分钟指定。在 CriteriaFilter.ts 中对应EvaluateOverTimeType枚举Average / Sum / Maximum Value / Minimum Value / All Values / Any Value与EvaluateOverTimeMinutes枚举提供 2、3、5、10、15、20、30、45、60 分钟等预设窗口。需要注意All Values的语义它只有在时间窗口被数据真正完整覆盖时才匹配。一个刚创建的监控或者其检查记录中断过的监控往往没有足够的最近 N 分钟历史数据此时该条件会等待数据积累而不会用仅有的一次读数去凑合匹配。相反Any Value适合 一旦单个检查突破阈值就立刻通知我 的场景它仍然会立即触发。无数据时的处理策略If No Data当评估窗口内没有数据来支撑该条件时例如监控刚创建、检查尚未覆盖整个窗口或数据记录中断If No Data选项决定如何处理Ignore忽略默认—— 条件不匹配。适用于常规的阈值告警场景避免数据不完整时误报Trigger触发—— 把数据缺失本身视为问题。适用于心跳heartbeat式检查此时静默本身就是故障Treat As Zero视为零—— 把整个窗口当作单个零值参与比较。适用于计数器类指标其中没有事件确实意味着零。在源码中这一策略对应NoDataPolicy枚举CriteriaFilter.ts 第 184-202 行Ignore不把缺失数据当作违规最安全、与多数 SaaS 工具一致、TreatAsZero把缺失数据点当作零、Trigger无论阈值如何都当作违规触发。未设置时默认取Ignore即一个被要求查看最近 N 分钟的过滤器会等待 N 分钟的数据而不是用刚到达的那一次读数去触发。条件示例主机不可达时标记为离线过滤器类型Is Online过滤器条件False这也是 OneUptime 为 Ping以及 IP、Port监控预置的默认离线条件getDefaultOfflineMonitorCriteriaInstance()会创建一个Is Online False的过滤器并同时生成一条 监控名 is offline 的事件incident与告警alert支持自动恢复autoResolveIncident/autoResolveAlert均为true相关逻辑见 MonitorCriteriaInstance.ts。响应时间超过 200ms 时告警过滤器类型Response Time (in ms)过滤器条件Greater Than值200底层原理探针如何执行一次 Ping 检查理解探针端的行为有助于你更好地配置阈值与重试参数。在 PingMonitor.ts 的ping()方法中一次完整的 Ping 检查流程如下发送探测通过ping.promise.probe()向目标发送 5 个 ICMP echo 请求Linux/macOS 对应-cWindows 对应-n默认超时为 5000ms可通过timeout选项调整最小按 1 秒取整避免小的毫秒值被舍入为 0 而落到库默认值。统计计算getPacketStatistics()从ping库的解析结果中重建包级统计——以收到的包数作为packetsReceived缺省时用(packetsSent - packetsReceived) / packetsSent * 100计算丢包率均值缺失时由所有 RTT 自行求平均抖动缺失时按方差公式sqrt(Σ(time − avg)² / n)计算标准差。响应时间取值优先使用多包平均 RTTavgRoundTripTimeInMs只有在该值缺失时才回退到首包 RTT——代码注释明确说明多包检查的均值才是更诚实的单一数字。重试机制如果响应时间超过 10 秒会自动追加一次重试每次重试间隔 1 秒当主机完全无响应时也会依据MonitorRetry.canRetry()决定是否重试未显式配置时默认最多尝试 5 次。每次尝试都会被记录到probeAttempts中最终一并上报。探针还专门区分了目标不可达与探针自身 ping 不可用两种情况当 ping 输出中出现operation not permitted、permission denied、must be superuser、lacks privilege、socket:、not found等标记PING_INFRA_FAILURE_MARKERS列表时说明是探针容器丢失了 ICMP 权限或 ping 二进制缺失而非主机离线。否则才判定为No ICMP echo reply from host (packetsSent sent)。这一点对自托管用户很重要如果你的探针容器运行环境限制了NET_RAW能力Ping 监控可能无法正常工作需要为探针授予必要的 ICMP 权限。与同类监控的分工与选择建议需要确认目标是否可达、延迟是否稳定 → 选择PingICMP 层面不经过 HTTP 协议栈需要验证 HTTP 状态码、页面内容、API 响应体 → 选择Website / API监控需要验证某个 TCP/UDP 端口是否可连接 → 选择Port监控仅需要监控一个 IP 地址无论 IPv4 还是 IPv6的可达性 → 也可以直接使用IP监控它与 Ping 共享同一套底层多包探测与指标管线。从 MonitorType.ts 的getActiveMonitorTypes()可以看到Ping 监控会作为活跃监控参与计费isBilledAsActiveMonitor()返回true这与 Manual手动监控不同——在免费套餐中创建时需要注意这一点。总结Ping 监控是 OneUptime 上配置成本最低、语义最直接的监控类型之一。只需一个主机名或 IP 地址就能获得在线状态、往返时间、丢包率与抖动四项核心指标再配合时间窗口聚合 无数据处理策略的条件组合可以构建从主机下线到网络质量劣化的完整告警体系。对 Ping 监控的完整配置字段说明可参考仓库内的多语言文档如 fa/monitor/ping-monitor.md、en/monitor/ping-monitor.md对底层实现的深入阅读建议从 PingMonitor.ts 与 APIRequestCriteria.ts 入手。赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐COLMAP三维重建解决方案从稀疏特征到密集点云的技术实践COLMAP三维重建解决方案从稀疏特征到密集点云的技术实践 COLMAP作为开源的三维重建工具通过运动恢复结构Structure from Motion可观测性后端运维前端云原生微服务AI AgentOneUptime Ping 监控ICMP 探活完整实战指南主机可用性、延迟与丢包监控OneUptime Ping 监控ICMP 探活完整实战指南主机可用性、延迟与丢包监控 Ping 监控Ping Monitor是 OneUptime可观测性后端运维前端云原生微服务AI AgentOneUptime Ping 监控基于 ICMP 的主机可用性、延迟与丢包监控OneUptime Ping 监控基于 ICMP 的主机可用性、延迟与丢包监控 本篇以 OneUptime 官方文档中的 Ping Monitor 功能为核心可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime Ping Monitor 完整指南：用 ICMP 探测实现主机可达性与延迟监控
可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载Ping 监控是 OneUptime 中最基础的可用性检测手段它以固定周期向任意主机名或 IP 地址发送 ICMP echo 请求并据此判断目标是否在线、延迟是否劣化。读完本文你将掌握在 OneUptime Dashboard 中创建 Ping 监控的完整流程、全部监控条件过滤器的语义与配置方法并理解底层探针如何采集往返时间、丢包率、抖动等指标以及服务端如何对这些指标进行评估。Ping 监控能做什么Ping 监控通过向目标主机发送 ICMP ping 请求来测试基础的网络连通性。它可以让你监控主机的正常运行时间uptime与可用性跟踪网络延迟与响应时间的变化趋势在连接问题影响你的服务之前提前发现故障苗头验证服务器与网络设备是否真正可达。与 Website / API 监控不同Ping 监控不关心 HTTP 状态码与页面内容它只回答一个更底层的问题网络层面上这个目标还能不能 ping 通在 OneUptime 的监控类型体系中Ping 与 Website、API、IP、Port、SSL Certificate 等同属于 Basic Monitoring 类别官方对其定位是ICMP reachability and round trip time for a host主机的 ICMP 可达性与往返时间其检索关键词覆盖icmp、echo、reachable、latency、rtt、packet loss等参见 MonitorType.ts。创建 Ping 监控在 OneUptime Dashboard 中创建一个 Ping 监控只需几步在 OneUptime Dashboard 中进入Monitors点击Create Monitor创建监控在监控类型中选择Ping输入要监控的主机名或 IP 地址按需配置监控条件Monitoring Criteria。创建完成后OneUptime 会通过全球分布的探针Probe按你设定的监控间隔周期性执行检查。从源码结构看Ping 属于MonitorTypeHelper.isProbableMonitor()列出的可探测类型意味着它会被分发到探针执行而不是在服务器端运行。配置目标Ping 主机名或 IP 地址在配置表单中输入你想监控的目标主机名或 IP 地址即可例如example.com或192.168.1.1。主机名与 IP 地址都被接受。在探针端Ping 的实现位于 PingMonitor.ts它对目标做了一些约束与兼容处理如果传入的是Hostname类型且携带了端口会抛出BadDataException——Ping 监控不支持端口端口探测请使用 Port 监控同时支持 IPv4、IPv6 与主机名IPv6 目标会自动使用 IPv6 的 ping 二进制v6: truemacOS 上的ping6没有逐包等待与 deadline 参数代码会针对darwin平台做特殊处理避免 IPv6 目标被误判为离线生产环境的探针通常运行在 Linux 容器中不受此限制。配置监控条件Monitoring Criteria监控条件Criteria决定了你的主机在什么情况下被判定为在线、降级或离线。OneUptime 支持按以下过滤器类型进行判定。可用的过滤器类型过滤器类型说明Is Online是否在线主机是否响应 ping 请求Response Time (in ms)响应时间ping 请求的往返时间单位为毫秒Packet Loss (in %)丢包率未收到回应的 ICMP echo 请求所占百分比Jitter (in ms)抖动一次检查中所有发送包往返时间的标准差Is Request Timeout请求是否超时ping 请求是否发生超时这些过滤器类型在服务端有对应的枚举定义见 CriteriaFilter.ts 中的CheckOn枚举ResponseTime、PacketLossPercent、Jitter、IsOnline、IsRequestTimeout等。其中Packet Loss与Jitter两个指标来自多包探测。探针每次检查默认发送5 个ICMP echo 请求源码常量PING_PACKET_COUNT 5见 PingMonitor.ts并从结果中计算出完整的包级统计。返回结构定义在 PingMonitorResponse.tspacketsSent/packetsReceived发送与收到的包数packetLossPercent丢包百分比minRoundTripTimeInMs/maxRoundTripTimeInMs/avgRoundTripTimeInMs最小、最大与平均往返时间jitterInMs抖动即本次检查所有包往返时间的标准差。提示PingMonitorResponse仅在探针发送多个 echo 请求时才会填充对于旧版探针的单包 ping或当 ICMP 被防火墙阻断、探针回退到 TCP 端口检查时这些字段不会出现packetLossPercent、jitterInMs均为可选字段。过滤器条件Is Online 与 Is Request Timeout使用布尔条件True—— 条件为真False—— 条件为假。Response Time、Packet Loss 与 Jitter使用数值比较条件Greater Than大于—— 值超过阈值Less Than小于—— 值低于阈值Greater Than or Equal To大于或等于—— 值达到或超过阈值Less Than or Equal To小于或等于—— 值达到或低于阈值。服务端评估时APIRequestCriteria.ts见 packages/Common/Server/Utils/Monitor/Criteria/APIRequestCriteria.ts会按过滤器类型分别从探测结果中取值IsOnline取ProbeMonitorResponse.isOnlineIsRequestTimeout取isTimeoutResponseTime取responseTimeInMs而PacketLossPercent与Jitter则取自pingResponse.packetLossPercent与pingResponse.jitterInMs。当目标字段不存在例如旧探针没有多包统计时比较结果返回null表示该条件不参与判定。在时间周期上评估条件Evaluate this criteria over a period of time在一段时间内评估该条件是条件表单上一个独立的复选框而不是一个过滤器条件。开启后评估将不再使用最新一次检查的数值而是使用在指定时间窗口内聚合得到的数值。聚合方式通过Evaluate评估方式选择Average平均值、Sum总和、Maximum Value最大值、Minimum Value最小值、All Values所有值、Any Value任意值时间窗口通过For the last (in minutes)最近 N 分钟指定。在 CriteriaFilter.ts 中对应EvaluateOverTimeType枚举Average / Sum / Maximum Value / Minimum Value / All Values / Any Value与EvaluateOverTimeMinutes枚举提供 2、3、5、10、15、20、30、45、60 分钟等预设窗口。需要注意All Values的语义它只有在时间窗口被数据真正完整覆盖时才匹配。一个刚创建的监控或者其检查记录中断过的监控往往没有足够的最近 N 分钟历史数据此时该条件会等待数据积累而不会用仅有的一次读数去凑合匹配。相反Any Value适合 一旦单个检查突破阈值就立刻通知我 的场景它仍然会立即触发。无数据时的处理策略If No Data当评估窗口内没有数据来支撑该条件时例如监控刚创建、检查尚未覆盖整个窗口或数据记录中断If No Data选项决定如何处理Ignore忽略默认—— 条件不匹配。适用于常规的阈值告警场景避免数据不完整时误报Trigger触发—— 把数据缺失本身视为问题。适用于心跳heartbeat式检查此时静默本身就是故障Treat As Zero视为零—— 把整个窗口当作单个零值参与比较。适用于计数器类指标其中没有事件确实意味着零。在源码中这一策略对应NoDataPolicy枚举CriteriaFilter.ts 第 184-202 行Ignore不把缺失数据当作违规最安全、与多数 SaaS 工具一致、TreatAsZero把缺失数据点当作零、Trigger无论阈值如何都当作违规触发。未设置时默认取Ignore即一个被要求查看最近 N 分钟的过滤器会等待 N 分钟的数据而不是用刚到达的那一次读数去触发。条件示例主机不可达时标记为离线过滤器类型Is Online过滤器条件False这也是 OneUptime 为 Ping以及 IP、Port监控预置的默认离线条件getDefaultOfflineMonitorCriteriaInstance()会创建一个Is Online False的过滤器并同时生成一条 监控名 is offline 的事件incident与告警alert支持自动恢复autoResolveIncident/autoResolveAlert均为true相关逻辑见 MonitorCriteriaInstance.ts。响应时间超过 200ms 时告警过滤器类型Response Time (in ms)过滤器条件Greater Than值200底层原理探针如何执行一次 Ping 检查理解探针端的行为有助于你更好地配置阈值与重试参数。在 PingMonitor.ts 的ping()方法中一次完整的 Ping 检查流程如下发送探测通过ping.promise.probe()向目标发送 5 个 ICMP echo 请求Linux/macOS 对应-cWindows 对应-n默认超时为 5000ms可通过timeout选项调整最小按 1 秒取整避免小的毫秒值被舍入为 0 而落到库默认值。统计计算getPacketStatistics()从ping库的解析结果中重建包级统计——以收到的包数作为packetsReceived缺省时用(packetsSent - packetsReceived) / packetsSent * 100计算丢包率均值缺失时由所有 RTT 自行求平均抖动缺失时按方差公式sqrt(Σ(time − avg)² / n)计算标准差。响应时间取值优先使用多包平均 RTTavgRoundTripTimeInMs只有在该值缺失时才回退到首包 RTT——代码注释明确说明多包检查的均值才是更诚实的单一数字。重试机制如果响应时间超过 10 秒会自动追加一次重试每次重试间隔 1 秒当主机完全无响应时也会依据MonitorRetry.canRetry()决定是否重试未显式配置时默认最多尝试 5 次。每次尝试都会被记录到probeAttempts中最终一并上报。探针还专门区分了目标不可达与探针自身 ping 不可用两种情况当 ping 输出中出现operation not permitted、permission denied、must be superuser、lacks privilege、socket:、not found等标记PING_INFRA_FAILURE_MARKERS列表时说明是探针容器丢失了 ICMP 权限或 ping 二进制缺失而非主机离线。否则才判定为No ICMP echo reply from host (packetsSent sent)。这一点对自托管用户很重要如果你的探针容器运行环境限制了NET_RAW能力Ping 监控可能无法正常工作需要为探针授予必要的 ICMP 权限。与同类监控的分工与选择建议需要确认目标是否可达、延迟是否稳定 → 选择PingICMP 层面不经过 HTTP 协议栈需要验证 HTTP 状态码、页面内容、API 响应体 → 选择Website / API监控需要验证某个 TCP/UDP 端口是否可连接 → 选择Port监控仅需要监控一个 IP 地址无论 IPv4 还是 IPv6的可达性 → 也可以直接使用IP监控它与 Ping 共享同一套底层多包探测与指标管线。从 MonitorType.ts 的getActiveMonitorTypes()可以看到Ping 监控会作为活跃监控参与计费isBilledAsActiveMonitor()返回true这与 Manual手动监控不同——在免费套餐中创建时需要注意这一点。总结Ping 监控是 OneUptime 上配置成本最低、语义最直接的监控类型之一。只需一个主机名或 IP 地址就能获得在线状态、往返时间、丢包率与抖动四项核心指标再配合时间窗口聚合 无数据处理策略的条件组合可以构建从主机下线到网络质量劣化的完整告警体系。对 Ping 监控的完整配置字段说明可参考仓库内的多语言文档如 fa/monitor/ping-monitor.md、en/monitor/ping-monitor.md对底层实现的深入阅读建议从 PingMonitor.ts 与 APIRequestCriteria.ts 入手。赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐COLMAP三维重建解决方案从稀疏特征到密集点云的技术实践COLMAP三维重建解决方案从稀疏特征到密集点云的技术实践 COLMAP作为开源的三维重建工具通过运动恢复结构Structure from Motion可观测性后端运维前端云原生微服务AI AgentOneUptime Ping 监控ICMP 探活完整实战指南主机可用性、延迟与丢包监控OneUptime Ping 监控ICMP 探活完整实战指南主机可用性、延迟与丢包监控 Ping 监控Ping Monitor是 OneUptime可观测性后端运维前端云原生微服务AI AgentOneUptime Ping 监控基于 ICMP 的主机可用性、延迟与丢包监控OneUptime Ping 监控基于 ICMP 的主机可用性、延迟与丢包监控 本篇以 OneUptime 官方文档中的 Ping Monitor 功能为核心可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考