elasticsearch+logstash+kinana搭建的日志收集系统
elasticsearch是基于倒排序查询的查询引擎，什么叫倒排序？比如mysql建立的索引是正排序，对于规范化数据(比如表格，元数据)而言基本使用正排序索引，倒排序一般用于文本之类的查询，典型的例子是关键字搜索文献，在录入文献时，对每一个关键字建立索引，可以看到它属于哪一篇文章，这样就可以很方便的进行查询，缺点是对内容建索引代价比较高，如果要进行查询需要把所有的日志加载到内存中，耗内存大
logstash作为日志系统的收集器起着收集和过滤功能，需要在每一台被收集日志的主机上安装logstash_shippment，master节点安装logstash_indexer,可以在其中使用grok插件在里面编写一些正则完成过滤，规定内容格式（比如json）,设置一些规则或者做统计，最典型的例子：指定输入路径/var/log/messages,输出的地方写kafka host:9092这样就默认把日志导出到kafka中，注意要有时间戳，还要符合默认格式，
kibana作为可视化工具，只需要会安装，使用和其他组件通过网络端口对接即可。可以在文本框里输入查询条件查询，也可以确定索引条件之后进行查询。
中间件为了保证性能（查询快）和高可用性（一个节点崩掉还能使用的集群）用了kafka消息队列搭建的集群做logstash_shippment和logstash_indexer的对接，kafka对某一类日志创建topic,每一个topic收集的日志划分为若干partition（日志收集太多一个节点的存储不够），每一个partition可以复制来保证高可用性，每个broker存放一个topic下的一个partition,仔细看的话，一个topic实际上是一个消息队列，partition是拆分的文件，如broker1存放着topic_1文件夹，broker2存放着topic_2文件夹，合并起来是一个topic。shippement做生产者，indexer做消费者。为了保证高可用，kafka有一个参数replic表示一份消息的备份数量，集群会选出一个master节点，每次日志先导入master节点，之后master节点同从节点进行通信从而完成同步，主节点崩掉之后从节点中再次选举出主节点，集群之间选举使用zookeeper组件完成节点之间的同步通信和选举。
部署集群至少使用三个节点，少于3会引起zookeeper选举master的一个bug.
最早无脑搭建，花了三天时间排查错误，发现kibana只有一个空界面，没有索引。后来排查是和es对接有问题，问题1KO。
再往下，有索引出不来查询日志，往下抠，抠到kafaka，看kafka的日志，发现是zookeeper报错，zkServer没启动起来，再看zookeeper.out(zk安装目录下的日志文件)，有一个java connected refused错误，最后先单节点的zkServer自己和自己通信，发现zkServer可以启动，和其他主机通信有问题，可能是网络问题。
发现报错，不要慌，先看报错行，有时候你看到的不一定是真实的，比如zkSever.sh执行之后会报zkServer has Started，但是真的Started了吗？没有，看zk.out就会看到
javaExceptiioin(5607) connected refused，这时候先在核对配置，有时候注释啦，空格啦的低级失误可能是元凶，之后再想想和理想化环境有什么差别，比如电脑上安装了什么软件，有影响？最后把错误搬到网上，可能之前其他人也碰到过这种诡异的事情。其中最诡异的事情是，我把主机上的kibana卸载之后，打开host:5601之后发现kibana还能访问？最后发现是主机上装了docker,访问的是docker上的kb
在排查zk错误的过程中，去检查了三遍配置，网上查kafka,zk原理，学习了一些新命令,尝试着写#!/bash/bin开头的shell脚本在每一台主机上部署
sh -n先检查脚本，sh -x执行脚本并且在控制台打印输出，echo变量
sudo -i登陆root的方法
tail -n 200 aaa.log打印最新的日志
sudo ufw enable|disable打开或者关闭防火墙
最常用两个安装目录/usr/local,/opt
