如何选择微服务监控工具

微服务允许开发者将他们的应用程序分解成更小的、松散耦合的服务，这些服务独立开发、部署、扩展。但是，您需要一个监控工具来追踪软件是否工作正常——这意味着您需要有用的标准来选择此类工具。

您习惯于追踪应用程序性能以确认其是否正常运行，但微服务增加了一些新花样。监控是管理任何微服务架构的关键方面。根据定义，其中包括大量独立的部分。 

但是您如何为自己的业务选择最佳微服务监控工具？我们不是来偏心的，也不是来支持特定的工具。然而，我们在该领域确实有大量经验，很乐意与您分享。

监控您的期望

在选择工具之前，要思考您获得它的动机。您的团队应该讨论，“我们尝试解决或防止什么问题？”由此产生，“我们需要检查哪些数据，才能确定我们是否正在解决或防止这些问题？”答案有助于您识别要监控哪些内容——以及您可以忽略哪些内容（或不那么关注哪些内容）。 

对您监控的内容要深思熟虑。要有理由。不要采用这样的态度：“万一对我有用，那就监控所有事情吧”。大多数团队的资源有限，这意味着无论如何都不可能监控所有事情；最好的情况是，您最终会感到警报疲劳。

也就是说：您的期望可能与现实不符。很难提前知道意外事件发生时什么会有用。在一切都陷入混乱且您试图弄清楚正在发生什么之前，不清楚需要监控什么。您需要“深思熟虑”和“根据经验调整”相结合。

微服务监控工具标准

任何类型的应用程序监控工具都具有一系列功能。您可能不需要所有这些功能。最好从我们的 Redis 专家和经验丰富的从业人员（有过经历的人）确定的首要标准开始。

它应该可以扩展。随着微服务架构的增长，您的监控需求也会增长。您最不想要的是一个无法承受负载的工具。确保您的监控系统可以自行关闭，而不会导致微服务崩溃！

它需要收集正确的数据并对其进行分析。仔细查看该工具收集的数据以及它如何呈现该信息。 

一个稳健的监控工具会收集和分析分布式系统中每个角落缝隙的数据——但它不应该用嘈杂、不相关的信息淹没您。它应为您提供全面的见解，包括性能指标、日志和跟踪等值得称为“见解”的内容。 

对于微服务架构，优先考虑分布式追踪。调试跨多个微服务的问题可能是一场噩梦。分布式追踪有助于您追踪跨服务的请求流，有助于识别性能瓶颈并了解复杂的交互。例如，确保每个日志消息/记录/行都有一个可归因的 traceid 连接到它，并使用一个允许您聚合视图的系统。

它应当与您使用的其他工具轻松集成，无需繁琐的设置或自定义代码。或许比任何其他应用程序更重要的，监控工具应当与其他工具很好地配合使用。

类似地，查看从现有供应商迁移到新监控工具的过程，包括数据结构要求。研究一下，如果此工具无效，切换到其他工具需要做什么。了解 API 是什么，因为您在某个时刻肯定会需要它。考虑未来的标准支持，例如 OpenTelemetry。

请让它易于学习和易于使用（它们不是同一件事）。谁愿意努力学习另一个工具？浏览分布式系统已经足够复杂；您的监控工具应当简化事情，而不是增加系统的复杂性。配置不应该很痛苦。密切注意其仪表盘和可视化，以决定它们是否像供应商承诺的那样直观。

它应当设置明智的警报和通知。当风暴来临时，您需要立即知道！您的监控工具应当提供强大的警报和通知功能，这样您才能在小问题变成大问题之前采取行动。

它必须符合您的预算。虽然您为分布式系统想要最好的工具，但您不想与 CFO 有不舒服的对话。对于任何 IT 支出都是如此，但在这里尤其如此，因为成本和定价模式差异很大。众所周知，意外的使用会造成所谓意外超支的事故。按用户付费模式有时会产生尴尬的决定，即谁可以获得访问权限。

这些工具实际上监控什么？

微服务监控工具应当提供跨整个微服务生态系统的可见性，包括性能指标、资源利用、服务网格数据、自定义指标和错误率。

理想的工具应当在收集、存储和分析分布式系统的数据方面表现出色，为每个微服务的健康和性能提供可操作的见解。它应当与其他工具和系统（如日志系统、警报工具和事件管理平台）无缝集成。

• 性能指标：监控工具收集和监控来自各种组件的性能指标，例如 CPU 使用、内存利用率、网络流量和单个微服务的响应时间。这有助于追踪整体运行状况和系统性能。
• 资源利用：监控工具会密切关注微服务和基础设施组件的资源消耗。其中包括监控 CPU、内存、磁盘使用量和网络带宽，以确保资源的有效分配。
• 错误率和故障分析：这些工具会追踪来自微服务的错误率、状态代码和错误消息。这可以帮助快速检测异常现象和潜在问题，帮助开发者精确定位故障并迅速解决。
• 延迟和吞吐量：监控工具会衡量微服务处理微服务请求所花费的时间以及处理这些请求的速度。
• 警报和阈值：如果任何指标超过指定阈值，则系统会触发警报，以便 IT 团队可以立即采取行动。
• 日志和追踪：一些监控工具会与日志系统集成，以从多个服务中捕获和分析日志。追踪功能使开发者能够在各个微服务中追踪请求的流程。
• API 监控：这些工具可以监控不同微服务和 API 之间的互动，确保 API 调用成功（并且在调用失败时通知您），以及确定 API 通信中的潜在瓶颈。
• 容器监控：监控工具可以捕获容器运行状况中的特定环境问题，例如资源利用和性能。
• 服务网格可观察性：对于使用服务网格的微服务架构，监控工具可以提供对网格中微服务之间通信和互动的洞察。
• 应用程序性能监控（APM）：APM 工具关注各个微服务的代码级性能，以使开发者更轻松地确定性能瓶颈。
• 自定义指标：高级监控工具认识到这些类别有时是不够的。它们使您可以定义和收集针对您的微服务架构的自定义指标。

实际上，如果您使用 Redis（用于微服务或其他用途），那么以下内容是一个良好的入门套件，可用于监控。您的仪表板可能包括这些项目，这些项目会进行配置，以便在任何指标出现大幅度峰值时向您发出警报。

• 按命令、服务和/或脚本/函数对命令量进行分类
• 按命令、服务和/或脚本/函数对命令故障率进行分类
• 按命令、服务和/或脚本/函数对命令延迟进行分类
• 内存使用量
• 键数（DBSIZE）

微服务监控工具

您可以自由选择。每种微服务监控工具都提供独特的功能。也许这些链接可以帮助您提前了解您的购物清单——尽管这里包含的选项还有很多。

• Prometheus：该开源监控和警报工具包专为分布式系统设计，因此适用于微服务监控。
• Grafana：Grafana 以其可视化和仪表板而闻名，这些功能有助于导航数据集合并将其以人类可理解的形式展现出来。
• Datadog：Datadog 提供实时警报、分布式跟踪和 APM，并具有可深入了解微服务生态系统的功能。
• Dynatrace：该监控工具为微服务环境提供自动应用程序发现和可观察性。
• Architect.io：该工具深受大型组织青睐，提供稳健的测试和监控功能，并能全面了解微服务架构。
• Lumigo：Lumigo 提供端到端的可视性、实时调试和成本监控，并特别注重无服务器架构。
• AppDynamics：该工具实时可视化、异常点检测、网络性能监控以及 Docker 和 Kubernetes 监控，可能适用于追踪大型复杂架构中的事件。
• Instana：该工具承诺为整个微服务环境提供完全的可观察性。
• Uptrace：Uptrace 侧重于对性能数据的可视性和与流行的编程语言和框架的集成，帮助开发人员识别、诊断和解决微服务生态系统中的性能问题；我们最近撰写了有关我们 Uptrace 体验的文章。

哪款工具最适合你？由你来决定。

优化微服务监控

 与选择任何其他软件一样，最终重要的是它能适合你。'nbsp;

没有明确的对错之分。关键问题是，“这是适合我具体项目的吗？” 关键是找到符合你项目的当前和未来需求的工具，并做出明智的选择。理想情况下，你选择的工具可以帮助你维护一个健康高效的微服务环境，最终交付可靠的高性能应用程序。Redis 与所有这些工具均兼容。

我们相信，你可以利用 Redis Enterprise 将你的微服务应用程序提升到一个新的水平。阅读面向微服务的缓存和消息代理解决方案简介，了解如何使用 Redis Enterprise 进行缓存，探索顶级缓存模式，以及使用 Redis Streams 作为轻量级消息代理进行服务间通信。