Hugging Face 生产基础设施警报策略
Hugging Face 采用了强大的监控和警报系统，以确保其生产基础设施的稳定性和可扩展性。通过对网络流量、日志管道和编排 API 健康实施针对性警报，团队能够在潜在问题升级为重大事件之前识别它们。
高 NAT 网关吞吐量与成本优化
Hugging Face 使用 NAT（网络地址转换）网关将私有网络的出站流量集中到公共互联网，为安全和成本分析提供了战略视角。为管理云费用，团队使用静态阈值警报监控网络流量量，当吞吐量超过预定义限制时触发警报。
此警报机制有两个主要功能：
- 早期预警系统： 检测可能表明系统异常行为的异常流量峰值。
- 基础设施审查： 促使定期审查流量趋势，以使基础设施增长与不断变化的需求保持一致。
在实际操作中，当第三方安全和自动扩缩工具增加遥测数据出口时，此警报帮助团队优化配置。它还能够识别流量错误地绕过低成本私有路径的情况。例如，直接从 LFS 仓库存储获取对象比使用 CDN 托管的资产更具成本效益。为解决此类问题，Hugging Face 通过 CDKTF AWS 提供程序的 DNS 覆盖，将流量路由到私有网络路径。
端到端日志归档验证
Hugging Face 使用复杂的日志管道来捕获 Hub 模型使用数据。该管道从 Filebeat（日志收集）流向 Logstash（转换和增强），再到 Elasticsearch（存储和分析），最终到 AWS object storage（以 Parquet 格式进行长期归档），可通过 Amazon Athena 进行查询。
尽管设计如此，该管道仍易受到以下故障的影响：
- Elasticsearch 回压： 高入口流量或密集查询可能导致日志被拒绝或延迟。
- 模式不匹配： 应用日志字段类型的显著变化可能导致自动模式检测失败，从而产生写入错误。
- 内存耗尽： Logstash 和 Filebeat 的内存资源受限，在回压事件期间可能导致内存溢出（OOM）崩溃。
- 归档失败： 资源密集型的归档作业可能因节点容量限制或异常大的日志条目而失败。
为降低这些风险，Hugging Face 实施了一项警报，通过 比较应用负载均衡器 (ALB) 接收的请求数量与成功归档的日志数量 来验证端到端日志流。该比例确保进入系统的数据量与归档的数据量相匹配，使团队能够在基础设施重构或归档作业失败期间检测日志丢失。
Kubernetes API 健康与速率限制
由于 Kubernetes API 是容器管理的中心编排点，Hugging Face 监控 API 错误率和速率限制指标，以防止连锁故障。基础设施高度依赖 kube-rs 库，该库提供基于 Rust 的反射器、控制器、观察者和终结器抽象。
在 Hugging Face 中 kube-rs 的关键应用包括：
- 自动证书管理： 使用
kube::api::模块管理 Spaces 产品中自定义域的 HTTPS 证书。 - 自定义控制器： 使用
kube::runtime::模块构建计费管理的控制器，观察者和终结器跟踪客户 pod，以实现精确的资源计费。 - 维护操作： 在基础设施更新期间促进节点排空和终止。
监控 Kubernetes API 至关重要，因为中断可能影响客户 pod 和云网络资源的管理。例如，团队利用这些警报识别出一个第三方工具的 bug，该 bug 重复请求节点排空，导致 API 速率限制，在问题影响用户体验之前被捕获。
检测静默集群指标故障
为管理经常创建和销毁的动态环境，Hugging Face 使用特定的 Prometheus 查询来检测未向中心 Grafana Mimir 存储发送指标的集群。
该警报监控本地 Prometheus 实例的 container_network_transmit_packets_total 指标。查询在以下情况触发：
- 新集群已添加但尚未发送任何指标。
- 集群已存在超过 48 小时但从未发送任何指标。
通过将当前的数据包传输速率与 48 小时前的历史速率进行比较来实现。如果当前速率和历史速率均为零，则触发警报，通知团队指标基础设施崩溃或集群设置期间的故障。