SkyWalking - 自定义告警指标：基于 Meter 或日志的扩展告警

大家好欢迎来到我的技术博客 在这里我会分享学习笔记、实战经验与技术思考力求用简单的方式讲清楚复杂的问题。 本文将围绕SkyWalking这个话题展开希望能为你带来一些启发或实用的参考。 无论你是刚入门的新手还是正在进阶的开发者希望你都能有所收获文章目录SkyWalking - 自定义告警指标基于 Meter 或日志的扩展告警为什么需要自定义告警指标 SkyWalking 告警机制概览 方式一基于 Meter 指标的自定义告警 什么是 Meter 指标步骤 1在应用中集成 Meter SDK步骤 2定义并上报自定义 Meter 指标步骤 3在 SkyWalking UI 中验证指标步骤 4配置自定义告警规则步骤 5配置告警通知渠道高级用法复合指标与表达式方式二基于日志的自定义告警 适用场景步骤 1确保日志被 SkyWalking 采集步骤 2在 OAP 中配置日志指标规则步骤 3编写应用日志代码步骤 4验证日志指标步骤 5配置日志指标告警规则日志指标的局限性与优化自定义告警的最佳实践 ✅1. 避免告警疲劳2. 指标命名规范3. 测试告警规则4. 结合上下文信息5. 定期审查告警规则实战案例电商大促监控 实现购物车清空率告警实现优惠券核销失败告警实现库存超卖告警故障排查指南 ️问题 1自定义指标未显示在 UI 中问题 2告警规则未触发问题 3日志指标匹配不到与其他可观测性工具的对比 未来展望SkyWalking 的演进方向 总结 SkyWalking - 自定义告警指标基于 Meter 或日志的扩展告警在现代分布式系统架构中可观测性Observability已成为保障系统稳定性和性能的关键支柱。Apache SkyWalking 作为一款开源的 APMApplication Performance Monitoring系统凭借其强大的追踪、指标监控和拓扑分析能力被广泛应用于微服务、云原生等复杂环境中。然而随着业务场景的不断演进标准的监控指标往往难以满足特定需求。此时自定义告警指标就显得尤为重要。本文将深入探讨如何在 SkyWalking 中通过Meter 指标和日志数据两种方式扩展告警能力帮助开发者构建更贴合业务逻辑的监控体系。我们将从基础概念入手逐步讲解配置方法、编写代码示例并结合实际场景说明如何设计有效的告警规则。无论你是 SkyWalking 的初学者还是已有一定经验的用户都能从中获得实用的技巧和最佳实践。为什么需要自定义告警指标 SkyWalking 默认提供了丰富的内置指标如服务响应时间、吞吐量、错误率、JVM 内存使用等。这些指标对于通用性能监控非常有效但在以下场景中可能力不从擎业务关键指标缺失例如电商系统中的“下单成功率”、金融系统中的“交易失败次数”、IoT 平台中的“设备离线率”等。特定异常检测某些业务异常不会直接导致 HTTP 5xx 错误但会影响用户体验或数据一致性。日志驱动的告警某些关键事件仅记录在日志中如“数据库连接池耗尽”、“第三方 API 调用超时”无法通过标准指标捕获。合规与审计需求某些行业要求对特定操作如敏感数据访问进行实时监控和告警。此时通过Meter 指标或日志解析来创建自定义指标再结合 SkyWalking 的告警引擎就能实现精准、灵活的告警策略。 提示SkyWalking 的告警机制基于规则引擎支持动态加载和热更新无需重启服务即可生效。SkyWalking 告警机制概览 在深入自定义之前先简要了解 SkyWalking 的告警工作流程数据采集Agent 或 SDK 收集追踪、指标、日志等数据。指标聚合OAPObservability Analysis Platform服务器对原始数据进行聚合、计算。规则匹配告警规则引擎周期性默认每分钟评估所有已定义的规则。触发告警当指标值满足规则条件时生成告警消息。通知发送通过 Webhook、Slack、邮件等方式将告警推送给运维或开发人员。SkyWalking 支持两类主要的自定义指标来源Meter 指标通过 OpenTelemetry 或 SkyWalking 原生 Meter API 上报数值型指标。日志指标通过日志模式匹配如正则表达式提取关键信息转化为计数或数值指标。接下来我们将分别介绍这两种方式的实现细节。方式一基于 Meter 指标的自定义告警 什么是 Meter 指标Meter 是 SkyWalking 中用于表示可度量数值的抽象概念通常对应于计数器Counter、直方图Histogram、计量器Gauge等类型。它源自 OpenTelemetry 的 Metric APISkyWalking 对其进行了兼容和扩展。通过 Meter你可以将业务逻辑中的关键数值如订单数量、缓存命中率、队列长度上报到 SkyWalking进而用于告警。步骤 1在应用中集成 Meter SDK首先确保你的 Java 应用已集成 SkyWalking Agent。然后添加 SkyWalking Meter SDK 依赖以 Maven 为例dependencygroupIdorg.apache.skywalking/groupIdartifactIdapm-toolkit-meter/artifactIdversion8.16.0/version!-- 请使用与 OAP 服务器匹配的版本 --/dependency⚠️ 注意版本必须与 SkyWalking OAP 服务器一致否则可能导致兼容性问题。步骤 2定义并上报自定义 Meter 指标假设我们有一个电商服务需要监控“每分钟成功下单数”。我们可以使用Counter类型的 Meterimportorg.apache.skywalking.apm.toolkit.meter.Counter;importorg.apache.skywalking.apm.toolkit.meter.MeterFactory;publicclassOrderService{// 创建一个名为 order.success.count 的 Counter 指标privatestaticfinalCounterORDER_SUCCESS_COUNTERMeterFactory.counterBuilder(order.success.count).tag(service,order-service)// 可选标签用于多维过滤.build();publicvoidprocessOrder(Orderorder){try{// 业务逻辑处理订单doProcess(order);// 订单成功递增计数器ORDER_SUCCESS_COUNTER.increment();}catch(Exceptione){// 处理失败不增加计数log.error(Order processing failed,e);}}privatevoiddoProcess(Orderorder){// 实际订单处理逻辑}}在这个例子中order.success.count是指标名称将在 SkyWalking UI 中显示。tag(service, order-service)添加了维度标签便于在多服务环境中区分。每次成功处理订单时调用increment()方法。你也可以使用Gauge来上报瞬时值例如当前活跃用户数privatestaticfinalGaugeACTIVE_USERS_GAUGEMeterFactory.gaugeBuilder(user.active.count).tag(region,us-east).build();// 在某个定时任务中更新publicvoidupdateActiveUsers(){intcountgetCurrentActiveUsers();// 从缓存或数据库获取ACTIVE_USERS_GAUGE.set(count);}步骤 3在 SkyWalking UI 中验证指标启动应用后进入 SkyWalking UI导航到Metrics页面。在搜索框中输入order.success.count。应能看到实时变化的曲线图。如果看不到指标请检查Agent 是否正确附加到 JVM。网络是否能连通 OAP 服务器。指标名称是否拼写正确。步骤 4配置自定义告警规则现在我们基于order.success.count创建告警规则。编辑 SkyWalking OAP 服务器的alarm-settings.yml文件通常位于config/目录下rules:# 自定义规则订单成功率过低order_success_rate_rule:# 指标名称必须与 Meter 名称一致metrics-name:order.success.count# 操作符lt (小于), gt (大于), eq (等于) 等op:lt# 阈值每分钟少于 10 个成功订单threshold:10# 周期连续 3 个周期即 3 分钟都低于阈值才触发period:3# 告警消息模板message:订单服务异常过去 {0} 分钟内成功订单数低于 {1}当前值为 {2}# 是否包含实体如服务名include-entities:true# 告警级别可选level:CRITICAL 说明period表示连续多少个评估周期默认 1 分钟满足条件才触发避免瞬时抖动误报。{0},{1},{2}是占位符分别对应 period、threshold、当前值。保存文件后SkyWalking 会自动热加载规则无需重启 OAP。步骤 5配置告警通知渠道默认情况下告警会输出到 OAP 日志。为了实际使用需配置 Webhook 或其他通知方式。在alarm-settings.yml中添加webhooks:-http://your-alert-receiver.com/skywalking-alert接收端需实现一个 HTTP POST 接口接收 JSON 格式的告警消息。示例 payload{scopeId:1,scope:SERVICE,name:order-service,id:dGVzdA,ruleName:order_success_rate_rule,alarmMessage:订单服务异常过去 3 分钟内成功订单数低于 10当前值为 5,startTime:1717020000000}你可以将其集成到企业微信、钉钉、Slack 或自研告警平台。SkyWalking 官方文档提供了 Webhook 配置示例。高级用法复合指标与表达式SkyWalking 还支持通过指标表达式创建复合指标。例如计算“订单成功率”composite-rules:order_success_rate:# 表达式成功订单数 / 总订单数 * 100expression:order.success.count / order.total.count * 100# 单位unit:%然后基于order_success_rate设置告警规则。这需要你同时上报order.total.count总订单数和order.success.count。方式二基于日志的自定义告警 并非所有关键信息都适合通过 Meter 上报。有时重要事件仅存在于日志中。SkyWalking 从 8.5.0 版本开始支持日志模式匹配可将日志内容转化为指标。适用场景捕获特定错误日志如“数据库死锁”。统计业务事件如“用户登录失败”。监控第三方依赖状态如“支付网关超时”。步骤 1确保日志被 SkyWalking 采集首先你的应用日志必须被 SkyWalking Agent 采集。这通常通过以下方式实现使用 Logback 或 Log4j2并配置 SkyWalking 的日志插件。在agent.config中启用日志收集# agent.config plugin.toolkit.log.transmitterON日志格式建议包含结构化字段如 JSON便于后续解析。步骤 2在 OAP 中配置日志指标规则编辑 OAP 的log-metric-config.yaml文件位于config/目录logMetrics:-name:db.deadlock.countselector:SERVICEconditions:-message matches Deadlock found when trying to get lockmetrics:-name:db.deadlock.counttype:COUNTlabels:service:{service}解释name: 指标名称将用于告警规则。selector: 作用范围SERVICE、INSTANCE 等。conditions: 匹配条件支持正则表达式matches或精确匹配equals。metrics.type:COUNT表示每匹配一条日志计数加 1。保存后OAP 会自动加载配置。步骤 3编写应用日志代码在 Java 应用中确保关键事件被记录。例如importorg.slf4j.Logger;importorg.slf4j.LoggerFactory;publicclassDatabaseService{privatestaticfinalLoggerloggerLoggerFactory.getLogger(DatabaseService.class);publicvoidexecuteTransaction(){try{// 执行数据库事务}catch(DeadlockLoserDataAccessExceptione){// 记录死锁日志内容需匹配上述正则logger.error(Deadlock found when trying to get lock, transaction aborted,e);}}} 提示日志消息必须与conditions中的正则完全匹配包括大小写。建议使用常量字符串避免拼写错误。步骤 4验证日志指标在 SkyWalking UI 中进入Log页面确认日志已被采集。切换到Metrics页面搜索db.deadlock.count。触发一次死锁观察指标是否增加。步骤 5配置日志指标告警规则在alarm-settings.yml中添加规则rules:db_deadlock_alert:metrics-name:db.deadlock.countop:gtthreshold:0# 只要有死锁日志就告警period:1message:数据库死锁检测服务 {0} 在过去 {1} 分钟内发生 {2} 次死锁level:WARNING由于死锁是严重问题即使一次也应立即告警。日志指标的局限性与优化性能影响日志匹配在 OAP 侧进行大量日志可能增加 CPU 负载。建议只匹配关键日志。延迟日志从应用到 OAP 存在传输延迟告警可能滞后几秒到几十秒。正则复杂度避免使用过于复杂的正则以免影响匹配效率。为优化性能可在应用侧预过滤日志或使用结构化日志如 JSON配合字段提取logMetrics:-name:payment.timeout.countselector:SERVICEconditions:-event PAYMENT_TIMEOUT# 假设日志中有 event 字段metrics:-name:payment.timeout.counttype:COUNT这要求日志格式为{event:PAYMENT_TIMEOUT,orderId:12345,timestamp:...}自定义告警的最佳实践 ✅1. 避免告警疲劳过多的告警会导致“狼来了”效应使团队忽视真正的问题。建议设置合理的阈值和周期例如错误率 5% 且持续 5 分钟。使用分级告警CRITICAL立即处理、WARNING关注、INFO记录。聚合告警同一问题在短时间内多次触发应合并为一条告警。2. 指标命名规范采用清晰、一致的命名约定例如业务域.指标类型.描述order.success.count、user.login.failure.rate避免使用缩写或模糊词汇。3. 测试告警规则在生产环境部署前务必在测试环境验证指标是否正确上报。规则是否在预期条件下触发。通知是否送达。可以使用 SkyWalking 的模拟数据工具或手动注入测试事件。4. 结合上下文信息在告警消息中包含足够的上下文例如服务名、实例 IP时间窗口当前值与阈值对比这有助于快速定位问题。5. 定期审查告警规则业务变化可能导致原有告警失效或产生噪音。建议每月审查哪些告警从未触发是否已过时哪些告警频繁误报是否需要调整阈值实战案例电商大促监控 假设我们正在为“双11”大促准备监控方案需要关注以下自定义指标购物车清空率用户将商品加入购物车但未下单的比例。优惠券核销失败用户使用优惠券时系统报错。库存超卖下单时库存不足。实现购物车清空率告警首先在应用中上报两个 Meter// 购物车添加事件CounterCART_ADD_COUNTERMeterFactory.counterBuilder(cart.add.count).build();// 订单创建事件代表购物车被清空CounterORDER_CREATE_COUNTERMeterFactory.counterBuilder(order.create.count).build();// 在购物车服务中publicvoidaddToCart(CartItemitem){CART_ADD_COUNTER.increment();}// 在订单服务中publicvoidcreateOrder(Orderorder){ORDER_CREATE_COUNTER.increment();}然后在alarm-settings.yml中定义复合指标和告警composite-rules:cart_abandonment_rate:expression:(cart.add.count - order.create.count) / cart.add.count * 100unit:%rules:high_cart_abandonment:metrics-name:cart_abandonment_rateop:gtthreshold:70# 清空率超过 70% 告警period:2message:购物车清空率过高{0}%可能影响转化率实现优惠券核销失败告警通过日志方式// 优惠券服务logger.error(COUPON_REDEMPTION_FAILED: couponId{}, userId{},couponId,userId);OAP 配置# log-metric-config.yamllogMetrics:-name:coupon.redeem.failure.countconditions:-message startsWith COUPON_REDEMPTION_FAILEDmetrics:-name:coupon.redeem.failure.counttype:COUNT告警规则rules:coupon_redeem_failure:metrics-name:coupon.redeem.failure.countop:gtthreshold:5# 每分钟超过 5 次失败period:1message:优惠券核销失败激增{2} 次/分钟实现库存超卖告警同样使用日志// 库存服务if(stock0){logger.error(STOCK_OVERSOLD: productId{}, stock{},productId,stock);}配置类似优惠券告警此处略。故障排查指南 ️问题 1自定义指标未显示在 UI 中检查 Agent 日志查看是否有 Meter 注册成功的日志。验证网络确保 Agent 能连接 OAP 的 gRPC 端口默认 11800。确认指标名称大小写敏感不能包含特殊字符。问题 2告警规则未触发检查规则语法YAML 缩进是否正确metrics-name是否拼写一致查看 OAP 告警日志通常位于logs/alarm.log会记录规则评估过程。测试指标值在 Metrics 页面确认当前值确实满足条件。问题 3日志指标匹配不到检查日志格式是否包含完整的消息文本是否有换行或截断转义正则特殊字符如.、*、?等需转义。使用简单匹配先测试例如message contains ERROR。与其他可观测性工具的对比 SkyWalking 的自定义告警能力与 Prometheus、Datadog 等工具有何异同特性SkyWalkingPrometheusDatadog指标来源Meter 日志Exporter PushgatewayDogStatsD 日志告警规则YAML 配置PromQL自定义查询日志集成原生支持需 Loki 或其他强大日志分析学习曲线中等较高需掌握 PromQL低图形化开源免费✅✅❌SkyWalking 的优势在于一体化追踪、指标、日志在同一平台关联分析特别适合微服务场景。而 Prometheus 更适合基础设施监控Datadog 则提供更丰富的商业功能。 想了解更多参考 CNCF 可观测性全景图。未来展望SkyWalking 的演进方向 SkyWalking 社区正积极增强自定义告警能力动态指标创建无需重启应用即可定义新 Meter。机器学习基线告警自动学习指标正常范围减少手动阈值设置。更强大的日志处理支持 Grok 模式、字段提取等。此外SkyWalking 与 OpenTelemetry 的深度集成将进一步简化指标上报。开发者未来可能只需使用标准 OpenTelemetry APISkyWalking 即可自动识别并用于告警。总结 自定义告警指标是 SkyWalking 从“通用监控”迈向“业务监控”的关键一步。通过Meter 指标你可以将业务逻辑中的关键数值转化为可监控的指标通过日志解析你能捕获那些隐藏在文本中的重要事件。两者结合构建出全方位、多层次的告警体系。在实施过程中请牢记明确业务目标告警是为了保障业务而非技术指标本身。渐进式实施从最关键的 2-3 个指标开始逐步扩展。持续优化根据实际运行效果调整规则避免告警疲劳。希望本文的详细步骤和代码示例能帮助你在 SkyWalking 中成功实现自定义告警。如果你有更多问题或实践经验欢迎在社区交流 延伸阅读SkyWalking 官方文档 - 告警OpenTelemetry Metrics 规范微服务可观测性最佳实践上报 Meter输出日志触发未触发应用代码SkyWalking AgentLog CollectorSkyWalking OAP指标聚合Meter 指标日志指标告警规则引擎Webhook/Slack/邮件继续监控通过上图可见无论是 Meter 还是日志最终都会汇聚到 OAP 的告警引擎形成统一的告警流。这种设计保证了告警策略的一致性和可维护性。现在是时候为你的应用添加那些“缺失的告警”了 感谢你读到这里 技术之路没有捷径但每一次阅读、思考和实践都在悄悄拉近你与目标的距离。 如果本文对你有帮助不妨 点赞、收藏、分享给更多需要的朋友 欢迎在评论区留下你的想法、疑问或建议我会一一回复我们一起交流、共同成长 关注我不错过下一篇干货我们下期再见✨