漫谈容器监控系统

序言

    无风不起浪，这个世界监控无处不在，等到了5g时代，哼。。。就更加猖狂了。

    当出了故障的时候，你才知道哪些人和你是同一根绳上的蚂蚱。

监控系统

    人生路漫漫，你也不知道有多少眼睛在盯着你，期待你的表演。

    容器一般运行在虚拟机上，也可以运行在物理机上，不同的情况分而治之。

    1 运行在物理机上

        当容器运行在物理机上的时候，一般的监控的agent是直接运行在物理机上，在进行容器的健康检查的时候，依赖于docker客户端程序。

    从而一般会执行很多的docker exec id bash checkhealthy，然后根据返回值来判断容器是正常还是不正常。

    不同的容器有不同的健康检查脚本，从而这都是黑盒监控，发生了什么，我在哪里？因为你只能看到一个返回值是255或者127等，你必须登陆到容器里面，看下健康检查脚本，然后看看是不是服务oom了，看看是不是nginx挂了。

    容器里面一般运行几个进程，一个是nginx，一个是java进程，所以呢，很多时候是java挂了，从而导致健康检查不通过。

    容器的docker exec只能进行检查服务是否正常，也就是用户侧能看到的一些内容，那么对于白盒检查呢，各种内部的性能数据，这个就要靠agent来进行收集了，例如cpu，内存，网络等性能数据，这些都是通过容器里面的一个监听服务，然后监控系统的服务端来拉取相关的性能指标。

    当一个物理机上面运行一百个容器的时候，如果服务不稳定，咋整？在容器的镜像里面直接打入supervisord服务，这样其他的服务挂了就能自动拉起了，当然，这种导致的结果就是，可能会直接不告警了，当有服务挂了的时候，直接拉起，然后有的时候查问题，就得一个一个找了。

    2 运行在虚拟机中

    当容器运行在虚拟机中的时候，一般的设计是一个容器占用一个虚拟机，为啥不用多个呢？是因为在申请虚拟机资源的时候，可能设定的就是容器使用的内存和cpu和存储，从而并不会运行多个。

    当容器运行在虚拟机的时候，监控怎么来做，是在虚拟机上运行监控，还是在容器里面运行监控？

    一般都是在容器里面运行监控，是因为虚拟机的文件和容器的文件系统挂载的目录不同，从而导致在虚拟机中很难找到日志路径进行监控。

    当把监控的agent直接打入到容器的镜像的时候，依旧是通过定时任务来进行收集相关的性能指标，而对于一些基础的监控，那就可以直接监听服务的端口了。

    当使用容器监控的时候，由于需要监听虚拟机端口，从而容器里面和虚拟机里面同时只能运行一个监控程序。

    在使用监控agent的时候，一般是使用单独的用户，例如monitor，单独的定时任务，例如crontab -l -u monitor，使用固定的端口进行监听，从而监控的服务端可以定时来拉取监控数据。

    3 k8s的daemonset

    emmm，为啥要提daemonset，因为这个可以设置node-exporter,也就是从每个node节点上收集到相关的metric数据。

    daemonset的特点是在每个节点上最多运行一个pod，就像前面说到的一样，一个容器中最多一个agent，多了就容易打架。

    而且使用daemonset的好处还有当有新的node上线之后，会自动调度到这个node上运行这个pod，再也不用担心扩容和所容的安装各种agent了。

    当在容器里面看进程的时候，你会发现进程显示的不是uid，而是用户名，而在虚拟机里看进程的时候，显示的是uid，而不是用户名。

    那么问题来了：当容器里面使用了chkconfig加入了开机启动的进程之后，那么容器重启的时候，这些进程会自动拉起吗？

    你关注什么，什么就会出现问题。。。这是什么规则呢？

    提出正确的问题，你能去思考，而其他的问题，则毫无意义。。。

    现在我的胡说八道都没多少人看的懂了。。。心好累，如果我写了这么多，你啥都看不懂，那我写了干啥，还不如听风吹。。。每一句牛逼都有它独一无二的价值，需要的只不过是一双慧眼。。。redis里面的watch看过吗？那就是慧眼。。。每个细节都逃不过。。。