日志系统ELK使用详解(一)--如何使用

概述

日志系统ELK使用详解(一)–如何使用
日志系统ELK使用详解(二)–Logstash安装和使用
日志系统ELK使用详解(三)–elasticsearch安装
日志系统ELK使用详解(四)–kibana安装和使用
日志系统ELK使用详解(五)–补充

当我们管理和使用的后端服务程序突破单台场景，进入到集群部署场景时，日志文件就会散落在多台后端服务器上。

这时候要查看、统计日志信息就需要到各个服务器上去取和查看，所以我们可能很想把这些日志文件归集到一个统一的地方，统一管理。

在业内常见的部署组合就是ELK系统了，ELK是elasticsearch、logstash、kibana三个系统的首字母组合。接下来的几篇博客会从整体和三个系统细分角度看ELK如何使用。

使用场景

说道日志，一般有这么几类：异常日志、请求日志、操作日志。

异常日志是大家写代码时经常看到的日志堆栈，这类日志有很多行，详细列出了异常信息、异常名称、出错的代码调用栈、内部异常原因（Caused by），是一类多行日志。

请求日志是接口的调用日志，常见的是nginx、tomcat、weblogic等负载均衡和web容器的日志，一行里面包含了访问时间、访问路径、状态码、结果大小、响应时间等信息。也有一些自定义的信息，比如SLA统计系统或者一些性能监控系统所需的日志信息，一般来说会包含请求编号、访问路径、步骤编号、响应时间等自定义的信息。

操作日志一般是用来审计或者结果追踪的信息，这类信息一般会专门的做统一存储，这类日志也比较重要，一般用数据库专门存储。

在ELK使用的场景中，多见的是对异常日志和请求日志的统一处理。

然而，由于请求日志一般来说生成的速度比较快。是至少相当于系统访问量，通常大于访问量，因为日志记录大多还会记录系统下游接口的访问日志，缓存访问日志等。因此，对于请求日志放到ELK的可能也不是特别多见，而是通过脚本针对特定的需求进行收集和查询。

部署方式

ELK部署最简单的方式就是L-E-K方式，不添加任何其他辅助系统，部署简单快速，容易上手。

第二种方式是在L-E之间添加一层redis辅助，这样能够减少日志在服务端的积压，把压力转移到ELK系统服务器上。这种方式添加redis之后，由于redis是内存系统所以响应速度很快，而且可以在redis后添加多个消费系统（Logstash），来扩展消费能力，增强处理速度。

接下来简单说一下E-L-K的三个组成部分。

Logstash

Logstash的独立性很强，它的用途就是一个内容的转存系统，通过灵活的插件可以做到很多种类数据的读取和很多种类数据的写入。

支持的输入类型很多，当前包括以下这些：

输出类型包括这些：

logstash在ELK组合里面担当的是数据收集和解析的功能。

elasticsearch

es的独立性也很强，它本身是一个分布式的搜索引擎，通过倒排序索引对存储的数据进行索引。

当输入查询关键字之后，es依据命中结果的匹配度有序返回结果，效果就像大家百度或者google搜索一样。

在ELK组合中，担当的是数据存储、索引和提供查询接口的功能。

kibana

kibana是一个数据展示的客户端，提供对es中数据的可视化搜索和展示功能，主要提供了时间维度和数据中字段值的检索。以及功能丰富的看板，能够添加曲线图、饼图、地址分布图等多种样式的展示图形。