SLS告警最佳实践——在通知中引用日志内容

本文涉及的产品
对象存储 OSS,20GB 3个月
文件存储 NAS,50GB 3个月
云备份 Cloud Backup,100GB 3个月
简介: 在配置告警通知的时候,通常我们需要知道告警的触发详情。例如Nginx访问错误告警,我们需要知道错误的HTTP Status 分布,错误的机器IP等信息,并且需要将这些信息体现在通知中,以便在接收到告警通知后,能够一目了然地知道发生了什么事情。那么在创建告警规则的时候,我们就需要进行合理的配置,使得告警在触发后,可以将这些信息放在合适的位置发送给通知服务,从而在通知模板里可以被引用到,从而被正确地通知。

概述

在配置告警通知的时候,通常我们需要知道告警的触发详情。例如Nginx访问错误告警,我们需要知道错误的HTTP Status 分布,错误的机器IP等信息,并且需要将这些信息体现在通知中,以便在接收到告警通知后,能够一目了然地知道发生了什么事情。

那么在创建告警规则的时候,我们就需要进行合理的配置,使得告警在触发后,可以将这些信息放在合适的位置发送给通知服务,从而在通知模板里可以被引用到,从而被正确地通知。

基本属性介绍

在告警规则触发告警后,我们可以通过如下一些属性获取到告警的原始日志信息,它们分别是:

  • labels
  • annotations
  • results
  • fire_results

它们的基本格式以及如何在模板中引用可以参考 内容模板变量说明(新版)。下面来分别进行介绍。

labels

自定义标签

在配置告警规则的时候,我们可以手动添加标签,例如:

那么在告警触发后,告警消息里就会包含如下信息:

{
"labels": {
"app": "nginx",
"env": "prod"    }
}

因此在内容模板里,就可以通过如下方式引用标签字段,例如:

应用: {{ alert.labels.app }}
环境: {{ alert.labels.env }}

分组评估

如果设置了分组评估,那么分组评估的字段会默认添加到标签中。关于分组评估的介绍,可以参考文档 分组评估。例如下面的配置,根据 status 字段做分组评估,那么当有错误时,不同的错误码是不同的告警,例如 400 的错误会是一个告警,404 的错误会是另外一个告警,等等。

此时除了自定义的 app 和 env 标签,还会有一个系统加上去的 stauts 标签。例如 404 的错误触发的告警会包含如下信息:

{
"labels": {
"app": "nginx",
"env": "prod",
"status": "404"    }
}

因此在内容模板里,就可以通过如下方式引用标签字段,例如:

应用: {{ alert.labels.app }}
环境: {{ alert.labels.env }}
错误码: {{ alert.labels.status }}

特别注意:

在设置分组评估的时候,需要特别注意,应当使用可枚举的字段。例如 http_status,slb_id 等。而对于不可枚举的随机字段,则不应该作为分组字段,例如 request_time,uuid 等。

annotations

自定义标注

在配置告警规则的时候,我们可以添加标注。与标签相比,标注更加灵活。标注不仅可以配置为固定的文本,还可以引用日志的字段,例如下面配置:

这里需要注意,默认有两个标注:

  • 标题,即 title 属性
  • 描述,即 desc 属性

那么在告警触发后,告警消息里就会包含如下信息:

{
"annotations": {
"title": "Nginx访问错误告警触发",
"desc": "状态码400错误发生了15次"    }
}

因此在内容模板里,就可以通过如下方式引用标注字段,例如:

告警标题: {{ alert.annotations.title }}
告警描述: {{ alert.annotations.desc }}

自动添加标注

除了自定义标注,还可以使用自动添加标注功能,例如:

它本质上相当于:

fire_results

fire_results 表示的是满足条件的告警记录。例如告警查询语句的结果如下:

当告警规则中触发条件配置为 cnt > 0 的时候:

触发的告警会有如下属性:

{
"fire_results": [
        { "status": "401", "ip": "127.0.0.1", "cnt": "3" },
        { "status": "400", "ip": "127.0.0.1", "cnt": "7" },
        { "status": "501", "ip": "127.0.0.1", "cnt": "4" },
        { "status": "404", "ip": "127.0.0.1", "cnt": "4" },
        { "status": "402", "ip": "127.0.0.1", "cnt": "6" },
        { "status": "403", "ip": "127.0.0.1", "cnt": "8" }
    ]
}

当告警规则中触发条件配置为 cnt > 5 时:

触发的告警的 fire_results 如下:

{
"fire_results": [
        { "status": "400", "ip": "127.0.0.1", "cnt": "7" },
        { "status": "402", "ip": "127.0.0.1", "cnt": "6" },
        { "status": "403", "ip": "127.0.0.1", "cnt": "8" }
    ]
}

然后就可以在模板变量中引用 fire_results 字段,例如:

告警触发详情: {{ alert.fire_results|to_json }}

results

results 是告警查询最原始的数据,例如上面的例子,告警触发后 results 信息如下:

{
"results": [{
"store_type": "log",
"region": "cn-hangzhou",
"project": "test-alert",
"store": "nginx-access-log",
"query": "status >= 400 | select status, __source__ as ip, count(*) as cnt group by status, ip",
"start_time": 1640006894,
"end_time": 1640007014,
"dashboard_id": "",
"raw_results": [
            { "status": "401", "ip": "127.0.0.1", "cnt": "3" },
            { "status": "400", "ip": "127.0.0.1", "cnt": "7" },
            { "status": "501", "ip": "127.0.0.1", "cnt": "4" },
            { "status": "404", "ip": "127.0.0.1", "cnt": "4" },
            { "status": "402", "ip": "127.0.0.1", "cnt": "6" },
            { "status": "403", "ip": "127.0.0.1", "cnt": "8" }
        ],
"raw_result_count": 6,
"fire_result": {
"status": "401",
"ip": "127.0.0.1",
"cnt": "3"        },
"has_sql": true,
"truncated": false,
"role_arn": ""    }]
}

之后也可以通过如下方式来引用原始日志:

告警查询详情: {{ alert.results[0].raw_results|to_json }}

注意:

  • 如果一个告警规则有多个查询语句,那么 results 数组就会有多项,每一项对应一个查询语句。
  • results 表示的是查询语句的原始查询数据,fire_results 表示的是满足告警触发条件的数据,这两者可能会有所差别的。例如触发条件是满足 cnt > 5,那么 results[0].raw_results 结果可能是 6条,但是 fire_results 结果可能是 3条,因为只有3条记录满足 cnt > 5

模板变量引用

循环展示触发日志

上文中 {{ alert.fire_results | to_json }} 会将 fire_results 以 JSON 字符串的形式来进行展示。有时候为了展示更友好,我们会希望通过循环的方式,一行行展示触发日志,此时可以通过循环来实现,例如:

{%-forresultinalert.fire_results%}
-status: {{ alert.status }}, count: {{ alert.cnt }}
{%-endfor%}

更多相关信息,可以参考 内容模板语法(新版)

通过模板函数进行数据处理

如果需要对告警的字段进行一些格式化或者处理后再展示,可以通过内置函数来实现。具体可以参考:

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
26天前
|
Kubernetes Ubuntu Windows
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
|
8天前
|
Java
日志框架log4j打印异常堆栈信息携带traceId,方便接口异常排查
日常项目运行日志,异常栈打印是不带traceId,导致排查问题查找异常栈很麻烦。
|
10天前
|
开发者 Python
基于Python的日志管理与最佳实践
日志是开发和调试过程中的重要工具,然而,如何高效地管理和利用日志常常被忽略。本文通过Python中的logging模块,探讨如何使用日志来进行调试、分析与问题排查,并提出了一些实际应用中的优化建议和最佳实践。
|
18天前
|
存储 监控 数据可视化
SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
【9月更文挑战第2天】SLS 虽然不是直接使用 OSS 作为底层存储,但它凭借自身独特的存储架构和功能,为用户提供了一种专业、高效的日志服务解决方案。
50 9
|
25天前
|
JSON Java fastjson
Java日志通关(五) - 最佳实践
作者日常在与其他同学合作时,经常发现不合理的日志配置以及五花八门的日志记录方式,后续作者打算在团队内做一次Java日志的分享,本文是整理出的系列文章第五篇。
|
26天前
|
开发框架 .NET Docker
【Azure 应用服务】App Service .NET Core项目在Program.cs中自定义添加的logger.LogInformation,部署到App Service上后日志不显示Log Stream中的问题
【Azure 应用服务】App Service .NET Core项目在Program.cs中自定义添加的logger.LogInformation,部署到App Service上后日志不显示Log Stream中的问题
|
19天前
|
API C# 开发框架
WPF与Web服务集成大揭秘:手把手教你调用RESTful API,客户端与服务器端优劣对比全解析!
【8月更文挑战第31天】在现代软件开发中,WPF 和 Web 服务各具特色。WPF 以其出色的界面展示能力受到欢迎,而 Web 服务则凭借跨平台和易维护性在互联网应用中占有一席之地。本文探讨了 WPF 如何通过 HttpClient 类调用 RESTful API,并展示了基于 ASP.NET Core 的 Web 服务如何实现同样的功能。通过对比分析,揭示了两者各自的优缺点:WPF 客户端直接处理数据,减轻服务器负担,但需处理网络异常;Web 服务则能利用服务器端功能如缓存和权限验证,但可能增加服务器负载。希望本文能帮助开发者根据具体需求选择合适的技术方案。
54 0
|
19天前
|
C# Windows 监控
WPF应用跨界成长秘籍:深度揭秘如何与Windows服务完美交互,扩展功能无界限!
【8月更文挑战第31天】WPF(Windows Presentation Foundation)是 .NET 框架下的图形界面技术,具有丰富的界面设计和灵活的客户端功能。在某些场景下,WPF 应用需与 Windows 服务交互以实现后台任务处理、系统监控等功能。本文探讨了两者交互的方法,并通过示例代码展示了如何扩展 WPF 应用的功能。首先介绍了 Windows 服务的基础知识,然后阐述了创建 Windows 服务、设计通信接口及 WPF 客户端调用服务的具体步骤。通过合理的交互设计,WPF 应用可获得更强的后台处理能力和系统级操作权限,提升应用的整体性能。
42 0
|
19天前
|
SQL 数据库 Java
Hibernate 日志记录竟藏着这些秘密?快来一探究竟,解锁调试与监控最佳实践
【8月更文挑战第31天】在软件开发中,日志记录对调试和监控至关重要。使用持久化框架 Hibernate 时,合理配置日志可帮助理解其内部机制并优化性能。首先,需选择合适的日志框架,如 Log4j 或 Logback,并配置日志级别;理解 Hibernate 的多级日志,如 DEBUG 和 ERROR,以适应不同开发阶段需求;利用 Hibernate 统计功能监测数据库交互情况;记录自定义日志以跟踪业务逻辑;定期审查和清理日志避免占用过多磁盘空间。综上,有效日志记录能显著提升 Hibernate 应用的性能和稳定性。
28 0
|
21天前
|
存储 消息中间件 监控
Java日志详解:日志级别,优先级、配置文件、常见日志管理系统ELK、日志收集分析
Java日志详解:日志级别,优先级、配置文件、常见日志管理系统、日志收集分析。日志级别从小到大的关系(优先级从低到高): ALL < TRACE < DEBUG < INFO < WARN < ERROR < FATAL < OFF 低级别的会输出高级别的信息,高级别的不会输出低级别的信息

热门文章

最新文章

相关产品

  • 日志服务