logstashkafka（logstashkafka配置）

by intanet.cn ca 大数据 on 2024-03-19

本篇文章给大家谈谈logstashkafka，以及logstashkafka配置对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

1、记一次日志采集问题：logstash没有向ES写入数据
2、logstash好用不
3、怎么查看logstash发送到kafka上的数据
4、efk 日志集群架构了解
5、Logstash Output（二）Kafka

记一次日志采集问题：logstash没有向ES写入数据

又出现了数次这样的问题，觉得不应该是es问题，又重新分析发现如团轮是修改过Logstash的配置文件，增加了日志的grok处理，导致logstash的处理速度跟不上kafka生产数据的速度，进而积压了数据。

看来还需要再优化。

===================以下是原分析================

某天突然日志审计系统不能采集数据，表现为查不到最近1小时的日志。

日志写入或裤ES有几条通路：

1、WebServer API接口服务-kafka集群-logstash-ES集群

2、filebeat syslog 514端口-kafka集群-logstash-ES集群

3、filebeat采集nginx日志目录/var/log/nginx/access.log-kafka集群-logstash-ES集群

4、metricbeat、auditbeat采集系统日志-kafka集群-logstash-独立ES节点（系统监控日志）

前三条通路都无法采集到数据，而第四条通路时而能采集到数据，时而不行。

首先想定位出是哪个地方出了问题

1、先验证kafka集群的状态。

用命令行消费消息：

/usr/local/kafka/bin/kafka-console-consumer.sh --bootstrap-server 192.168.1.180:9092 --from-beginning --topic testtopic

验证结果：能正常的收到日志数据。说明kafka集群状态正常。

2、接着验证logstash输出是否正常

将logstash的配置文件做修改，

output {

stdout {

codec = rubydebug # 将日志输出到当前的终端上显示

}

查看输出结果，也是正常的。

3、最后，检查ES集群

重启ES集群发现主节点报错如下

[2020-09-01T15:59:41,129][ERROR][o.e.x.s.a.e.ReservedRealm] [node-3] failed to retrieve password hash for reserved user [elastic]

org.elasticsearch.action.UnavailableShardsException: at least one primary shard for the index [.security-7] is unavailable

参考这篇文章：

依旧没有。

4、最后重建索引发现是前几天有一次es集群离线，Kafka日志消息积压过多，导致数据恢复较慢。耐心等待1小时，恢复渣信了。。。

[img]

logstash好用不

Logstash 是 Elastic Stack 中功能最强大的 ETL 工具，相较于 beats 家族物腔悄，虽然它略显臃肿，但是强在功能丰富、处理能力强大。罩渣

但是在好用的东西也得看个人掌握的技圆迟能程度，你如果都不能深入的理解，那就根本谈不上好不好用了。萝卜青菜各有所爱，最终还得看个人。

怎么查看logstash发送到kafka上的数据

在output-elasticsearch下增竖没加一个index配置掘闷 output { elasticsearch { hosts = ["192.168.10.166:9200"] index = "test_system_log" } } 查看的的话，就装kibana好了，在kibana的settings-indices页判纤弯面，在页面里面的输入框输入test_system_。

efk 日志集群架构了解

0.基础架构：

说明：filebeat日志直接传送给es，直接从界面查看日志

1.架构图

使用filebeat收集日志直接写入kafka，然后再由logstash从kafka读取写到elasticsearch

其中各组件说明如下：

Filebeat：轻量级数据收集引擎。早期的ELK架构中使用Logstash收集、解析日志，但是Logstash对内存、cpu、io等资源消耗比较高。如果用它来对服务器进行日志收集，将加重服务器的负载。相比 Logstash，Beats所占系统的CPU和内存几乎可以忽略不计，所以filebeat作为一个轻量级的日志收集处理工具(Agent)，它可以用来替代Logstash，由于其占用资源少，所以更适合于在各个服务器上搜集日志后传输给Logstash，这也是官方推荐的一种做法。【收集日志】

Logstash：数据收集处理引擎圆拍。支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储以供后续使用。【对日志进行过滤、分析】

Elasticsearch：分布式搜索引擎。是基于Lucene的开源分布式搜索服务器，具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析，并能将这三者结合起来。【搜集、分析、存储数据】

Kibana：可视化平台。它能够搜余腔则索、展示存储在 Elasticsearch 中索引数据。使用它可以很方便的用图表、表格、地图展示和分析数据。【图形化展示日志】

如果还是遇到性能瓶颈

使用filebeat收集日志，先转发到beat端的logstash1，然后logstash1转发到kafka，然后再由logstash2从kafka读取写到elasticsearch。

2.架构升级：

架构解释：

（1）首先用户通过nginx代理访问ELK日志统计平台，这里的Nginx可以设置界面密码。

（2）Nginx将请求转发到kibana

（3）kibana到Elasticsearch中去获取数据，这里的Elasticsearch是两台做的集群，日志数据会随机保存在任意一台Elasticsearch服务器。

（4）Logstash1从Kafka中取出数据并发送到Elasticsearch中。

（5）Kafka服务器做日志数据的持久化保存，避免web服务器日志量过大的时候造成的数据收集与保存不一致而导致日志丢失，其中Kafka可以做集群，然后再由Logstash服务器从Kafka持竖棚续的取出数据。

（6）logstash2从Filebeat取出的日志信息，并放入Kafka中进行保存。

（7）Filebeat在客户端进行日志的收集。

注1：【Kafka的加入原因与作用】

整个架构加入Kafka，是为了让整个系统更好的分层，Kafka作为一个消息流处理与持久化存储软件，能够帮助我们在主节点上屏蔽掉多个从节点之间不同日志文件的差异，负责管理日志端（从节点）的人可以专注于向 Kafka里生产数据，而负责数据分析聚合端的人则可以专注于从 Kafka内消费数据。所以部署时要把Kafka加进去。

而且使用Kafka进行日志传输的原因还在于其有数据缓存的能力，并且它的数据可重复消费，Kafka本身具有高可用性，能够很好的防止数据丢失，它的吞吐量相对来说比较好并且使用广泛。可以有效防止日志丢失和防止logsthash挂掉。综合来说：它均衡了网络传输，从而降低了网络闭塞，尤其是丢失数据的可能性，

注2：【双层的Logstash作用】

这里为什么要在Kafka前面增加二台logstash呢？是因为在大量的日志数据写入时，容易导致数据的丢失和混乱，为了解决这一问题，增加二台logstash可以通过类型进行汇总分类，降低数据传输的臃肿。

如果只有一层的Logstash，它将处理来自不同客户端Filebeat收集的日志信息汇总，并且进行处理分析，在一定程度上会造成在大规模日志数据下信息的处理混乱，并严重加深负载，所以有二层的结构进行负载均衡处理，并且职责分工，一层汇聚简单分流，一层分析过滤处理信息，并且内层都有二台Logstash来保障服务的高可用性，以此提升整个架构的稳定性。