我七岁就开始编程(在纸上，没有电脑，但那是另一回事)。早期我学到的一件事就是软件开发就像生活一样充满了权衡：组织和开发人员过去常常不得不在性能或简单性，创新性或可管理性之间进行选择。但是，随着作为容器/ Docker趋势的一部分的微服务的出现，应用程序开发已转变为一系列小型的服务，每个服务都运行在自己的进程中，并与API等机制进行通信。微服务的优势非常明显：软件开发和部署的速度有了巨大的提升，从而节省了资金，并且在合适的情况下为组织带来了竞争优势。
在过去的几年中，我和很多开发人员进行了交流，并且了解了他们所面临的难题。这些对话清楚地告诉我，当开发人员接受了微服务，组织要彻底反思作为良好性能和安全卫生的一部分的软件管理实践。微服务的使用意味着软件管理方法的变革，特别是组织如何处理基础设施，应用程序和数据的监控。如果企业不思变革，它们在理解微服务性能时会困难重重，更不用说故障排除的问题了。下面来看看可以使你对微服务的监控更加智能，响应更快(更高的效率也不在话下)的五种方法。
1.监视容器和运行于其中的内容
容器作为微服务的基本构成材料，它是跨越开发人员笔记本电脑乃至云端的黑盒子。但是，如果没有对容器的真实可见度，要执行监视或服务故障排除等基本功能就很困难。你需要知道容器中运行的是什么，应用程序和代码的运行情况以及它们是否在生成重要的自定义指标。
随着贵组织规模的扩大，它可能要在数千台主机中运行数以万计的容器，部署可能会变得很昂贵，并成为编排上的棘手事情。要获得容器的监控权限，你有几个选择：要求开发人员直接测试代码，运行挎斗容器(sidecar container)，或利用通用内核级别的检测工具来查看所有的应用程序和容器的活动。每种方法都有各自的优缺点，因此你需要考察哪一种方法能实现你最重要的目标。重要的是，对虚拟机中的静态工作负载有效的老方法将不再能胜任工作了。
2.使用编排系统
你可以执行的最关键流程之一是跟踪与某个功能或服务关联的所有容器的聚合信息，比如每个服务的响应时间。举例来说，这种即时聚合还适用于基础设施级监控，以了解哪些服务的容器正在使用超出其CPU配额的资源。
如果你是开发团队的一员，那么你可以使用Kubernetes、Mesosphere DC/OS或Docker Swarm这样的编排系统来定义你的微服务并了解每个已部署服务的当前状态。如果你是开发运维团队的成员，那么你应该重新定义系统警报，要尽可能贴近监控服务的体验，因为警报是评估应用程序运行状况的第一道防线。如果监视系统是原生于容器的(container-native)，这样的监视系统使用编排元数据，动态地将容器和应用程序数据聚合起来，并且根据每个服务计算监视指标，那么这个过程会变得更容易。
根据编排工具的不同，可能会有不同的层次结构需要深入;Kubernetes提供Namespace、ReplicaSets、Pods和一些容器。无论服务的容器在物理上是如何部署的，在这些层进行聚合对于逻辑故障排除都至关重要。
3.为弹性的多地点服务做好准备
原生于容器的环境会发生迅速的变化，而这种活力暴露了所有监控系统的弱点。手动定义和调整衡量标准的做法可能适用于20或30个容器，但微服务监控必须能够与弹性服务一起扩展和收缩——而且无需人工干预。因此，如果你必须手动定义容器包含在监控中的服务，那么你很可能会错过Kubernetes或Mesos在白天启动的新容器。同样，如果贵组织在构建和部署新代码时安装了自定义的统计信息端点(custom stats endpoint)，则开发人员会从Docker注册表中提取基本的镜像(base image)，因此监视过程会变得非常复杂。
如果贵组织正在使用微服务，那么你还需要跨越多个数据中心或多个云的监控。例如，只有当你的微服务限用于AWS时，AWS CloudWatch才有用。。
4.监视API
作为微服务环境的通用语言，API是其他团队能体验到的唯一服务元素。如果尚未定义正式的服务水平协议，则API的响应和一致性甚至可能成为内部的服务水平协议。这意味着API监控必须超越标准的，非此即彼的启用/停用检查(binary up-down check)。
作为微服务的用户，你会发现了解作为时间函数的最常用的端点是很有价值的，它可以让你了解服务的使用情况发生了什么变化(不管是因为设计还是用户更改)。发现最慢的服务端点还可以向你表明哪些地方需要优化。通过系统跟踪服务调用的能力(通常仅由开发人员使用的功能)将有助于贵组织理解整体的用户体验。API监控的这一方面也将把信息分解成微服务环境的基于基础架构和应用程序的视图。
5.将监视映射到组织结构
虽然微服务预示着你和你的组织监控和保护软件基础架构的方式发生了全面转变，但你不忽视软件监控的人为方面，这是很重要的。如果贵组织希望从这种新的软件体系结构方法中受益，那么你的团队必须自行创建微服务的镜像。这意味着团队会更小，更松散，拥有大量的自主权，但把重点放在战略目标上。每个团队对所使用的语言，错误解决(bug resolution)或操作责任方面比以往任何时候都保留了更多的控制权。然后，你可以创建一个监控平台，这个平台允许每个微服务团队隔离警报、指标和仪表板，同时仍然在整个系统中为操作提供综览。
软件监控的一些基本改变有助于促进微服务的速度，效率和潜在节约。改进了的微服务监控使性能更强大，最终用户满意度更高。微服务得到适当调校后将在更短的时间内提供更多的功能，这是服务交付的良性循环。
版权声明：本文为企业网D1Net编译，转载需注明出处为：企业网D1Net，如果不注明出处，企业网D1Net将保留追究其法律责任的权利。
京公网安备 11010502049343号