监控系统
人生路漫漫,你也不知道有多少眼睛在盯着你,期待你的表演。
容器一般运行在虚拟机上,也可以运行在物理机上,不同的情况分而治之。
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加入了开机启动的进程之后,那么容器重启的时候,这些进程会自动拉起吗?