简易版
标准版
logstash 和filebeat都具有日志收集功能,filebeat更轻量,占用资源更少,但logstash 具有filter功能,能过滤分析日志。一般结构都是filebeat采集日志,然后发送到消息队列,redis,kafaka。然后logstash去获取,利用filter功能过滤分析,然后存储到elasticsearch中
可以参考网址:https://www.iyunv.com/thread-443374-1-1.html
解压文件
|
|
由于es不能用root账户启动,所以需要添加一个非root账户
|
|
修改es文件夹的权限
|
|
修改配置文件
|
|
修改elasticsearch.yml
的内容如下
|
|
创建data和logs文件夹
|
|
启动es(为了方便观察日志没有后台启动)
|
|
安装过程遇到的问题
[1]: max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]
vim /etc/security/limits.conf
# 在最后面追加下面内容
* soft nofile 65536
* hard nofile 131072
* soft nproc 2048
* hard nproc 4096
[2]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
vi /etc/sysctl.conf
添加下面配置:
vm.max_map_count=262144
并执行命令:
sysctl -p
解压文件
|
|
进入config文件夹新建log4j_es.conf文件并编写内容
|
|
log4j_es.conf内容
|
|
启动logstash (为了方便观察日志没有后台启动)
|
|
解压
|
|
修改配置文件kibana.yml
|
|
启动kibana
|
|
进入kibana界面
点击 Management 点击Index Patterns
在 Create index pattern 的文本框输入索引名称,因为我在logstash中设置索引为 log4j-%{+YYYY.MM.dd}
,所以我们填写 log4j-*
点击下一步设置直到完成。
点击Discovery
可以看到我们的日志了。
三、kafka和zookeeper安装与配置
zookeeper的安装参考 :zookeeper集群搭建步骤
kafka的安装参考: Kafka集群搭建步骤
启动zk:
|
|
启动kafka
启动kafka
|
|
创建topic
|
|
创建生产者
|
|
创建消费者
|
|
参考:
https://www.elastic.co/guide/en/logstash/current/plugins-inputs-kafka.html
vi logstash_agent.conf
|
|
完整配置文件可参考:test.conf
启动elk之后,在kafka生产者输入一条信息之后logstash打印出对应的内容,说明集成成功了
。在kibana设置对应的日志。
解压
|
|
配置filebeat.yml
|
|
完整配置文件可参考:filebeat.yml
运行
|
|
把logstash停止,修改配置文件,添加filebeat配置的topic。重启logstash。打开kibana刷新页面,看到filebeat收集到的日志
清除es index及logstash日志相关脚本(仅供参考)如下:
#/bin/bash
# clean elastic history index data
# author lujie
# createTime 2018-06-09 12:00:12
CLEAR_LOGSTASH_TIME=`date +%Y-%m-%d -d "7 days ago"`
#delete logstash logs
DELETE_LOGS=/data/elk/logstash-6.2.4/logs/logstash-plain-$CLEAR_LOGSTASH_TIME*
if [ ! -n "$DELETE_LOGS" ]; then
echo -e '\n get logstash path is null,check it!'
else
echo -e '\n delete logstash logs start...'
echo -e '\n execute common is: rm -rf '$DELETE_LOGS
rm -rf $DELETE_LOGS:
echo -e '\n delete logstash logs fininshed!'
fi
echo -e '\n delete elasticsearch index start...'
#define clear_time current is 7 days ago
CLEAR_TIME=`date +%Y.%m.%d -d "7 days ago"`
#curl delete request formatter is xxx-YYYY.MM.dd
curl -XDELETE 'http://192.168.0.45:9200/*-'${CLEAR_TIME}
echo -e '\n delete elasticsearch index fininshed!'
注意:
在logstash中,当input里面有多个kafka输入源时,client_id => "xxx"必须添加且需要不同,否则会报错javax.management.InstanceAlreadyExistsException: kafka.consumer:type=app-info,id=logstash-0。
input {
kafka {
group_id => "es1"
}
kafka {
group_id => "es2"
}
}
vim /etc/security/limits.conf
# 在最后面追加下面内容
*** hard nofile 65536
*** soft nofile 65536
五 ELK相关配置文件
定时清理日志脚本位置:
/data/elk/elk_logs_clean.sh
执行脚本在crontab里面配置:
/etc/crontab,如果定时任务不执行,可以查看crontab执行情况 tail -f /var/log/cron
|
/data/elk_agent/filebeat-6.2.4-linux-x86_64/filebeat.yml
|
详细配置可以参考:https://www.elastic.co/guide/en/beats/filebeat/5.5/index.html
logstash配置:/data/elk/logstash-6.2.4/config/test.conf
|
虽让上面的配置能让系统运行起来,我们能筛选内容,但是索引里面有好多我们用不到的字段,接下来我们对索引字段处理
修改logstash的配置文件,在filter内修改timestamp标签
如下使用自定义的timestamp替换内置的:
date {
match => ["message","UNIX_MS"]
target => "@timestamp"
}
ruby {
code => "event.set('timestamp', event.get('@timestamp').time.localtime + 8*60*60)"
}
ruby {
code => "event.set('@timestamp',event.get('timestamp'))"
}
mutate {
remove_field => ["timestamp"]
}
原计划将kafka输出的message解析成json格式,在logstash中的filter添加如下配置
json {
source => "message"
target => "message"
}
在运行的时候一直报json解析失败。从kafka拿到具体的topic数据发现,kafka发送给logstash的是json格式massage只是具体日志内容,注释这个配置即可。目前filter默认没有配置任何东西
- type: log
# Change to true to enable this prospector configuration.
enabled: true
# Paths that should be crawled and fetched. Glob based paths.
paths:
- D:\htdocs\logs\*.log
fields:
log_topics: testlocal
multiline:
##将日志以时间开头的作为一行(用于java日志多行合并)
pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
negate: true
match: after
在filebeat的data牡蛎有个文件是 registy,用文本编辑器打开可以看到里面记录了,读取文件的相关信息如下,如果想重新读取文件停止filebeat后删除该文件即可:
[{"source":"/data/Tomcat/logs/catalina.out","offset":1048680657,"timestamp":"2018-06-06T11:57:18.215705238+08:00","ttl":-2,"type":"log","FileStateOS":{"inode":100671962,"device":64769}},
{"source":"/htdocs/logs/kstore_haoxianggou_site.log","offset":0,"timestamp":"2018-06-06T12:44:29.718548093+08:00","ttl":-1,"type":"log","FileStateOS":{"inode":88086231,"device":64769}},
{"source":"/htdocs/logs/kstore_haoxianggou_site_error.log","offset":0,"timestamp":"2018-06-06T12:44:29.721257882+08:00","ttl":-1,"type":"log","FileStateOS":{"inode":88086232,"device":64769}}
]
优势:
拥有很多的插件,使用起来很灵活。网上相应的资源比较丰富,以下例子可以参考下:
5 minute intro
reindexing data in Elasticsearch
parsing Elasticsearch logs
rewriting Elasticsearch slowlogs so you can replay them with JMeter
劣势:
1.Logstash 致命的问题是它的性能以及资源消耗(默认的堆大小是 1GB)。尽管它的性能在近几年已经有很大提升,与它的替代者们相比还是要慢很多的。
这里有 Logstash 与 rsyslog 性能对比以及Logstash 与 filebeat 的性能对比。它在大数据量的情况下会是个问题。
2. 目前不支持缓存,目前的典型替代方案是将 Redis 或 Kafka 作为中心缓冲池:
应用场景:
因为 Logstash 自身的灵活性以及网络上丰富的资料,Logstash 适用于原型验证阶段使用,或者解析非常的复杂的时候。
在不考虑服务器资源的情况下,如果服务器的性能足够好,我们也可以为每台服务器安装 Logstash 。我们也不需要使用缓冲,因为文件自身就有缓冲的行为,而 Logstash 也会记住上次处理的位置。
如果服务器性能较差,并不推荐为每个服务器安装 Logstash ,这样就需要一个轻量的日志传输工具,将数据从服务器端经由一个或多个 Logstash 中心服务器传输到 Elasticsearch:
随着日志项目的推进,可能会因为性能或代价的问题,需要调整日志传输的方式(log shipper)。当判断 Logstash 的性能是否足够好时,重要的是对吞吐量的需求有着准确的估计,这也决定了需要为 Logstash 投入多少硬件资源。
Filebeat 是一个轻量级的日志传输工具,它的存在正弥补了 Logstash 的缺点:Filebeat 作为一个轻量级的日志传输工具可以将日志推送到中心 Logstash。
在版本 5.x 中,Elasticsearch 具有解析的能力(像 Logstash 过滤器)— Ingest。这也就意味着可以将数据直接用 Filebeat 推送到 Elasticsearch,并让 Elasticsearch 既做解析的事情,又做存储的事情。也不需要使用缓冲,因为 Filebeat 也会和 Logstash 一样记住上次读取的偏移:
如果需要缓冲(例如,不希望将日志服务器的文件系统填满),可以使用 Redis/Kafka,因为 Filebeat 可以与它们进行通信:
优势:
Filebeat 只是一个二进制文件没有任何依赖,使用go语言开发。它占用资源极少。尽管它还十分年轻,正式因为它简单,所以几乎没有什么可以出错的地方,所以它的可靠性还是很高的。
它也为我们提供了很多可以调节的点,例如:它以何种方式搜索新的文件,以及当文件有一段时间没有发生变化时,何时选择关闭文件句柄。
劣势:
Filebeat 的应用范围十分有限,所以在某些场景下我们会碰到问题。例如,如果使用 Logstash 作为下游管道,我们同样会遇到性能问题。正因为如此,Filebeat 的范围在扩大。开始时,它只能将日志发送到 Logstash 和 Elasticsearch,而现在它可以将日志发送给 Kafka 和 Redis,在 5.x 版本中,它还具备过滤的能力。
典型应用场景
Filebeat 在解决某些特定的问题时:日志存于文件,我们希望
将日志直接传输存储到 Elasticsearch。这仅在我们只是抓去(grep)它们或者日志是存于 JSON 格式(Filebeat 可以解析 JSON)。或者如果打算使用 Elasticsearch 的 Ingest 功能对日志进行解析和丰富。
将日志发送到 Kafka/Redis。所以另外一个传输工具(例如,Logstash 或自定义的 Kafka 消费者)可以进一步丰富和转发。这里假设选择的下游传输工具能够满足我们对功能和性能的要求。
也有很多公司的日志系统使用的是EFK,可以到网上查询相应的资料。
https://www.digitalocean.com/community/tutorials/elasticsearch-fluentd-and-kibana-open-source-log-search-and-visualization
Fluentd 创建的初衷主要是尽可能的使用 JSON 作为日志输出,所以传输工具及其下游的传输线不需要猜测子字符串里面各个字段的类型。这样,它为几乎所有的语言都提供库,这也意味着,我们可以将它插入到我们自定义的程序中。
优势:
和多数 Logstash 插件一样,Fluentd 插件是用 Ruby 语言开发的非常易于编写维护。所以它数量很多,几乎所有的源和目标存储都有插件(各个插件的成熟度也不太一样)。这也意味这我们可以用 Fluentd 来串联所有的东西。
劣势:
因为在多数应用场景下,我们会通过 Fluentd 得到结构化的数据,它的灵活性并不好。但是我们仍然可以通过正则表达式,来解析非结构化的数据。尽管,性能在大多数场景下都很好,但它并不是最好的,和 syslog-ng 一样,它的缓冲只存在与输出端,单线程核心以及 Ruby GIL 实现的插件意味着它大的节点下性能是受限的,不过,它的资源消耗在大多数场景下是可以接受的。对于小的或者嵌入式的设备,可能需要看看 Fluent Bit,它和 Fluentd 的关系与 Filebeat 和 Logstash 之间的关系类似
典型应用场景
Fluentd 在日志的数据源和目标存储各种各样时非常合适,因为它有很多插件。而且,如果大多数数据源都是自定义的应用,所以可以发现用 fluentd 的库要比将日志库与其他传输工具结合起来要容易很多。特别是在我们的应用是多种语言编写的时候,即我们使用了多种日志库,日志的行为也不太一样。