作者：iyacontrol

来源：https://zhuanlan.zhihu.com/p/269398999

Istio 生成网格内所有服务通信的详细遥测数据。这种遥测功能使运维学生能够观察服务行为并对应用程序进行故障排除、维护和优化，而不会给服务开发人员带来额外的负担。 Istio 提供了对受监控服务如何与其他服务以及Istio 组件本身交互的全面可见性。

Istio 生成以下遥测类型以提供跨服务网格的可观察性。

指标：Istio 基于四个监控“黄金信号”生成一组服务指标：延迟、流量、错误和饱和度。 Istio 还提供了网格控制平面的详细指标。还提供了围绕这些指标构建的一组默认网格监控仪表板。分布式跟踪：Istio 为每个服务生成分布式跟踪范围，提供对网格内的调用流和服务依赖性的详细了解。访问日志：当流量流入网格中的服务时，Istio 可以生成每个请求的完整记录，包括源和目标元数据。此信息允许您审核服务行为直至单个工作负载实例级别。这篇文章主要讲的是日志。

Logs 简介

为什么我们需要日志？

这里所说的日志仅包括代理Envoy的访问日志，不包括业务本身的日志。

Envoy 访问日志包含丰富的流量信息，包括：

开始时间-- 请求开始时间方法-- 请求方法协议-- HTTP/1.1 或HTTP/2。如果协议为TCP，则值为-Response Code -- HTTP 响应代码。如果请求是TCP 请求，则值为-Response Flags。如果超出标准响应代码，此字段将显示有关响应或连接的详细信息。 HTTP 和TCP 请求的可能值包括UH（上游连接失败）、UO（上游溢出）和URX（由于上游重试限制或最大连接尝试而失败）。已接收）已拒绝）已接收字节数/已发送字节数-- 正文接收或发送的字节数。对于WebSocket 连接，发送的字节包括响应标头字节。 响应持续时间——从开始时间到从上游主机读取第一个字节的请求总持续时间（以毫秒为单位）。 上游服务时间——请求开始时间（以毫秒为单位）。上游主机处理了该请求。这在比较服务时间和网络延迟时非常有用。 X-Forwarded-ForUser-Agent——该字符串允许服务器识别特定类型的软件请求代理。 请求ID——Envoy 使用x-request-id 标头来唯一标识每个请求。这对于跨多个微服务的分布式跟踪和稳定访问日志记录尤其重要。权限——主机（HTTP/1.1）或权限（HTTP/2）标头的值还包括通过五组信息的流量的五条信息。清楚地了解您的流量来自何处以及流向何处。

UPSTREAM_CLUSTERDOWNSTREAM_REMOTE_ADDRESSDOWNSTREAM_LOCAL_ADDRESSUPSTREAM_LOCAL_ADDRESSUPSTREAM_HOST 对于使用istio 的进程，代理的引入会延长整体访问链路并使某些问题的故障排除变得复杂。例如，如果请求返回诸如503 之类的状态代码，您无法确定它是由服务本身返回还是由代理返回。 Envoy 使用访问日志来记录流量信息，可以根据访问日志提供更详细的故障定位。

作品

Istio中的访问日志设置主要通过以下设置项完成。

MeshConfig.accessLogFile——如果设置为/dev/stdout，则表示启用了访问日志功能。以标准输出格式输出日志。基本上，这些日志是由docker收集并保存到主机上的指定位置。将此值设置为“”以禁用访问日志记录。 MeshConfig.accessLogEncoding -- 设置为JSON 或TEXT 以选择访问日志输出格式。 MeshConfig.accessLogFormat——此项允许用户根据自己的实际需要自定义访问日志格式。

实战

在生产中，使用组合filebeat + kafka + es + clickhouse + kibana + superset。具体结构如下。

采集终端

采集器选择轻量级日志采集组件filebeat。自动发现功能允许您只收集指定容器的日志，非常灵活。

当应用程序在容器上运行时，容器的弹性意味着传统的基于配置文件的发现和收集目标的方法不再适用。自动发现会跟踪它们并允许您在发生更改时调整设置。通过定义配置模板，自动发现子系统可以在服务开始运行时对其进行监控。

选择kubernetes autodiscovery 并将以下设置专门添加到您的filebeat 配置中：

filebeat.autodiscover: 提供商： - 类型： kubernetes 模板： - 条件： 等于： kubernetes.container.image: 'docker.io/istio/proxyv2:1.7.3' config: - 模块： 特使日志： 输入： 360容器路径：-/var/log /containers/*-${data.kubernetes.container.id}.log 符合条件。我只收集了istio 数据平面Envoy 的访问日志。

卡夫卡

由于日志量比较大，所以我们引入了kafka。避免高峰时段笔压过大导致数据丢失。

ES+Kibana

将日志写入es的目的是为了在短时间内调试时更容易从大量日志中检索重要信息。出于成本考虑，es只保留最近三天的日志。

点击House + 超级组

中期来看，我们计划聚合原始日志，将聚合后的数据存储在ClickHouse中，并以超集的形式显示。这些聚合结果反映了每个服务各个维度的流量信息。

聚合后的实际显示效果如下。

访问日志分析和查看实际上增强了另一个维度的基于指标的监控。

事实上，我们仍然保留完整的原始日志并将其存储在云上的对象存储中。这主要用于长期存储，以便在您的业务出现问题时更容易追踪故障。我们当前的离线分析解决方案使用presto。未来我们也会重点关注线下分析。

作者：iyacontrol

来源：https://zhuanlan.zhihu.com/p/269398999

版权声明：本文转载于网络，版权归作者所有。如有侵权，请联系本站编辑删除。