在 AWS 容器的可观测性策略中要考虑的 7 件事

7 你要考虑的因素可观测性战略AWS容器 云原生架构具有您所知道的所有优势——速度、规模和敏捷性——但它们也存在障碍，尤其是在监控方面。如果你负责充分利用组织的容器实现，则可能会遇到挑战 ，以保持领先于问题。许多有远见的组织正在通过基于可观测性的容器监控策略来应对这些挑战。 选择正确的容器监视和可观测性策略可能与选择正确的运行时和编排技术一样令人生畏。它是使容器架构做好生产准备的最关键组件之一。如果您在没有万无一失的监控和可观察性策略的情况下将新容器推向生产环境，您将 有问题。 根据CNCF对近2，400名CNCF成员的调查，监控和可观察性已成为采用新云原生架构的DevOps团队最关心的问题。 调查结果：容器监控是最大的挑战 受访者表示监控是挑战 38% 大企业得到更大的挑战 46% 资料来源：CNCF调查：云原生技术在生产中的使用量增长了200%以上 在规划和执行容器监控和可观测性策略时，需要考虑以下事项。 1 考虑 集成 有许多容器技术可供选择，就像有一样 多种云原生技术。了解容器技术在更广泛的云原生堆栈中的集成程度至关重要。 例如，如果您的Elasticsearch数据位于监控系统A中，而您的容器遥测数据位于监控系统B中，则成功的机会不大。为了确保您拥有做出有效决策的所有数据，您需要一个监控平台，该平台具有捕获和关联数据所需的所有集成，以及可观测性的单一事实来源。在集成方面，您需要考虑稳健性、广度和覆盖范围。 推荐策略 选择高度集成到云原生生态系统中的监控供应商，例如Splunk与AWS相结合。 2 考虑 下面的SplunkAmazonECS监控控制面板显示了与ECS任务相关的性能指标。 发现和摄取 由于容器的生存期可能非常短（秒/分钟），因此在上下旋转时发现新容器并将其与正确的主机（EC2等）和微服务相关联以加快MTTR至关重要。容器是轻量级的，因此在传统监控供应商使用的容器上运行重量级代理是没有意义的。 推荐策略 选择使用轻量级代理自动发现新容器和服务的供应商。借助Splunk基础设施监控，您可以查看详细的指标，这些指标可以使用SplunkAWS容器资源监控控制面板提供实时主动故障排除见解。选择基于开放标准的解决方案，而不是使用其重量级或专有代理的解决方案。这减轻了供应商锁定的担忧，并获得了生态系统友好的好处 。 3 考虑 在更高的数据量下快速响应。最后，数据突发性意味着峰值负载远高于正常水平，并且为峰值容量进行配置会在非高峰时段浪费大量资金。 提供商业选项。在为许多监控团队利用K8s和容器时，通常会选择开源TSDB（时间序列数据库）。但是，在某些时候，您会感受到上面讨论的问题的痛苦。这可能是更好地利用您的时间，开发人员和金钱来集中精力在您的核心业务上。调整托管监控解决方案，例如使用容器构建的Splunk基础架构监控（如下所示）。 规模 微服务和容器的激增造成了需要分析的数据点的爆炸式增长。当前的趋势将继续增加数据点的数量：垃圾箱打包是一种常见的策略，它增加了每个主机的容器数量，这意味着每个主机的数据更多。团队这样做是为了帮助节省云计算的成本。此外，正确调整计算实例的大小意味着实例比传统的大型主机多得多。 精细的可观测性用例（例如基于每个客户或类别的监视/警报）会导致传统监视工具的性能下降。高数据量会阻止重要的用例（例如，在一年内搜索1，000个容器转化为310亿个数据点）、容量规划，甚至会减慢中断期间的根本原因分析。 推荐策略 构建自己的解决方案来处理规模需要认真权衡，最终可能不值得头疼。请记住，随着您将来继续扩展容器，数据量将继续快速增长。自行开发的系统不仅必须处理当今的数据规模，而且必须在未来继续保持良好的性能。这将需要大量的投资、护理和喂养。您不仅需要扩展数据存储，因此不需要 在多个孤立的数据库中进行分段，但查询必须继续 4 考虑 延迟 每次评估警报时运行完整查询并加载完整数据集的传统批处理监视系统不足以满足现代需求。这些系统无法每隔几分钟刷新一次查询，这意味着最终用户无法以精细粒度跟踪应用程序。由于容器的短暂（短暂）性质，它们还会错过有关容器的重要警报和分析。 推荐策略 在正确实施的情况分析技术在监视方面优于批处理方法。流分析不仅可以支持更大的数据量和并发用户/查询，还可以实时触发更新和警报。建议生成或购买流式传输数据的监视解决方案，以便在几秒钟内对容器数据发出警报和分析。这提供了更快地对问题采取行动的能力，并且 甚至可以通过Webhook触发警报，以执行自动回滚和其他操作，以在机器时修复问题。 5 考虑 如果您已经构建或计划构建系统，您需要考虑以下一些事项：您计划预置容量以处理突发或减慢代码推送以平滑突发如果过去查询数据对您来说是一个重要的用例，您最终可能会在每个服务或应用程序的基础上实施某种“预聚合”或“预计算”方案来处理这个问题。但是，这将在警报的及时性和准确性之间进行权衡。大多数开源工具不会让你同时拥有两者。 生产 流失是监测中最被低估的，也可能是最痛苦的问题。从技术角度来看，当一个数据源被另一个等效数据源替换时，就会发生流失。这种容器的搅动创造了 元数据的爆炸式增长，因为数据源的标识不断变化。导致这种流失的一些用例包括CI/CD部署（一些组织将其整个环境蓝绿）、自动扩展、云中短期spot实例以及影响许多指标的大规模标记（例如，向所有指标添加“customer_id”等新标签）。流失不仅会导致元数据随着时间的推移而累积，而且有时也会发生 突发（例如，在蓝绿整个应用程序或服务时）。许多监控系统无法处理这种突然的元数据量，也无法足够快地处理或索引它。 推荐策略 流失可能对您的监控系统造成危险，并且随着时间的推移，其影响可能会逐渐恶化。如果你每天推送代码，一年后你将不得不处理365倍以上的元数据，而容器的挑战性要大得多。 流失问题在当今的监控供应商中也广泛存在。它们在小型概念证明（POC）中可能效果很好，但性能会随着环境的时间和规模而降低。选择在构建系统时考虑到流失问题的供应商。 6 考虑 可见性 在当今的分布式容器化环境中，很难找到问题的根本原因。拥有一个可以帮助您可视化堆栈中的数据的解决方案对于在事件突然出现时从噪音中梳理信号非常重要。 推荐策略 利用Grafana进行一般可视化或利用Sysdig深入了解容器的可视化直至内核级别是选项，但它们只能解决可观测性难题的一部分。请注意不要堆叠太多点工具。相反，请考虑尽可能多地整合您的工具以节省成本。您可能希望选择一个端到端的可观测性平台，而不是将可以覆盖整个堆栈广度的点工具拼凑在一起，并使用预构建的仪表板来快速实现价值。 7 考虑 故障排除 将基础结构与基础结构所服务的应用程序相关联非常重要。随着一些公司采用容器，他们这样做的心态是将其整体式应用分解为微服务，或者重新开始为其绿地应用的分布式服务架构。这使得在事务数据遍历容器支持的这些服务时捕获事务数据变得至关重要。 推荐策略 利用基于尾部的分布式跟踪解决方案，该解决方案可观察遍历应用层的所有事务，并存储p90和p99跟踪以进行历史分析。此外，请确保你的解决方案将帮助你的团队以引导式方式解决问题。当今系统的分布式特性在服务之间创建了相互依赖关系，这些相互依赖关系至关重要，并且需要能够梳理出服务之间通信中大部分延迟的位置 。您还需要快速回答底层基础架构是否会导致延迟或错误增加， 因此，您需要一个将基础架构指标和应用程序跟踪联系在一起的解决方案。 Splunk作为容器可观测性策略的核心 Splunk通过单一管理平台为AWS基础设施、Kubernetes平台、AppMesh数据平面（Envoy、Docker容器和微服务）提供统一监控。无论您是在AmazonEKS、ECS还是EC2上的Kubernetes中部署AppMesh，Splunk都能提供全面的全栈监控。 Splunk基础设施监控提供了与CloudWatch的强大集成，为基础设施导航器提供了CloudWatch支持的模式，并且 包括许多内置控制面板，可帮助您开始监控亚马逊云科技。您还可以使用智能代理监控亚马逊云科技实例及其上运行的服务。与AWSCloudWatch相比，智能代理提供的自定义程度要高得多，对于您希望在 更精细的分辨率，或者对发送的指标的详细控制很重要。智能代理是用Go编写的度量代理，用于监视各种不同环境中的基础结构和应用程序服务。它安装了100多个捆绑的监视器，用于收集数据，包括基于Python的插件，如Mongo、Redis和Docker。 智能代理最初是作为Kubernetes集成开发的，现在从容器化和非容器环境中收集主机性能、应用程序和服务级别指标。有关AWS的完整列表 Splunk监控的服务和基础设施见：https://docs.signalfx.com/en/latest/integrations/amazon-web-services.html。 容器是开发库中的强大工具，但了解如何和 容器环境的运行情况。要了解更多信息，请立即注册免费试用版。 开始 Splunk、Splunk>和TurnDataIntoDo是SplunkInc.在美国和其他国家/地区的商标和注册商标。所有其他品牌名称、产品名称或商标均属于其各自所有者。©2022斯普伦克公司保留所有权利。 22-25586-splunk-7AWS容器的OBS策略中需要考虑的事项-LS-105