五条原则——关于DevOps监控微服务

    今天这样我们将介绍一下关于网络监控微服务的 5 条原则：

     1、监控容器及其内部内容
     容器对于构建微服务非常重要，它们的速度、可移植性和隔离性使得开发人员很容易爱上微服务模型。
     容器就像它的外围系统的黑匣子。这对于企业开发来说有很大的好处，从开发工作环境到生产生活环境；从开发者的笔记本到云端，可以带来经济高度可移植性。
     非容器环境中的一个典型措施是在主机或虚拟机上的用户空间中运行代理，但这不适用于容器。因为容器具有体积小的优点，所以它们将流程分离并最小化依赖性。
     此外，在规模上，数以千计的监测人员，即使是中型部署，也是浪费和管理资源的噩梦。
    2、使用业务流程性能警报系统
    理解的是，集装箱船的运行数据是不容易的，因为相比于由单个功能或服务聚合容器中，低得多的复杂度测量的容器。这特别适用于企业应用系统程序进行级别的信息，同样也适用于架构级别的监测。
     为了尽可能贴近监控服务的体验，DevOps 团队应该将告警重点放到运行特征上来。 如果应用受到影响，警报便作为评估情况的第一道防线。但要获得这些警报是不容易的，除非你是在监控系统诞生是基于原来的容器上。
     3、监控弹性Elastic和多地部署Multi-Location服务
     弹性服务在容器环境中的变化速度比虚拟化环境快得多，快速变化将严重影响检测系统的正常运行。
传统的监控系统通常需要部署软件，检查手动调节指数。这种结构调整是通过具体的、或基于企业应用系统程序在一个具有特定的容器中的操作人员配置要收集的数据。 在一个小规模范围内，我们可以接受的。微服务的集中进行监控系统必须自己能够通过自由的随弹性服务而增长和缩减，无需人工干预。
    在生产环境中，建立面向跨越多个数据中心或多个云的复杂部署的监控，比如，如果你的服务跨越私有数据中心和 AWS，那么亚马逊的 AWS CloudWatch 就很难做到这一点。这要求我们建立一个跨不同区域的监控系统，并且可以在动态的本地容器环境中运行。
     4、 监控 API
     在微服务环境中，API 接口是通用的，它们是暴露给其他球队服务的唯一组成部分。API 的响应和一致性可以看作是“内部 SLA”，即使还没有定义一个正式的 SLA。
因此，API 接口的监控也是必要的。 API监控可以采取不同的形式，它绝对不是一个简单的二进制上下检查。例如，了解像时间函数这样的最常使用的端点endpoint是有价值的。这使得企业团队管理可以看到服务系统使用的变化，无论是由于我们设计变更或用户的改变。
    最后，另一个很重要的能力是跟踪管理系统进行服务响应的能力，它主要是开发者可以使用，也能帮助你了解企业整体提高用户体验，同时将信息技术基于社会底层和应用研究程序视角分成两大部分。
    5、将您的监控映射至您的组织结构 

    这篇文章的重点是微服务和监控，就像在其他技术文章中一样，因为许多人都关心这个水平。
    所以，如果他们想从这个新的软件架构中受益，他们的团队必须映射到微服务团队本身。换句话说，他们需要一个更小，更松散耦合的球队，只要他们能够满足整个需求可以选择自己的方向。
    DevOps的球队本可以使监控平台：让每队可以拥有自己的微服务警报，度量和控制面板，也赋予了整个系统的视图。
    以上就是关于网络监控微服务的 5 条原则。

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！