认识达内从这里开始

DevOps技术是目前大多数企业在开发软件的时候都会用到的一个编程技术，而本文我们就通过案例分析来简单了解一下，DevOps监控微服务的原则分享。

1、监控弹性Elastic和多地部署Multi-Location的服务

弹性服务不是一个新概念，但是它在原生容器环境中的变化速度比在虚拟环境中快的多。迅速的变化会严重影响检测系统的正常运行。

监测传统的系统经常需要根据软件部署，手动调整检查指标。这种调整可以是具体的，如定义要捕获的单个指标，或基于应用程序在一个特定的容器中的操作配置要收集的数据。在小规模上(比如几十个容器)我们可以接受，但是再大规模就难以承受了。微服务的集中监控必须能够自由的随弹性服务而增长和缩减，无需人工干预。

比如，如果DevOps团队必须手动定义容器包含哪个服务需要监控，他们毫无疑问会失手，因为Kubernetes或者Mesos每天都会定期创建新的容器。同样，如果代码发布并置于生产环境时要求运维团队安装一个定制的状态端点customstatsendpoint，也给开发者从Docker仓库获取基础镜像带来更多的挑战。

在生产环境中，建立面向跨越多个数据中心或多个云的复杂部署的监控，比如，如果你的服务跨越私有数据中心和AWS，那么亚马逊的AWSCloudWatch就很难做到这一点。这就要求我们建立一个跨不同地域的监控系统，并可在动态的原生容器环境下运行。

2、监控API

在微服务环境中，API接口是通用的。本质上，它们是将服务暴露给其它团队的组件。事实上，API的响应和一致性可以看作是“内部SLA”，即使还没有定义一个正式的SLA(服务等级协议)。

因此，API接口的监控也是必要的。API监控可以有不同的形式，但是很显然它绝对不是简单的二进制上下检查。例如，了解像时间函数这样的常使用的端点endpoint是有价值的。这使得团队可以看到服务使用的变化，无论是由于设计变更或用户的改变。

你也可以记录服务缓慢的端点，这些可能揭示出重大的问题，或者至少指向需要在系统中做优化的区域。

后，跟踪系统服务响应的能力是另一个很重要的能力，它主要是开发者使用，也能帮助你了解整体用户体验，同时将信息基于底层和应用程序视角分成两大部分。

3、将您的监控映射到您的组织结构

这篇文章着重在微服务和监控上，像其他科技文章一样，这是因为很多人都关注此层面。

对于那些熟悉康威定律Conway’slaw的人来说，系统的设计是基于开发团队的组织结构。创造更快，更敏捷的软件的压力推动了团队去思考重新调整他们的开发组织和管理它的规则。

所以，如果他们想从这个新的软件架构(微服务)上获益，他们的团队必须将微服务映射到团队自身中。也就是说，他们需要更小的更松散耦合的团队，可以选择自己的方向只要能够满足整个需求即可。在每一个团队中，对于开发语言的使用，bug的提交甚至工作职责都会有更大的控制能力。

DevOps团队对此可以启用一个监控平台：让每一个微服务团队可以有自己的警报，度量指标，和控制面板，同时也要给出整体系统的视图。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。