Elastic Stack是ELK日志系统的官方称呼，而ELK则是盛名在外的一款开源分布式日志系统，一般说来包括了Elasticsearch、Logstash和Kibana，涵盖了后端日志采集、日志搜索服务和前端数据展示等功能。
本文将会对Elastic Stack的安装部署流程进行一系列简单的介绍，并记录下了一些部署过程中遇到的坑及解决方法。
在本次实践中，我们所部署的ELK分布式日志系统，其架构大致如下：
首先在各日志产生机上部署收集器Filebeat，然后Filebeat将监控到的log文件变化数据传至Kafka集群，Logstash负责将数据从kafka中拉取下来，并进行字段解析，向Elasticsearch输出结构化后的日志，Kibana负责将Elasticsearch中的数据进行可视化。
【重点参考】：
ELK中文书 http://kibana.logstash.es/content/
一、Elasticsearch的部署
首先在https://www.elastic.co中找到ES的安装包。下文中所用的安装包均为Linux 64的tar.gz压缩包，解压即可用。
其中，Elasticsearch需要依赖Java JDK1.8。JDK的安装方法在此不做赘述。
1.1 Elasticsearch的配置
ES的配置文件在解压根目录下的config文件夹中，其中elasticsearch.yml是主配置文件。
以基本可用作为部署目标，在该文件中仅需要设置几个重要参数：
cluster.name、node.name这两者顾名思义，作为集群和节点的标识符。 Paths部分下的path.data和path.logs，表示ES的数据存放位置，前者为数据存储位置，后者为ES的log存储位置。请尽量放到剩余空间足够的地方，此外在进行调优时有一种方法是将数据放置到SSD上。 bootstrap.memory_lock: true，设为true以确保ES拥有足够的JVM内存。 network.host: localhost和http.port，在此处设置ES对外服务的IP地址与端口
设置完以上几项参数后，即可在ES根目录下使用命令./bin/elasticsearch启动ES进程。也有相应的后台启动方式，具体不赘述。
1.2 Elasticsearch 5.x的Bootstrap Checks
Elasticsearch在升级到5.x版本后，启动时会强制执行Bootstrap Checks(官方文档)
其中经常性的问题是需要增大系统可使用的最大FileDescriptors数（参考https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html）
剩下的其他问题可以查询官方文档。
1.3 Elasticsearch的X-pack插件
X-pack是官方提供的一系列集成插件，包括了alert、monitor、secure等功能，十分强大（但是并不免费）。
在ELK 5.0中安装大部分插件仅需要输入命令：./bin/elasticsearch-plugin install 即可
X-pack插件安装后会自动开启ELK的权限功能，需要注意的是如果启用了X-pack，则在向ES输入数据或发起API请求时，均需要附带相应的auth信息。
考虑到X-pack并非免费且价格昂贵，暂时不安装X-pack包。
1.4 Elasticsearch的Head插件
Head插件作为ELK 2.x版本中较为通用的前端管理插件，在ELK 5.x版本中无法直接使用./bin/elasticsearch-plugin install head的方式安装，但是可以采取standalone的方式进行运行。
参考官方文档：https://github.com/mobz/elasticsearch-head#running-with-built-in-server
一篇较好的ES 5.x安装Head的博文：http://www.cnblogs.com/xing901022/p/6030296.html
【特别注意】：暂时没有找到x-pack和head相互兼容的方法，目前由于认证的问题，如果启用了x-pack的secure功能，会导致head插件无法连接ES集群。
二、Logstash的部署
与Elasticsearch类似，在官网下载压缩包后，解压即可用。
在非高级场景下，Logstash本身不需要进行太多的配置（配置文件在logstash根目录下的./config/logstash.yml），高级场景请参考官方文档。
logstash的启动命令为:./bin/logstash -f --config.reload.automatic，其中-f指定了pipeline配置文件的位置，--config.reload.automatic指定了pipeline配置文件可以进行热加载。
本次我们使用Logstash作为日志解析模块（Logstash其实也可以作为日志采集器），重点需要配置pipeline的三大部分：input、filter和output。pipeline文件需要自己创建。
我们选取Kafka作为数据输入。
| 1234567891011121314 | input {kafka{bootstrap_servers => "xxx1:9092,xxx2:9092,xxx3:9092"topics => ["log_analysis","system_metric_monitor","sf_web_log","sf_engine_log","sf_platform_log"]codec => "json"group_id => "logstash"session_timeout_ms => "80000"request_timeout_ms => "810000"heartbeat_interval_ms => "1000"consumer_threads => 8#max_poll_records => "100"auto_commit_interval_ms => "1000"}} |
其中需要重点注意session_timeout_ms与request_timeout_ms两项，在logstash消费能力不足时，需要酌情修改上述两个timeout值，以防止kafka无法及时获取数据offset的问题。
2.2 filter配置
filter是重中之重，负责针对不同来源的日志进行解析。
本次使用数据中的fields.msg_type字段判断日志类型（属于文件日志还是系统metric），并使用fields.log_tag标记具体的来源模块。
当前使用的一个例子：
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！
