可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载本指南围绕 OneUptime 的Metrics Monitor指标监控展开讲解如何对通过 OpenTelemetry 采集的自定义应用指标与基础设施指标CPU、内存、磁盘、网络等进行查询、公式组合、阈值判断与异常检测并深入剖析其按序列分组告警Group By机制。读完本文你将掌握从创建指标监控、配置查询与聚合策略到编写多指标公式、设置静态阈值与基线异常检测再到实现每台主机一个告警的完整实战方案。概览什么是 Metrics MonitorMetrics Monitor 会查询并评估来自遥测服务的数值型指标在设定的时间窗口内对指标值进行聚合再依据你配置的判据Criteria触发告警。它支持的能力包括监控自定义应用指标例如请求速率request rate、队列深度queue depth、错误率error rate等追踪基础设施指标例如 CPU、内存、磁盘、网络通过过滤器Attributes与聚合Aggregation构建复杂的指标查询使用数学公式把多条指标组合成新的派生指标基于指标阈值Threshold设置告警也支持无阈值的基线异常检测。在 OneUptime 的监控体系中Metrics Monitor 的数据来源是 OpenTelemetryOTel遥测管线你的应用或基础设施必须先把指标发送到 OneUptime监控才能查询到数据。这一点在 OpenTelemetry 接入文档 中有完整说明后文设置前提一节也会再次强调。创建 Metrics Monitor 的步骤在 OneUptime Dashboard 中按以下流程创建进入Monitors页面点击Create Monitor监控类型选择Metrics配置一个或多个指标查询Metric Query并按需添加公式Formula选择聚合策略Aggregation Strategy按需配置监控判据Monitoring Criteria。从数据模型上看一个 Metrics Monitor 步骤由三部分构成见 MonitorStepMetricMonitor.tsmetricViewConfig查询与公式的完整配置queryConfigsformulaConfigsrollingTime评估时间窗口默认值为Past1MinutetelemetryServiceIds可选遥测服务范围限定用于把监控限定到某个应用如 RUM 推荐创建的监控保持为空则作用于整个项目内所有匹配序列。// MonitorStepMetricMonitor 默认值源码节选 { metricViewConfig: { queryConfigs: [], formulaConfigs: [] }, rollingTime: RollingTime.Past1Minute, telemetryServiceIds: [], }需要注意监控步骤以 JSON 形式持久化metricViewConfig在运行时可能缺失因此代码中提供了getMetricViewConfig()防御性读取见 MonitorStepMetricMonitor.ts避免旧版本数据导致前端白屏。配置选项详解指标查询Metric Queries一个查询定义一条要查询的指标序列核心字段如下字段说明是否必填Metric Name指标名称要查询的指标名例如http_requests_total是Aggregation Type聚合类型原始指标值的聚合方式sum、avg、min、max、count是Attributes属性过滤键值对过滤器用于缩小指标数据范围例如status5xx否Group By分组依据按属性把查询拆分成每个唯一值一条序列例如按host.name拆成每台主机一条否每个查询都会被分配一个别名Alias例如a、b、c供公式引用。在源码层面查询配置对应 MetricQueryConfigData.ts 与 MetricQueryData.tsmetricAliasData承载别名metricVariable、图表标题title与图例单位legendUnit见 MetricAliasData.tsmetricQueryData.filterData包含metricName与属性过滤条件attributesgroupByAttributeKeysOpenTelemetry 属性键数组如host.name、service.name当它被设置时监控 Worker 会为每个唯一属性组合产出一条序列从而支持每台主机/每个服务各建一个告警topN分组查询最多绘制多少个分组默认上限 10transformAsRate对于 OTel 的累计计数器如system.disk.io、system.network.io把数据点转换为每秒变化率(value - previousValue) / Δt避免画出单调递增的累计值。聚合类型在 AggregationType.ts 中定义除文档提到的Max、Min、Sum、Avg、Count之外还支持百分位聚合P50、P90、P95、P99对直方图桶数据使用quantileExactWeighted计算可用于对http.server.request.duration这类直方图指标做 P95 告警。公式Formulas公式用于把多条查询组合成数学表达式每个公式同样拥有自己的别名。常用形式a / b * 100— 由两条查询计算百分比a b— 两条指标求和a - b— 两条指标求差。公式定义对应 MetricFormulaConfigData.ts含metricFormulaData.metricFormula表达式与别名元数据。评估时Worker 会按别名索引到对应查询或公式的聚合结果查询与公式共享同一索引空间公式索引偏移量为查询数量见 MetricMonitorCriteria.ts。公式还支持嵌套一个公式可以引用另一个公式的别名。滚动时间窗口Rolling Time Window选择指标评估的时间窗口文档列出的选项为过去 1 分钟Past 1 Minute过去 5 分钟Past 5 Minutes过去 10 分钟Past 10 Minutes过去 15 分钟Past 15 Minutes过去 30 分钟Past 30 Minutes过去 60 分钟Past 60 Minutes在 RollingTime.ts 中枚举值从Past1Minute一直覆盖到Past365Days按天级窗口用于指标浏览/图表场景监控默认窗口为 1 分钟。窗口越大参与评估的样本越多对瞬时抖动越不敏感。聚合策略Aggregation Strategy聚合策略决定窗口内的所有采样值如何折叠成一个参与判据比较的结果策略说明Average平均值窗口内所有值的平均Sum求和所有值的总和Maximum Value最大值窗口内最高值Minimum Value最小值窗口内最低值All Values所有值窗口内所有值都必须满足判据Any Value任一值至少一个值满足判据该枚举对应源码 CriteriaFilter.ts 中的EvaluateOverTimeType。当判据未显式指定聚合类型时评估器会回退到AnyValue见 MetricMonitorCriteria.ts。这与按序列分组告警配合尤其重要例如任何一台主机的磁盘用量超过 90% 就告警应选择Any Value而所有主机都超过阈值才告警则应选择All Values。监控判据Monitoring Criteria评估对象Metrics Monitor始终评估指标值Metric Value——即配置的查询或公式在窗口内聚合后的数值。判据表单没有过滤器类型Filter Type选择器而是直接展示Metric指标、Aggregation聚合、Condition条件与Threshold阈值。静态阈值条件静态阈值会把聚合值与你在Threshold中输入的数值比较Greater Than大于— 指标值超过阈值Less Than小于— 指标值低于阈值Greater Than or Equal To大于或等于— 指标值达到或超过阈值Less Than or Equal To小于或等于— 指标值处于或低于阈值Equal To等于— 指标值与阈值完全相等。源码中的比较逻辑见 MetricMonitorCriteria.ts 的sampleBreaches()与文档列表一一对应另支持NotEqualTo不等于。比较时还会做单位换算采样值已按查询配置的legendUnit归一化若阈值指定了不同的thresholdUnit评估器会先把样本从legendUnit换算到阈值单位再比较见 MetricMonitorCriteria.ts。无数据策略NoData Policy虽然文档主表未单列源码 CriteriaFilter.ts 明确支持三种无数据策略值得在实战中配置Ignore默认把窗口内没有任何数据当作不触发最安全符合多数 SaaS 工具的默认行为Treat As Zero把缺失数据点当作 0适合没有事件就代表 0的计数器场景Trigger无论阈值如何直接把无数据判为违约适合心跳类指标——数据消失本身即故障。评估器在samples.length 0时按上述策略分支处理见 MetricMonitorCriteria.ts避免静默把无数据当 0 而误报。基线异常检测Baseline Anomaly Detection不需要手工输入阈值判据表单此时展示Sensitivity灵敏度与Baseline Window基线窗口系统会把每个采样点与基于该窗口构建的、同小时同星期hour-of-week基线比较Anomalously High异常偏高— 指标值高出预期区间Anomalously Low异常偏低— 指标值低于预期区间Anomalous异常— 指标值向任意方向偏离预期区间。异常条件会保持在Learning学习中状态直到积累的指标历史至少达到所选的基线窗口长度之前不会产生任何告警。这是冷启动保护基线样本不足时绝不误报。源码实现位于 MetricMonitorCriteria.ts 的evaluateAnomaly()中要点如下基线按星期几的第几小时hour-of-week分桶建立评估窗口若跨越小时边界会同时拉取两个桶的基线灵敏度映射为标准差倍数expectedHigh mean sigmaCount × stddev、expectedLow mean - sigmaCount × stddev超出该区间即违约基线状态机为Learning/Normal/Anomalous三态见 MetricCriteriaContext.ts冷启动或样本不足时为Learning不触发基线可靠且未越界为Normal越界为Anomalous触发默认基线窗口为 14 天DEFAULT_WINDOW_DAYS灵敏度枚举为 Low / Medium / High当前版本公式不支持异常检测公式没有可基线的指标名评估器直接返回 Learning 不触发仅普通指标查询可用根因信息会报告观测值与基线均值的偏离标准差数observedSigma例如偏差 3.2σ。异常检测单元换算有专门测试覆盖见 MetricMonitorCriteriaAnomalyUnits.test.ts验证均值、标准差与观测值均按人类可读比例显示、σ 保持纯数字、比率类指标按百分比呈现。判据示例示例 1错误率超过 5% 时告警查询 ahttp_requests_total过滤条件status5xx查询 bhttp_requests_total全部请求公式a / b * 100条件Greater Than大于阈值5。示例 2请求队列深度过高时告警查询request_queue_size聚合方式选Maximum Value最大值条件Greater Than阈值1000。按序列告警Per-Series Alerting / Group ByGroup By会把一条指标查询按属性拆成每个唯一属性值一条序列——每台主机、每个容器、每个挂载点各一条。设置了 Group By 的监控会独立评估每一条序列。这一个设置就是整个集群不健康与prod-db-01这台机器不健康之间的差别。每分组一个告警以host.name分组为例一个磁盘用量监控同时看着五十台主机每台越限的主机都会触发一条独立的告警或事件 Incident。主机 A 磁盘写满会打开它自己的告警十分钟后主机 B 写满会在旁边打开第二条彼此独立的告警。如果不设置 Group By同一个监控退化为一个标量查询把全部主机的数据折合成一个数字整个监控只能产生一条告警。在这条告警未关闭期间第二台主机越限不会产生任何新东西——监控已经在告警了没有新事件可建值班工程师永远不会知道主机 B 出问题。设置 Group By 是获得每主机告警的唯一途径。如果你想按主机、按容器或按挂载点被呼叫page务必设置它。源码层面的实现路径是查询配置了groupByAttributeKeys后Worker 在 MetricMonitorResponse.ts 中产出seriesBreakdown——每个序列携带一个fingerprint指纹由标签值稳定拼接而成、labels标签字典以及仅限该序列的聚合结果含逐序列公式结果见 MetricSeriesResult.ts。评估器evaluateAllSeries()对每条序列独立执行同一判据见 MetricMonitorCriteria.ts调用方再按违约序列逐个创建事件。对应测试见 MetricMonitorCriteria.test.ts三条序列两台越限、一台正常只返回两个违约结果且各自携带独立的 breaching-samples 上下文。独立解决Independent Resolution每个分组告警只跟踪自己的分组。主机 A 回落到阈值以下后A 的告警自动解决主机 B 的告警会一直保持打开直到 B 恢复。一个分组恢复绝不会关闭另一个分组的告警。判据评估的差异分组监控会评估每一条判据。因此多个严重程度带可以同时在不同分组上生效当Critical严重— 大于 95排在Warning警告— 大于 80之上时96% 的主机在同一次检查中触发严重告警而 85% 的主机同时触发警告告警。同一台主机即使同时越过两个带也只得到恰好一条告警——来自第一条匹配的判据所以请把最严重的判据排在前面。未分组监控在第一条匹配的判据处停止。只有那一条判据会触发这是把告警判据放在健康判据之上的另一个理由一条宽泛的健康判据如果排在前面几乎每次检查都会匹配从而让排在它下面的告警判据永远得不到评估。如何选择分组属性按你确实会因为某个独立实体而呼叫某人的属性来分组面向整个集群的主机指标 → 用主机属性如host.name容器指标 → 用容器或 Pod 属性文件系统或磁盘 I/O 指标 → 用挂载点mountpoint或设备属性网络指标 → 用接口interface属性。Group By 下拉列表由你的 Collector 实际发送的属性填充所以应从列表中选择而不是手敲键名。反之不要对本来就是全系统标量的指标分组——例如集群级 leader 标志、调度器积压、或单主机监控上的单台主机 CPU。给这类指标分组只会产生恰好一条序列除了告警标题外什么都改变不了。分组属性的值还可以作为模板变量用在告警或事件的标题、描述与修复备注中——按host.name分组后标题可以显示为Disk almost full on {{host.name}}。设置前提指标监控要求你的应用或基础设施通过 OpenTelemetry 把指标发送到 OneUptime。完整的接入指引见 OpenTelemetry 文档包括主机 Collector、Kubernetes、Docker、Serverless 等场景的采集配置。只有数据进入 OneUptime 的指标存储后Metrics Monitor 的查询、公式与判据评估才有数据可依这也是Learning 状态与无数据策略得以存在的底层原因——它们都在处理数据不完整这一现实约束。小结Metrics Monitor 是 OneUptime 面向数值型遥测指标的通用告警引擎查询 公式定义看什么滚动窗口 聚合策略定义怎么算静态阈值 基线异常定义何时告警而 Group By 则把一个监控升级为按实体主机/容器/挂载点/接口独立评估与独立告警的舰队级监控能力。建议按以下顺序落地先确认 OpenTelemetry 指标已入库再创建查询与公式接着选好窗口与聚合策略最后用分组 多级判据严重 警告 健康把告警粒度收敛到你需要被呼叫的最小实体。赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime Metrics Monitor 完整指南基于 OpenTelemetry 的指标监控与告警配置OneUptime Metrics Monitor 完整指南基于 OpenTelemetry 的指标监控与告警配置 导读 Metrics Monitor指标可观测性后端运维前端云原生微服务AI AgentOneUptime Docker Monitor 完整指南基于 OpenTelemetry 的容器监控、指标告警与日志采集OneUptime Docker Monitor 完整指南基于 OpenTelemetry 的容器监控、指标告警与日志采集 本文是 OneUptime 开源可可观测性后端运维前端云原生微服务AI AgentOneUptime 指标监控器Metrics Monitor完全配置指南基于 OpenTelemetry 的自定义指标告警实战OneUptime 指标监控器Metrics Monitor完全配置指南基于 OpenTelemetry 的自定义指标告警实战 本文是 OneUptime可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考