一、需求描述

在上一篇《利用Vector和鸿鹄搭建微服务应用的可观测性平台》中，阐述了微服务的基本概念、优点及如何利用鸿鹄来处理分布式应用的日志。本文将进一步讨论微服务架构面临的问题、服务网格及鸿鹄处理Istio Gateway的独特优势。

1.1 微服务架构面临的挑战

1.1.1 云基础设施并不总是可靠

无论是公有云还是私有云，都由成千上万的硬件和软件构成。理论上，或多或少存在不可用的组件。而我们的微服务一般会部署在云上，工程师在构建微服务时，一般都会假设基础设施是非永久的且部分基础设施甚至是不可用状态。所以在架构中，必须前瞻性地考虑云基础设施的非永久性特征。

1.1.2 必须确保服务之间通信的弹性

因为云基础设施的不可靠性，在设计微服务系统的时候，需要考虑服务本身的弹性，确保部分基础设施不可用的情况下，还能持续对外提供服务。业界目前一般有如下的解决方案：

• 客户端负载均衡: 提供多个服务端点，由客户端决定如何调用

• 服务发现机制：定期的更新健康的服务端点

• 短路：对于非正常的服务，实施一定时间的隔离

• 限制措施：对连接数、线程数、会话数等进行限制

• 超时：对API请求的时长，设置超时机制

• 重试及重试控制：失败重试及限制最大重试次数或一定时间范围内的重试次数

• 请求有效期限：如果请求返还超时，则丢弃，不做进一步处理

1.1.3 实时了解系统状态

我们需要实时的知道服务之间的调用关系、某个典型服务当前的负载、失败是否在预期之内、如果服务挂了系统如何表现等。总的来说，运营一个微服务平台，除了微服务本身，利用指标类数据、日志、追踪来把握整个系统的全局是必不可少的一环。

1.2 传统的解决方案：应用程序库

早期的时候，为了解决如上的问题，业界一般采用应用程序库（如下），以方便开发人员快速地开发和实现非功能性的需求，但带来的坏处是应用程序必须和某个语言绑定。

• Hystrix：用于短路及限流

• Ribbon：用于客户端负载均衡

• Eureka：服务注册和发现

• Zuul：动态服务代理

1.3 现代的解决方案：服务网格

服务网格是一种透明的、独立于程序之外的、用于处理网络通信的分布式基础设施，它由数据平面和控制平面所组成，如下图所示：

微服务架构集成服务网格后，对日志收集和监控也带来了进一步要求；分析上述拓扑图，我们需要收集对应的Istio Proxy日志及进一步做关联分析，经过了解，这也是鸿鹄平台所擅长的。

二、解决方案

2.1 系统架构

相比于上一篇《利用Vector和鸿鹄搭建微服务应用的可观测性平台》， 此方案引入了Istio服务网格的概念，除了采集应用程序本身的日志之外，需要采集Istio Ingress Gateway和Istio Proxy的日志，以得到对全局服务网格的洞察性。

2.2 数据接入

鸿鹄具备多种数据接入功能，内置的Vector和Kafka数据接入功能，大大方便了企业收集数据，导入鸿鹄分析平台进一步挖掘数据价值的便利性。基于以上的采集系统，具体操作步骤如下：

2.2.1 启用鸿鹄数据收集接口

2.2.1.1 进入：鸿鹄 -> 数据导入 -> 从外部数据源导入

2.2.1.2 配置Vector接口，选择数据集范围

2.2.1.3 选择数据集和数据源类型，生成和下载Vector配置模版，以备后续配置Vector使用

2.2.2 配置及安装Vector

按照Vector的设计（如上图），Data Pipeline分为三个阶段：确定数据源、对数据做转换和数据汇集。以下是实际运行的配置文件（考虑到信息安全性，对部分做了脱敏处理）。

这个配置主要包含了确定采集的数据源、数据如何被加工转换（多行处理、如何进一步解析和抽取数据、丰富数据以满足鸿鹄的需求）和数据最终汇集到鸿鹄，相信大家不难理解。

有了Vector的配置文件，就可以安装Vector了。本文的方案需要采集运行在Kubernetes上的微服务的日志，Vector将会用Helm命令来安装，具体命令如下：

如果需要详细了解Vector Helm chart，可参考 Vector Helm Chart（https://github.com/vectordotdev/helm-charts/tree/develop/charts/vector）

2.3 数据加工

2.3.1 创建数据源

鸿鹄系统提供了常用的数据源类型，比如json、csv、nginx、syslog等，以方便用户开箱即用地接入数据。本文提到的Istio Ingress Gateway网关本身是基于Envoy实现的，为了更好的说明后续步骤，让我们首先来介绍下Istio Gateway日志的格式。

根据文档 Envoy Access Log（https://istio.io/latest/docs/tasks/observability/logs/access-log/），默认格式如下：

根据如上的信息，Envoy的日志包含了丰富的信息，为了后续方便分析和处理，需要单独创建数据源，如下图。

2.3.2 字段加工

字段加工是鸿鹄的核心功能，也就是在读时模式下，对字段进行进一步抽取和丰富，以满足各种业务部门对同一数据以不同视角分析的需要。那接下去以Envoy Access Log为例，看看鸿鹄是怎么做的。

2.3.2.1 打开高级搜索窗口

从搜索窗口可以看到，此数据包含266279条数据，因为没有对数据进行读时抽取，共用0.9s时间。

2.3.2.2 点击 “抽取新字段”，进入字段抽取向导页面

2.3.2.3 编辑正则表达式，抽取所需的字段

选择抽取规则为正则抽取，正则表达式如下图所示

按向导保存抽取规则，即可看到数据源类型增加了一条读时抽取规则。

2.3.2.4 支持多重可持续抽取

鸿鹄系统支持多重可持续性抽取，也就是基于新字段的基础上，可以再抽取再产生字段，比如拿UserAgent字段来说，可以再抽取，获取user_agent_os、user_agent_os_version、user_agent_name、user_agent_version等新字段。能够在读时支持字段多重可持续抽取，鸿鹄在这块应该是属于一枝独秀的。

2.3.2.5 验证读时抽取规则

打开高级搜索， 我们可以看到同样的数据规模，搜索时间有一定的增加，但期望的字段已经成功抽取，可以进一步分析和形成所需仪表盘。

2.4 数据展示

2.4.1 查询加速

前面数据加工部分，我们讲述了如何利用鸿鹄的读时建模机制来动态抽取字段。在数据展示环节，大概率会对同一数据源做搜索，这样就会大概率降低页面展现的效果。鸿鹄系统充分地考虑这一点，提供了几种机制来提高搜索加速。本文会比较细致的讲述预存查询功能。

创建预存查询

进入高级查询  --> 查询 --> 点击“另存为” --> 选择预存查询， 注意红框部分

从预存查询中搜索

进入高级查询  --> 利用saved_search表函数从预存查询中进行查询。

从结果来看，利用预存查询，性能提高了4-5倍。

2.4.2 展示效果

三、鸿鹄价值

鸿鹄平台提供了一整套从数据导入、二次加工及仪表盘快速生成的一整套解决方案，方便用户能快速构建监控平台。本文着重提到的几个核心功能，围绕数据工程师的日常工作，对数据收集、收据探索、数据展示做了高度封装和抽象，减少了使用者的门槛。

3.1 技术优势

自建数据源类型：在大数据领域，存在各种半结构化和非结构化的数据，每一个数据源类型，对应的处理逻辑不尽相同。鸿鹄允许用户非常方便地定义特有的数据源类型，且对每个类型可以灵活定义ingest time和search time的抽取规则。

读时模式：满足了基于同一数据源，不同视角审视的需求。大大地减轻了数据采集端的复杂度。功能上，鸿鹄可满足不同机制的抽取规则，从简单的JSON规则、键值对规则到复杂的正则抽取规则。

查询加速：在数据展示阶段，考虑到用户大概率会对同一数据同时做查询，必然会牺牲性能的前提下，鸿鹄提供了一系列加速查询的方案，以提高页面展示的效果。

3.2 应用价值

精确定位问题，提高开发效率：比如本次使用中，我们对浏览器类型做了分析，发现某一个浏览器类型名字有错误，汇报给开发人员后，结合鸿鹄的日志，开发人员很快定位了问题，及时修复了客户端类型名字错误。

即时监控Envoy网关， DevOps团队能精确的掌握进出站的相关流量指标和访问异常信息。

四、期待的改善

本文体验了鸿鹄几个高级核心功能，能够非常方便地满足业务的需求。从个人角度来看，以下几个部分觉得可以改善以提高用户的友好性：

• 数据抽取正则规则：自动划取字段和手工输入，这两个功能可以合并在一个功能页面上，减少用户切换操作页面。

• 数据抽取正则表达式性能：鸿鹄社区中提供了高效正则表达式匹配文档来指导用户更高效地使用正则来做数据加工，避免正则性能陷阱。对于用户，我们期待的更多。非常期望，在将来的版本中，鸿鹄本身就可以对正则进行分析，以辅助用户修正性能不高的表达式，从而提供使用的友好性。

• 更多的案例支撑加速查询的最佳实践：物化试图和预存查询是鸿鹄系统提供两个加速查询的高级功能，在初次使用过程中，比较难以取舍该用哪个方案来加速查询。相信随着社区的发展，会有越来越多的实际案例来指导用户在这个环节的最佳实践。