容器可观测性框架的最佳实践
容器可观测性有助于您理解 为什么 和 怎么样 容器化系统在使用指标、日志和追踪数据时会出现各种问题。由于容器具有瞬态性和复杂性，传统的监控方式往往难以奏效。以下是您需要了解的内容：
- 指标跟踪容器性能（例如 CPU、内存使用情况）。.
- 日志集中汇总容器日志，以便更轻松地进行故障排除。.
- 痕迹：跟踪微服务中的请求，找出瓶颈。.
为了取得成功，请使用 OpenTelemetry 等工具规范您的可观测性设置，高效管理数据以控制成本，并集成镜像扫描和运行时监控等安全措施。这些步骤可确保更快地解决问题并提高系统可靠性。.
停电造成的损失高达 每小时 $500,000, 投资于可观测性对于技术和财务健康都至关重要。.
容器可观测性的三大核心组成部分：指标、日志和追踪
可观测性的三个核心组成部分
收集指标
指标提供了容器健康状况和性能的快照，涵盖 CPU 使用率、内存消耗、网络吞吐量和错误率等领域。在 Kubernetes 环境中，kube-apiserver 和 kubelet 等组件已经通过 Prometheus 格式公开了这些指标。 /指标 端点，使其易于收集。.
对于 CPU、内存和网络使用情况等容器级指标，cAdvisor 是一个不错的选择。它通过以下方式提供数据： /metrics/cadvisor 端点可供 Prometheus 等工具定期抓取。Prometheus 会存储这些时间序列数据以进行分析和告警。为了优化性能，可以使用记录规则预先计算复杂查询，从而最大限度地减少资源需求。.
为了避免高基数问题导致系统过载，必须将标签限制在关键维度上，例如命名空间、Pod 名称和服务类型。需要监控的关键指标包括： apiserver_request_total API服务器负载, 容器 CPU 使用时间（秒）总计 CPU 使用率，以及 容器内存使用量（字节） 在内存泄漏升级为系统故障之前检测到它们。.
一旦各项指标都得到了控制，下一步就是集中管理日志，以便更全面地了解情况。.
集中式日志记录
集中式日志将系统事件、错误和安全警报集中存储在一个位置。由于容器日志本质上是临时性的，因此将它们聚合到中心位置至关重要。.
为了实现这一点，可以部署日志代理，例如轻量级的 Fluent Bit 或提供高级路由功能的 Fluentd。这些代理可以跟踪日志。 /var/log 并将它们转发到 Elasticsearch、OpenSearch 或 CloudWatch 等平台进行索引和搜索。.
使用 结构化日志记录 日志元素以键值对的形式格式化，相比纯文本，这使得解析、筛选和可视化日志变得更加容易。此外，始终启用 对数旋转 为了 /var/log 为了防止磁盘空间意外耗尽（这是导致节点崩溃的常见问题），妥善的日志管理不仅可以加快事件响应速度，还有助于缩短平均恢复时间 (MTTR)。.
为了完成可观测性的三重奏，集成分布式追踪来绘制请求如何在系统中流动。.
分布式追踪
跟踪功能允许您追踪请求在微服务中的流转过程。指标可以突出显示响应时间过长等问题，日志可以显示具体错误，而跟踪功能则可以精确定位分布式系统中的瓶颈。跟踪中的每个"跨度"代表一次操作，它们共同构成了一幅详细的服务交互图。.
开放遥测 现在，gRPC 已成为分布式追踪的首选标准，并得到超过 90 种可观测性工具的支持。从 Kubernetes 1.35 开始，可以通过内置的 gRPC 导出器，使用 OpenTelemetry 协议 (OTLP) 直接导出 span。Jaeger 和 Zipkin 等工具可以处理这些追踪数据，帮助您可视化延迟模式，并识别效率低下的问题，例如缓慢的数据库查询或优化不佳的 API 调用。.
追踪最强大的方面之一是 上下文传播 该方法确保每个请求在所有服务边界上都拥有唯一的标识符。它将指标、日志和跟踪信息整合到一个统一的系统中，从而更容易快速定位根本原因。通过连接这些可观测性组件，您可以显著缩短平均修复时间 (MTTR) 并简化事件处理流程。.
AWS re:Invent 2023 – 容器可观测性最佳实践 (COP319)
标准化您的可观测性框架
搭建好可观测性的核心组件后，下一步就是规范你的实践。这能确保你的数据在整个容器环境中保持一致，并且易于解读。.
使用 OpenTelemetry 标准
OpenTelemetry (OTel) 已成为容器可观测性的首选标准，并得到 90 多家厂商的支持。它提供了一个统一的、厂商中立的框架，用于生成、收集和导出跟踪、指标和日志。这消除了对多个专有代理的需求，并确保您保留对数据的所有权。.
"您拥有您生成的数据的所有权。不存在供应商锁定。"——OpenTelemetry 文档
OpenTelemetry 的优势在于其语义约定，它为不同代码库和平台之间的命名约定带来了统一性。例如，容器指标如 容器运行时间 （以秒为单位）, 容器 CPU 使用率 （占可分配 CPU 的比例），以及 container.memory.working_set 遵循可预测的模式。这些指标可以与 Prometheus、Jaeger 或其他商业平台等后端无缝集成。.
为了充分利用 OpenTelemetry，请在应用程序启动时立即初始化它。这可以确保所有后续的库调用都能被正确地进行检测。此外，部署集中式的 OpenTelemetry 收集器允许您在将遥测数据发送到后端之前对其进行批处理、压缩和转换。这种方法不仅可以降低系统开销，还可以让您灵活地切换可观测性平台，而无需重新修改应用程序的检测代码。.
一致的标签和元数据
标准化元数据是将原始遥测数据转化为可操作洞察的关键。使用一致的标签，例如 traceID, pod_name, 节点名称， 和 命名空间 帮助您关联不同类型的遥测数据。例如，如果您发现延迟激增，这些标签可帮助您将问题追溯到特定容器，并确定其是否达到资源限制。.
采用 Prometheus 的命名规则——例如 操作员名称实体指标名称 ——可以进一步增强资源间的一致性。但是，请注意标签的基数。避免使用高基数维度，例如用户 ID 或电子邮件地址，因为它们会增加存储成本，并导致系统被过多的唯一时间序列数据淹没。.
通过尽早遵循 OpenTelemetry 的语义规范，您可以确保数据清晰且易于搜索，从而减少故障排除或事件响应过程中的混淆。一旦您的遥测数据标准化，即可部署可靠的托管基础设施。.
使用 服务器 托管解决方案
有了完善的可观测性框架，Serverion 的 VPS 和专用服务器即可提供大规模托管 OpenTelemetry Collector 所需的可靠性。对于节点特定的遥测数据，请在 Serverion VPS 实例上使用"Daemonset"模式部署 Collector。如果您要聚合整个集群的数据，请在专用服务器上使用"Deployment"模式，以集中处理数据并避免重复计算。.
为了确保您的部署安全，请实施基于角色的访问控制 (RBAC)，将收集器的权限限制在必要的范围内。使用精确的卷挂载权限，并通过强大的配置管理来保护敏感数据。此外，通过跟踪收集器的内部遥测数据并设置 CPU 和内存使用率警报，监控可观测性基础架构的运行状况。这有助于即使在高负载下也能保持稳定性。.
如果单个托管实例达到资源上限，您可以通过在 Serverion 的全球数据中心部署多个负载均衡的 Collector 来实现横向扩展。Serverion 会处理繁重的计算任务，因此您的可观测性框架可以随着容器化应用程序的扩展而轻松增长。.
建立监控和警报系统
建立监控和警报系统至关重要，它能及早发现潜在问题，防患于未然。一套精心设计的监控系统能将标准化的框架与可执行的洞察相结合，使您的团队能够高效地识别和解决问题。.
定义 SLO 和 SLI
服务级别指标 (SLI) 是你跟踪的指标，而 服务水平目标（SLO） 是你为这些指标设定的目标。重点关注直接影响用户体验的指标，例如 API 服务器延迟、节点健康状况和 Pod 就绪状态。.
设置基于严重性的服务级别目标 (SLO)。例如：
- 扳机 关键警报 5分钟内，针对可能导致重大服务中断的情况做出响应。.
- 扳机 警告警报 非紧急问题将在 60 分钟内处理完毕。.
"仅当出现可能导致数据丢失或集群整体服务中断的情况时，才应发布严重级别警报。"——运维人员可观测性最佳实践
为了管理大规模环境，可以使用 Prometheus 记录规则预先计算常用表达式。这在跨数百或数千个容器跟踪 SLO 时尤其有用。与 SLO 关联的每个警报都应该包含一个 运行手册网址 提供注释，提供逐步解决方案指导，并最大限度地减少事件发生期间的停机时间。.
配置可操作警报
可操作的警报侧重于真正影响系统或用户的症状，而不仅仅是标记异常的指标值。例如，避免对不影响功能的轻微指标波动触发警报。相反，应优先处理以下情况：
- 持续高延迟
- 反复重启 pod
- 资源耗尽
利用 PromQL 的功能 预测线性 此功能可创建动态阈值，使您的团队能够在潜在问题升级之前预测并解决它们。静态阈值往往不够准确，而预测性警报则能让您的团队抢占先机。.
配置告警时，请设置 15 分钟的持续时间，以过滤掉瞬态问题。同时，请提供集群、命名空间和 Pod 等关键信息，以及仪表盘链接以便快速了解上下文。.
监测资源利用情况
为确保系统平稳运行，请监控不同系统层的资源使用情况：
- 控制平面跟踪 API 服务器和 etcd 等组件。.
- 集群状态：密切关注节点状态和 Pod 调度问题。.
- 容器指标密切关注 CPU、内存和网络 I/O。.
例如，监控 kube_pod_container_status_restarts_total 为了发现循环崩溃的容器，一个常见的阈值是 15 分钟内重启超过三次。同样，跟踪 etcd 数据库的大小（apiserver_storage_db_total_size_in_bytes），因为超出其极限可能会危及整个控制平面。.
其他需要监控的关键领域包括待处理的 Pod 和调度失败，这通常表明资源不足或请求配置错误。当容器因以下原因终止时： OOMKilled 事件，设置信息级警报，以便及早标记资源限制突破，防止大范围故障。.
最后，定期评估警报的性能。分析警报频率、解决时间和误报率等指标。这有助于优化规则，使其在环境变化时仍能保持有效性。.
sbb-itb-59e1987
为您的可观测性框架添加安全性
在监控容器化应用程序时，安全性并非锦上添花，而是必不可少。通过将安全性直接嵌入到可观测性框架中，您可以利用与性能跟踪相同的工具来识别潜在威胁。但这只有在所有配置从一开始就正确无误的情况下才能奏效。.
图像扫描和漏洞管理
将镜像扫描集成到 CI/CD 流水线中，是一种主动出击的方式，可以在开发过程早期发现漏洞。内联扫描通过在本地扫描镜像，仅将元数据发送给扫描工具，从而确保敏感数据的私密性。这种方法可以在未经批准的镜像造成问题之前将其拦截。.
"图像扫描是安全 DevOps 工作流程中的第一道防线。"——Sysdig
通过实施镜像仓库级扫描来扩展这种保护，在部署前验证所有镜像（包括第三方镜像）。使用 Kubernetes 准入控制器来阻止未经扫描或不符合合规标准的镜像。由于新的漏洞（CVE）不断涌现，定期重新扫描生产环境中的镜像以应对"零日"威胁至关重要。.
专注于修复生产环境中已被积极利用的漏洞。为了保持一致性，请使用不可变的标识符（例如 SHA256 摘要）标记镜像，而不是使用可变的标签。 ：最新的.
运行时安全监控
运行时监控通过密切关注容器行为，增加了一层额外的保护。例如，监控内核系统调用可以帮助您检测异常的文件访问或网络活动。建立基线可以更轻松地快速发现偏差。.
集中化 标准输出 和 标准错误输出 容器运行时日志会按时间顺序记录安全事件，即使容器关闭后该记录仍然可用。为了最大限度地降低风险，请为容器配置随机化的用户标识符 (UID)，以防止权限提升。此外，还可以应用 seccomp 或 AppArmor 配置文件，禁用不必要的 Linux 功能，并设置 CPU 和内存限制，以防止资源耗尽攻击。.
使用 Serverion 进行 DDoS 防护和日志记录
运行时监控固然能保障内部流程的安全，但抵御 DDoS 攻击等外部威胁同样至关重要。Serverion 的托管基础设施通过其全球分布式数据中心提供内置的 DDoS 防护。这种架构能够在流量攻击到达您的应用程序之前将其拦截。速率限制和地理封锁等功能则在应用层进一步增强了防御能力。.
Serverion 的日志记录功能可以与您的可观测性框架无缝集成，捕获整个技术栈（从云配置到单个容器）中的安全事件。通过建立流量基线，您可以区分正常的流量高峰和机器人驱动攻击的早期迹象。仅去年一年，全球就有近 900 万次 DDoS 攻击针对关键服务。.
"关键挑战在于区分合法用户和恶意机器人，尤其是在两者都产生大量入站流量的情况下。"——SecurityScorecard
为了进一步确保日志记录设置的安全性，请遵循最小权限原则。使用基于角色的访问控制 (RBAC) 将可观测性工具的访问权限限制在它们所需的目录中。对于服务器类组件，启用持有者令牌或基本身份验证，并限制其运行的 IP 地址。此外，监控可观测性工具的性能（例如 CPU、内存和吞吐量），以确保它们在攻击期间不会过载。.
管理规模和成本
为了保持系统高效运行，管理规模和成本与维护强大的可观测性和安全性实践同等重要。随着容器使用量的增长，可观测性数据量也随之增长。例如，跟踪单个指标 节点文件系统可用 10,000 个节点大约会产生 100,000 个时间序列——这对许多系统来说都能处理。但如果引入高基数标签，例如用户 ID，时间序列的数量就会飙升至 1 亿，远远超出标准 Prometheus 配置的处理能力。挑战在于如何控制这些时间序列。 基数 同时保留关键见解。.
管理高基数数据
当指标包含取值范围无限大的标签时，例如用户 ID、电子邮件地址或动态 Pod 名称，就会出现高基数问题。每个唯一的标签组合都会生成一个新的时间序列，从而消耗大量资源。.
"每个标签集都是一个额外的时间序列，会占用内存、CPU、磁盘和网络资源。通常情况下，这些开销可以忽略不计，但在指标数量庞大、数百个标签集分布在数百台服务器上的情况下，这些开销会迅速累积。"——Prometheus 文档
为了解决这个问题，, 聚合 成为你最好的帮手。记录规则可以预先计算复杂的查询，从而创建新的、资源消耗更少的时序序列。例如，一条类似这样的规则： 不包含（实例、命名空间、pod）的总和 移除高基数标签，同时保留有意义的数据。此外，在数据摄取期间，您可以使用 metric_relabel_configs 去掉不必要的标签，例如 实例 要么 荚 ——尤其适用于长期趋势分析。对于高容量指标或分布式追踪，, 摄入采样 这是另一种有效的策略。该方法可以捕获 100% 的关键错误跟踪数据，同时将正常跟踪数据量减少到例如 1%，从而在确保统计相关性的同时，避免系统过载。.
尽量将大多数指标的基数控制在 10 或以下。对于超过此限制的指标，应在整个环境中仅保留少数几个。避免为程序生成的值使用标签，而是导出事件的 Unix 时间戳，而不是"自上次更新以来的时间"计数器，以最大程度地减少频繁更新。这些做法有助于在不增加系统过载的情况下保持高效的可观测性。.
数据保留政策
并非所有可观测性数据都需要以相同的方式存储。使用 分层存储 既能控制成本，又能确保所需数据的可访问性。以下是一种常见方法：
- 热路径：将用于警报和实时仪表板的实时数据存储在 Kafka 或流处理器等系统中。.
- 暖路径使用 Prometheus 等时间序列数据库进行近实时分析和故障排除。.
- 冷路将长期合规性和审计数据归档到数据湖或 S3 等存储中。.
例如，默认的 Istio 配置对本地 Prometheus 实例使用 6 小时的数据保留窗口，以减轻高基数标签的存储负担。高分辨率数据可以保留用于即时故障排除，而聚合的低基数数据则用于历史分析。这种策略不仅可以节省高达 40% 的存储成本，还能提高查询性能。可观测性预算通常占整体基础设施成本的 3% 左右，因此优化数据保留策略可以直接提高财务效率。.
使用 eBPF 工具进行扩展
为了进一步优化，可以考虑使用内核级监控。 基于eBPF的工具 就像地表植被一样。这些工具直接从 Linux 内核收集数据，提供关于网络流量、磁盘 I/O 和进程间通信的详细信息——所有这些都以极低的资源占用实现。最棒的是什么？它们完全透明地运行，无需更改您的应用程序代码。.
与传统的插桩方式（需要集成库，可能会增加系统开销）不同，eBPF 在内核级别运行，系统调用开销极低。这使其成为生产环境的理想选择，因为在生产环境中，每个 CPU 周期都至关重要。为了进一步降低资源消耗，像 OpenTelemetry 批处理处理器这样的工具可以将数据分组（例如每 500 个数据项或每 30 秒一次），然后再发送。这种方法可以最大限度地减少网络调用次数，减轻可观测性框架的负载，同时最大限度地提高效率。.
结论
最佳实践总结
建立强大的容器可观测性框架是保持应用程序流畅运行的关键。该框架依赖于三个核心组件—— 指标, 日志， 和 痕迹 – 共同努力，提供集群内部运作的完整视图。.
采用 OpenTelemetry 等标准并设置智能警报有助于团队专注于真正重要的事项。关键警报应在 5 分钟内触发，并且仅在发生重大事件时才需要立即关注。在安全方面，您的可观测性框架应跟踪失败的登录尝试、未经授权的更改和异常网络活动，以及传统的性能数据。为了有效控制成本，数据保留策略、基数控制以及 eBPF 等工具至关重要。服务中断可能造成高达 10 ... 每小时 $500,000, 这些做法既能保障您的运营，又能保障您的财务安全。.
"与安全性一样，可观测性也不应是开发或运维的次要考虑因素。最佳实践是将可观测性尽早纳入规划之中。"——AWS 可观测性最佳实践
当然，这些最佳实践都建立在稳定可靠的托管平台之上。.
Serverion 如何支持可观测性
Serverion 通过提供可靠且安全的托管解决方案来增强可观测性。为了充分利用这些最佳实践，您的可观测性工具需要强大的基础架构。Serverion 的托管服务为 Prometheus 爬虫和 Fluent Bit 聚合器等工具提供了坚实的基础，同时还提供了其他服务。 DDoS 保护 和 安全日志记录 保持一流表现。.
能够访问关键主机信号和 期刊 日志记录和集群问题调试变得更加快捷高效。内置的 DDoS 防护和详细日志记录功能构建了额外的安全层，能够实时关联网络攻击与应用程序性能。无论您使用的是 VPS、专用服务器还是 AI GPU 基础设施，Serverion 的全球数据中心都能确保您的监控工具即使在系统故障期间也能正常运行。毕竟，高可用性托管是可观测性工具真正发挥作用的基础。.
常见问题解答
使用 OpenTelemetry 监控容器的主要优势是什么？
OpenTelemetry 是一个开源框架，它通过标准化容器的可观测性实现方式，使容器可观测性更加简单。 痕迹, 指标， 和 日志 数据会被收集起来。它采用厂商中立的方式，这意味着您无需绑定到特定的供应商，可以自由选择或在不同的后端系统之间轻松切换。.
借助 OpenTelemetry，您只需对应用程序进行一次插桩。之后，您可以轻松地将数据导出到任何可观测性平台。这种一致性简化了监控，优化了故障排除，并确保您的可观测性设置能够适应未来的变化。.
如何以最佳方式管理高基数指标，从而提高系统性能？
管理高基数指标是保持容器可观测性框架快速且经济高效的关键。当指标包含具有大量唯一值的标签时（例如），就会出现高基数。 实例, 荚， 或者 命名空间这可能会导致存储系统不堪重负，增加资源需求，并损害性能——尤其是在 Kubernetes 或 Istio 等环境中。.
以下是一些处理高基数指标的实用方法：
- 标签仅限于必需品：坚持使用对故障排除至关重要的标签。避免使用高变异性标签，例如容器 ID 或请求 ID，因为它们会迅速增加唯一指标的数量。.
- 早期汇总指标像 Prometheus 这样的记录规则工具可以通过预先计算更高层次的指标来提供帮助。这可以减少需要存储的原始时间序列数据量。.
- 简化您的指标在数据摄取过程中，删除或重写不必要的标签。您还可以使用更高效的指标类型，例如计数器或桶数有限的直方图。.
通过简化和汇总指标，您可以维护一个可扩展且高效的可观测性框架。这在像 Serverion 提供的这种强大的基础设施上运行工作负载时尤为重要。.
容器可观测性框架的关键安全实践有哪些？
为了确保容器可观测性框架的安全，必须将遥测数据（例如指标、日志和跟踪数据）不仅视为发现威胁的工具，更视为需要保护的资产。在整个可观测性流程中融入安全措施，有助于及早发现异常，同时保护容器监控系统的安全。.
以下是一些需要考虑的关键步骤：
- 使用已验证和扫描的容器图像这有助于在部署前发现漏洞，降低引入安全缺陷的风险。.
- 以受限权限运行容器。避免授予 root 权限并强制执行只读文件系统，以最大限度地减少安全漏洞可能造成的损害。.
- 保护 API 密钥和令牌等机密信息将敏感信息存储在专用的密钥管理工具中，并在运行时安全地注入，以防止泄露。.
- 对遥测数据进行加密：对传输中的数据使用 TLS 加密，对静态数据使用安全的存储方法，以确保机密性。.
- 实施严格的访问控制实施基于角色的访问控制（RBAC）来限制谁可以查看和管理可观测性数据。.
通过遵循这些做法，特别是与 Serverion 的托管解决方案等可靠的基础设施相结合，您可以构建一个安全可靠的框架来保护您的容器化环境。.
