安装ELK Stack海量日志分析系统(3)

为什么要使用logstash => redis => logstash Server这种结构?
首先，我们要了解redis在此处的用处。
redis在此处，做为一个消息队列，可以用来整合多个ngxin那里收集而来的日志。
当elasticsearch发生故障或重启的时候，redis仍可接受来自web端的日志。
当elasticsearch重新启动的时候，则会从消息队列中重新读取数据。
这样就可以不会因为重启的这段时间而丢失那段时间的日志数据。

安装kibana 1.在任意节点安装kibana #配置kibana的清华镜像 [root@bc ~]# vim /etc/yum.repos.d/kibana.repo [Kibana-4.5] name=Kibana-Tsinghua baseurl=https://mirrors.tuna.tsinghua.edu.cn/ELK/yum/kibana-4.5/ gpgcheck=0 enabled=1 [root@bc ~]# yum install kibana -y 2.修改配置文件 [root@bc ~]# vim /opt/kibana/config/kibana.yml elasticsearch.url: "http://node1.bc.com:9200" 3.启动kibana #启动kibana [root@bc ~]# nohup /opt/kibana/bin/kibana & #浏览器输入，可以使用ip地址 :5601

kibana.jpg

ELK stack的安全问题

(1).ELK安全相关：
由于ELK stack是日志信息，相对来说比较私密，不能任由谁都能访问。
a.在前端使用nginx做代理，并且启用basic认证。
b.nginx设置访问控制，来限制访问来源的ip。
c.把ELK stack在局域网内，不向外提供服务。

(2)redis的安全相关：
a.redis启动自带的认证功能
b.nginx设置访问控制，来限制访问来源的ip。
c.把redis在局域网内，不向外提供服务。

#实际上，由于NoSQL的产品兴起不久，最近都有一些安全相关的资讯。 #一定要在安全相关方面，引起注意。 1.redis被提权之后，被恶意被执行flush_all导致被清库。 2.mongodb低版本没有认证功能，被清库。 3.elasticsearch被恶意勒索。（自身为开源免费，认证插件收费。） 总结：

(1).ELK安装起来看起来十分容易，但是实际操作起来，因为版本之间有差异，所以很容易出错。而这个时候，我们可以通过查看日志，或者到官方文档
(2).写出正确的grok规则是最花时间，也就是说ELK里面，最烧脑的是logstash。
但是elasticsearch的配置文件很严格，有时即使是少写一个空格也会启动失败。
(3).因为ELK stack需要启动java虚拟机，很占用内存。
同时elasticsearch、logstash都需要安装JVM虚拟机，一般不搭建在同一台服务器。
(4).redis很消耗内存，在redis内存占用达到总体70%以上的时候就需要引起注意。
同时，redis最好安装3或者以上的高版本，因为低版本的redis很容易和logstash不兼容，写不进去。
(5).由于权限的问题而导致启动失败
可修改/etc/sysconfig/logstash中启动用户为root。
(6)这个架构中的单点故障：Redis。
1.logstash Server故障的时候，消息储存在消息队列中
2.logstash Client故障的时候，日志仍然保存在nginx日志文件中。
但是重启的时候，只要配合sincedb依然可以继续上次断开的地方开始读取。
3.Elasticsearch故障的时候，集群中的其他节点会生效
4.Redis故障的时候，，logstash client的多个主机都无法向redis写入数据。

所以将在不久写一篇文章，讲述如何搭建一个redis集群。

关于新版本的见解：
文章都是实际搭建之后而成，关于理论部分不过多阐述。
ELK stack2.4版本目前使用较多，新版ELK由于变动较大并追加了新功能。
在搭建或者使用期间时报错，可能较难搜索到结果。
如果求稳定使用而不是追求新功能的话，本文可以作为参考。