Istio 是一个开源服务网格，开发人员和运维人员可以使用它在分布式微服务的环境中成功地控制、保护和连接服务。尽管 Istio 对于这些团队来说是一个强大的工具，但对于管理员来说，全面了解其运行状况也很重要。在这篇博文中，我们将介绍如何使用 Elastic 可观测性监测 Istio 及其微服务。
如 Istio 文件所述：
通过 Istio，只需对服务代码进行很少的改动或无需改动，即可轻松创建具有负载平衡、服务到服务身份验证、监测等功能且已部署服务的网络。您可以通过在整个环境中部署一个特殊的 Sidecar 代理来为服务添加 Istio 支持，这个代理会拦截微服务之间的所有网络通信，然后使用其控制平面功能配置和管理 Istio，这些功能包括：
- HTTP、gRPC、WebSocket 和 TCP 流量的自动负载平衡。
- 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行精细控制。
- 可插拔的策略层和配置 API，支持访问控制、速率限制和配额。
- 集群内所有流量的自动指标、日志和跟踪，包括集群入口和出口。
- 通过强大的基于身份信息的身份验证和授权，在集群中实现安全的服务对服务通信。
在 1.5 版之前，Istio 采用微服务架构构建而成，其控制平面和管理组件由多个微服务组成：Pilot、Mixer、Galley 和 Citadel。
Metricbeat 支持监测这些微服务，但是在 1.5 版中，Istio 将其架构更改为单体方式，现在控制平面附带了一个名为 istiod 的应用程序。Pilot、Galley 和 Citadel 现在是 istiod 的一部分，而 Mixer 负责从 Envoy 代理收集流量指标，其功能现在由 Istio 代理直接提供。Istio 的当前架构如下所示：
使用 Elastic 制定监测解决方案
虽然在 1.5 版之前已经有多个 Istio Metricbeat 模块的指标集提供支持，但在这篇博文中，我们将着重讨论在 Kubernetes 上运行 Istio 时对较新版本的支持。
控制平面指标
如上面的 Istio 架构图所示，我们只有一个可从中收集控制平面指标的资源。Istiod 提供了一个 Prometheus 导出器，我们可以从中收集 Prometheus 指标。
为了使用 Prometheus 终端的指标，我们需要一个指标集来正确地收集、筛选并相应地存储这些指标。基于 Prometheus 模块创建一个轻量型指标集，然后利用指标筛选之类的强大选项并使用直方图和类型，便可轻松实现这一目标。
我们来看看这个新的轻量型指标集的定义：
input:
module: prometheus
metricset: collector
defaults:
metrics_path: /metrics
metrics_filters:
include: ["citadel_*", "galley_*", "pilot_*"]
exclude: ["^up$"]
use_types: true
rate_counters: true
这定义了收集器指标集将从中采集指标并筛选出我们不需要的指标的路径，同时启用了速率和类型，以便将数据正确地存储在 Elasticsearch 中，从而使我们能够充分利用它。
在 Kubernetes 集群上部署 Metricbeat 时配置此指标集的方法如下所示：
- module: istio metricsets: ['istiod'] period:10s hosts: ['istiod.istio-system:15014']
其中 istiod 是公开 Istiod Pod 的 Kubernetes 服务的名称，而 istio-system 是其所部署的命名空间。
大功告成！我们已经有了 istiod 指标集来从 istiod 收集指标，它还附带一个预先构建的仪表板来概述服务网格的控制平面，以及一些可以在您自己的定制仪表板中使用的可视化功能：
数据平面指标
现在，我们已经开始使用 istiod 指标集从控制平面收集指标，接下来我们可以通过从数据平面收集指标来扩展监测范围。这将使我们可以有效了解 Istio 所管理服务之间的流量概况。
如前所述，Mixer 是负责收集和提供这些数据平面指标的微服务。但在 1.5 版之后，这些指标是使用 Prometheus 导出器直接从 Istio 代理收集并公开的。
我们需要做的就是，指定另一个轻量型指标集，类似于我们对 istiod 所做的操作，以收集以下其他指标：
input:
module: prometheus
metricset: collector
defaults:
metrics_path: /stats/prometheus
metrics_filters:
include: ["istio_*"]
exclude: ["^up$"]
use_types: true
rate_counters: true
与之前相同，我们设置 metrics_path，并且仅保留所需的指标并使用类型来存储它们。
不过，这里缺少一环：我们不知道如何到达这些代理容器，因为我们不知道它们的 IP 地址。即使我们在部署 Metricbeat 之前就知道了这些容器的 IP，我们也无法从那些启动 Metricbeat 之后部署的服务中收集数据。我们需要一种方法来自动识别这些容器，并在它们启动时开始收集指标，这是 Metricbeat 的自动发现功能的最佳之处。这意味着，我们定义了一个自动发现条件来识别这些容器，每当发现一个新的 Istio 代理 Sidecar 容器时，Metricbeat 就会自动启用代理指标集并开始从中收集数据。
以下是这个自动发现配置的示例：
metricbeat.autodiscover:
providers:
- type: kubernetes
node: ${NODE_NAME}
templates:
- condition:
contains:
kubernetes.annotations.prometheus.io/path: "/stats/prometheus"
config:
- module: istio
metricsets: ["proxy"]
hosts: "${data.host}:15090"
这时就轮到我们上场了！我们正在从集群上运行的所有 Istio Sidecar 容器中收集指标，并且能够动态识别其中的任何新容器。这是 Istio 模块的代理指标集，它还附带一个预先构建的仪表板：
此外，我们可以利用 Kibana 中的图表分析来探索我们的数据与服务之间的关联。例如，在下面的图表中，我们可以概览这些服务如何相互连接，以及它们与 http 状态代码的关联程度。与 500 状态代码有密切关系的服务将指示我们应调查的问题。
立即监测 Istio
如果要开始监测 Istio 服务网格，请下载 Metricbeat 7.11，然后开始使用 Elasticsearch 和 Kibana 高效地探索指标。部署集群最快的方法是启动 Elasticsearch Service 的免费试用版。如果有任何疑问，请记住，我们很乐意在讨论论坛上为您提供帮助。