监控系统---（二）ELK日志分析平台

 日志主要包括系统日志、应用程序日志和安全日志。系统运维和开发人员可以通过日志了解服务器软硬件信息、检查配置过程中的错误及错误发生的原因。经常分析日志可以了解服务器的负荷，性能安全性，从而及时采取措施纠正错误。

通常，日志被分散在储存不同的设备上。如果你管理数十上百台服务器，你还在使用依次登录每台机器的传统方法查阅日志。这样是不是感觉很繁琐和效率低下。当务之急我们使用集中化的日志管理，例如：开源的syslog，将所有服务器上的日志收集汇总。

集中化管理日志后，日志的统计和检索又成为一件比较麻烦的事情，一般我们使用grep、awk和wc等Linux命令能实现检索和统计，但是对于要求更高的查询、排序和统计等要求和庞大的机器数量依然使用这样的方法难免有点力不从心。

通过我们需要对日志进行集中化管理，将所有机器上的日志信息收集、汇总到一起。完整的日志数据具有非常重要的作用：
1）信息查找。通过检索日志信息，定位相应的bug，找出解决方案。
2）服务诊断。通过对日志信息进行统计、分析，了解服务器的负荷和服务运行状态，找出耗时请求进行优化等等。
3）数据分析。如果是格式化的log，可以做进一步的数据分析，统计、聚合出有意义的信息，比如根据请求中的商品id，找出TOP10用户感兴趣商品。

开源实时日志分析ELK平台能够完美的解决我们上述的问题，ELK由ElasticSearch、Logstash和Kiabana三个开源工具组成：
1）ElasticSearch是一个基于Lucene的开源分布式搜索服务器。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是第二流行的企业搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
在elasticsearch中，所有节点的数据是均等的。
2）Logstash是一个完全开源的工具，它可以对你的日志进行收集、过滤、分析，支持大量的数据获取方法，并将其存储供以后使用（如搜索）。说到搜索，logstash带有一个web界面，搜索和展示所有日志。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。
3）Kibana 是一个基于浏览器页面的Elasticsearch前端展示工具，也是一个开源和免费的工具，Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助您汇总、分析和搜索重要数据日志。

为什么要用到ELK？
一般我们需要进行日志分析场景是：直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。
一般大型系统是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。

一般大型系统是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。
一个完整的集中式日志系统，需要包含以下几个主要特点：
1）收集－能够采集多种来源的日志数据
2）传输－能够稳定的把日志数据传输到中央系统
3）存储－如何存储日志数据
4）分析－可以支持 UI 分析
5）警告－能够提供错误报告，监控机制

ELK提供了一整套解决方案，并且都是开源软件，之间互相配合使用，完美衔接，高效的满足了很多场合的应用。目前主流的一种日志系统。

ELK是三个开源软件的缩写，分别表示：Elasticsearch、Logstash、Kibana，它们都是开源软件；新增了一个FileBeat，它是一个轻量级的日志收集处理工具(Agent)，Filebeat占用资源少，适合于在各个服务器上搜集日志后传输给Logstash，官方也推荐此工具

Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能；它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等；主要负责将日志索引并存储起来，方便业务方检索查询

Logstash主要是用来做日志的搜集、分析、过滤的工具，支持大量的数据获取方式；一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作然后一并发往elasticsearch上去，简单来说就是一个日志收集、过滤、转发的中间件，主要负责将各条业务线的各类日志统一收集、过滤后，转发给Elasticsearch进行下一步处理

Kibana也是一个开源和免费的工具，Kibana可以为Logstash和ElasticSearch提供日志分析友好的 Web界面，可以帮助汇总、分析和搜索重要数据日志

elasticsearch

Elasticsearch是一个开源的分布式搜索分析引擎，建立在一个全文搜索引擎库Apache Lucene基础之上

Elasticsearch不仅仅是Lucene，并且也不仅仅只是一个全文搜索引擎：

一个分布式的实时文档存储，每个字段可以被索引与搜索

一个分布式实时分析搜索引擎

能胜任上百个服务节点的扩展，并支持PB级别的结构化或者非结构化数据

基础模块：

cluster：管理集群状态，维护集群层面的配置信息

alloction：封装了分片分配相关的功能和策略

discovery：发现集群中的节点，以及选举主节点

gateway：对收到master广播下来的集群状态数据的持久化存储

indices：管理全局级的索引设置

http：允许通过JSON over HTTP的方式访问ES的API

transport：用于集群内节点之间的内部通信

engine：封装了对Lucene的操作及translog的调用

elasticsearch应用场景：信息检索、日志分析、业务数据分析、数据库加速、运维指标监控

官网：

Elastic Stack and Product Documentation | Elastichttps://www.elastic.co/guide/index.html软件下载：

下载中心 - Elastic 中文社区Elastic 官方中文社区，围绕 Elastic 开源项目：elasticsearch、logstash、kibana、beats 等及周边技术的交流与探讨。https://elasticsearch.cn/download安装elasticsearch：

##下载并安装elasticsearch并启动；7.6版本自代JDK

##elasticsearch默认监听本地lo的9200和9300端口

搭建elasticsearch集群

##配置elasticsearch的yml配置文件，声明集群信息

启动集群前的一些配置：

理想情况下，Elasticsearch应该在服务器上单独运行，并使用所有可用的资源。为此，您需要配置操作系统，允许运行Elasticsearch的用户访问比默认情况下允许的更多的资源

大多数操作系统都试图为文件系统缓存使用尽可能多的内存，并急切地交换未使用的应用程序内存。这可能导致JVM堆的某些部分甚至其可执行页面被交换到磁盘。

交换对性能和节点稳定性都非常不利，应该不惜一切代价避免。它可能导致垃圾收集持续几分钟而不是几毫秒，并可能导致节点响应缓慢，甚至断开与集群的连接。在弹性分布式系统中，让操作系统杀死节点更有效。

有三种方法可以禁用交换。首选选项是完全禁用交换。如果这不是一个选项，那么选择最小化交换性还是选择内存锁定取决于您的环境。

通常Elasticsearch是运行在机器上的唯一服务，它的内存使用由JVM选项控制。应该不需要启用交换

##此步骤配置不需要重启elasticsearch服务

Linux系统上的另一个可用选项是确保sysctl值vm.Swappiness设置为1。这减少了内核交换的倾向，并且在正常情况下不应该导致交换，而在紧急情况下仍然允许整个系统进行交换。

另一种选择是在Linux/Unix系统上使用mlockall，或者在Windows上使用VirtualLock，尝试将进程地址空间锁定到RAM中，防止任何Elasticsearch内存被交换出去。这可以通过将 bootstrap.memory_lock: true 添加到config/elasticsearch.yml文件中来实现

启动elasticsearch后，如果看到mlockall为false，则意味着mlockall请求失败。您还将在日志中看到一行带有更多信息的内容，其中有“Unable to lock JVM Memory”字样。

在Linux/Unix系统上，最可能的原因是运行Elasticsearch的用户没有锁定内存的权限。这可以通过以下方式授予；当在使用systemd的系统上使用RPM或Debian包时，必须通过systemd指定系统限制

Elasticsearch使用了大量的文件描述符或文件句柄。耗尽文件描述符可能是灾难性的，并且很可能导致数据丢失。请确保将运行Elasticsearch的用户打开文件描述符的数量限制增加到65,536或更高；而RPM和Debian包已经默认文件描述符的最大数量为65535，不需要进一步配置。

Elasticsearch默认使用一个mmapfs目录来存储索引。操作系统对mmap计数的默认限制可能太低，这可能导致内存不足异常；而RPM和Debian包将自动配置此设置。无需进行其他配置。