在 DigitalOcean 的目标一直都是：为用户的云服务开发提供灵活可扩展和简单易用的工具和基础设施。许多独立软件供应商 (ISV) 和初创公司（如 Snipitz、ScraperAPI、Nitropack、Zing 和 BrightData）已经通过 DigitalOcean Kubernetes 成功实现了业务的扩展和快速增长。
DigitalOcean Kubernetes （DOKS）以其简单易用的用户体验、稳定且可预测的定价模型、几乎免费的出站流量和多功能的云主机，成为 Kubernetes 托管服务的理想选择。这些功能使其非常适合那些寻求在 Kubernetes 上部署和扩展应用程序的企业，它能提供可靠且经济高效的解决方案。
在本系列的第 1 篇中，我们介绍了在 Kubernetes 上采用和扩展的挑战，以及"开发人员生产力"的最佳实践。随着企业的发展和应用程序的复杂度增加，可观察性成为生产环境中的关键组成部分。可观察性有助于快速识别并解决问题，同时优化环境，以提升性能和资源利用效率。
在这一部分（第 2 部分），我们将重点讨论 DigitalOcean Kubernetes 的可观察性最佳实践。首先，我们将介绍可观察性的整体概念，讨论其各个组成部分及其重要性。接着，我们将探讨企业在 Kubernetes 环境中实施可观察性时常遇到的挑战。最后，我们会提供一份全面的最佳实践清单，帮助你在 DigitalOcean Kubernetes 上实现有效的应用程序可观察性。
可观察性 - 总体情况
可观察性和监控经常被当作同义词使用，但两者的范围和方法有所不同。监控主要关注预定义的指标，并在超过阈值时触发警报；而可观察性则通过结合指标、日志、事件和跟踪，提供系统状态的全貌。在 Kubernetes 环境中，可观察性由多个组件组成，它们共同提供对应用程序和基础设施运行状况及性能的可见性。可观察性帮助你深入了解系统，并更高效地诊断问题。
传统上，可观察性依赖于三个支柱：指标、日志和跟踪。然而，在 Kubernetes 部署中，事件在故障排除和理解集群健康状况方面同样重要。因此，我们将探索 Kubernetes 可观察性的四大支柱：指标、日志、跟踪和事件。
指标 ：指标是对一段时间内测量数据的数值表示。在 Kubernetes 环境中，指标可能包括 CPU 和内存的使用率、网络流量、磁盘 I/O 以及自定义的应用程序级指标。指标在监控资源使用情况、识别性能瓶颈和设置警报方面至关重要。以下是一个 Prometheus 中常见的指标示例：
container_cpu_usage_seconds_total{container_name="oauth-server", namespace="production"}[5m]
This metric measures the total CPU time consumed by the oauth-server container in the production namespace over the last 5 minutes.**日志：**日志是事件记录流，用于捕获有关应用程序和基础架构的状态和活动的信息。Kubernetes 组件（例如控制平面和工作节点）会生成日志，容器化应用程序也是如此。日志对于调试、审计和故障排除非常有用。Kubernetes 中的典型日志条目如下：
2024-03-14T10:00:00Z ERROR [oauth-server] Failed to connect to database: timeout exceeded.
This metric measures the total CPU time consumed by the oauth-server container in the production namespace over the last 5 minutes.**事件：**Kubernetes 生成事件来记录集群内的状态变化和重大事件。事件可以提供有关资源创建、删除、扩展和错误情况的见解。监控事件可以帮助您了解 Kubernetes 集群的整体运行状况并及时应对紧急情况。Kubernetes 中的典型事件如下：
2024-03-14T10:05:00Z INFO [kubelet] Successfully pulled image "myapp:latest" for pod "myapp-pod" in namespace "production".
This log shows kubelet's success in pulling the latest image for "myapp-pod" in the "production" namespace.**跟踪：**在分布式微服务环境中，跟踪可在各个请求通过不同服务传播时提供端到端的可见性。跟踪有助于识别跨服务边界的性能瓶颈、延迟问题和错误情况，因此对于排除故障和优化复杂应用程序至关重要。以下是典型的跟踪示例：
Trace ID: 12345. Operation: GET /api/v1/users. Duration: 250ms. Status: Success.
This trace captures a successful GET request to the /api/v1/users endpoint, taking 250 milliseconds to complete.**警报：**有效的可观察性在很大程度上依赖于警报机制。通过根据预定义的阈值或条件设置警报，您可以在出现问题时及时通知相关团队或个人，从而缩短响应时间并最大限度地减少对应用程序和客户的影响。以下是警报示例：
Alert: CPU utilization for pod "api-server" in namespace "production" exceeds 80% for more than 5 minutes.
This alert notifies that the CPU utilization of the "api-server" pod has been above 80% for over 5 minutes, potentially indicating an issue.可观察性跨越多个层：
-
底层平台（Kubernetes 控制平面、工作节点、网络和存储）
-
你的应用程序（微服务、容器和工作负载）
-
业务数据（应用程序日志、用户交互和特定于领域的指标）
通过捕获和关联来自上述各层的数据，你可以全面了解系统的行为，更有效地检测并解决问题。
另一个需要考虑的重要方面是你是运行单个集群还是多个集群。在多集群环境中，可观察性变得更加重要，因为你需要跨不同集群聚合和关联数据，可能还涉及多个区域或云提供商。
对于 ISV 或初创公司来说，在你收集的可观察性数据和所需的洞察之间取得平衡至关重要。开发人员可能需要更细粒度的数据来调试和优化特定组件，而运营人员和站点可靠性工程师 (SRE) 更专注于提供整个系统健康状况的宏观视图，使用高级别的指标和事件。
考虑到这一点，我们来回顾一个示例，看看如何利用可观察性数据解决问题、找出根本原因并采取行动。
大海捞针 - 一个例子
假设你在 Kubernetes 上运行一个流行的电子商务应用程序，在销售高峰期，你开始收到客户的投诉，称在向购物车添加商品时响应变慢，且出现间歇性错误。你该如何确定问题的根本原因并解决它？
让我们来看看这个场景：
-
指标显示性能下降：你的监控仪表板显示购物车微服务的第 95 个百分位响应时间出现峰值，表明存在潜在的性能问题。此外，你注意到运行该服务的节点上的 CPU 和内存利用率有所增加。
-
日志提供上下文：通过分析应用程序日志，你发现购物车服务记录了大量与数据库连接超时相关的错误。这可能解释了客户遇到的性能下降和间歇性错误。
-
跟踪突出显示延迟：你转向分布式跟踪，发现对购物车服务的请求耗时远超平时，大多数延迟发生在数据库交互阶段。
-
事件指向资源争用：查看 Kubernetes 事件后，你发现集群中的几个节点一直面临高内存压力，导致频繁出现内核 OOM（内存不足）事件和 pod 驱逐。
-
关联和根本原因识别：通过关联指标、日志、跟踪和事件中的信息，你拼凑出问题的根本原因：销售高峰期的流量激增导致托管购物车服务及其数据库的节点出现资源争用。这种资源争用引发了数据库连接超时，进而导致响应时间变慢，并出现客户报告的间歇性错误。
有了这些洞察，你可以立即采取行动解决问题，例如扩展购物车服务和数据库。此外，你可以设置适当的警报和通知，以便将来主动检测类似问题。
这个例子展示了可观察性在快速识别和诊断复杂分布式系统中的问题方面的强大功能。通过利用指标、日志、跟踪和事件，并关联这些数据来源，你可以深入了解应用程序的行为，找出性能问题或故障的根本原因，从而实现更快的问题解决和更好的用户体验。
Kubernetes 可观察性的挑战
在 Kubernetes 环境中实施有效的可观察性可能会带来一些挑战，特别是对于资源有限的初创公司和 ISV。以下是一些常见的挑战和注意事项：
-
数据量和信噪比：Kubernetes 环境会生成大量可观察性数据，包括指标、日志、跟踪和事件。筛选这些海量数据以识别有用的信号和可操作的见解可能既耗时又让人不知所措。
-
存储成本：除非出于安全或合规原因需要，否则长时间存储和保留可观察性数据可能不划算。在数据保留策略和存储成本之间找到平衡至关重要，确保既能控制成本，又能保留必要的历史数据供分析和合规使用。
-
数据关联和上下文：来自不同来源的可观察性数据（如指标、日志、跟踪和事件）可能被孤立，使得关联这些数据并得出有意义的见解变得具有挑战性。合适的仪表板和警报对于获得良好见解至关重要。
-
警报和通知管理：定义合适的警报规则并有效管理通知也是一个难题。
-
扩展和多集群可观察性：随着业务的扩展以及 Kubernetes 集群跨多个区域或集群的增加，可观察性变得更加复杂。对于资源有限的 ISV，如何聚合和关联多个来源的数据，同时保持对系统的可见性和控制力是一个重大挑战。
-
安全性和合规性：可观察性数据可能包含敏感信息，如应用程序日志或用户数据。ISV 必须确保适当的访问控制和数据加密，同时遵守行业法规，这增加了可观察性实施的复杂性和成本。
为了有效应对这些挑战，ISV 应考虑采用根据其特定需求和约束量身定制的可观察性最佳实践，如下一节所述。
Kubernetes 可观察性的最佳实践
在 Kubernetes 环境中实施有效的可观察性需要采用结构化的方法并遵循最佳实践。以下是一些关键建议：
清单：将可观察性视为一段旅程
- 可观察性是一个持续的过程，而不是一次性的实施。随着 Kubernetes 环境的发展，你的可观察性需求也会随之变化。采用迭代方法，持续优化可观察性实践，以适应新需求、新兴技术和变化的工作负载。
在开始可观察性之旅之前，明确你的目标和目的。这些目标可以简单而明确，例如：
-
增强系统和应用程序的可见性
-
缩短平均检测时间 (MTTD)
-
缩短平均解决时间 (MTTR)
指标是任何可观察性策略的基础。先从指标开始可观察性之旅，它们为理解系统行为和性能提供了基础。
随着可观察性逐渐成熟，逐步将日志和事件纳入你的可观察性堆栈。日志提供关于应用程序行为的详细信息，帮助进行故障排除和根本原因分析。事件则可以揭示 Kubernetes 集群中的状态变化和重大事件。
通常，中小规模的 ISV 不建议从分布式跟踪开始，除非你对其复杂性和优势有深入了解。
清单：考虑使用 SaaS 平台实现可观察性
利用 SaaS 可观察性平台是资源有限的 ISV 和初创公司的最佳实践，因为它允许你专注于核心业务目标，同时享受企业级可观察性功能。通过将可观察性基础设施外包给托管服务提供商，你可以减少运营开销，降低对专业知识的需求，并确保可观察性堆栈的可扩展性和可靠性。
SaaS 可观察性平台提供了广泛的功能和优势，包括：
-
集中收集指标、日志和事件数据
-
无需管理底层基础设施，实现可扩展性和可靠性
-
与流行的 Kubernetes 版本、监控工具和日志框架的预构建集成
-
使用预构建的仪表板进行强大的查询和可视化
-
管理警报和通知
-
团队成员间通过共享仪表板、警报和见解进行协作
大多数 ISV 和初创公司资源有限，需专注于核心业务。选择 SaaS 可观察性解决方案，如 Logtail、Papertrail、Datadog、New Relic、Elastic Cloud 或 Grafana Cloud，是一个不错的选择。这些托管服务提供了全面的可观察性平台，同时将运营开销降至最低，让你专注于核心业务目标。在评估 SaaS 可观察性平台时，需考虑定价、易用性、与现有工具和平台的集成，以及客户支持。
清单：考虑使用 kube-prometheus-stack 进行自托管
使用 kube-prometheus-stack 是自托管可观察性的最佳实践之一。它提供了经过实战验证、专为 Kubernetes 环境设计的集成解决方案。通过使用此堆栈，团队可以快速建立强大的监控和警报系统，而无需大量配置和集成工作。该堆栈遵循最佳实践，为 Kubernetes 可观察性奠定了坚实的基础。
kube-prometheus-stack 是一组 Kubernetes 清单、Grafana 仪表板和 Prometheus 规则的集合，提供全面且易于部署的监控和警报堆栈。该堆栈包含流行的开源工具，如 Prometheus、Grafana 和 Alertmanager，并预先配置了最佳实践警报，可以与 Kubernetes 无缝协作。该堆栈可以扩展以监控和分析 Kubernetes 事件和日志，从而提供关于集群状态和资源变化的宝贵见解。
我们推荐使用 Loki 来记录 Grafana 的日志。Loki 是由 Grafana Labs 开发的可扩展、高可用的多租户日志聚合系统，专注于简单性和效率。它提供了一种经济高效的解决方案，用于在 S3/Spaces 存储中存储和查询大量日志数据。与传统日志聚合系统不同，Loki 通过标签而非全文索引进行日志搜索，极大降低了存储和计算要求。Loki 与 Grafana 无缝集成，提供了强大的查询和可视化功能。
为了进一步增强 kube-prometheus-stack 的警报功能，你可以考虑集成 Robusta 等工具。Robusta 能丰富来自 Alertmanager 和 Kubernetes 事件的警报，提供额外的背景信息，简化警报管理，并帮助主动识别和响应问题。
使用 Grafana 仪表板时，建议根据不同用户角色进行定制。开发人员可能需要更详细的信息来进行调试和优化，而运维人员和 SRE 可能更关心系统健康状况和性能的概览。根据用户角色自定义仪表板能提高效率并提供更具可操作性的见解。
清单：控制成本
控制可观察性成本需要实施策略来管理和优化数据的存储和保留。随着 Kubernetes 环境的增长，指标、日志和事件的数据量可能迅速增加，若管理不善，会导致高昂的存储成本。
以一个 10 节点的 Kubernetes 集群为例：
-
假设每个节点每天生成 100 MB 的日志数据，每分钟产生 100 个指标。
-
每天的存储需求为：
-
日志数据：10 个节点 × 100 MB/天 = 1 GB/天
-
指标数据：10 个节点 × 每分钟 100 个指标 × 1440 分钟/天 × 8 字节/指标 = 115 MB/天
-
这意味着每月大约需要 30 GB 的日志存储和 3.45 GB 的指标存储。这些数据量会迅速累积，增加存储成本。
为了控制成本，考虑以下策略：
-
数据收集优化：选择对你可观察性需求至关重要的指标、日志和事件。使用过滤和聚合技术在存储前减少数据量。
-
数据保留策略：根据可观察性和合规要求，定义明确的数据保留策略。实施分层保留策略，短期内存储高分辨率数据，长期保存聚合数据。
检查表：集中多集群环境的可观察性
许多 ISV 运营多个 Kubernetes 集群。虽然你可以通过独立部署 kube-prometheus-stack 并使用良好的警报（如 Slack 集成）进行管理，但在这种情况下，集中可观察性是最佳实践。
集中可观察性带来的好处包括：
-
统一可见性：通过聚合多个集群的可观察性数据，你可以获得整个 Kubernetes 环境的整体视图。
-
简化故障排除：集中可观察性使你能够快速识别和排查跨集群的问题。
-
一致的监控和警报：使用集中式可观察性解决方案，你可以在所有集群中定义并执行一致的监控和警报策略。
-
高效的资源利用：通过集中可观察性，你可以更深入地了解跨集群应用程序的性能和扩展性，优化资源利用率。
上图展示了这样的架构。要将多集群环境中的可观察性集中化，你可以使用 Grafana Mimir 或 Thanos 等工具。这些工具旨在聚合和联合多个 Prometheus 实例的数据，这些实例通常用于监控 Kubernetes 集群。
Grafana Mimir 是一个高度可扩展的分布式时间序列数据库，它可以从多个 Prometheus 服务器提取并存储指标。你只需将 Mimir 作为数据源连接到 Grafana。这样可以减少大量配置工作，你也无需在每个集群上公开每个 Prometheus 服务。现在，你可以在所有连接的集群中获得全局查询视图，从而实现跨集群分析和可视化。Mimir 还提供水平扩展、高可用性和长期存储功能。
在集中化可观察性时，需要考虑以下几个方面：
-
数据聚合：确定需要从每个集群聚合的指标和日志，并相应地配置可观察性工具。
-
查询性能：确保你的集中式可观察性解决方案能够处理查询负载，提供快速响应时间，即使是在处理多个集群的大量数据时。
-
数据保留：为你的集中式可观察性系统制定数据保留策略，同时考虑存储需求和历史数据分析需求。
-
访问控制：实施合适的访问控制机制，确保用户只能访问与其角色和职责相关的可观察性数据。
可观察性是一个持续的过程，持续改进和适应是成功的关键。定期审查和优化你的可观察性实践，以适应不断变化的业务需求和技术进步。
接下来几步
随着我们继续探索 ISV 采用 Kubernetes 的历程，接下来的博客系列将深入探讨如何提升你的部署弹性、效率和安全性。
-
开发人员生产力（第 1 部分）：通过简化 Kubernetes 环境中的开发和部署流程，最大化开发人员的生产力。
-
可观察性（本帖）：解析工具和策略，帮助深入了解你的应用程序和基础设施，确保你能够有效监控性能并解决问题。
-
可靠性和规模（第 3 部分）：探讨如何实现零停机部署、就绪/活跃度探测、应用程序扩展、DNS 和 CNI 管理，以在不同负载下保持最佳性能。
-
灾难准备（第 4 部分）：讨论制定可靠的灾难恢复计划的重要性，包括备份策略、实践以及定期演练，以确保业务连续性。
-
安全性（第 5 部分）：深入探讨如何保护你的 Kubernetes 环境，涵盖网络策略、访问控制以及应用程序工作负载的安全实践。
这些主题对于驾驭 Kubernetes 的复杂性、增强基础设施弹性、扩展性和安全性都至关重要。请继续关注我们的见解，帮助你在 Kubernetes 之旅中取得成功。
准备好踏上变革之旅，并充分利用DigitalOcean Kubernetes了吗？如果你还需要了解更多关于 DigitalOcean Kubernetes 托管服务的细节，欢迎联系 DigitalOcean 中国区独家战略合作伙伴卓普云科技。