容器监控部署 -- 总体架构

上一节梳理了一下prometheus的简介，接下来的将重心放到环境的搭建。搭建好环境以后再配置具体的监控内容。

---

1、总体架构

　　在容器监控的这套系统中，prometheus是一个重要的组件，它能够完成监控指标的收集、存储以及报警，但因为prometheus自身功能不够强大，所以须要结合其余组件来构成一个完成容器监控体系。

　　prometheus有许多许多的第三方插件，这些插件各司其职，有各类数据库的监控插件、硬件监控插件、系统消息插件、存储插件、HTTP相关插件、容器插件、云平台插件等等许多插件。官方文档提供的第三方插件就有一百多个，这些插件的输出格式都按照prometheus的要求输出，因此你本身也能够写插件供prometheus来使用。Export列表

　　本方案中，我选取了两个插件，node_exporter 监控系统指标，cAdvisor可监控容器指标。prometheus的图标展现功能较弱，且告警功能较复杂，所以引入Granfa代替。

　　influxdb是一个时序型数据库，能够存储以上两个插件提供的数据，且存储效果和查询优于prometheus，但因为个人项目属于小项目，所以不会用到。

　　上图是这次项目的架构图，cadvisor从不一样的虚机获取docker容器的指标，node_exporter从虚机获取系统相关的指标，prometheus会定时从以上节点PULL取数据，最后将prometheus数据接入granfa以图标形式展现和报警。

2、各个组件介绍

　　一、prometheus

　　　　已经在前一节中作了简单的介绍，接下来接收一下prometheus的存储

　　　　prometheus有这一个复杂的本地存储系统，它首先会将全部当前使用的块保留在内存中（每一个块的大小是1k），并将最新使用的块保留在内存中。默认prometheus使用1048576字节（1G）

　　　　默认存储时间15天

　　　　每1k是一个块，向这个块中写数据，写满后，再生成新的块，按期将这些块中的数据写入磁盘

　　　　由于采集到的数据会先写入内存，为了防止prometheus运行失败形成数据没法恢复，采用了WAL机制，当prometheus启动时，会从写入日志的WAL中进行重播，从而恢复数据，内存中的块，使用checkpoint file去同步写入数据。data目录的数据结构：

天天的数据默认会写一个块，重启也会重写一个块。这样作能够提升查询效率。

　　

　　二、node_exporter

　　一个linux系统下的采集硬件和操做系统指标的组件，由Go语言编写。

　　在默认状况下，会显示全部收集到的指标，可使用“collect[]”过滤指标，在prometheus的配置下使用词语法。

　　node_exporter会收集许多信息，可是默认状况下，因为内核的安全性设置，它不能收集linux上的perf，若要容许，须要开启linux系统的sysctl配置

　　　sysctl -w kernel.perf_event_paranoid=X

　　其中，

　　　　2    容许用户

　　　　1    容许内核和用户

　　　　0　容许访问特定的CPU，但不容许访问原始跟踪点

　　　　-1   无限制

 

　　三、cAdvisor

　　以上的组件既提供二进制安装方法，也可提供容器安装方法，可是cAdvisor只能经过容器的方式安装，

　　cAdvisor做用是监控容器内的指标，可对容器的资源使用。容器其余特性进行收集、聚合、处理和导出。

　　根据收集到的指标咱们能够调整容器的性能，监控容器运行状态。

 

　　四、grafana　　

　　将prometheus的数据接入grafana，进行图表展现以及报警功能

 

以上组件默认状况下，均不是加密传输，所以须要利用stunnel对上述各个组件进行加密传输。