容器监控部署 -- 整体架构
上一节梳理了一下prometheus的简介，接下来的将重心放到环境的搭建。搭建好环境之后再配置具体的监控内容。
一、整体架构
在容器监控的这套系统中，prometheus是一个重要的组件，它可以完成监控指标的收集、存储以及报警，但由于prometheus自身功能不够强大，因此需要结合其他组件来构成一个完成容器监控体系。
prometheus有许多许多的第三方插件，这些插件各司其职，有各种数据库的监控插件、硬件监控插件、系统消息插件、存储插件、HTTP相关插件、容器插件、云平台插件等等许多插件。官方文档提供的第三方插件就有一百多个，这些插件的输出格式都按照prometheus的要求输出，所以你自己也可以写插件供prometheus来使用。Export列表
本方案中，我选取了两个插件，node_exporter 监控系统指标，cAdvisor可监控容器指标。prometheus的图标展示功能较弱，且告警功能较复杂，因此引入Granfa代替。
influxdb是一个时序型数据库，可以存储以上两个插件提供的数据，且存储效果和查询优于prometheus，但由于我的项目属于小项目，因此不会用到。
上图是此次项目的架构图，cadvisor从不同的虚机获取docker容器的指标，node_exporter从虚机获取系统相关的指标，prometheus会定时从以上节点PULL取数据，最后将prometheus数据接入granfa以图标形式展示和报警。
二、各个组件介绍
1、prometheus
已经在前一节中做了简单的介绍，接下来接收一下prometheus的存储
prometheus有这一个复杂的本地存储系统，它首先会将所有当前使用的块保留在内存中（每个块的大小是1k），并将最新使用的块保留在内存中。默认prometheus使用1048576字节（1G）
默认存储时间15天
每1k是一个块，向这个块中写数据，写满后，再生成新的块，定期将这些块中的数据写入磁盘
因为采集到的数据会先写入内存，为了防止prometheus运行失败造成数据无法恢复，采用了WAL机制，当prometheus启动时，会从写入日志的WAL中进行重播，从而恢复数据，内存中的块，使用checkpoint file去同步写入数据。data目录的数据结构：
每天的数据默认会写一个块，重启也会重写一个块。这样做可以提高查询效率。
2、node_exporter
一个linux系统下的采集硬件和操作系统指标的组件，由Go语言编写。
在默认情况下，会显示所有收集到的指标，可以使用“collect[]”过滤指标，在prometheus的配置下使用词语法。
node_exporter会收集许多信息，但是默认情况下，由于内核的安全性设置，它不能收集linux上的perf，若要允许，需要开启linux系统的sysctl配置
sysctl -w kernel.perf_event_paranoid=X
其中，
2 允许用户
1 允许内核和用户
0 允许访问特定的CPU，但不允许访问原始跟踪点
-1 无限制
3、cAdvisor
以上的组件既提供二进制安装方法，也可提供容器安装方法，但是cAdvisor只能通过容器的方式安装，
cAdvisor作用是监控容器内的指标，可对容器的资源使用。容器其他特性进行收集、聚合、处理和导出。
根据收集到的指标我们可以调整容器的性能，监控容器运行状态。
4、grafana
将prometheus的数据接入grafana，进行图表展示以及报警功能
以上组件默认情况下，均不是加密传输，因此需要利用stunnel对上述各个组件进行加密传输。
