虹科干货|一份选择微服务监控工具的指北

毋庸置疑，监控是管理任何微服务架构的一个关键方面。但是如何为业务选择最佳的微服务监控工具呢？有哪些微服务监控工具？这些工具有什么功能？这里一份参考指北供你参阅。

监控您的期望

监控哪些内容？

在选择工具之前，请考虑一下您购买工具的动机。您的团队应该讨论“我们试图解决或预防哪些问题？” 这就导致了“我们需要检查哪些数据来确定我们是否正在解决或预防这些问题？” 这些答案可帮助您确定要监控的内容以及可以忽略（或较少关注）的内容。 

不要采取“监控所有事情以防万一有用”的态度。大多数团队的资源有限，这意味着无论如何都不可能监控所有的事情；充其量，你最终会感到警觉疲劳。也就是说：您的期望可能与现实不符。当意外的事情发生时，很难提前知道什么是有用的。直到一切都着火并且您试图弄清楚发生了什么之前，并不清楚需要监视什么。您需要将“仔细思考”和“根据经验进行调整”结合起来。

微服务监控工具标准

任何类型的应用程序监控工具都具有许多功能。您可能不需要全部。最好从我们的 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 的经历。

· .......

加强微服务监控

没有明确的正确或错误的选择。关键问题是，“这是适合我的特定项目的工具吗？” 关键因素是找到适合您项目当前和未来需求的工具并做出明智的选择。理想情况下，您选择的工具可以帮助您维护健康高效的微服务环境，最终交付可靠的高性能应用程序。Redis 可以与所有这些一起工作。您可以使用 Redis Enterprise 将您的微服务应用程序提升到新的水平。

监控您的期望

监控哪些内容？

在选择工具之前，请考虑一下您购买工具的动机。您的团队应该讨论“我们试图解决或预防哪些问题？” 这就导致了“我们需要检查哪些数据来确定我们是否正在解决或预防这些问题？” 这些答案可帮助您确定要监控的内容以及可以忽略（或较少关注）的内容。 

不要采取“监控所有事情以防万一有用”的态度。大多数团队的资源有限，这意味着无论如何都不可能监控所有的事情；充其量，你最终会感到警觉疲劳。也就是说：您的期望可能与现实不符。当意外的事情发生时，很难提前知道什么是有用的。直到一切都着火并且您试图弄清楚发生了什么之前，并不清楚需要监视什么。您需要将“仔细思考”和“根据经验进行调整”结合起来。

微服务监控工具标准

任何类型的应用程序监控工具都具有许多功能。您可能不需要全部。最好从我们的 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 的经历。

· .......

加强微服务监控

没有明确的正确或错误的选择。关键问题是，“这是适合我的特定项目的工具吗？” 关键因素是找到适合您项目当前和未来需求的工具并做出明智的选择。理想情况下，您选择的工具可以帮助您维护健康高效的微服务环境，最终交付可靠的高性能应用程序。Redis 可以与所有这些一起工作。您可以使用 Redis Enterprise 将您的微服务应用程序提升到新的水平。