可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载OneUptime 的 Traces Monitor追踪/链路监控让你基于应用上报的分布式追踪数据Distributed Traces自动告警它在一段时间窗口内统计匹配指定过滤条件的 Span并根据 Span 数量与状态码触发告警。本文以 traces-monitor.md 为骨架结合 MonitorStepTraceMonitor.ts、TraceMonitorCriteria.ts 等源码完整讲解 Traces Monitor 的创建步骤、全部配置项、Span 过滤语法、阈值判定逻辑与前置接入要求读完即可在 OneUptime 中配置错误 Span 突增接口错误率告警等实战监控方案。Traces Monitor 能做什么Traces Monitor 的核心机制是在指定时间窗口内搜索并计数与特定过滤条件匹配的 Span。OneUptime 会周期性评估来自各遥测服务Telemetry Services的追踪数据将统计结果与阈值比较从而判定监控是否处于告警状态。通过它你可以实现对服务中的错误 Span 突增error span spikes进行告警监控特定的操作operations与接口端点endpoints例如POST /api/checkout跟踪 Span 的总体数量与变化模式volume and patterns按 Span 状态码、Span 名称、自定义属性attributes进行过滤从追踪数据中发现性能与可靠性问题例如某个下游依赖失败导致的错误链路激增。从源码看OneUptime 将Traces定义为一种独立的监控类型MonitorType与Logs、Metrics、Exceptions等并列见 MonitorType.ts 中Traces Traces的定义。创建 Traces Monitor 的完整步骤在 OneUptime Dashboard 中按以下步骤创建进入Monitors监控页面点击Create Monitor创建监控监控类型选择Traces选择要监控的遥测服务Telemetry Services——支持单选或多选按需配置Span 过滤条件Span Filters与监控标准Criteria。保存后监控器会按设定的评估周期执行先从遥测数据库中检索窗口内的 Span再与阈值条件比较并写入监控状态与事件。配置选项详解遥测服务Telemetry Services选择需要监控的一个或多个服务。前提是这些服务已经通过OpenTelemetry将追踪数据上报到 OneUptime——否则没有数据可供评估。在源码层面这一步对应MonitorStepTraceMonitor.telemetryServiceIds字段。构建查询时OneUptime 会将该字段映射为 Span 分析模型中的primaryEntityIdSpan 所属的服务/主实体过滤条件使用IncludesIN 集合匹配一次性匹配多个服务 ID见 MonitorStepTraceMonitor.ts。此外源码还支持可选的entityKeys字段用于将监控范围进一步限定到携带特定实体键如 host / pod / container的 Span——它编译为服务端的hasAny(entityKeys, [...])过滤。该字段是后加的早期创建的监控可能没有此字段属于可选能力见 MonitorStepTraceMonitor.ts。Span 过滤器Span Filters过滤器说明是否必填Span 状态码Span Statuses按 Span 状态码过滤OK、ERROR、UNSET否Span 名称Span Name对特定 Span 名称做文本搜索如操作名、端点名否属性Attributes键值对按自定义 Span 属性过滤否时间窗口Time Window回溯搜索 Span 的时间范围单位秒默认 60否各过滤项与MonitorStepTraceMonitor接口字段一一对应spanStatuses→ 编译为query.statusCode new Includes(spanStatuses)spanName→ 编译为query.name new Search(spanName)属于文本搜索而非精确匹配attributes→ 直接以字典key-value形式赋给query.attributeslastXSecondsOfSpans→ 以当前时间为终点、向前回退 N 秒生成query.startTime new InBetween(startDate, endDate)的时间范围查询。完整转换逻辑集中在MonitorStepTraceMonitorUtil.toQuery()见 MonitorStepTraceMonitor.ts。对应的单测覆盖了每个过滤项的映射行为例如scopes to telemetry services when provided、filters by span status when provided、searches the span name when provided、builds a trailing time window from lastXSecondsOfSpans见 MonitorStepTraceMonitor.test.ts。Span 状态码Span Status CodesOK—— 操作成功完成ERROR—— 操作遇到错误UNSET—— 状态未被显式设置。这些状态与 OTLP/OpenTelemetry 的 Span 状态语义一致。在 OneUptime 的 Span 分析模型中状态码以枚举形式存储Unset 0、Ok 1、Error 2对应Span模型的statusCode列见 Span.ts。监控配置中选择的状态会通过Includes匹配该列因此多个状态码可同时选择例如同时统计 OK 与 ERROR。监控标准Criteria配置可用检查类型Check On检查类型说明Span CountSpan 数量时间窗口内匹配过滤条件的 Span 总数目前 Traces Monitor 只提供Span Count一种检查维度在代码中对应CheckOn.SpanCount Span Count见 CriteriaFilter.ts。评估结果由TraceMonitorResponse承载包含spanCount计数结果、spanQuery实际执行的查询、projectId、monitorId等字段见 TraceMonitorResponse.ts。过滤条件Filter Conditions / 阈值类型大于Greater Than—— Span 数量超过阈值小于Less Than—— Span 数量低于阈值大于或等于Greater Than or Equal To—— Span 数量达到或超过阈值小于或等于Less Than or Equal To—— Span 数量不高于阈值等于Equal To—— Span 数量精确等于阈值。在服务端TraceMonitorCriteria.isMonitorInstanceCriteriaFilterMet()会取出criteriaFilter.value作为阈值将实际spanCount与阈值交给CompareCriteria.compareCriteriaNumbers()做数值比较并返回是否触发见 TraceMonitorCriteria.ts。也就是说Span Count 阈值类型最终在服务端被归一化为一次简单的数值比较实时评估与告警都由 OneUptime 后端完成无需探针参与。异常检测Anomaly进阶能力除静态阈值外源码还实现了基于基线的异常检测路径evaluateSpanCountAnomaly见 TraceMonitorCriteria.ts将观测到的 Span 数量归一化为每分钟速率spanCount * 60 / windowSeconds通过SpanCountBaselineService.getBaseline()获取**同小时段same-hour-of-week**的历史基线基线范围限定为监控选定的服务与状态码属性与名称过滤器不参与基线统计基线是这些范围的全量体量使用均值/标准差Mean/Stddev或中位数/MADMedian/Mad方法计算偏离 σ并支持灵敏度sensitivity配置冷启动保护基线样本不足不可靠时返回不告警避免在学习期产生误报零方差基线同样被跳过防止任何微小波动都触发告警。该能力的测试覆盖见 TraceMonitorCriteria.test.ts。这意味着在 Dashboard 中除了大于/小于等静态条件还可以为 Span Count 配置异常检测型条件让监控在流量偏离历史规律时自动告警。示例一60 秒内错误 Span 超过 50 个即告警适合在错误突增场景如依赖服务故障、发布回滚下快速告警Span 状态码ERROR时间窗口60 秒检查类型Check OnSpan Count过滤条件Greater Than大于阈值50示例二特定接口出现任何错误即告警适合对关键交易链路如支付、下单做零容忍监控Span 名称POST /api/checkoutSpan 状态码ERROR时间窗口120 秒检查类型Check OnSpan Count过滤条件Greater Than大于阈值0第二个示例中Span 名称在源码层面对应query.name new Search(POST /api/checkout)的文本搜索因此可以按操作名/端点名精确圈定告警范围阈值 0 表示只要窗口内出现一条匹配的错误 Span 就告警。前置接入要求通过 OpenTelemetry 上报追踪使用 Traces Monitor 的前提是应用必须通过 OpenTelemetry 将分布式追踪数据发送到 OneUptime。请按照 OneUptime 官方文档 open-telemetry.md法文版或 英文版完成接入配置包括为应用安装 OpenTelemetry SDK/Agent配置 OTLP 导出器指向 OneUptime 的遥测接入端点使用遥测接入密钥Telemetry Ingestion Key完成鉴权参见 TelemetryIngestionKey.ts确认服务出现在 Dashboard 的遥测服务列表中后再创建 Traces Monitor。默认值与行为细节时间窗口默认 60 秒MonitorStepTraceMonitorUtil.getDefault()返回的默认配置为lastXSecondsOfSpans: 60、空状态列表、空名称、空属性见 MonitorStepTraceMonitor.ts空配置也是合法监控toQuery(getDefault())只生成一个最近 60 秒的时间范围查询不额外收紧任何过滤条件也就是说即使不选任何过滤器也会统计该服务全量 Span 数量对应测试见 MonitorStepTraceMonitor.test.ts多次评估、阈值比较在服务端完成监控数据提取与标准判定位于 MonitorCriteriaDataExtractor.ts 与 TraceMonitorCriteria.ts无需自建探针降低了接入成本。小结Traces Monitor 是 OneUptime 遥测监控家族Logs / Metrics / Traces / Exceptions中针对分布式追踪的告警入口。配置它的关键三步是确认遥测服务已通过 OpenTelemetry 上报、用状态码/名称/属性/时间窗口圈定 Span 范围、再为 Span Count 设定静态阈值或异常检测条件。结合源码可以看到每一个 Dashboard 配置项最终都会通过MonitorStepTraceMonitorUtil.toQuery()编译成精确的 Span 查询并由TraceMonitorCriteria在服务端完成计数与阈值评估——理解这层映射关系能帮你更准确地设计出低误报、高灵敏的链路告警规则。赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime 分布式链路追踪监控Traces Monitor实战指南基于 OpenTelemetry Span 的告警配置与实现原理OneUptime 分布式链路追踪监控Traces Monitor实战指南基于 OpenTelemetry Span 的告警配置与实现原理 在 OneUp可观测性后端运维前端云原生微服务AI AgentOneUptime Traces Monitor 使用指南基于 OpenTelemetry Span 的分布式链路告警配置与实现原理OneUptime Traces Monitor 使用指南基于 OpenTelemetry Span 的分布式链路告警配置与实现原理 Traces Monit可观测性后端运维前端云原生微服务AI AgentOneUptime Traces 监控指南基于 OpenTelemetry 分布式追踪的 Span 监控与告警OneUptime Traces 监控指南基于 OpenTelemetry 分布式追踪的 Span 监控与告警 Traces Monitor追踪监控器是可观测性后端运维前端云原生微服务AI Agent上一篇自动化脚本为什么总误触纯视觉屏幕识别的一个思路下一篇10个必学的Claude-Trading-Skills筛选工具轻松捕捉优质交易机会创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考