zoukankan      html  css  js  c++  java
  • 聊聊监控系统

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

    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。

  • 相关阅读:
    5、include为应用指定多个struts配置文件
    4、struts处理流程和action的管理方式
    8、类型转换器
    7、请求参数接收
    UESTC 2014 Summer Training #6 Div.2
    Codeforces Round #FF
    css ul li去除圆点
    css a标签去除下划线
    Axure的热区元件的作用
    结组开发项目(TD学生助手)
  • 原文地址:https://www.cnblogs.com/ldxsuanfa/p/9908656.html
Copyright © 2011-2022 走看看