部署elk日志分析系统

日志分析是运维工程师解决系统故障，发现问题的主要手段。日志主要包括系统日志、应用程 序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的 错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠 正错误。 
通常，日志被分散的储存在不同的设备上。如果你管理数十上百台服务器，你还在使用依次登 录每台机器的传统方法查阅日志，即繁琐又效率低下。为此，我们可以使用集中化的日志管理，例 如：开源的 syslog，将所有服务器上的日志收集汇总。 
集中化管理日志后，日志的统计和检索又成为一件比较麻烦的事情，一般我们使用 grep、awk 和 wc 等 Linux 命令能实现检索和统计，但是对于更高要求的查询、排序和统计等，再加上庞大的机 器数量，使用这样的方法依然难免有点力不从心。 
开源实时日志分析 ELK 平台能够完美的解决我们上述的问题，ELK 由 ElasticSearch、Logstash 和 Kiabana 三个开源工具组成。官方网站：https://www.elastic.co/products 
Elasticsearch 是个开源分布式搜索引擎，它的特点有：分布式，零配置，自动发现，索引自 动分片，索引副本机制，restful 风格接口，多数据源，自动搜索负载等。 
Logstash 是一个完全开源的工具，它可以对你的日志进行收集、过滤，并将其存储，供以后使 用（如，搜索）。 
Kibana 也是一个开源和免费的工具，Kibana 可以为 Logstash 和 ElasticSearch 提供友好的 日志分析 Web 界面，可以帮助您汇总、分析和搜索重要数据日志。 
 
Logstash 收集 AppServer 产生的 Log，并存放到 ElasticSearch 集群中，而 Kibana 则从 ES 集 群中查询数据生成图表，再返回给 Browser。简单来说，进行日志处理分析，一般需要经过以下几 个步骤： 
1. 将日志进行集中化管理（beats） 2. 将日志格式化（logstash） 3. 对格式化后的数据进行索引和存储（elasticsearch） 4. 前端数据的展示（kibana） 
2 案例前置知识点： 
1) elasticsearch 介绍 
   Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎， 基于 RESTful web 接口。Elasticsearch 是用 Java 开发的，并作为 Apache 许可条款下的开放源码发布， 是第二流行的企业搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使 用方便。 Elasticsearch 的基础核心概念： 接近实时（NRT） elasticsearch 是一个接近实时的搜索平台，这意味着，从索引一个文档直到这个文档能够被搜索 到有一个轻微的延迟（通常是 1 秒）。 集群（cluster） 一个集群就是由一个或多个节点组织在一起，它们共同持有你整个的数据，并一起提供索引和 搜索功能。其中一个节点为主节点，这个主节点是可以通过选举产生的，并提供跨节点的联合索引 和搜索的功能。集群有一个唯一性标示的名字，默认是 elasticsearch，集群名字很重要，每个节点是 基于集群名字加入到其集群中的。因此，确保在不同环境中使用不同的集群名字。一个集群可以只 有一个节点。强烈建议在配置 elasticsearch 时，配置成集群模式。 
4 
节点（node） 节点就是一台单一的服务器，是集群的一部分，存储数据并参与集群的索引和搜索功能。像集 群一样，节点也是通过名字来标识，默认是在节点启动时随机分配的字符名。当然，你可以自己定 义。该名字也很重要，在集群中用于识别服务器对应的节点。  节点可以通过指定集群名字来加入到集群中。默认情况，每个节点被设置成加入到 elasticsearch 集群。如果启动了多个节点，假设能自动发现对方，他们将会自动组建一个名为 elasticsearch 的集群。
 索引（index） 一个索引就是一个拥有几分相似特征的文档的集合。比如说，你可以有一个客户数据的索引， 另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写 字母的），并且当我们要对对应于这个索引中的文档进行索引、搜索、更新和删除的时候，都要使 用到这个名字。在一个集群中，如果你想，可以定义任意多的索引。 索引相对于关系型数据库的库。 类型（type） 在一个索引中，你可以定义一种或多种类型。一个类型是你的索引的一个逻辑上的分类/分区， 其语义完全由你来定。通常，会为具有一组共同字段的文档定义一个类型。比如说，我们假设你运 营一个博客平台并且将你所有的数据存储到一个索引中。在这个索引中，你可以为用户数据定义一 个类型，为博客数据定义另一个类型，当然，也可以为评论数据定义另一个类型。  类型相对于关系型数据库的表。 文档（document）     一个文档是一个可被索引的基础信息单元。比如，你可以拥有某一个客户的文档，某一个产品 的一个文档，当然，也可以拥有某个订单的一个文档。文档以 JSON（Javascript Object Notation）格 式来表示，而 JSON 是一个到处存在的互联网数据交互格式。     在一个 index/type 里面，只要你想，你可以存储任意多的文档。注意，虽然一个文档在物理上 位于一个索引中，实际上一个文档必须在一个索引内被索引和分配一个类型。  文档相对于关系型数据库的列。 分片和副本（shards & replicas） 在实际情况下，索引存储的数据可能超过单个节点的硬件限制。如一个 10 亿文档需 1TB 空间 可能不适合存储在单个节点的磁盘上，或者从单个节点搜索请求太慢了。为了解决这个问题， elasticsearch 提供将索引分成多个分片的功能。当在创建索引时，可以定义想要分片的数量。每一个 分片就是一个全功能的独立的索引，可以位于集群中任何节点上。  分片的两个最主要原因：  a. 水平分割扩展，增大存储量  b. 分布式并行跨分片操作，提高性能和吞吐量  分布式分片的机制和搜索请求的文档如何汇总完全是有 elasticsearch 控制的，这些对用户而言是 透明的。  网络问题等等其它问题可以在任何时候不期而至，为了健壮性，强烈建议要有一个故障切换机 制，无论何种故障以防止分片或者节点不可用。 为此，elasticsearch 让我们将索引分片复制一份或 多份，称之为分片副本或副本。  副本也有两个最主要原因：  a. 高可用性，以应对分片或者节点故障。出于这个原因，分片副本要在不同的节点上。  b. 提供性能，增大吞吐量，搜索可以并行在所有副本上执行。 
5 
总之，每个索引可以被分成多个分片。一个索引也可以被复制 0 次（意思是没有复制）或多次。 一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之 别。分片和副本的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改 变副本的数量，但是你事后不能改变分片的数量。      默认情况下&#