ELK日志采集实战

时间：2025-02-25 14:06:29

ELK日志采集实战

需求背景：

  • 业务发展越来越庞大，服务器越来越多
  • 各种访问日志、应用日志、错误日志量越来越多，导致运维人员无法很好的去管理日志
  • 开发人员排查问题，需要到服务器上查日志，不方便
  • 运营人员需要一些数据，需要我们运维到服务器上分析日志,并用图标更直观的展示出来

为什么要用到ELK

  • 一般我们需要进行日志分析场景：直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大也就是日志量多而复杂的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。
  • 大型系统通常都是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。
    一个完整的集中式日志系统，需要包含以下几个主要特点：
  1. 收集－能够采集多种来源的日志数据
  2. 传输－能够稳定的把日志数据传输到*系统
  3. 存储－如何存储日志数据
  4. 分析－可以支持 UI 分析
  5. 警告－能够提供错误报告，监控机制
    而ELK则提供了一整套解决方案，并且都是开源软件，之间互相配合使用，完美衔接，高效的满足了很多场合的应用。是目前主流的一种日志系统。

ELK简介

ELK是三个开源软件的缩写，分别为：Elasticsearch 、 Logstash以及Kibana , 它们都是开源软件。不过现在还新增了一个Beats，它是一个轻量级的日志收集处理工具(Agent)，Beats占用资源少，适合于在各个服务器上搜集日志后传输给Logstash，官方也推荐此工具，目前由于原本的ELK Stack成员中加入了 Beats 工具所以已改名为Elastic Stack.

Elastic Stack包含:

  • Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。详细可参考Elasticsearch权威指南
  • Logstash 主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。
  • Kibana 也是一个开源和免费的工具，Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。
  • Beats在这里是一个轻量级日志采集器，其实Beats家族有6个成员，早期的ELK架构中使用Logstash收集、解析日志，但是Logstash对内存、cpu、io等资源消耗比较高。相比 Logstash，Beats所占系统的CPU和内存几乎可以忽略不计

需求介绍

我的需求是,需要采集两种日志,一种是正常的系统日志,这个日志异常排查做服务的,还有一种日志是自定义日志结构,这个日志用来统计分析.

解决思路

  1. 系统部署到docker容器中,通过logback将日志存放到指定目录下,比如说我有十个服务,这时候我需要部署十个docker容器,这十个系统的日志,我都放到同一目录下,再启动docker容器时,我需要将docker容器的 目录和本地机器做目录映射.
  2. 采集日志我是用FileBeat进行日志采集,但我不打算在每个服务的docker 容器中部署一个filebeat,那我filebeat怎么才能采集到系统日志呢, 我是这样解决的,我部署一个FileBeat的容器,但在启动容器时,我映射上面说的系统目录,这时候所有的日志都会到FileBeat容器内部,这样我只需要部署一台filebeat就可以采集十台服务的日志,这里我没有考虑性能,大家实际情况实际分析.
  3. 上面说过,我有两种日志结构,我用filebeat采集日志,在Logstash中通过判断,将两种不同的日志,存到不同的index 中就可以了.下面开始实际操作.

搭建ELK环境

在这里我们使用docker来部署ElK,我们使用docker hub 上的镜像来进行搭建.

镜像介绍

我们这里使用docker hub 上的sebp/elk镜像,网站为/r/sebp/elk.下面我针对该镜像开始介绍搭建.我们以670为例.

拉取镜像

在你的系统中运行 docker pull sebp/elk:670

创建容器

docker run -p 5601:5601 -p 9200:9200 -p 5044:5044 -p 9300:9300 -p 9201:9201 -v /home/ubuntu/iri/chenzhe/logstash/config:/etc/logstash// -v /home/ubuntu/iri/chenzhe/elasticsearch/:/etc/elasticsearch/ -it --name elk --restart=always sebp/elk:670

命令介绍

上面了命令我们做了端口映射,和文件映射,

端口介绍
  • 5601 (Kibana web interface).
  • 9200 (Elasticsearch JSON interface).
  • 5044 Logstash input 开放端口
  • 9300 因为我的程序需要使用Java代码操作ES 9300 是ES的内部通讯端口
  • 9201 是我通过logback 往ES里存储Sleuth的端口
目录映射介绍

做目录映射的目的是为了方便我们操作容器内部的配置文件,防止因为直接修改容器内的配置文件,出错后容器跑不起来,我们还改不了配置文件,只能重新搭建.

  1. /etc/logstash// 是LogStash的 input 和 output 配置文件
  2. etc/elasticsearch/ 是ES的配置文件目录,它和我们正常下载的ES的配置文件所在地址不太一样,在elasticsearch目录下也有一个 但是你改这个不生效
常见问题

容器创建后会默认启动全部程序,你可能遇到一些错误

  1. 你可能会遇到ElasticSearch 报出 用户执行内存权限不够的情况你需要在 /etc/ 下 添加 vm.max_map_count=300000
  2. ES默认不能使用root用户操作,你需要使用其他用户
总结

当你完成上面的步骤之后到这里你的ELK环境已经搭建完成,下面我们针对我遇到的实际需求来讲解我的实现过程.

部署服务应用

配置项目的logback

  1. 可以看到我们将日志文件全部输出到了/opt/logs/tdf-cloud/zipkin/下

  2. CONSOLE_LOG_PATTERN 是日志采集的正则表达式符合规则的日志才进行采集

  3. 这个日志配置你可以在Spirng Cloud Sleuth 官网中看到

    /spring-cloud-static/spring-cloud-sleuth/2.2.0.M1/

  4. 这个配置文件你必须在你每个项目下都配置一个,你可以根据不同的项目将日志输出到不同的目录下.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <include resource="org/springframework/boot/logging/logback/"/>
    ​<property resource="" />
    <springProperty scope="context" name="springAppName" source=""/>
    <!-- Example for logging into the build folder of your project -->
    <property name="LOG_FILE" value="/opt/logs/tdf-cloud/zipkin/"/>​

相关文章