一、微服务、容器化技术进展监测之痛
1 .首要挑战：监测对象的动态化
通过集装箱化的部署，监视对象变为了动态。 随着名为K8s的服务组织框架的大规模落地，APP应用部署单元从原始主机变成了一个Pod。 每次发布时，Pod都会放弃重建，IP也会发生变化。 在微服务体系下，我们注重快速迭代、持续集成，从而使得发布越来越频繁，Pod的生命周期非常短。 据统计，每个Pod的生命周期只有两三天，然后被销毁和重建。 随着DevOps的普及，负责发布APP的角色发生了变化，APP发布变得更弱、更敏捷，一个APP不断滚动发布，实现快速迭代的目标。
也就是说，随着软件生产流程的变化和相关技术的成熟，我们的监控对象处于不断变化的状态。
2 .第二个挑战：监测水平/对象多样化
首先，与Kubernetes相关的kube组件和容器层是我们必须监视的新对象。 其次，微服务划分后，由于行业在中间件、DB等领域的日益细化，可以看出依赖的PaaS层组件越来越多样化，也需要监测高度依赖这些APP应用的PaaS组件。 最后是多语言。 微服务划分后，各团队可以选择自己擅长的语言进行APP应用开发。 因此，这些APP应用程序的监视指标会出现一个问题，即为了生产和曝光，需要支持各种语言的客户端库。
3 .第三个挑战：监测内容复杂化
监控内容的复杂化源于以下几个方面，第一个是复杂的APP应用依赖。 二是在高度分散的环境中，为了描绘系统整体的状态，需要非常复杂和粒状性的指标。
在上图中，可以更直观地感受到上述课题是如何产生的。 左边是传统单体APP应用程序的部署体系结构，右边是微服务部署的体系结构。 虽然只需要监视一个APP应用程序对象，但现在已经有几十几百个动态发布，IP地址在不断变化。 传统的监视工具可能会以静态配置的方式发现这些监视目标。 但是，在微服务的场合，这种方式已经不能实施了。 单体APP可能只需要依靠MySQL即可。 但是，现在依赖的组件在增加。 传统的监控工具不能完全支持这种大规模的监控需求，传统的监控工具缺乏容器级的监控能力。为了解决上述问题，我们发现Prometheus可能是一个理想的解决方案。
二、云本机时代，为什么是Prometheus
动态化： Prometheus具有先发优势。 Kubernetes诞生之初，标准的监视工具是Prometheus，自然符合Kubernetes的体系结构和技术特征，能够自动发现监视目标。 在大规模、监测目标不断变化的监测场景下，根据实践经验，主动提取采集是一种较好的实现方式，可以避免监测目标指标漏采，监测目标需要解决保持采集点配置和实现推送模式成本大等一系列问题。 然后，动态容器指标由Kubernetes的Kubelet/VK组件收集，它们天然地以Prometheus格式生产和暴露指标数据。
多样化：由于Kubernetes有许多控制平面组件(如API server )，并自然以Prometheus数据格式暴露监控指标，因此Prometheus可以非常标准、轻松地收集这些组件的监控指标其次，Prometheus是开放社区，可以使用100个公式或非正式导出器。 例如，如果要监视数据库、消息队列、分布式存储、注册中心和网关，则打开各种导出器后，立即将原始组件的非Prometheus标准数据格式转换为Prometheus数据格式此外，Prometheus还支持go、Python和Java等20多种语言，使您可以非常轻松地生成和监视APP应用程序的度量。 最后，Prometheus具有很强的可扩展性，如果不能满足APP应用程序的需要，也有一个强大的工具，让商务人员可以轻松地编写自己的导出器。
复杂化： Prometheus定义了多维模型。 多维模型可以很容易地理解为我可以标记任何事情，用标签描述对象的系统状态。 虽然多维模型听起来比较简单，但许多监测工具起初无法以这种方式描述监测目标。 通过多维模型，可以容易地描绘出整个监视目标的复杂状态，还可以描绘出APP应用程序之间的依存关系。
其次，Prometheus提供了一种称为PromQL的查询语言，它非常强大，可以过滤、聚合和计算复杂的指标。 内置20-30种计算函数和运算符，其中包括常规累积值、差值、平均值、最大最小值、P99、TopK等，可以根据这些计算能力直接创建指标视图和放置警告。 由此，可以省去本来需要的代码开发工作，可以非常简单地得到期望的业务结果。在上图中，我们来看看实际的PromQL语句。 http _ request _ duration _ seconds _ bucket是Histogram型指标，有多个bucket。 使用上面的PromQL语句，可以计算出RT超过500ms，而无需编写代码
文/蓝盟IT外包
中文
电话咨询
微信咨询
公众号
