消息队列机制的ELK（Filebeat -Kafka-Logstash-es-kibana）

之前文章采用最简单ELK（此篇文章 需要看之前文章搭建成功基础上完成这个哦）
架构分层
第二种架构，引入了消息队列机制，位于各个节点上的Logstash Agent先将数据/日志传递给Kafka（或者Redis），并将队列中消息或数据间接传递给Logstash，Logstash过滤、分析后将数据传递给Elasticsearch存储。最后由Kibana将日志和数据呈现给用户。因为引入了Kafka（或者Redis）,所以即使远端Logstash server因故障停止运行，数据将会先被存储下来，从而避免数据丢失。这种架构适合于较大集群的解决方案，但由于Logstash中心节点和Elasticsearch的负荷会比较重，可将他们配置为集群模式，以分担负荷，这种架构的优点在于引入了消息队列机制，均衡了网络传输，从而降低了网络闭塞尤其是丢失数据的可能性，但依然存在Logstash占用系统资源过多的问题。

共计分为5层，各层实现功能及含义如下：

第一层：数据采集层。在每个应用服务器上部署 filebeat做日志采集（考虑打包集成?）,然后把日志信息放到 kafka(zk)集群。
第二层：消息队列层。kafka负责日志存储，和被消费。（缓冲日志压力，同时保证数据不丢失）
第三层：数据分析层。logstash作为消费者，会实时拉取采集的日志信息，然后将获取到的日志根据规则进行分析、清洗、过滤，最后将清洗好的日志转发给ES集群。
第四层：数据持久化存储层（ES集群）。ES集群将logstash发送过来的数据，执行写磁盘，建立索引等操作，最后将结构化的数据存储起来。
第五层：数据查询、展示层。Kibana可视化数据展示平台，可以利用它进行可视化和多维度分析。通过自建ES查询、统计等服务，也可以做到定制化数据分析。

说的简单点
就是 Filebeat 进行 各个应用收集日志 ，然后传输给kafka

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /speedchina/48888.log
    - /speedchina/log(4).log
    - /speedchina/server-test/base-platform-server-1.0.1/logs/*/*.log
  close_removed: true
 
#output:
  #elasticsearch:
    #hosts: ["192.168.10.111:9200"]
processors:
- drop_fields:
    fields: ["beat","input","source","offset"]
 
output.kafka:
    enable: true
    hosts: ["192.168.10.111:9092"]
    topic: es-tmslogs
    required_acks: 1
    compression: gzip
    max_message_bytes: 1000000
  

kafak的搭建如下:(KAFKA_ZOOKEEPER_CONNECT 这个是zookper的IP地址)
https://hwy.ac.cn/2018/08/07/%E4%BD%BF%E7%94%A8docker%E5%AE%89%E8%A3%85kafka/

 docker run  -d --name kafka -p 9092:9092 -e KAFKA_BROKER_ID=0 -e KAFKA_ZOOKEEPER_CONNECT=192.168.10.111:2181 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://192.168.10.111:9092 -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092 -t wurstmeister/kafka 

然后我们由logstash进行读取kafka的数据 然后输出到es里面
grok 内容 语法 对应文字
2021-12-24 16:50:29.838 [system] [WARN] [92817378773147649] [172.17.0.1] [base_platform_server] [main] [OperationImplicitParameterReader.java:170] Unable to interpret the implicit parameter configuration with dataType: String, dataTypeClass: class java.lang.Void

# 输入端
input {
  kafka{
        bootstrap_servers => "192.168.10.111:9092"
        topics => ["es-tmslogs"]
        codec => json
    }
}
filter {
    grok {
        match => {"message" => '%{TIMESTAMP_ISO8601:time} \[%{WORD:logType}\] \[%{LOGLEVEL:loglevel}\] \[%{NUMBER:traceId}\] \[%{HOSTNAME:hostAddress}\] \[%{WORD:appId}\] \[%{DATA:thread}\] \[%{DATA:fileline}\]%{GREEDYDATA:msg}'}
    }
    json {
        source => "msg"
    }
    mutate {
        remove_field => ["log", "agent", "host", "message", "@timestamp", "@version", "ecs"]
    }
}
#输出端
output {
  stdout {
    codec => rubydebug
  }
  elasticsearch {
    #hosts中的地址应该写同一network下的容器名称（这个地方特别注意需要docker的那个ip）
    hosts => ["http://172.17.0.9:9200"]
    # 输出至elasticsearch中的自定义index名称（这个地方有bug 一开始会有日期后续都在elastic-里面）
    index => "elastic-%{+YYYY.MM.dd}"
    #user => "elastic"
    #password => "changeme"
  }
}

然后kibanna里面可以正常看了。

参考 https://blog.csdn.net/metheir/article/details/88593994 进行json多次处理

工具辅助：
1.Docker安装elasticsearch-head监控ES栏… https://blog.csdn.net/gmijie/article/details/79475153
2.kafka可视化辅助工具offsetexplorer 进行连接


小插曲
日志收集规范
支持分步
第一步「完成」：@ControllerAdvice 全局异常，捕获后预警，局限性：仅在Controller控制范围内有效。
第二步「进行中」：应用内预警（消息预警平台）, 用于业务层面、内部工具接入使用（方便可控）。
第三步「技术预研」：标准ELK收集和基础预警，通过WebHock统一收取到桥接平台后，再分发到预警平台，形成消息闭环（比默认方式支持更灵活可控）。
简版：通过 filebeat 维护好固定数据格式，将解析数据再拼接为json发送到Kafka，进而转到预警平台，形成轻量级日志预警（弥补了api局限性）（待实践）。
复杂版本（提供日志检索、分析）：结合轻量级 filebeat 到 logstash / es 再进行分析（重点是业务场景）（生产有实战）。

日志格式
收集内容有：日期、日志类型、日志等级、traceId、本机IP地址、应用唯一标记、线程名、文件及行、日志内容

<!--日期 [日志类型] [日志等级] [traceId] [本机IP地址] [应用唯一标记] [线程名] [文件及行] - 日志内容 -->
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%X{logType}] [%-5level] [%X{traceId}] [%X{hostAddress}] [%X{appId}] [%thread] [%file:%line] - %msg%n</pattern>