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

分享人：李猛
一、什么是全观测性

全观测性简单讲就是“监控”、“一体化的监控”。它包括几个方面：一方面叫日志数据，就是文本，第二方面包括一些指标数据，第三方面就是这套产品必须有告警通知。

日志数据

工作开发中日志是免不了的，它一般包含几个重要信息，比如发生时间、发生模块和详细信息等。

指标数据

指标可以理解为文本日志的高级抽象，主要用来记录数值类型的数据，如CPU、内存图、磁盘等。

告警通知

在日志和指标采集后就要做一些告警规则，比如日志的错误达到某一数量，或CPU消耗占到某一比例的时候进行触发；另外，它还要能够发通知给我们，比如通过Webhook等；最后，在面对庞大日志和指标数据量的时候，还需要进行智能化，通过机器学习自动生成规则，并在规则基础上自动监测异常。

二、为什么是Elastic Stack？

Elastic Stack技术栈分由4个产品栈组成，包括做UI展示的Kibana，负责数据存储、查询、计算、聚合的Elasticsearch，负责数据采集的Beats，以及ETL轻量级工具Logstash。

Kibana

Kibana能把所有的日志数据集中起来，在一个界面上就能搜索和查看。同时在这里我们可以看到，不管是日志还是指标，它们展示出来都一样。

另外，Kibana还有个更高级的功能叫Alerts and Actions，就是用来做安全告警通知。我们可以在里面写一些自定义的告警规则，然后创建一些action。所以，Kibana相当于把日志的展现和告警一体化了。

Elasticsearch

Elasticsearch是我们的核心，它主要有3个职责，数据存储、数据查询和数据分析。首先，它能把Pb级海量的数据存储到ES上；随后，它能基于倒排索引支持海量的数据查询，在做多条件检索的时候它可以说是最快的索引算法；最后，它还能支持行式和列式的分析，比如用行式分析来做明细查询，用列式分析来做统计分析。

Beats

Beats主要用于数据采集，非常轻量级，包括Auditbeat、Metricbeat、Filebeat、Packetbeat、Heartbeat和Winlogbeat几种。为了和Logstash做职责区分，Beats就主要做日志数据采集，但如果遇到一些数据需要做自定义转换，就需要把采集完的数据先传到Logstash里进行一些处理再写到ES里。

Filebeat

Filebeat专门采集文本日志，比如服务器和应用上的文本log。另外，Filebeat已经写好了规则，非常方便。比如如果要抓取ES的日志，它里面直接有一个ES的模块，日志格式都帮忙解析完成了，只需要配一个日志路径就能完成采集。所以Beats家族更加“傻瓜化”，把Logstash的可编程性都替代掉了，直接做成最终落地。

Metricbeat

Metricbeat专门采集指标数据，启动之后直接对接应用、中间件，它们都可以采集。比如这个图里面是采集操作系统的，我可以直接部署在这台操作系统上面，然后就可以监测到操作系统里面到底有多少资源在消耗内存、CPU、网络等等。我们也可以自己拓展里面的配制模块，自己编写规则，自己去采集。

Packetbeat

Packetbeat主要采集网络数据，它比Metricbeat采集的网络数据更详细，Metricbeat只能监测到我的网卡数据进了多少出了多少，而Packetbeat能知道网络的数据有多少，朝哪些IP去了，有多少是哪些IP访问进来。我们可以把它看作是日志数据和指标数据的结合，因为网络地址是一个字符串，而流量又是指标，所以我们说全观测，不外乎就是这两种数据，而如果再抽象一点，最终只有文本数据。

Heartbeat

Heartbeat负责监控应用的心跳。比如Java开发现在最流行的用微服务，虽然微服务里面可以监控应用的上线下线，但是它并不是很全面，仅仅只能监控自己的微服务。如果要监控别的，比如一套大型的分布式系统，就需要在Heartbeat里面配置。

APM

最后再和大家推荐一个APM，就是应用程序性能监控。这是我们开发人员最关心的，很多公司加入程序后什么监控都没有，请求数量、响应数量、请求时间、响应时间都不知道。但是如果了解过Elastic Stack就会发现，它能把你需要研发的东西一网打尽，这个就是APM。比如这里面举了几个图，你可以看到程序每分钟的请求数量，也可以看到服务的调用链路……

我们一个一个来讲，下面这个是APM高层次的调用链路图。如果我的微服务有几十个或者上百个几百个不同的应用、服务，调用的时候就有严格的一个调用链路，那么我们能从这里面看到前段和后端整个链路，这是ES推出APM自动采集数据之后自动绘制的。

除了上面的应用程序，它服务之间也有绘制相应的图。比如下面你从Java调到Go再调到Ruby，它都可以帮你自动来绘制出来，仅仅只需要把你的应用程序部署起来就可以了。

Logstash

Logstash以前是日志采集的工具，基本上已知的所有数据它都支持，数据库、文本、日志、网络都可以采集进来，然后经过它的中间转换传输到ES中去。但是现在我们把它定位成数据的ETL，比如前端Beats采集完数据后放到Kafka，而数据到ES里面又需要Logstash来抽取，所以它相当于一个典型的ETL。

以上就是我们对为什么选择Elastic Stack的解释，因为我们全观测性监控需要一体化，需要这么多数据的采集展示，而目前只有ES一家做的比较全。

接下来我们介绍一下全观测的应用场景，一些案例。

三、全观测性行业应用场景

例1：微服务平台

现在做传统业务系统开发或者分布式软件都离不开微服务的理念。比如某大型微服务业务系统应用可能要部署几百个，然后在下面拆分为用户商品订单、支付、仓储、数据等等，这些可以按照领域拆分，也可以从垂直或水平方向拆分，而且它们部署的数量都不一样，比如如果用户的服务请求量特别大，它可能就要部署20、30个。

这些数据我们最关注的是APM，就是综合的应用指标，来看它服务的请求数量，哪些服务比较慢，什么时间比较慢等等；第二个，微服务会写入大量的日志文本数据，有的是系统相关，有的是业务相关，我们都要通过Filebeat采集过来；第三个，我们会用到Heartbeat。比如当用户的服务突然下线了，从20个下线到12个，我们就需要它进行告警。

还有最关键的这些微服务的链路调用，比如User、Product和Order之间的互相调用，可能调用过程中就把程序串联起来了，这对我们的分析非常重要。目前来说，没有哪个产品能像ES一样，把应用开发和微服务需要的这种监控做到一体化。

例2：中间件平台

中间件是应用系统里面必不可少的，比如数据库、缓存等等。举个例子，比如我们现在做分布式开发，要写一堆分布式任务调度，调度任务为了做到高可用就要部署多个高实例，这就要每一时刻只能有一个程序在运行。这里面会用到Zookeeper来做Leader选取协调，用它把中间件做一个监控，因为任何时候出了故障可能就意味着你的服务程序会失败，运营出错。

再一个就是Kafka。我们前面讲到微服务调用，几百个微服务有那么多数据采集，数据量是非常大的，所以会引入Kafka承担信息缓冲，它非常重要，所以我们也会对它进行完整的链路监控。

例3：基础平台

我们的服务程序一般是部署在操作系统上面，不管是用云，还是用自己的自主机房，还是用私有云，私有云或者是云平台的监控至关重要。比如网络突然出现瞬间的阻塞怎么办？磁盘空间满了不够了怎么办？这些都需要我们实时地去监控采集。

我们可以从这个系统指标的demo图看到，采集操作系统的指标，网络、磁盘、CPU、内存、交换区、负载、应用程序等。因为我们一台服务器实际部署的时候肯定不止一个，微服务可能部署了很多个，所以对这套操作系统的监控也很重要。

以上关于全观测性在具体行业的应用我们基本上讲完了，包括应用系统、中间件和操作系统。其实从个人的职业生涯开发周期来看，我们所有做的监控就是这三个场面。如果你是作为一个普通开发人员，你最关心的可能就是Java应用程序、服务接口、处理能力、数据量之类的；如果你稍微资深一点，可能关心Java APP的问题；如果你是一个架构师，可能要关心更加综合一点的东西，如果你是运维或者公司的总监，你需要通盘关注，而这就需要一个更加整体的技术平台。