聊聊监控系统

版权声明:本文为博主原创文章,未经博主同意不得转载。

https://blog.csdn.net/TM6zNf87MDG7Bo/article/details/79466449

 

 

 

1、 为什么须要监控系统

 

    作为运维者,第一个接触的基本上是监控平台,各种各样的监控。看各种各样的指标。好像没有监控就认为不正常。那么为什么须要监控呢?

 

    监控:预防故障,比如当磁盘空间增长到一定的程度的时候,就会产生故障,这个时候监控系统的作用就是当达到一个阀值的时候,发出告警,然后进行处理。

 

    监控:预測变化趋势,比如我的分布式文件系统,每天数据增长1T空间,那么我总共同拥有多少空间。剩余空间大小,是否要进行扩容等操作。

 

    监控:当故障发生的时候,能提供给我基本信息给与我排查的思路。比如redis不可读。能否看到是哪个实例,能看到相关的日志信息,能測试是否刻读写。能查看哪个是master。

 

    监控:监控系统关键指标,比如对于webserver来说,响应速度,来推断是否中间件有问题,是否数据库有问题。还是网络有问题;活跃的用户数,每天我的站点有多少用户訪问;有多少新注冊的用户。

 

2、 怎样选择监控系统

    

    看过好多监控系统,各种各样的公司使用的监控系统各不一样。有的用nagios。有的用zabbix,有的自研。so much more choice。。。

 

 

    选择监控系统的时候。无非是须要几个特性的支持:

    是否支持多主机监控。比如监控一个分布式系统的集群。

    是否支持多维度的数据分析,比如一个主机上有多少个容器。一个主机上容器总共使用了多少内存,每一个容器又使用了多少内存。

    是否支持各种各样的告警方式,设置一个阀值,能够声音告警,能够颜色告警,能够邮件通知,能够短信通知,能够短信通知。能够电话通知

    是否支持告警过滤或者屏蔽。当一个告警是同样的时候。充斥着大量的告警,平台是否支持临时忽略。或者仅仅通知几次,后面在界面上显示告警的内容,開始发生的时间,发生的次数。

    

3、 告警系统的优化

    当一个告警系统每天发出的告警数量超过10条。是不是应该优化?这个主要看运维的人数,假设每一个告警都须要人工进行干涉,那么这个告警数量可能过多,要么优化运维的系统。要么把开发增加运维的团队中进行on call。

 

 

    当一个告警系统每天发出的误报数量在5条以上。怎样优化?假设是正常的动作导致,那就不应该告警,比如在进行公布应用的时候,一个port down,这样的告警就不应该发生,应该做到自己主动屏蔽。

 

    当一个告警系统发出了迷惑性的告警,何为迷惑性,就是监控平台发出了告警。可是却找不到明白的错误信息,那么这样的告警必须进行优化,在告警的时候,应该给出详细的报错信息。总是有人喜欢自己定义告警,然后不给出本来的报错信息。非要进行封装一层。。。。

自作聪明。

。。

从现象直接能看到本质问题,这样的告警平台是最好的。

 

 

4、 容器的监控

    对于一个容器系统,我须要监控哪些指标?

 

    宿主机的负载,内存,CPU,磁盘,网络;

    容器数量。容器的执行状态。容器的使用的内存,进程,cpu,网络,磁盘。

 

    事实上。当你使用了k8s管理平台之后。可能你会发现。这样的监控可能没有太大的含义。。

 

    当使用了这样的重量级的管理平台之后,都是有自愈功能的。。

。就是当一个容器里面执行着java进程,OOM被杀之后。k8s的管理平台会自己再次创建一个容器,自己主动进行dns解析,自己主动进行负载均衡,自己主动进行服务。。。self-healing。

。。金刚狼的能力。

 

    分析OOM,那是媛们的事情。。

。这个时候,运维在干啥,无须进行人工干涉。传统运维都是出现OOM,手动重新启动下java进程,如今。。。。运维平台自己干活了。

 

    期望状态?你期望服务是什么状态,它会自己主动进行调度到终于的状态。。

你要几个副本进行负载均衡,就给你几个。

 

    你要进行升级,自己主动rolling进行更行,先创建一个高版本号的镜像。然后删除一个实例容器,负载均衡增加轮询。。。怕公布的时候中断服务?那是不可能的,7*24。

。so easy。。。

 

 

    要进行扩容。都不须要手动进行处理。能够依据流量自己进行推断,流量太高了,就自己主动进行创建容器。进行负载均衡。。

。流量减少了,自己主动销毁容器。进行负载均衡。。。

    

    对于这样的能自我管理的应用或者服务,还须要监控么。

。。

 

    充其量。

。。

仅仅要做好响应的规划就好了。给你多少内存。给你多少CPU。给你多少磁盘,偶尔看看增长趋势。。。。so。。。

 

 

    可是。。。在出现问题的时候,还是须要告警平台。。。

 

    适用的场景不同。从而选择不同。当你须要一个能使用shell直接连接的时候。监控工具weavescope。非常是美丽。。

 

640?</p><p>wx_fmt=png

 

    当你须要进行多纬数据分析的时候,而且设定阀值,自己主动进行告警的时候,那么prometheus还是非常酷的。

640?wx_fmt=png

 

5、 IAAS的监控

    

    在非常多的时候。构建一个IAAS平台。一种自我測试的监控系统,那是相当酷的。。。我喜欢

 

    何为自我測试呢

        比如构建了分布式的文件系统。相隔几分钟,自己上传一个文件,訪问文件,删除文件,假设这个測试能通过。那么表示基础设施全然正常。

 

        比如构建一个DAAS。数据库即服务。那么相隔几分钟,自己创建一个mysql的master和slave。然后写入数据,HA切换。然后删除。假设这个測试能通过。那么表示基础服务全然正常。

 

    这样的思想还是极好的。

 

    监控平台怎样构建?不想大段的论述了,据我所知,python。

posted @ 2018-11-05 13:29  ldxsuanfa  阅读(178)  评论(0编辑  收藏  举报