利用鸿鹄可观测性监控Istio Ingress网关

一、需求描述

在上一篇《利用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等新字段。能够在读时支持字段多重可持续抽取，鸿鹄在这块应该是属于一枝独秀的。