对于微服务架构监控应该遵守的原则 _架构

随着软件交付方式的变革，微服务架构的兴起使得软件开发变得更加快速和灵活。在这种情况下，监控系统成为了微服务控制系统的核心组成部分。随着软件的复杂性不断增加，了解系统的性能状况和及时排除问题变得更加困难。因此，监控系统也需要与时俱进，进行全面的改造，以更好地适应微服务环境的需求，并能够更好地发挥作用。
【对于微服务架构监控应该遵守的原则】新兴的微服务架构对软件开发带来了速度和灵活性的提升，从而改变了传统的软件开发模式。其中，速度是微服务的核心需求之一。为了更好地满足这一需求，监控系统也需要随之进行调整和改进。
监控在微服务体系结构中变得尤为关键，因为随着软件复杂性的增加，我们需要更好地了解系统的性能和及时发现问题。下面是我们制定的五个指导性原则，以帮助我们整监控方法：

监控容器及其内部：微服务通常在容器中运行，因此监控容器本身以及容器内的各种组件和资源是至关重要的。
关注服务性能而不是容器性能：在微服务架构中，重点应该放在监控服务的性能和健康状态上，而不是单纯地监控容器的资源使用情况。
监控弹性和多地部署的服务：微服务架构的一个优势是其弹性和多地部署的能力，因此监控系统需要能够有效地跟踪和管理这些特性。
监控 API：微服务通常以 API 的形式提供服务，因此监控这些 API 的性能和可用性对于确保整个系统的稳定运行至关重要。
将监控映射到组织结构：根据我们的组织结构和团队的职责，设计监控系统的结构，确保监控数据能够直观地反映出整个组织的运行状态。

通过遵循这五个原则，可以建立起更加有效和全面的微服务监控系统，从而更好地应对微服务架构所带来的技术和组织上的挑战。
下面我们细说这五个原则监控容器及其内部随着微服务架构的流行，容器技术已成为构建微服务的重要组成部分。容器具有速度、可移植性和隔离性等优势，使得开发人员更容易接受微服务模型。容器的好处已经被广泛讨论，不再赘述。
然而，对于外部系统来说，容器就像一个黑盒子一样。这对于开发人员来说是非常方便的，因为容器可以轻松地在不同的环境中部署。但是一旦容器开始运行，当需要监控和解决服务问题时，这个黑盒子就会成为挑战，因为常规的监控方法往往无法生效。我们需要深入了解容器内部运行的情况：究竟运行了哪些程序和代码？它们的性能如何？是否有重要的输出指标？从DevOps的角度来看，我们需要更深入地了解容器，而不仅仅是知道它们的存在。
在非容器环境下，常见的监控方法是在主机或虚拟机的用户空间内运行一个代理程序。然而，这种方法并不适用于容器环境。容器的优点之一是轻量级，它们将各种进程隔离开来，并尽可能地减少依赖关系。
此外，大规模使用成千上万个监控代理对于即使是中等规模的部署来说都是一种昂贵的资源浪费和管理上的挑战。对于容器环境，有两种潜在的解决方案：

要求开发人员直接监控他们的代码：让开发人员负责监控其代码的性能和运行状况。这种方法可以让开发人员更深入地了解其代码的运行情况，但可能会增加他们的工作负担，并且对于整个系统的全面监控可能不够全面。
利用内核级的检测方法：使用一种通用的内核级监控方法来查看主机上的所有应用程序和容器活动。这种方法可以减少代理的数量，并提供更全面的监控覆盖范围，但可能会影响主机的性能，并且可能无法提供与每个容器相关的详细信息。

每种方法都有其优点和缺点，选择最适合环境的方法取决于我们的具体需求和限制。
利用业务流程系统提醒服务性能在容器环境中理解运行数据并不容易，相比于单个容器，聚合多个容器组成的功能或服务的复杂度要低得多。
这种方法特别适用于应用程序级别的信息，比如哪个请求具有最短的响应时间，或者哪些 URL 遇到了最多的错误。同样，它也适用于架构级别的监控，比如哪个服务的容器使用了超出事先分配的 CPU 资源。