监控系统---（二）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包将自动配置此设置。无需进行其他配置。

##配置完成，重启elasticsearch服务后，9200和9300端口监听所有接口

##Xmx设置不超过物理RAM的50％，以确保有足够的物理RAM留给内核文件系统缓存。但不要超过32G

在集群server102、server103主机进行如上配置使其加入到集群中

##通过9200端口访问此elasticsearch集群

cerebro可视化工具

##通过podman容器部署

##登陆可查看到elasticsearch集群信息

elasticsearch-head插件安装

##下载插件压缩包并解压

head插件本质上是一个nodejs的工程，因此需要安装node

curl -sL https://rpm.nodesource.com/setup_9.x | bash -

##下载nodesource仓库文件

##安装nodejs-9.11.2

关于npm、nodejs可参考博客：npm是干什么的?为什么要使用npm？（适合不太了解 npm 的新人阅读）_山淼的博客-CSDN博客_npm怎么读网上的 npm 教程主要都在讲怎么安装、配置和使用 npm，却不告诉新人「为什么要使用 npm」。今天我就来讲讲这个话题。本文目标读者是「不太了解 npm 的新人」 。社区程序员自古以来就有社区文化：社区的意思是：拥有共同职业或兴趣的人们，自发组织在一起，通过分享信息和资源进行合作。虚拟社区的参与者经常会在线讨论相关话题，或访问某些网站。前端程序员也有社区，世界上最大的前端社区应该就是 GitHub 了。前端通过 GitHub 来分享源代码（线上代码仓库）讨论问题（Issue 列表）收https://blog.csdn.net/qq_43229056/article/details/109895437?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522163653849816780264060141%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=163653849816780264060141&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~top_positive~default-1-109895437.first_rank_v2_pc_rank_v29&utm_term=npm&spm=1018.2226.3001.4187

##安装cnpm

关于npm和cnpm的区别可参考博客：cnpm与npm的区别_种花童心-CSDN博客

##使用cnpm安装依赖模块

##修改ES主机ip和端口

##启动head插件

##访问插件的web页面，此时集群状态显示为未连接

##head插件服务使用的端口号可以在这个文件中自定义

##配置elasticsearch支持跨域访问并重启elasticsearch服务

关于跨域：​​​​​​什么是跨域及怎么解决跨域问题？_lianzhang861的博客-CSDN博客_如何解决跨域问题

##此时集群状态变为正常的绿色

##创建索引；此时索引分片在server2和server3主机上，且各有一个分片

##停掉server102主机的elasticsearch服务然后重新启动后，server102主机的分片迁移至server101主机上

##此时通过集群其他节点连接head插件时显示未连接状态

##配置server102、server103主机elasticsearch服务的跨域访问后即可通过节点连接head插件

elasticsearch集群节点角色及节点优化

集群节点角色

Master：主要负责集群中索引的创建、删除以及数据的Rebalance等操作；Master不负责数据的索引和检索，所以负载较轻；当Master节点失联或者挂掉的时候，ES集群会自动从其他Master节点选举出一个Leader

Data Node：主要负责集群中数据的索引和检索，一般压力比较大

Coordinating Node： 原来的Client node，主要功能是来分发请求和合并结果；所有节点默认就是Coordinating node，且不能关闭该属性

Ingest Node：专门对索引的文档做预处理

elasticsearch节点优化

在生产环境下，如果不修改elasticsearch节点的角色信息，在高数据量、高并发的场景下集群容易出现脑裂等问题；默认情况下，elasticsearch集群中每个节点都有成为主节点的资格，也都存储数据，还可以提供查询服务

节点角色是由以下属性控制：【node.master==false/true】【node.data==true/false】【node.ingest==true/false】【search.remote.connect==true/false】；默认情况下这些属性的值都是true

node.master：这个属性表示节点是否具有成为主节点的资格 ，但此属性的值为true并不意味着这个节点就是主节点，因为真正的主节点，是由多个具有主节点资格的节点进行选举产生的

node.data：这个属性表示节点是否存储数据

node.ingest: 是否对文档进行预处理

search.remote.connect：是否禁用跨集群查询

第一种组合（默认）：

【node.master: true】【node.data: true】【node.ingest:  true】【search.remote.connect: true】

这种组合表示这个节点即有成为主节点的资格，又存储数据；如果某个节点被选举成为了真正的主节点，那么他还要存储数据，这样对于这个节点的压力就比较大了；测试环境下这样做没问题，但实际工作中不建议这样设置

第二种组合（Data node）：

【node.master: false】【node.data: true】【node.ingest: false】【search.remote.connect: false】

这种组合表示这个节点没有成为主节点的资格，也就不参与选举，只会存储数据；这个节点称为data(数据)节点；在集群中需要单独设置几个这样的节点负责存储数据，后期提供存储和查询服务

第三种组合（master node）：【node.master: true】【node.data: false】【node.ingest: false】【search.remote.connect: false】

这种组合表示这个节点不会存储数据，有成为主节点的资格，可以参与选举，有可能成为真正的主节点，这个节点我们称为master节点

第四种组合（Coordinating Node）：【node.master: false】【node.data: false】【node.ingest: false】【search.remote.connect: false】

这种组合表示这个节点即不会成为主节点，也不会存储数据， 这个节点的意义是作为一个协调节点，主要是针对海量请求的时候可以进行负载均衡

第五种组合（Ingest Node）：【node.master: false】【node.data: false】【node.ingest: true】【search.remote.connect: false】

这种组合表示这个节点即不会成为主节点，也不会存储数据，这个节点的意义是ingest节点，对索引的文档做预处理

生产集群中可以对这些节点的职责进行划分：

建议集群中设置3台以上的节点作为master节点，这些节点只负责成为主节点，维护整个集群的状态

再根据数据量设置一批data节点，这些节点只负责存储数据，后期提供建立索引和查询索引的服务，这样的话如果用户请求比较频繁，这些节点的压力也会比较大

所以在集群中建议再设置一批协调节点，这些节点只负责处理用户请求，实现请求转发，负载均衡等功能

节点需求：

master节点：普通服务器即可(CPU、内存消耗一般)

data节点：主要消耗磁盘、内存（path.data: data1,data2,data3：这样的配置可能会导致数据写入不均匀，建议只指定一个数据路径，磁盘可以使用raid0阵列，而不需要成本高的ssd）

Coordinating节点：对cpu、memory要求较高

##配置server101主机作为集群的master节点时，重启elasticsearch服务后出现报错

##日志显示报错原因是此server101主机上还存在索引分片

##清除server101主机的分片数据后elasticsearch服务重启成功

##此时server101主机的分片迁移至server102主机上

##配置server102、server103主机为集群的数据和备选master节点

logstash数据采集

Logstash是一个开源的服务器端数据处理管道，其拥有200多个插件，能够同时从多个来源采集数据，转换数据，然后将数据发送到您最喜欢的“存储库”中（大多都是 Elasticsearch）；Logstash管道有两个必需的元素，输入和输出，以及一个可选元素过滤器

输入：采集各种样式、大小和来源的数据

Logstash支持各种输入选择，同时从众多常用来源捕捉事件，能够以连续的流式传输方式，轻松地从您的日志、指标、Web 应用、数据存储以及各种AWS服务采集数据

过滤器：实时解析和转换数据

数据从源传输到存储库的过程中，Logstash过滤器能够解析各个事件，识别已命名的字段以构建结构，并将它们转换成通用格式，以便更轻松、更快速地分析和实现商业价值

利用Grok从非结构化数据中派生出结构；从IP地址破译出地理坐标；将PII数据匿名化，完全排除敏感字段；简化整体处理，不受数据源、格式或架构的影响

输出：选择您的存储库，导出您的数据

尽管Elasticsearch是我们的首选输出方向，能够为我们的搜索和分析带来无限可能，但它并非唯一选择；Logstash提供众多输出选择，您可以将数据发送到您要指定的地方，并且能够灵活地解锁众多下游用例

软件下载：下载中心 - Elastic 中文社区

##安装logstash

##命令行标准输入到标准输出 

##文件方式标准输入到标准输出

##使用标准输入并定制数据格式且标准输出到文件

##输出至elasticsearch

##在elasticsearch的head插件查看logstash写入数据

##将系统日志/var/log/messages文件内容输出至es端

##查看es数据

##删除es端的数据

logstash通过把进度保存到sincedb文件中来区分设备、文件名、文件的不同版本

sincedb文件内容解释：sincedb文件一共6个字段，依次为inode编号---文件系统的主要设备号---文件系统的次要设备号---文件中的当前字节偏移量---最后一个活动时间戳（浮点数）---与此记录匹配的最后一个已知路径

##当sincedb文件存在时再次将/var/log/messages的文件内容输出至es时不会成功

##删除sincedb文件后，重新推送数据成功

##往日志文件中写入数据

##logstash可以伪装成日志服务器，直接接受远程日志

##配置客户端传入日志

##写入日志

##es端查看数据

##多行过滤可以把多行日志记录合并为一行事件(EOF字样可自定义)

##拷贝server101主机的my-es.log至server104主机并上传至es端

##my-es.log中有这样一个事件的日志但占用了很多行的行为，这样显然不便于运维人员查看和分析

##从es端删除my-es.log的索引

##删除sincedb文件，以便于重新推送my-es.log至es

##使用多行过滤把多行日志记录合并为一行事件

##完成！这下看着就很明了了

grok过滤插件

##安装apache，生成apache的acce_log

##写入更多日志

##可以看出apache的access_log都是有一定格式的但是是一个key对应一长串非结构化value的形式

##在logstash运行指定文件中添加grok过滤

##添加grok过滤后，标准输入的非结构化的请求日志被转换成结构化的键值对形式输出

##logstash定义了一些应用的日志格式，当然我们用户也可以自定义

##调用logstash已经维护好的apache混合日志格式作为过滤项

##此时输出至es的apache日志呈结构化的键值对形式

3.kibana日志可视化

软件下载：下载中心 - Elastic 中文社区

##安装kibana并配置，然后启动，默认监听5601端口

##访问浏览器页面

##创建索引模式

##创建可视化并生成访问量可视化

##修改数据更新时间间隔，以便查看效果；查看只今天的数据指标

##运行logstash收集apache的日志并输出至es(保持压测时一直是运行状态)

##此处本人是在logstash为运行时压测了1000的请求，当时是没反应，logstash一运行后kibana可视化的访问数量就发生变化

##使用不同主机进行压测

##保存此可视化

##创建apache_log的垂直条形图可视化

##生成柱状图

##保存此可视化柱状图

##将可视化添加至仪表板并保存

##将指标可视化添加至仪表板并保存

##设置可视化指标刷新频率，进入全屏模式查看效果

##进行压测并查看效果

kibana监控elasticsearch集群

##在图形化界面打开堆栈检测进入设置模式后有大量右下角形式的报错弹出

启用xpack安全验证

##集群模式需要先创建证书(需要输入密码时直接回车即可)

##拷贝证书至集群所有节点并配置所有节点的xpack验证，然后重启集群所有节点的elasticsearch服务

##重启成功后kibana连接es集群时需要进行验证；head插件连接集群也会失败

##交互式生成es集群操作用户的密码

##在kibana主机端指定连接es集群的用户及密码，重启kibana服务

##此时通过kibana用户登陆kibana显示资源不可用

##此时通过elastic用户登陆时则成功显示到监控页面，并且无报错窗口弹出

##此时配置使用Metricbeat监测server101节点，显示为检测到数据

配置Metricbeat监测es集群

##下载metricbeat软件包并安装

##配置启用metricbeat的elasticsearch-xpack模块并启动metricbeat服务

##q启动metricbeat一会儿后及可发现kibana监测es集群主机server101的数据迁移至使用metricbeat监测

点击主机名称即可看到metricbeat的监测数据

##配置head访问es的认证，重启elasticsearch服务

##http://172.25.100.101:9100/?auth_user=elastic&auth_password=westos 此时可以使用此URL通过server101连接es集群访问到数据，连接其他es集群节点则不行

##此时访问cerebro可视化es集群时也需要登陆认证

##配置整个es集群使用metricbeat进行数据监测

配置filebeat

FileBeat是一个日志收集器，基于Logstash-Forwarder的源代码；FileBeat一般以代理的身份运行在服务器中，并监视用户指定的目录、文件，同时把日志文件更新部分推送给Logstash解析或者直接推送给ES索引

FileBeat的工作方式：
当FileBeat在服务器上启动后，它同时启动一个或者多个prospectors来监视用户指定的日志文件目录
prospectors然后针对每个日志文件，都启动一个harvester，每一个harvester监视一个文件的新增内容，并把新增内容送到spooler中，然后spooler来汇总这些events事件，最后把这些事件传送给logstash或者es

软件下载：下载中心 - Elastic 中文社区

##安装filebeat并配置启动

##此时在kibana端即可看到采集的日志

##配置es集群中的server102、server103主机使用filebeat采集日志数据

##kibana查看日志