Elastic Stack 生态是 Elastic 公司最近两三年提出的架构，如果你对 Elastic Stack 陌生，那我们先聊聊它的前身 ELK 生态。
ELK 是 Elastic 公司的三个开源项目的缩写，这三个项目分别如下。
Elasticsearch：基于 Apache Lucene 搜索引擎，使用 RESTful 接口屏蔽了搜索架构的复杂性。
Logstash：服务器数据处理管道。
Kibana：Elasticsearch 搜索引擎的可视化平台。
当应用服务的日志通过 Logstash 进行结构化处理，进入 Elasticsearch 搜索引擎后，海量的日志就具备了在 Kibana 平台上的集中式实时分析的能力。
以上三者便让 Elastic Stack 成为目前最流行，也最具代表性的日志分析架构。在了解 Elastic Stack 之前，我们需要先了解下日志分析架构的演进过程。
日志分析框架的演进学习过往，助于引发我们对当下日志分析架构的思考：理解为什么 Elastic Stack 生态是最优解？Elastic Stack 生态又到底解决了什么痛点？
日志分析架构大致有以下三个阶段。
1.“原始”时期时间拨回 2000 年初，互联网刚刚兴起，整体的应用服务架构还未进入微服务时代，应用服务大多都是单体的，所以应用服务的日志天生就是集中在那台单体机器上打印的日志。
由于互联网企业都着眼在拓展业务上，且当时的开发人员也都非常淳朴，还没有窃取公司数据贩卖的案例。顺应当时的时代背景，大多数公司的一线开发都被授予直接登录服务器的管理员权限。
所以这个时候开发人员一般都使用 Llinux 服务器的统计命令来探索和分析日志。
2.集中式日志架构初期时间往后拨几年，互联网应用进入了微服务架构时代。随着产品根据不同的功能，切分为多个微服务，企业的产品迭代迎来了质的提效。
但任何事物都没有单方面的优点，不加治理的微服务让日志结构更加复杂，再加上流量红利，日志的复杂度和量级都以指数趋势上升。即使一线开发依然被授予应用服务器的管理员权限，“原始”的日志分析手段也变得耗时、费力，且效率低下。
这时，无法高效的处理，复杂日志场景的缺点完全暴露出来了，再加上安全审计的监管要求，集中式日志架构的诉求呼之欲去。
由于此时市场上还没有开源好用的集中式日志架构，为了快速解决这一问题，最典型的架构就是使用 Hadoop 平台实现日志的离线处理。不过 Hadoop 框架是编程框架，并非可以拿来即用的日志分析平台。
所以这个阶段的集中式日志架构的共通点是：需要耗费人力通过编码才能实现，且上线后实时性较差。
重新认识日志在展开对Kibana的学习前，我们有必要重新认识下原始物料，就是每一行日志的内容。理解日志的内容，有助于更好地学习下文的“如何对海量日志进行搜索和图形化展示”部分。
因为如果不对原始物料进行思索，贸然接入 Elastic Stack 日志架构后，会发现存到 Elasticsearch 搜索引擎日志数据会仅有时间戳和原始日志内容。这样在探索和分析上，由于都是未加处理成结构化的日志，根本无法发挥Kibana的可视化能力。所以为了让日志更具备分析性，便需要先复习下当下日志的内容，然后再学习如何进行探索和分析。
当下的业务开发人员都是将日志信息委托给日志框架进行打印，所以日志内容可以分为两类：
日志框架打印的日志信息
一线开发人员打印的日志信息
除了业务开发人员通过日志框架打印业务日志外，在框架层面还有框架日志。
其中日志框架打印的信息，常用的属性如下。
时间戳：调用日志方法时生成时间戳，解决异步打印、异步收集造成的时间不精准问题。
线程名称：由于线程 ID 不直观，所以通常使用线程名称来标识线程（注意不可以使用默认线程名称，需要根据使用线程情况来重命名线程名称）。
日志级别：根据日志级别的不同，可粗略地对日志进行预处理。比如 DEBUG、TRACE 级别的日志只有在定位问题时才记录；当日志为 ERROR 级别时，立刻发出告警。
调用位置：记录打印日志的类名和行号，有助于开发人员快速寻找源代码的上下文现场。
增强属性：如全链路跟踪 ID，用于追溯引起日志打印的上下游。
那现在可以简单认为：日志在接入 Elastic Stack 生态后，通过Grok 工具使用与结构化匹配的正则，将原始日志提取出通用的日志属性和对应的值，产出结构化的 Elasticsearch Doc 文档。然后再将其存储到 Elasticsearch 中，开发人员就可以根据这些属性在 Kibana 中，更好地进行日志数据的探索和分析了。
Kibana 探索和分析日志使用 Kibana 探索和分析日志大致分为以下三种使用方式。
第一种：通过 Kibana 探索（Discovery）功能，进行准确、实时的集中日志搜索。
第二种：创建多样的可视化视图（Visualize），将相关联的视图组合成仪表盘（Dashboard）。
第三种：通过 Elasticsearch SQL 直接从 Elasticsearch 中提取数据，加上丰富元素布局绘制画布（Canvas）。
前两种相对通用，使用方式都是必须基于创建索引模式（index pattern），然后对索引数据进行探索和分析，而第三种相较前两种也较个性化和高级。
1.创建索引模式索引模式告诉 Kibana 哪些 Elasticsearch 索引包含了你想处理的日志数据，创建索引模式有多种方式，最常见的就是使用后置通配符。
在单个 Elasticsearch 集群内部完成索引模式的创建。如下图所示，集群内部有多个以“天”为切分维度的日志索引。如 data_logs-20210307、data_logs-20210306、data_logs-20210305 等，我们可以通过 data_logs-* 的正则表达式完成索引的匹配。
在创建好一个日志索引模式后，我们就可以在“探索页面”中搜索日志数据了；然后再在可视化视图中以图表、表格等方式分析数据。
探索功能非常容易上手，在企业内部 SRE 负责部署 Elastic Stack，一线业务开发只需将应用日志在机器上的地址和日志结构化正则表达式告诉给 SRE。
不一会儿在探索功能页面上就能看到应用服务所有节点的日志了。通过探索功能，开发人员可以搜索日志数据的每个属性，并过滤结果。
不仅如此，我们还可以获取与搜索相匹配的文档字段级详细信息，以及查看搜索命中日志前后发生的日志。下面探索场景包括以下三个部分。
搜索条件：网站请求非正常返回（HTTP 状态码非 200），且地域为中国流量。结果过滤：由于日志属性较多，实现只返回 IP 地址、机器设备和请求的 host。时间范围：最近七天。 3.制作多样的可视化视图可视化视图是制作仪表盘的素材，视图的质量紧密关着仪表盘的效果。如何掌握制作可视化视图呢？我们可以先学习最热门视图，然后在对更多视图的学习逐个击破，目前 Kibana 可视化视图共有 20 个左右的视图。