实现 logback + kafka + ELK 的SSH项目日志改造
1 简介
前言:
SSH框架中已集成logback,部门已搭建好Kafka + ELK平台(后称日志平台),因为需要容器化部署项目,日志不能像以往写在本地日志文件,而是需要通过Kafka+Logstash将日志消息收集存储在日志平台。不同于Springboot项目自带logback,改造方便,SSH项目需要自己改造日志工具并且集成kafka,有诸多不同地方,文章主要是对改造过程及出现问题做介绍。
前序知识:名词的简单介绍
- logback : java日志组件,是系统中编写的日志打印代码的具体实现,可以单独或和日志接口(如slf4j)搭配实现日志输出。
- ELK:Elasticsearch、Logstash、Kibana的简称,是一套应用组件,三者构成一个日志分析管理平台。
- Elasticsearch:分布式搜索引擎,即实现对已收集的日志数据的搜索
- Logstash:数据收集处理引擎,即实现对日志数据的收集、处理、存储
- Kibana:可视化平台,即实现对已收集日志数据的可视化展示
- Kafka:实时数据处理系统,即充当消息中间件(消息队列)的功能,Logstash通过Kafka传递日志数据,Kafka起缓冲数据作用,弥补仅靠Logstash可能出现的性能和可靠性问题。
更详细的介绍:
- 关于kafka + ELK: 基于Kafka+ELK搭建海量日志平台、
- 关于Kafka、消息队列:Kafka简明教程
- 关于SSH项目(非SpringBoot项目)集成logback的集成过程:log4j2升级为logback,logback+slf4jcommons-logging+Jboss-logging(SSH项目)
2 改造步骤及问题解决
2.1 引入相关依赖
- logback-kafka-appender:提供给logback的appender,顾名思义,用于配置输出到kafka的appender。
appender决定日志要输出到哪,日志自带的常见的如:RollingFileAppender,输出到文件;ConsoleAppender,输出到控制台。
- logstash-logback-encode :提供给logback的编码器,输出的日志通过该编码器编码后被Logstash收集,存储。
- jackson:我们日志采用的是json格式,所以在logback中使用的日志encoder用的logstash.encoder.LoggingEventCompositeJsonEncoder,需要依赖处理Json格式类库jackson,详细配置解释见2.2。
- kafka-clients:系统的生产的日志是消息的生产者,我们要将生产出来的日志给到日志平台,所以系统作为客户端,logback输出日志并被Logstash编码收集处理的日志数据发送给kafka,由kafka再发送给Logstash服务端处理。
不同于SpringBoot项目,使用的spring-kafka是在spring-client基础上再封装的,非spring-boot项目中好像用不了,所以直接用kafka-clients,目前未找到详细使用上的问题
依赖包汇总:
- logback-kafka-appender-0.2.0-RC2.jar
- logstash-logback-encoder-5.2.jar
- jackson-core-2.9.7.jar
- jackson-databind-2.9.7.jar
- jackson-annotations-2.9.7.jar
- kafka-clients-2.0.0.jar
2.2 logback配置文件增加kakfa的appender
<appender name="kafkaAppender" class="com.github.danielwegener.logback.kafka.KafkaAppender">
<encoder charset="UTF-8"
class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
<providers>
<timestamp>
<timeZone>UTC</timeZone>
</timestamp>
<pattern>
<pattern>
{
"log_level": "%-5level",
"log_topic": "cw-log",
"division": "cw",
"appName": "test_grams_gramsapi_feature",
"dmAppName": "xxx",
"message": "${LOG_PATTERN}"
}
</pattern>
</pattern>
</providers>
</encoder>
<topic>cw-log</topic>
<!-- we don't care how the log messages will be partitioned -->
<keyingStrategy class="com.github.danielwegener.logback.kafka.keying.NoKeyKeyingStrategy"/>
<!-- use async delivery. the application threads are not blocked by logging -->
<deliveryStrategy class="com.github.danielwegener.logback.kafka.delivery.AsynchronousDeliveryStrategy"/>
<!-- each <producerConfig> translates to regular kafka-client config (format: key=value) -->
<!-- producer configs are documented here: https://kafka.apache.org/documentation.html#newproducerconfigs -->
<!-- bootstrap.servers is the only mandatory producerConfig -->
<producerConfig>bootstrap.servers=11.4.66.217:9094,11.4.66.220:9094,11.4.66.219:9094</producerConfig>
<!-- don't wait for a broker to ack the reception of a batch. -->
<!-- <producerConfig>acks=0</producerConfig>-->
<!-- wait up to 1000ms and collect log messages before sending them as a batch -->
<producerConfig>linger.ms=100</producerConfig>
<!-- even if the producer buffer runs full, do not block the application but start to drop messages -->
<!-- <producerConfig>max.block.ms=0</producerConfig>-->
<!-- define a client-id that you use to identify yourself against the kafka broker -->
<!-- <producerConfig>client.id=${HOSTNAME}-${CONTEXT_NAME}-logback-relaxed</producerConfig>-->
</appender>
2.3 启动后检测试
到对应的Kinana平台,根据对应的过滤条件筛选到我们输出的日志。