日志服务(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日志并进行多维度分析。
目录
相关文章
|
3天前
|
XML Java Maven
Spring5入门到实战------16、Spring5新功能 --整合日志框架(Log4j2)
这篇文章是Spring5框架的入门到实战教程,介绍了Spring5的新功能——整合日志框架Log4j2,包括Spring5对日志框架的通用封装、如何在项目中引入Log4j2、编写Log4j2的XML配置文件,并通过测试类展示了如何使用Log4j2进行日志记录。
Spring5入门到实战------16、Spring5新功能 --整合日志框架(Log4j2)
|
4天前
|
数据采集 监控 Kubernetes
Job类日志采集问题之iLogtail以减小容器发现和开始采集的延时如何优化
Job类日志采集问题之iLogtail以减小容器发现和开始采集的延时如何优化
|
4天前
|
数据采集 Kubernetes Java
Job类日志采集问题之在日志中添加容器的元信息标签,如何操作
Job类日志采集问题之在日志中添加容器的元信息标签,如何操作
|
4天前
|
存储 容器
Job类日志采集问题之DaemonSet采集方式的参数以减小采集延时如何调整
Job类日志采集问题之DaemonSet采集方式的参数以减小采集延时如何调整
|
4天前
|
容器
Job类日志采集问题之ECI产品采集方式对于弹性扩缩容是如何支持的
Job类日志采集问题之ECI产品采集方式对于弹性扩缩容是如何支持的
|
4天前
|
存储 数据采集 容器
Job类日志采集问题之DaemonSet采集方式在Job日志采集上如何表现
Job类日志采集问题之DaemonSet采集方式在Job日志采集上如何表现
|
4天前
|
存储 Kubernetes 数据处理
Job类日志采集问题之为什么Job容器的日志采集要考虑容器发现速度和开始采集延时,如何理解
Job类日志采集问题之为什么Job容器的日志采集要考虑容器发现速度和开始采集延时,如何理解
|
4天前
|
存储 Kubernetes Java
阿里泛日志设计与实践问题之在写多查少的降本场景下,通过SLS Scan方案降低成本,如何实现
阿里泛日志设计与实践问题之在写多查少的降本场景下,通过SLS Scan方案降低成本,如何实现
|
4天前
|
弹性计算 监控 索引
阿里泛日志设计与实践问题之SLS Scan服务的稳定性和可用性如何保证
阿里泛日志设计与实践问题之SLS Scan服务的稳定性和可用性如何保证
|
6天前
|
SQL 存储 JSON
更快更强,SLS 推出高性能 SPL 日志查询模式
从海量的日志数据中,按照各种灵活的条件进行即时查询搜索,是可观测场景下的基本需求。本文介绍了 SLS 新推出的高性能 SPL 日志查询模式,支持 Unix 风格级联管道式语法,以及各种丰富的 SQL 处理函数。同时通过计算下推、向量化计算等优化,使得 SPL 查询可以在数秒内处理亿级数据,并支持 SPL 过滤结果分布图、随机翻页等特性。
217 65

相关产品

  • 日志服务