Elasticsearch 全观测技术解析与应用（三）:能力呈现与应用价值-阿里云开发者社区

Elasticsearch 全观测技术解析与应用（三）:能力呈现与应用价值

2020-12-17 1272

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

检索分析服务 Elasticsearch 版，2核4GB开发者规格 1个月

简介： 本文梳理了全观测流程，介绍了Elastic的整套工具及其在全观测中的能力，并且用两个实例展示了如何用这些工具进行全观测。

点击免费下载
《Elasticsearch 全观测技术解析与应用》>>>

分享嘉宾：朱杰

这节课承接《全观测技术原理与技术生态》，介绍Elastic整套工具带来的能力，以及用demo展示怎么用这些能力构建全方位的观测性。

实现全观测主要有以下步骤

第一步是数据采集，这些数据可能来自日志、指标或APM，每一种数据都有对应的采集工具；数据采集完成后，会进到Kafka这样的数据汇聚层，以经济高效的方式保证海量数据的涌入；随后在数据处理层，有Logstash等工具对数据进行加工、转换、清洗，变成结构化数据，然后交由Elasticsearch进行存储和提供搜索能力；最后，可以通过Kibana进行数据的可视化，以及用机器学习进行告警。

目前，除数据汇聚层的Kafka外，Elasticsearch提供的工具已经贯穿了全观测的全链路，能在各环节提供相应的工具。

Elastic Stack提供的数据采集全套工具

即用；Metricbeat采集指标和底层的性能数据，有40多个插件；Packetbeat从网络包层面采集数据；Functionbeat主要对接在云端吐出来的指标日子；Winlogbeat主要适配Windows上的日志系统；Heartbeat主要检测服务的可用性，比如检测API是否在线等；最后，Auditbeat可以连到Linux的audit framework来采集Linux各种各样的事件，汇总到Elasticsearch。除此之外，我们的社区也制造了很多beat，大家可以去看看。

数据处理工具

数据处理工具提供的是Logstash，它分为输入、过滤和输出三个部分。它并不是独属于Elasticsearch数据输入和输出的工具，它有很多数据接入源，比如syslog、redis等，输出也可以到Kafka、Elasticsearch和其他数据库，而它的过滤部分主要体现在数据的加工和处理，比如用grok进行正则抽取。Logstash能很容易地把像日志一样的流式文本抽取成Json的结构化数据，进而给后面的Elasticsearch进行存储和索引。

数据存储搜索工具

这部分主要由Elasticsearch提供核心的功能。Elasticsearch经过了一系列演变，从倒排序仅支持全文搜索，到列存储支持结构化数据，加速排序聚合，再到BKD树支持的数值型运算，提升数值类型的范围搜索效率，以及数据上卷节省存储空间。

经过演变，Elasticsearch能支持结构化的数据搜索和聚合，还有全文搜索、地理搜索等能力。这种丰富的处理能力可以应用到全观测的应用场景，产生很多有价值的图表分析。同时，它还有自动化的监测监控，并且执行告警。

告警系统

全观测需要持续部署大量的监控规则，来自动化地进行监控和告警。我们在Kibana里植入了新的告警系统，它能跟上层的各种APP和解决方案进行无缝整合，大幅简化使用门槛

除了基于规则的告警，Elastic Stack还提供了机器学习的异常检测。

Elasticsearch中存在大量的指标数据，它们随时间序列的波动是非常常见的，但当指标数量越来越多，就很难用传统的方式一个一个地设置规则。所以我们利用机器学习，通过对历史数据的建模去学习正常的波动范围，不再需要人工来标注数据。同时，模型也会根据数据的持续写入来不停地更新，以反映最新的指标状态。

数据分析和展示工具

Kibana经过演化现在已经拥有了丰富的可视化展示能力，并且我们引入了Kibana Lens这样更加便捷的制图工具，同时也不断添加各种图表类型，帮助展示Elasticsearch里的各种数据。

把工具组合起来使用——两个全观测实例

下面这张仪表板的图，融合了日志、指标和APM数据，能进行统一的过滤、搜索和展示等。我们能从多个维度进行统计和观测，同时，日志、指标和APM数据也能对齐时间，对照着进行分析。

另外因为所有的数据都汇聚到这儿，所以我们可以建立统一的基于规则的监控和告，并通过参考三份数据源，来判断是否要触发某一个告警，减少误判。此外，我们还能建立统一的基于机器学习的智能监控和告警。

再看另外一个较复杂的实例。

下图呈现了当前常见的微服务架构，它所有的服务都部署在K8s容器化的环境中。在前端，它全部基于Nodejs提供Web服务，而核心业务是基于Spring框架的Java服务，并连接到后端MySQL数据库，同时它还有基于Python Flash提供地址查询的Rest API服务，通过连接Elasticsearch服务器实现全文搜索的功能。

那么我们如何用上面的工具对这一架构进行监测呢？

首先我们采用Filebeat去采集每一个Pod的日志，把它们汇总到Elasticsearch里，然后通过Metricbeat采集系统的性能数据，以及把Packetbeat安装在某些Pod中采集网络包数据，最后是用APM探针植入到Nodejs、Java代码和Python中监控代码层面的各种性能、响应、延迟等数据。

通过这些，我们就能把日志、指标、APM数据汇总到一起，统一地进行观测。同时，由于数据量很大，所以也将使用机器学习来对里面的性能指标进行自动化的监控和告警。

从故障告警到故障定位的流程

全观测定位故障主要有以下几步。首先我们会收到来自机器学习的警告，告知我们可能遇到了问题，随后我们可以点击链接跳转到Kibana的分析平台。在机器学习的告警页面，会把告警全部对齐，方便我们去分析各个服务之间的状态和依赖关系等。

在看到告警之后我们可以进行排查，通过跳转到其他的Kibana应用来帮助我们进行侦测和定位各种故障。比如跳到APM应用程序中，从APM的角度观测发生故障时代码层面的一些异常，或者在综合仪表板中统一地观测各种数据，或者在指标的应用中看到发生故障时K8s基础架构的情况。

下面我们更具体地来看定位故障的每一步流程。

机器学习告警

我们能在机器学习告警页面看到很多机器学习的任务，他们能够进行告警对齐。另外，机器学习根据API响应时间的历史情况自动建模，当监控值超过动态阈值就触发告警，并且可以指出是哪个API性能下降。这旁边还有action，能引导我们到其他应用中做分析，比如跳转到APM、仪表板、指标、Uptime等来诊断这个故障。