日志系统（日志采集系统）

2023-09-20 阅读 11 评论 0

摘要：本篇文章给大家谈谈日志系统，以及日志采集系统对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。Linux系统日志子系统详解在Linux系统中，有三个主要的日志子系统：连接时间日志--由多个程序执行，把纪录写入到/var/log/wtmp和/var/run/utmp，login等程序更新wtmp和utmp文件，使系统管理员能够跟踪谁在何时登录到系统。进程统计--由系统内核执行。当一个进程终

本篇文章给大家谈谈日志系统，以及日志采集系统对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

Linux系统日志子系统详解

在Linux系统中，有三个主要的日志子系统：

连接时间日志--由多个程序执行，把纪录写入到/var/log/wtmp和/var/run/utmp，login等程序更新wtmp和utmp文件，使系统管理员能够跟踪谁在何时登录到系统。

进程统计--由系统内核执行。当一个进程终止时，为每个进程往进程统计文件（pacct或acct）中写一个纪录。进程统计的目的是为系统中的基本服务提供命令使用统计。

错误日志--由syslogd（8）执行。各种系统守护进程、用户程序和内核通过syslog（3）向文件/var/log/messages报告值得注意的事件。另外有许多Unix程序创建日志。像HTTP和FTP这样提供网络服务的服务器也保持详细的日志。

常用的日志文件如下：

Access-log纪录HTTP/web的传输

acct/pacct纪录用户命令

aculog纪录MODEM的活动

btmp纪录失败的纪录

lastlog 纪录最近几次成功登录的事件和最后一次不成功的登录

messages从syslog中记录信息（有的链接到syslog文件）

sudolog 纪录使用sudo发出的命令

sulog 纪录使用su命令的使用

syslog从syslog中记录信息（通常链接到messages文件）

utmp纪录当前登录的每个用户

wtmp一个用户每次登录进入和退出时间的永久纪录

xferlog 纪录FTP会话

utmp、wtmp和lastlog日志文件是多数重用Unix日志子系统的关键--保持用户登录进入和退出的纪录。有关当前登录用户的信息记录在文件utmp中；登录进入和退出纪录在文件wtmp中；最后一次登录文件可以用lastlog命令察看。数据交换、关机和重起也记录在wtmp文件中。所有的纪录都包含时间戳。这些文件（lastlog通常不大）在具有大量用户的系统中增长十分迅速。例如wtmp文件可以无限增长，除非定期截取。许多系统以一天或者一周为单位把wtmp配置成循环使用。它通常由cron运行的脚本来修改。这些脚本重新命名并循环使用wtmp文件。通常，wtmp在第一天结束后命名为wtmp.1；第二天后wtmp.1变为wtmp.2等等，直到wtmp.7。

每次有一个用户登录时，login程序在文件lastlog中察看用户的UID。如果找到了，则把用户上次登录、退出时间和主机名写到标准输出中，然后login程序在lastlog中纪录新的登录时间。在新的lastlog纪录写入后，utmp文件打开并插入用户的utmp纪录。该纪录一直用到用户登录退出时删除。utmp文件被各种命令文件使用，包括who、w、users和finger。

下一步，login程序打开文件wtmp附加用户的utmp纪录。当用户登录退出时，具有更新时间戳的同一utmp纪录附加到文件中。wtmp文件被程序last和ac使用。

具体命令

wtmp和utmp文件都是二进制文件，他们不能被诸如tail命令剪贴或合并（使用cat命令）。用户需要使用who、w、users、last和ac来使用这两个文件包含的信息。

who：who命令查询utmp文件并报告当前登录的每个用户。Who的缺省输出包括用户名、终端类型、登录日期及远程主机。例如：who（回车）显示

chyangpts/0 Aug 18 15:06

ynguo pts/2 Aug 18 15:32

ynguo pts/3 Aug 18 13:55

lewis pts/4 Aug 18 13:35

ynguo pts/7 Aug 18 14:12

yloupts/8 Aug 18 14:15

如果指明了wtmp文件名，则who命令查询所有以前的纪录。命令who /var/log/wtmp将报告自从wtmp文件创建或删改以来的每一次登录。

w：w命令查询utmp文件并显示当前系统中每个用户和它所运行的进程信息。例如：w（回车）显示：3:36pm up 1 day, 22:34, 6 users, load *** erage: 0.23, 0.29, 0.27。

USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT

chyang pts/0 202.38.68.242 3:06pm 2:04 0.08s 0.04s -bash

ynguo pts/2 202.38.79.47 3:32pm 0.00s 0.14s 0.05 w

lewis pts/3 202.38.64.233 1:55pm 30:39 0.27s 0.22s -bash

lewis pts/4 202.38.64.233 1:35pm 6.00s 4.03s 0.01s sh /home/users/

ynguo pts/7 simba.nic.ustc.e 2:12pm 0.00s 0.47s 0.24s telnet mail

ylou pts/8 202.38.64.235 2:15pm 1:09m 0.10s 0.04s -bash

users：users用单独的一行打印出当前登录的用户，每个显示的用户名对应一个登录会话。如果一个用户有不止一个登录会话，那他的用户名将显示相同的次数。例如：users（回车）显示：chyang lewis lewis ylou ynguo ynguo

last：last命令往回搜索wtmp来显示自从文件第一次创建以来登录过的用户。例如：

chyang pts/9202.38.68.242 Tue Aug 1 08:34 - 11:23 (02:49)

cfan pts/6202.38.64.224 Tue Aug 1 08:33 - 08:48 (00:14)

chyang pts/4202.38.68.242 Tue Aug 1 08:32 - 12:13 (03:40)

lewis pts/3 202.38.64.233 Tue Aug 1 08:06 - 11:09 (03:03)

lewis pts/2 202.38.64.233 Tue Aug 1 07:56 - 11:09 (03:12)

如果指明了用户，那么last只报告该用户的近期活动，例如：last ynguo（回车）显示：

ynguopts/4 simba.nic.ustc.e Fri Aug 4 16:50 - 08:20 (15:30)

ynguopts/4 simba.nic.ustc.e Thu Aug 3 23:55 - 04:40 (04:44)

ynguopts/11 simba.nic.ustc.e Thu Aug 3 20:45 - 22:02 (01:16)

ynguopts/0 simba.nic.ustc.e Thu Aug 3 03:17 - 05:42 (02:25)

ynguopts/0 simba.nic.ustc.e Wed Aug 2 01:04 - 03:16 1+02:12)

ynguopts/0 simba.nic.ustc.e Wed Aug 2 00:43 - 00:54 (00:11)

ynguopts/9 simba.nic.ustc.e Thu Aug 1 20:30 - 21:26 (00:55)

ac：ac命令根据当前的/var/log/wtmp文件中的.登录进入和退出来报告用户连结的时间（小时），如果不使用标志，则报告总的时间。例如：ac（回车）显示：total 5177.47

分布式日志系统Graylog、Loki及ELK的分析和对比

日志系列：

企业级日志平台新秀Graylog，比ELK轻量多了

日志系统新贵Loki，比ELK轻量多了

1. 为什么需要集中的日志系统？

在分布式系统中，众多服务分散部署在数十台甚至是上百台不同的服务器上，要想快速方便的实现查找、分析和归档等功能，使用Linux命令等传统的方式查询到想要的日志就费时费力，更不要说对日志进行分析与归纳。

如果有一个集中的日志系统，便可以将各个不同的服务器上面的日志收集在一起，不仅能方便快速查找到相应的日志，还有可能在众多日志数据中挖掘到一些意想不到的关联关系。

作为DevOps工程师，会经常收到分析生产日志的需求。在机器规模较少、生产环境管理不规范时，可以通过分配系统账号，采用人肉的方式登录服务器查看日志。然而高可用架构中，日志通常分散在多节点，日志量也随着业务增长而增加。当业务达到一定规模、架构变得复杂，靠人肉登录主机查看日志的方式就会变得混乱和低效。解决这种问题的方法，需要构建一个日志管理平台：对日志进行汇聚和分析，并通过Web UI授权相关人员查看日志权限。

2. 日志系统选择与对比

关于企业级日志管理方案，比较主流的是ELK stack和Graylog。

常见的分布式日志系统解决方案有经典的ELK和商业的splunk。为什么没有选择上面的两种方案呢，原因主要是如下两种：

ELK目前很多公司都在使用，是一种很不错的分布式日志解决方案，但是需要的组件多，部署和维护相对复杂，并且占用服务器资源多，此外kibana也在高版本中开始商业化。

splunk是收费的商业项目，不在考虑范围。

3. 认识graylog

3.1 简介

graylog是一个简单易用、功能较全面的日志管理工具，graylog也采用Elasticsearch作为存储和索引以保障性能，MongoDB用来存储少量的自身配置信息，master-node模式具有很好的扩展性，UI上自带的基础查询与分析功能比较实用且高效，支持LDAP、权限控制并有丰富的日志类型和标准（如syslog，GELF）并支持基于日志的报警。

在日志接收方面通常是网络传输，可以是TCP也可以是UDP，在实际生产环境量级较大多数采用UDP，也可以通过MQ来消费日志。

3.2 优势

部署维护简单

资源占用较少

查询语法简单易懂(对比ES的语法…)

内置简单的告警

可以将搜索结果导出为 json

UI 比较友好

3.3 graylog单机架构图

3.4 graylog集群架构

4、基于 GrayLog ELK 的日志监控

Collector

FileBeat：轻巧占用资源少，但是功能有点弱。「想起了一些东西，都是泪」

Fluentd：个人理解在Logstash与FileBeat中间，可以简单处理一些日志，插件丰富「要再研究下」

自己弄：架构图里面只是mysql调用了自己实现的解析工具，但是其实当日志大到一定的量的还是必须自己来的，类似日志抽样、降级、控制频率等功能，是要真真切切的花费大量时间精力下去的一个sidecar并非动动嘴巴就能搞定的。「都是泪」

Queue

Kafka：王者地位「量小的时候也可以不用这个直接朝后面输出，有很多中间方案大家自己脑补」，不同的日志分不同的topic，严格区分日志所属类型，为后续消费打下基础，比如A业务进入A Topic并在日志中打上所属语言类型的Tag。

Consumer

Logstash：其实这个东西也可以作为收集端来使用，就是比较耗费资源有点重，还会莫名其妙挂了「应该是我不会玩」

GrayLog：本人最喜欢的一个组件，集解析、报警、简单分析、Dashboard、日志TTL的综合体，有这个东西吧其实Kibana就没啥用了，毕竟谁没事天天去分析日志。

Storage

ElasticSearch：全文索引Engine，其实并没有官方说的那么牛，当到一定的并发写入、大量查询之后其实根本不是加机器能解决的，怎么分shard，是按照天保存还是按照条数保存「我比较喜欢按照条数保存，这样可以保证每个index都差不多大小，对于reblance是有好处的，重复利用多盘」如何保存是需要不断调整的。「我们这边不讨论MongoDB去存日志，看着都不靠谱」

规范

其实日志系统最关键的是怎么打、什么格式打、但是这个东西需要消耗大量的时间去定义与各个部门Pk，遇到过大量不讲理的输出，直接线上Debug，600k的并发写入，日志又大又臭谁能扛得住「阿里云的SLS是真的很牛」

卷起袖子加油干，少动嘴，多动手，日志很好玩。在容器化的大环境下也越发的重要。

Flunted + Elasticsearch + Kibana的方案，发现有几个缺点：

不能处理多行日志，比如Mysql慢查询，Tomcat/Jetty应用的J *** a异常打印

不能保留原始日志，只能把原始日志分字段保存，这样搜索日志结果是一堆Json格式文本，无法阅读。

不符合正则表达式匹配的日志行，被全部丢弃。

对比图

总结

虽然两种解决方案在功能上非常相似，但仍有一些差异需要考虑。

两者之间最重要的区别在于，从一开始，Graylog就 *** 为强大的日志解决方案，而ELK则是大数据解决方案。Graylog可以通过网络协议直接从应用程序接收结构化日志和标准syslog。相反，ELK是使用Logstash分析已收集的纯文本日志的解决方案，然后解析并将它们传递给ElasticSearch。

在ELK中，Kibana扮演仪表盘的角色并显示从Logstash收到的数据。Graylog在这点上更方便，因为它提供了单一应用程序解决方案（不包括ElasticSearch作为灵活的数据存储），具有几乎相同的功能。因此，部署所需的时间更短。此外，与ELK相比，Graylog开箱即用，且具有出色的权限系统，而Kibana则不具备此功能。作为Elasticsearch的粉丝，我更喜欢Graylog而不是ELK，因为它完全符合我在日志管理方面的需求。

Graylog具有直观的GUI，并提供警报、报告和自定义分析功能。最重要的是，它能在多个日志源和跨机房收集数TB的数据。基于这些优势，我更喜欢用Graylog而不是另一个具有类似功能的流行堆栈——ELK。

如果有需要领取免费资料的小伙伴们，可以点击此处领取资料哦！

Logback日志系统

logback的易用性不用多讲，只需要通过下面两行就可以在console中输出日志：

程序运行时，logback会查找默认的配置文件logback.xml或者logback-test.xml文件，如果没有找到它就会使用默认的配置，将日志打印到console中。下面是一个配置文件示例：

在多数的Log工具中，级别是可以传递，例如如果指定了日志输出级别为DEBUG，那么INFO、ERROR级别的log也会出现在日志文件。这种默认给程序的调试带来了很多的麻烦。而在logback中可以通过 *** ender中的filter来严格限制日志的输出级别：

有时候一个类中可能要求打印不同的日志信息，例如有的用来调试，有的用来记录程序运行中的某些参数的变化等等。这时候可以通过下面的语句声明不同的日志：

在程序调试中，经常出现的情况是：错误只在某一个或者几个类或者包里，所以只需要打开这几个类或者包里的DEBUG级别的log。在以前的项目，使用spring和hibernate时，一旦打开DEBUG级别的log，程序本身的debug信息就会被Spring和Hibernate的大量日志淹没，大大降低了调试的效率。而logback让这一切变的简单起来了：