《日志管理与分析》读书笔记

316 阅读14分钟

序言

日志是非结构化的数据,不适合使用数据库来进行处理。

IT运维管理-->IT运维分析

日志(日志、网络日志、应用性能日志)

hadoop大数据分析框架-->spark-->flink

日志搜索引擎,更加注重实时性

日志分析=业务的可用性分析、应用性能的分析、安全分析、实时业务分析

人工智能+运维=aiops

第1章 走进日志

日志记录过多会影响设备的性能,日志记录和存储均要占用相应的资源。

良好的日志记录会为运维人员的后续工作提供便利。

日志挖掘的价值

tail -f /var/log/messages

什么是日志?日志就是程序运行过程中记录下来的一些运行信息。

非结构化日志-->清洗,生成结构化或者半结构化的日志

而日志的结构化清洗规范则主要取决于对日志的认知。不同类型的日志,其清洗的规则也是不同的。

常见的日志类型:

  1. 操作系统日志,windows、linux、aix、unix系统日志;
  2. 网络设备日志,防火墙日志,交换机日志,路由器日志,IPS,IDS日志;
  3. 中间件日志,weblogic,tomcat,apache,nginx等应用日志;
  4. 数据库日志,mysql,oracle,sql server等数据库日志
  5. 数据库数据,数据库的数据也可以当做日志进行采集。
  6. 业务系统日志,
  7. 消息队列日志,kafka,flume等日志。
  8. 服务器性能日志
  9. 操作命令历史记录
  10. 监控软件日志

不同的设备,日志的格式不同。因此对日志数据进行清洗或格式化的时候,需要建立不同的清洗规则,而清洗规则则与日志自身的语法有关。

日志的语法:因吹斯汀,日志也有语法。

语法是什么?语法是某种规范。

一个日志通常由若干个字段组成,这些字段包括:

(1)时间戳

(2)日志条目的类型?info/debug?

(3)产生该日志的系统或应用

(4)日志的严重性、优先级或重要性。

(5)与该日志相关的操作者或用户。

(6)日志正文(用户操作行为、程序调用结果等)

nginx日志-->正则表达式解析

日志解析就是将日志根据格式进行字段抽取并转换为结构化数据的过程,日志解析是数据清洗的方式之一。

建立标注化的日志管理规范,将促进企业日志分析实现流程化、标准化。

日志管理规范化,包括日志生成规范化、日志输出规范化、日志采集规范化和日志存储规范化。

规范化,标准化,流程化

云日志分析平台

根据使用目的,可以对不同模块的日志进行不同方式的处理。例如,对访问日志进行流计算,以实现实时监控;对操作日志进行索引,以实现性能查询;对重要日志进行备份存档等。

流计算和实时监控挂钩。

业务分析=指标分析、场景分析、关联分析、报表分析、智能运维

第2章 日志管理

法律、要求、问题、好处、归档的内容

法律:日志留存不少于6个月

统一日志输出规范:所内的iap文档

日志归档:根据不同的数据特性和要求对日志数据进行区别化管理,同时考虑数据时间价值评估及存储成本。

日志归档有以下要求:

(1)可以设置冷、热数据索引;

(2)日志打标签

(3)日志压缩

(4)日志恢复

(5)多路径存储

(6)自动删除超期归档的日志

第3章 日志管理与分析系统

日志采集:日志推送与日志拉取

日志推送,在采集端装agent,这样的做的好处(1)控制发送速率(2)可以压缩后在发送,节省流量。

日志拉取在生产环境中很少采用。

grep

awk

tail

head

sed

常见的开源方案为ELK,es+kafka+logstash

2是flume+kafka+storm

商业软件:splunk、日志易

第4章 日志采集

推和拉

拉的局限性比较大,本身消费端就很耗资源,还要再这样。另外如果在生产端主动推的话,可以进行灵活的配置。

常见的开源日志采集agent如logstash、filebeat等

使用agent的方式进行日志采集,需要注意:

  1. 使用低权限的用户账号启动,对采集的日志只需要只读权限
  2. 少占系统资源,日志是个旁路系统,在系统资源紧张的情况下, 宁可暂停日志的采集。
  3. 少用执行脚本功能?
  4. 少依赖系统底层库?

syslog

  1. syslog是Linux系统自带的服务,在linux系统中,最常见的日志收集方式就是syslog。一般情况下,syslog只用于系统日志。
  2. syslog默认的发送方式是UDP,这种方式有丢失日志的风险。
  3. 需要根据日志量的大小调整发送的缓冲区,如果缓冲区满了,也会丢失日志。
  4. 如果每条日志超过4KB,则必须使用TCP方式发送。

抓包:在交换机端口上配置镜像流量,将此流量引流到一个专用的硬件设备上,此硬件设备专门用来解析流量。

业务埋点采集:在应用特定的流程中注入代码,以便收集该流程的相关信息。埋点一般收集两个内容:用户的访问情况和用户的操作行为。一般用于跟踪应用的使用状况,以便持续优化产品或为运营提供数据支撑。

埋点有两种方式:1.自行代码注入;2.使用第三方工具。

Docker日志采集,

Docker的实现原理是多进程+进程隔离。

Docker Daemon父进程启动容器子进程,可以收集到子进程的日志,但是收集不到子进程的子进程的日志。

使用k8s管理容器,启动业务进程时,先启动pod(容器管理进程),再启动相关容器,容器上一般运行有业务进程。由于pod的存在,无法收集业务进程所产生的日志信息。

这样的解决办法有两种: 1. 通过docker api进行采集;2. 将业务进程的日志文件挂载出来,然后通过采集文件的方式进行日志采集。

大日志文件,在查询或读取日志时会消耗较多的资源,一般会对超过一定大小的日志文件进行切分。

可以按大小进行切分,也可以按时间进行切分。

日志文件顺序采集机制:为什么日志一定要顺序采集?因为日志的发生时间其实对我们来说很有意义。

事件和事务的区分,一个事务并不一定是单条日志,通常将整个业务流程(开启、处理、结束)视为一个事务。

发送事务日志:

好处:

  1. 做了事件合并;2.对运维人员更加友好。

坏处:

  1. 单条日志过大,后端处理系统压力较大。
  2. agent需要等待一个事务发送完才能发送下一条日志,导致agent发送效率会降低。agent对系统的资源消耗会增加。
  3. 事务的id,要在同一个事务的所有事件日志中初心,要有可串联,而且不能与其他事务的标识重复,这需要日志的规范性来进行介入处理。

高并发日志采集

日志轮转access.log变成了access.log.1.

  1. 可以采集日志轮转完毕之后的文件,这样可以保证日志没有遗漏,但是这样也有一个缺陷,就是没办法采集最新的日志,采集会存在延迟。

日志采集的一些问题:

  1. 事务日志
  2. 高并发采集,日志轮转问题
  3. 深层次目录采集
  4. 大量小文件日志采集

深层次目录会导致agent轮询一个文件时遍历很多层的目录,非常消耗性能。这时候agent的瓶颈在cpu上,因为每次扫描需要遍历整个目录。

对于这种问题,可以通过软链接的方式解决,将当前目录下的文件定时软链接到一个浅目录中,让agent只采集这个浅目录下的内容。

3和4的问题都是让agent浪费在了轮询扫描上,卡在了cpu瓶颈上,解决这个最根本的方法就是规范日志输出,不要让应用系统产生深层次目录和大量小文件的日志。

压缩、加密、限流、汇聚跨网传输

第5章 字段解析

字段解析=把日志中的字段提取出来并进行分析。

字段解析是日志分析的重要步骤,也是众多其他日志处理方法的前提。

日志中的内容都可以通过字段被提取出来。这个有点像态感上面的划词提取字段。

日志中的通用字段

  1. 时间戳

T后面代表时间,Z代表0时区,也成为UTC时间,UTC时间和英国伦敦本地时间相同,大概比北京时间慢了8个小时。 UTC时间比北京时间慢了8个小时。

一般计算机中用的就是UTC时间。

  1. 日志来源

推送日志来源的主要有syslog、snmp、windows等

拉取日志来源有checkpoint防火墙、mysql数据库日志等

  1. 执行结果,表示系统活动是成功还是失败。
  2. 日志优先级

log4j定义了8种日志级别,从高到低为 off、fatal、error、warn、info、debug、trace、all。

debug,开发过程中进行调试使用。

info,突出强调应用程序的运行过程。

warn,表现会出现潜在错误的情形。

error,虽然发送错误事件,但不影响系统继续运行。

fatal,某个严重的错误事件将导致应用程序退出,级别比较高。

off,最高级别,用于关闭所有日志记录。

当解析某个级别的日志时,比该级别高的所有日志也会被解析出来,也在输出范围内。

字段抽取是字段解析的第一个步骤

字段抽取和日志的语法紧密绑定,不同的日志有不同的语法

字段抽取:

  1. 简单的,根据起始位置+终止位置来进行提取;
  2. 用正则表达式来进行提取,正则表达式描述了一种字符串匹配模式,可以用来检查某个字符串中是否有某种子串,并将匹配的子串替换或抽取出来。
  3. 含义解析
  4. key-value解析
  5. 多种方法相结合

常见日志类型的字段抽取

  1. Apache
  2. nginx
  3. log4j
  4. json
  5. mysql
  6. linux

针对常见的日志类型,其实是有默认的正则表达式可以用来借鉴的。

schema on write与schema on read

日志采集过来之后,先存储再解析(schema on read),还是先解析再存储(schema on write)。

基于schema on read,可以根据具体需求,结合一些分析工具如hive,spark等,对数据做一些处理。

第6章 日志存储

日志的存储形式、方式、物理存储、存储策略、搜索引擎

日志的存储形式:普通文本,二进制文本,压缩文本,加密文本

syslog是一种应用广泛的日志存储格式,是许多系统(如linux、unix)的标准日志记录格式

mysql二进制日志文件主要记录修改数据或可能引起数据变更的mysql语句,用于数据库恢复、主从复制、审计等操作。

日志压缩,算法有gzip算法、bz2算法,其中bz2算法支持分片,可以结合mapreduce提升压缩效率。

java程序,AES算法。

日志存储,存到数据库中,或者存到分布式存储hadoop中。

hadoop,分布式文件系统,HDFS,一次写入,多次读取,流式访问,

namenode和datanode,namenode是一个中心服务器

namenode负责管理,datanode负责处理客户端的读写请求,在namenode的统一调度下进行数据块的创建、删除和复制。

文件检索系统,倒排索引,以前是有文件id找word关键字(正向索引),现在使用word关键字来寻找文件id(反向索引,倒排索引)。倒排索引,又成反向索引。既有反向索引,又有正向索引。

日志以文件的形式进行存储,如何在大量文件汇总进行快速高效的搜索

倒排索引,由关键字word来反查文件id。倒排索引是实现单词到文档映射关系的最佳方式和最有效的索引结构。

es就是基于倒排索引的。

倒排索引查起来很快,并发也很高,但是创建索引的过程会比较久一些

相当于是以空间换时间。

文档-->分词-->

倒排索引由单词词典倒排列表组成,单词词典由B+树实现,倒排列表记录单词余文档的对应关系。

云存储,分为公有云、私有云、混合云

公有云计算能力强,私有云安全性高,混合云则结合了二者的优点。

日志的物理存储

在线存储、近线存储、离线存储

日志留存策略

空间策略维度

时间策略维度

起始位移策略维度

日志搜索引擎

实时搜索引擎:ES

缓存、磁盘、reflush

存储数据到磁盘,但是中间是有一个缓存的,提供了reflush机制,和磁盘做一个同步。

第7章 日志分析

从事日志分析工作需要丰富的知识储备,安全知识、网络知识、系统运维知识、业务运维知识、业务逻辑知识、统计学知识。

日志分析的最大难点是日志格式不统一

国内做到既懂业务、安全、运维,又了解日志的专业人才非常少。

linux系统secure日志,在linux中,用户变更、提权、登录等安全事件会被记录在secure日志中。

(1)能否使用root

(2)是否堡垒机登录

(3)是否非工作时间登录

(4)是否新用户or僵尸用户

日志分析看似是技术问题,实际上是管理问题。

第8章 日志告警

监控和告警的关系

监控产生告警

Crontab定时任务

日志的查询时间区间,一般为左闭右开

监控设置:(可以用这个来梳理态势感知现有的监控策略

(1)检测频率

(2)目标日志

(3)查询语句

(4)时间区间

(5)触发条件

等有时间了对照着态势把这个做一下

告警监控对日志的查询,归根结底是对某些关键字或关键词出现情况的统计,

统计分析经常建立在对日志进行解析(正则解析)并提取所需目标字段的基础上

日志-->正则解析-->提取字段-->统计分析-->告警监控。

告警监控其实就是对日志进行统计分析

对日志进行统计分析,又依赖于对日志进行的先行处理(正则解析、字段提取)

统计形成指标,从而和阈值进行对比

8.2 监控设置,这个其实就是告警策略。

第9章 日志可视化

比较关系

分布关系

构成关系

联系关系

第10章 日志平台兼容性与扩展性

API设计理念,RESTful API

定义一套数据接入和解析规范,基于这套规范开发的应用可与日志系统无缝对接,做到即插即用。

RESTful表现层状态转换,用一个类型URL请求的形式对资源进行操作,

URL+GET/POST/DELETE/PUT/PATCH

RESTful是基于HTTP协议的,而HTTP协议是无状态的,

第11章 智能运维

文本内容

时序内容

业务指标

系统指标

单指标

多指标

周期性指标

非周期性指标

这章的内容基本上全是算法

第12章 SIEM

安全信息和事件管理

日志就是对应“发现”最重要的基础

12.6 SIEM适用场景,这个里面讲的全部是安全场景,可以对照着日常工作来看。

安全事件的基本属性 ( 可以用这个来分析事件报告

  1. 发生时间
  2. 持续时间
  3. 发生频率
  4. 事件类型
  5. 影响范围
  6. 攻击结果
  7. 上下文