实现 logback + kafka + ELK 的SSH项目日志改造_logback kafka elk 多个项目

实现 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可能出现的性能和可靠性问题。

更详细的介绍：

1. 关于kafka + ELK: 基于Kafka+ELK搭建海量日志平台、
2. 关于Kafka、消息队列：Kafka简明教程
3. 关于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>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

2.3 启动后检测试

到对应的Kinana平台，根据对应的过滤条件筛选到我们输出的日志。