[大厂实践] 边缘网络的可观测性

美国快餐连锁巨头 Chick-fil-A 在其 2800 多家餐厅部署了 Kubernetes 边缘集群，本文介绍了 Chick-fil-A 管理运维其边缘集群的最佳实践。原文: Observability at the Edge

管理 2800 个 Kubernetes 边缘集群

Chick-fil-A 共有约 2800 家餐厅，每一家都部署了Kubernetes边缘集群，以实现高可用性，负责运行关键业务工作负载，并且不用依赖互联网。在这些集群之上，还运行了一组平台服务，提供跨集群的身份管理、应用部署和可观测性等服务。此外，我们还管理着数十万物联网(IOT)设备，如煎锅、烤架或平板电脑(作为用户界面)，除了运营指标和日志外，这些设备每月还会发送数十亿条 MQTT 消息。

和内部团队部署的任何边缘应用一样，运维 2800 多个 Kubernetes 集群需要小心谨慎、充满挑战。这些团队都是平台的客户，任何运行应用程序的人都需要强大的可观测性，边缘网络当然也是如此。在这篇文章中，我们将分享 Chick-fil-A 边缘网络的可观测性架构。

边缘的挑战

边缘带来了许多独特的挑战和限制，这些挑战和限制对现代云原生思维模式来说有些陌生。

• 日志: 应用日志有很多，不可能将每个 Kubernetes pod 和 IOT 设备的调试日志都实时推送到云上。

• 带宽: 在服务的早期迭代中，因为要返回大量极其冗长的日志，曾经消耗了所有可用带宽，甚至影响到了信用卡处理业务(很不好!)。对生产环境的观测影响到了生产业务是很不好的结果。

• 成本: 跨 2800 个地点的度量成本可能会非常昂贵，与增加的业务价值成比例上升的成本令人望而却步。

• 异构数据源: 我们从许多类型的应用程序收集日志、指标和遥测数据，包括平台应用、其他团队的业务应用、供应商开发的应用以及餐厅物联网设备。

边缘即平台

我们的边缘环境提供了一个平台，内部团队可以在上面构建系统和服务，类似于在 AWS 或 Google 提供的云平台上构建应用程序，但不会限制用户用什么工具或如何使用。我们遵循类似的范例，允许团队拥有"框架内的自由"来选择不同的编程语言、可观测性工具等等。对于可观测性，这很重要，因为边缘平台需要为不同团队所选择的工具提供相关指标和日志(某些日志和指标组有一定程度的重叠)，因此日志管道非常适合这项任务。

红色为平台团队提供的服务，蓝色为其他团队的服务

度量指标

边缘网络可观测性的目标是为应用团队创造一种从"日志优先"到"度量优先"的心态转变，我们称之为"一流指标(first-class metrics)"的概念，"日志派生指标(first-class metrics)"是其替代方案。

在深入讨论之前，我们先来了解一下什么是度量指标，应该用于什么用途?

在我们的上下文中，度量是在一段时间间隔内收集的数据点，可以提供对系统的行为、性能和健康状况的洞察。度量类型包括:

1. 系统度量指标: 关于系统本身的度量，例如 CPU 使用情况、内存使用情况、网络带宽使用情况、磁盘 I/O 等，提供了对系统整体性能和健康状况的洞察。

2. 应用度量指标: 特定于系统上运行的应用程序的度量。例如，活动用户数、每秒事务数、错误率、响应时间等，通常是应用程序性能和有效性的关键指标。

3. 业务度量指标: 这些是将技术性能与业务结果联系起来的指标，例如每用户产生的收益、转换率、客户获取成本等。有时候，这些指标是判断系统是否正常运行的唯一指标。

度量对于建立标称性能的基线、根据该基线监视系统、排除异常行为以及做出决策(人工的或自动的)非常有用。

我们非常喜欢通过优秀的指标来理解应用程序行为，并通过较小的数据量提供良好的可观测性上下文。创建有用的指标(不要太多，也不要太少)来指示应用程序的性能很困难，我们也还在努力的过程中。在我们的边缘计算用例中，典型的 HTTP 状态指标用处不大，因为大多数应用不接受传入的 HTTP 请求，而是向我们的餐厅生态系统中的其他应用程序和设备发送 MQTT。这需要更批判性的思考，以确定哪些指标对确定健康状况有用。

Vector

Vector是用 Rust 构建可观测性管道的开源工具，由几个关键部分组成:

1. 源(Sources): 数据的来源。换句话说，源定义了将要使用的数据向量的来源。Vector 支持系统日志、应用程序日志、Kubernetes 日志、docker 日志、prometheus、来自云提供商的数据或任何其他类型的可观测性数据。

2. 转换(Transforms): Vector 也可以做实时转换，包括过滤、解析、采样、添加字段、类型转换、匿名化数据等操作。

3. 接收器(Sinks): 接收器是数据后处理的目的地，可以是像 AWS S3 这样的存储系统，也可以是 Datadog metrics 这样的监控服务，或者 Kafka 这样的事件总线，等等。

边缘指标收集

在我们的 Kubernetes 集群中，使用 Prometheus 从每个 pod 中暴露的/metrics 端点进行收集。我们收集所有指标，然后使用 Vector 云实例作为边缘 Vector 接收器。

餐厅的边缘架构，绿线和黑线表示出站日志和指标。

在许多情况下，当我们试图将指标和日志分离到单独的流时，转换非常困难。许多工具无法处理。在这两者结合的情况下，我们利用 sidecar 从日志中抓取与指标相关的标签，并将这些指标转发给 Vector，这样就可以拥有一个完整的指标驱动的环境运维视图。

日志

尽管我们更喜欢默认的良好指标，但日志对许多团队来说仍然至关重要。我们相信，当故障排除困难的问题时，特定上下文中的日志总是有用的，解决这些问题需要依赖超出度量或跟踪的额外上下文。

日志收集

默认情况下，所有边缘应用(应该)以DEBUG级别记录日志。Vector 通过抓取 Kubernetes 日志接口收集这些日志，并存储在本地。对于每个应用，都有独立参数为日志配置存储空间大小。

对于其他设备(炸锅、烤架、物联网设备)，我们还创建了本地运行的 HTTP 服务，允许集群外设备发布其日志以进行收集和转发。这通常是供应商提供的解决方案，使我们能够为他们提供日志(或指标)，而不需要他们直接写到云上，因为我们希望能够控制环境中的所有出站流量。

日志传送

何时/如何将日志发送到云上？总体策略是什么？

Vector 转换过滤日志，默认情况下只转发ERROR级别的日志到统一的 Vector 云实例上。只要集群有可用的互联网连接，日志就会近乎实时的传输。

为防止潜在网络饱和的级联效应，我们为 POS 和信用系统设置了和边缘网络不同的带宽，并分配了单独的 VLAN。在脱机场景中，滚蛋存储的日志会保存在存储中，并将在网络再次在线的时候收集。

但是等等！如果需要从应用日志中获取更多信息，而ERROR不够，怎么办？

如果团队为了支持生产环境需要某个特定时间段的更详细日志，可以调用自定义的云端部署的 API 端点，该端点将在任意时间段(通常为 30 分钟)将某个或某组餐厅的特地应用(pod)的日志收集过滤器更改为DEBUG。

时间一到，日志收集过滤器将恢复默认值。恢复默认值很容易被人忘记，但如果不加以解决，可能会产生潜在的长期影响，因此需要自动化控制。最终，这一解决方案确保了生产支持的可能性，但对餐厅集群的长期影响最小。自动化和自助服务对于成功大规模运维边缘平台至关重要。

Fan Out

日志和指标被交付到企业餐厅计算团队拥有的 AWS 云环境中。我们有一个云部署的 Kubernetes 集群(EKS)，运行大部分控制平面服务。在这个环境中，我们有一个集中的 Cloud Vector 实例，为每个部署配置接收器，将日志转发到对它们感兴趣的目标受众。

这样团队就可以使用任何想用的工具，并赋予他们自主权来构建报告和指示板来支持其应用。大多数团队都将他们的日志和指标发送给 Grafana、Datadog 或 CloudWatch。

此外，所有的警报事件都被发送到 OpsGenie, 并根据值班轮换安排为团队创建告警。

不，不要这样

对于边缘应用或集群外设备，有些事情是不允许的。

其中之一是直接将日志和指标发送到云上。从客户端应用程序或物联网执行此操作将绕过我们管理带宽限制的所有控制，特别是在带宽高度受限的备份网络连接模式中。在这些情况下，我们将面临网络被低优先级数据占据出口带宽的潜在风险。

结论

边缘网络的可观测性很有挑战，需要仔细选择平台和应用运行状况的关键指标。从使用日志作为支柱到创建一流指标的思维转变是一种变革，需要工程师采用全新的思维范式。然而，使用一流指标是获得关于边缘平台或应用程序高质量观察数据的好方法，并且不会生成太多出站数据。Vector 是一个强大工具，可以帮助我们实时转换可观测性流量，将出站操作数据减少到所需的最低限度，从而使业务遥测的带宽最大化。我们真的很高兴这个架构能够支持我们在边缘网络的当前需求以及新兴需求。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！