日志服务(SLS)初体验:采集、加工、查询分析及可视化

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 日志服务(SLS)是阿里集团自研的一站式日志平台,它包含数据实时采集、数据加工、智能查询分析以及数据分发四大基础功能,用户无需开发就能能够开箱即用地使用它来提升运维、运营效率,建立 DT 时代海量日志处理能力。为了让大家对日志服务有更直观的感受,本文将带着大家体验一下这些基础功能,以最常见的 Linux Syslog 作为对象,看看如何简单快速地实现对它的采集、加工、查询分析以及可视化。

日志服务(SLS)是阿里集团自研的一站式日志平台,它包含数据实时采集、数据加工、智能查询分析以及数据分发四大基础功能,用户无需开发就能能够开箱即用地使用它来提升运维、运营效率,建立 DT 时代海量日志处理能力。

为了让大家对日志服务有更直观的感受,本文将带着大家体验一下这些基础功能,以最常见的 Linux Syslog 作为对象,看看如何简单快速地实现对它的采集、加工、查询分析以及可视化。

Linux Syslog

Syslog 是 Unix 类操作系统上非常常见的一种日志,广泛应用于系统日志,但同样可作为应用输出日志的一种形式。在许多 Linux 发行版上,部分 Syslog 默认会被存放在本地目录 /var/log/ 中,其中包含 messageskernsecure 等多个分别用于存放不同类似日志的文件。

本文将以最常见的 /var/log/messages 作为实验目标,以下是一些示例日志:

# OOM 日志
[ 1074.669060] Out of memory: Kill process 20680 (perl) score 487 or sacrifice child
[ 1074.669089] Killed process 20680 (perl), UID 0, total-vm:1072528kB, anon-rss:943192kB, file-rss:0kB, shmem-rss:0kB

# 应用日志
Mar 16 12:04:08 clusterx-master systemd: Removed slice libcontainer_8947_systemd_test_default.slice.
Mar 16 12:04:08 clusterx-master systemd: Scope libcontainer-8952-systemd-test-default-dependencies.scope has no PIDs. Refusing.

# 登录日志(特殊应用)
Mar 13 12:29:25 clusterx-master sshd[13501]: Accepted publickey for root from 192.168.56.1 port 64934 ssh2: RSA SHA256:W8j/QK8kV0Ab8/yTENQko8
Mar 13 12:29:25 clusterx-master sshd[13501]: pam_unix(sshd:session): session opened for user root by (uid=0)
Mar 13 13:19:08 clusterx-master sshd[13501]: Received disconnect from 192.168.56.1 port 64934:11: disconnected by user
Apr 16 20:00:50 clusterx-master sshd[718]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.56.1  user=root
Apr 16 20:00:52 clusterx-master sshd[718]: Failed password for root from 192.168.56.1 port 54469 ssh2: RSA SHA256:W8j/QK8kV0Ab8/yTENQko8

数据实时采集

首先,我们需要实现对这些日志的采集。由于系统日志需要外部事件触发,产生时机不太确定,因此,我们针对上述的示例日志编写了一个生成器以保证实验过程持续有日志产生。

在机器上运行生成器,即会不断地有日志输出到文件 /var/log/mock_messages

$ mkdir mock-syslog; cd mock-syslog
$ wget http://baoze-oss-bj.oss-cn-beijing.aliyuncs.com/mock-syslog/raw_data
$ wget http://baoze-oss-bj.oss-cn-beijing.aliyuncs.com/mock-syslog/mock_messages.py
$ chmod +x mock_messages.py
$ nohup ./mock_messages.py /var/log/mock_messages &
$ tail /var/log/mock_messages

为了存放日志,我们需要先开通日志服务,并在控制台上创建相应的 project/logstore,过程可参考快速入门中的步骤 1。对于文本日志,我们可通过 SLS 自研的采集 agent Logtail 来实现采集。

操作步骤如下:

  1. 创建 Logtail 采集配置,选择【单行-文本日志】

  1. 在机器上安装 logtail,对于 ECS 机器,可直接在控制台上进行勾选,点击【立即执行】后即可完成安装
  2. 安装完成后,勾选机器 IP 会被自动加入到机器组列表中,在填写名称后即可完成创建机器组创建
  3. 填写配置
  4. 跟随向导完成配置,点击【立即尝试】进入查询界面

数据查询

进入查询界面后,只需稍等一会儿,待采集配置下发到 logtail 后,即可通过点击【查询/分析】按钮浏览日志内容。借助 SLS 针对日志的极致优化,我们可以通过关键词快速地从海量日志中查询我们感兴趣的日志。比如:

通过关键词 sshd 查询登录日志

通过关键词 Out of memory 查询 OOM 日志

除了基础的关键字查询外,SLS 还提供了 and/or/not 等谓词进行组合查询(文档),能够满足更为丰富的查询场景。

数据加工

在完成数据的采集和查询后,我们会发现,因为日志是单行采集上来的,日志的所有内容都被放在了单一的 content 字段中,相对来说会比较混乱。在这种情况下,我们很难对日志的内容进行进一步地分析,比如有哪些应用输出了系统日志、最近一天是否有应用发生 OOM、发生次数等等。

假设我们期望通过分析日志来得到以下信息:

  1. 哪些进程产生了系统日志,分别产生了多少?如果产生了较多日志的话,可能说明应用存在一些异常?
  2. 其中的哪些应用发生过 OOM ?频繁 OOM 的应用需要得到关注。
  3. 仅查看进程 sshd 产生的登录日志,检查短时间内是否有较多的密码登录失败(可能是入侵攻击)?如果有,IP 和端口是什么?

如果要完成上述需求,从数据分析的角度来说,我们需要识别出:

  • 每条日志所属的进程名
  • 哪些日志是 OOM 日志
  • 哪些日志是 sshd 密码登录失败?

通过数据加工,我们可以非常简单地完成上述需求,通过增加额外的字段来标记对需要识别的内容。

1. 标记 OOM 日志

[ 1074.669060] Out of memory: Kill process 20680 (perl) score 487 or sacrifice child
[ 1074.669089] Killed process 20680 (perl), UID 0, total-vm:1072528kB, anon-rss:943192kB, file-rss:0kB, shmem-rss:0kB

从示例来看,OOM 日志有两个关键字 Out of memoryKilled process,并且都包含了发生 OOM 的进程 ID 和进程名。因此,我们可以通过数据加工 DSL 中的正则提取来完成字段抽取,如下:

# 解析 oom_kill 日志
e_if(op_or(
        regex_match(v("content"), "Out of memory"),
        regex_match(v("content"), "Killed process")),
     e_compose(
         e_set("log_type", "oom_kill"),
         e_regex("content", "process (?<pid>[0-9]*) \((?<process>[a-zA-Z0-9_]*)\)")))

借助数据加工的预览功能,我们可以快速地判断上面的处理是否满足需求。

测试数据及处理逻辑

结果

可以看到,两条日志都增加了 log_type:oom_kill 的字段,并通过 processpid 两个字段记录了发生 OOM 的进程名和 PID。

2. 解析 Syslog 基本字段

虽然 Syslog 的输出格式并未严格统一,但大部分 Linux 发行版下,都由时间、主机名、进程名、可选的进程 PID 以及日志内容几部分组成,其中,最后的日志内容完全由应用定义。

为了能够分析各个应用输出日志的情况,我们可以按照上面的格式来对所有日志进行字段提取。类似地,我们借助 DSL 正则提取来实现:

# 解析 syslog 基本字段
e_regex("content", "(?<system_time>[a-zA-Z 0-9:]{15}) (?<hostname>[a-zA-Z0-9\-]*) (?<process>([a-zA-Z0-9\-]*))(\[(?<pid>[0-9]*)\])?: (?<message>.*)")

同样地,借助预览功能进行快速验证,确认日志被提取成我们所期望的 system_timehostnameprocesspidmessage 字段。

3. 丰富登录日志

从前面的示例日志我们可以知道,登录日志的 message 字段内容并不固定,不同内容向我们展示了不同信息,比如:

  • Accepted publickey 告诉我们有人成功使用密钥完成对某个用户的登录;
  • Failed password 告诉我们有人使用密码登录某个用户失败;
  • Received disconnect 告诉我们有人断开了连接。

而这些日志同时也有共性,它们记录了期望登录的用户、登录的 IP、端口等信息。基于这些特点,我们可以对 sshd 的日志进行进一步地处理,提取出这些公共字段,并根据展示内容进行特殊标记。

e_if(e_search('process=="sshd"'),
     e_compose(
         e_regex("content", grok('%{IP:ip}')),
         e_regex("content", "port (?<port>[0-9]*)"),
         e_if(regex_match(v("content"), "Received disconnect from"),
              e_set("sshd_action" , "client_disconnect")),
         e_if(regex_match(v("content"), "Failed password"),
              e_set("sshd_action" , "client_password_fail")),
         e_if(regex_match(v("content"), "Accepted publickey"),
              e_set("sshd_action" , "client_login"))
     ))

结果如下:

4. 输出到新目标

在完成了上述所有规则的调试后,我们可以把它们合并在一起,并为处理后的日志指定一个新的 logstore(命名为 processed_syslog,需要手动创建)作为输出目标。

在【加工结果页】中,点击【保存数据加工】即可将规则进行保存。

当加工任务启动后,我们就可以在新 logstore 中看到处理后的日志。

数据分析以及可视化

在借助数据加工完成数据处理后,我们就可以开始前面提到的分析工作了。SLS 提供了支持 SQL92 标准的分析语法,可以方便地支撑我们完成各类场景下的分析需求。

0. 快速创建索引

为了使用分析功能,我们首先需要对待分析的字段创建相应的索引,这一过程可以使用控制台提供的自动创建索引功能快速完成。

在创建完索引后,我们就可以使用 SQL 对先前提到的需求进行分析。

1. 分析应用日志分布

not log_type:oom_kill | select process, count(*) as c group by process order by c desc

通过上面的分析语句,我们即可得到每个进程分别输出了多少条日志,如下:

除了最基本的预览图表外,SLS 控制台提供了非常丰富的可视化能力,并且我们能够将对应的可视化图表以仪表盘的形式保存下来。比如使用饼图来呈现上面的结果:

仪表盘效果

2. 分析 OOM 应用

统计最近 10 分钟发生 OOM 的次数,并同比 10 分钟前的情况,以单值图的形式展示。

# 同环比
log_type:oom_kill | select diff[1] as today, round((diff [3] -1.0) * 100, 2) as growth from (select compare(count, 600) as diff from (select count(1) as count from log))

查看 OOM 应用分布

log_type:oom_kill and process:* | select process, count(*) as c group by process order by c desc

3. 分析登录失败 IP 分布

process:sshd and sshd_action:client_password_fail | select ip, count(*) as c group by ip order by c desc

根据 IP 获取来源地(国家)

process:sshd and sshd_action:client_password_fail | select ip_to_country(ip) as country, sum(c) as c from( select ip, count(*) as c from log group by ip order by c desc) group by country

最终仪表盘效果

更多示例

https://promotion.aliyun.com/ntms/act/logdoclist.html

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
1月前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
225 30
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
7天前
|
监控 测试技术 开发者
一行代码改进:Logtail的多行日志采集性能提升7倍的奥秘
一个有趣的现象引起了作者的注意:当启用行首正则表达式处理多行日志时,采集性能出现下降。究竟是什么因素导致了这种现象?本文将探索Logtail多行日志采集性能提升的秘密。
|
1天前
|
监控 安全 Apache
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
|
10天前
|
监控 应用服务中间件 定位技术
要统计Nginx的客户端IP,可以通过分析Nginx的访问日志文件来实现
要统计Nginx的客户端IP,可以通过分析Nginx的访问日志文件来实现
|
11天前
|
存储 监控 安全
什么是事件日志管理系统?事件日志管理系统有哪些用处?
事件日志管理系统是IT安全的重要工具,用于集中收集、分析和解释来自组织IT基础设施各组件的事件日志,如防火墙、路由器、交换机等,帮助提升网络安全、实现主动威胁检测和促进合规性。系统支持多种日志类型,包括Windows事件日志、Syslog日志和应用程序日志,通过实时监测、告警及可视化分析,为企业提供强大的安全保障。然而,实施过程中也面临数据量大、日志管理和分析复杂等挑战。EventLog Analyzer作为一款高效工具,不仅提供实时监测与告警、可视化分析和报告功能,还支持多种合规性报告,帮助企业克服挑战,提升网络安全水平。
|
1月前
|
存储 SQL 监控
|
1月前
|
运维 监控 安全
|
2月前
|
Web App开发 存储 监控
iLogtail 开源两周年:UC 工程师分享日志查询服务建设实践案例
本文为 iLogtail 开源两周年的实践案例分享,讨论了 iLogtail 作为日志采集工具的优势,包括它在性能上超越 Filebeat 的能力,并通过一系列优化解决了在生产环境中替换 Filebeat 和 Logstash 时遇到的挑战。
120 14
|
1月前
|
监控 关系型数据库 MySQL
分析慢查询日志
【10月更文挑战第29天】分析慢查询日志
38 3
|
1月前
|
监控 关系型数据库 数据库
怎样分析慢查询日志?
【10月更文挑战第29天】怎样分析慢查询日志?
35 2

相关产品

  • 日志服务