RHEL7
带有微服务程序的RHEL7一台
1、监控容器及其里面的东西容器因构建微服务而凸显其重要性，容器的速度、可移植性和隔离特性让开发者很容易就爱上了微服务模型。容器的好处已经写的够多了，毋庸赘述。容器对于其外围的系统来说就像是黑盒子。这对于开发来说大有裨益，从开发环境到生产环境，甚至从开发者的笔记本到云端，为它们带来高度的可移植性。但是当运行起来后，监控和解决服务问题时，这个黑盒子让常规的方法难以奏效了，我们会想：容器里到底在运行着什么?程序和代码运行性能如何?它有什么重要的输出指标吗?从 DevOps 的视角，你需要对容器有更深的了解而不是仅仅知道有一些容器的存在。非容器环境下衡量的典型做法，是让一个代理程序运行在主机或者虚机上的用户空间里，但这并不适用于容器。因为容器的优点是小，将各种进程分离开来，并尽可能的减少依赖关系。而且，从规模上看，成千上万的监测代理，对即使是一个中等大小的部署都是一个昂贵的资源浪费和管理的噩梦。对于容器有两个潜在的解决方案：1)要求你的开发人员直接监控他们的代码，或者2)利用一个通用的内核级的检测方法来查看主机上的所有应用程序和容器活动。这里我们不会深入说明，但每一种方法都有其优点和缺点。
2、 利用业务流程系统提醒服务性能理解容器容器中的运行数据并不容易，一个单一容器相比组成一个功能或服务的容器聚合，测量复杂度要低得多。这特别适用于应用程序级别的信息，比如哪个请求拥有最短响应时间，或者哪些 URL 遇到最多的错误，但它同样也适用于架构级别的监测，比如哪个服务的容器使用 CPU 资源超过了事先分配的资源数。越来越多的软件部署需要一个编排系统orchestration system，将应用程序的逻辑规划转化到物理的容器中。常见的编排系统包括 Kubernetes、Mesosphere DC/OS 和 Docker Swarm。团队可以用一个编排系统来(1)定义微服务(2)理解部署的每个服务的当前状态。你可以认为编排系统甚至比容器还重要。容器是短暂的，只有满足你的服务需求才会存在。DevOps 团队应该将告警重点放到运行特征上，以尽可能贴近监控服务的体验。如果应用受到了影响，这些告警是评估事态的第一道防线。但是获得这些告警并不容易，除非你的监控系统是基于原生于容器的。原生容器Container-native解决方案利用编排元数据orchestration metadata来动态聚合容器和应用程序数据，并按每个服务计算监控度量。根据您的编排工具，您可能想在不同层次进行深入检测。比如，在 Kubernetes 里，你通常有 Namespace、ReplicaSet、Pod 和一些其他容器。聚合这些不同的层，对排除逻辑故障是很有必要的，与构成服务的容器的物理部署无关。
3、 监控弹性Elastic和多地部署Multi-Location的服务弹性服务不是一个新概念，但是它在原生容器环境中的变化速度比在虚拟环境中快的多。迅速的变化会严重影响检测系统的正常运行。监测传统的系统经常需要根据软件部署，本文所有涉及到的原理都可以在《linux就该这么学》里找到相关的解释。手动调整检查指标。这种调整可以是具体的，如定义要捕获的单个指标，或基于应用程序在一个特定的容器中的操作配置要收集的数据。在小规模上(比如几十个容器)我们可以接受，但是再大规模就难以承受了。微服务的集中监控必须能够自由的随弹性服务而增长和缩减，无需人工干预。比如，如果 DevOps 团队必须手动定义容器包含哪个服务需要监控，他们毫无疑问会失手，因为 Kubernetes 或者 Mesos 每天都会定期创建新的容器。同样，如果代码发布并置于生产环境时要求运维团队安装一个定制的状态端点custom stats endpoint，也给开发者从 Docker 仓库获取基础镜像带来更多的挑战。在生产环境中，建立面向跨越多个数据中心或多个云的复杂部署的监控，比如，如果你的服务跨越私有数据中心和 AWS，那么亚马逊的 AWS CloudWatch 就很难做到这一点。这就要求我们建立一个跨不同地域的监控系统，并可在动态的原生容器环境下运行
5、 将您的监控映射到您的组织结构这篇文章着重在微服务和监控上，像其他科技文章一样，这是因为很多人都关注此层面。对于那些熟悉康威定律Conway’s law的人来说，系统的设计是基于开发团队的组织结构。创造更快，更敏捷的软件的压力推动了团队去思考重新调整他们的开发组织和管理它的规则。所以，如果他们想从这个新的软件架构(微服务)上获益，他们的团队必须将微服务映射到团队自身中。也就是说，他们需要更小的更松散耦合的团队，可以选择自己的方向只要能够满足整个需求即可。在每一个团队中，对于开发语言的使用，bug 的提交甚至工作职责都会有更大的控制能力。