精华内容
参与话题
问答
  • QT实战之监控系统

    千人学习 2018-08-10 03:32:02
    支持添加摄像头播放监控画面,支持1、4、9、16分屏显示,通过封装播放器,可以支持多协议,本地视频多种播放方式,随意封装播放器功能,并且可在此基础上对本次监控系统进行二次开发,友好的界面操作,支持系统拖盘...
  • Nagios监控系统

    千次阅读 2018-11-01 21:47:52
    Nagios监控系统 前言:Nagios是一款开源的免费网络监视工具,可以监控Windows、Linux和Unix的主机状态,交换机路由器等网络设备,在系统或服务状态异常时发出邮件或短信报警,第一时间通知网站运维人员。流量监控...

    Nagios监控系统

    • 前言:Nagios是一款开源的免费网络监视工具,可以监控Windows、Linux和Unix的主机状态,交换机路由器等网络设备,在系统或服务状态异常时发出邮件或短信报警,第一时间通知网站运维人员。流量监控不是他的强项,流量监控建议使用cacti(可以绘制非常直观的图形。

    总结一下nagios主要可以监控以下方面:

    • l 主机是否宕机(通过ping命令,如果ping不通会认为主机属于宕机状态,但不影响所监控的其他服务)
    • l 服务器资源(cpu使用率、硬盘剩余空间等)
    • l 网络服务(smtp\pop3\http\)
    • l 监控网络设备(路由器、交换机等)

    一、需要了解的知识点
    1、nagios工作原理

    • Nagios本身不包括监控主机和服务的功能。所有的监控、监测功能都是通过各种插件来完成的。安装完nagios之后,在nagios主目录下的/libexec里面放有nagios自带的插件,如:check_disk是检查磁盘空间的插件,check_load是检查cpu负载的插件,每一个插件可以通过运行./check_xxx -h命令来检查其使用方法和功能。

    2、nagios的四种监控状态

    • Nagios可以识别四种状态返回信息。0(OK)表示状态正常(绿色显示),1(WARNING)表示出现警告(黄色),2(CRITICAL)表示出现非常严重错误(红色),3(UNKNOWN)表示未知错误(深黄色),nagios根据插件返回来的值来判断监控对象的状态,并通过web显示出来,以供管理员即时发现故障。

    3、nagios通过nrpe插件来远程管理服务的工作过程

    1.     Nagios执行安装在它里面的check_nrpe插件,并告诉check_nrpe去检测哪些服务。
      
    2.     通过ssl,check_nrpe连接远端机器上的NRPE daemon。
      
    3.     NRPE运行本地的各种插件去检测本地服务器和状态(check_disk,...etc)。
      
    4.     NRPE把检测的结果传给主机端的check_nrpe,check_nrpe再把结果送到nagios状态队列中。
      
    5.     Nagios依次读取队列中的信息,再把结果显示出来。
      

    Nagios通过NRPE监控远程主机系统状况(如msyql主机)

    在这里插入图片描述

    NRPE总共由两部分组成:

    check_nrpe插件:运行在监控主机上 (即nagios主机)
    NRPE daemon:运行在远程的linux主机上(通常就是被监控机)

    整个的监控过程:

    当Nagios需要监控某个远程linux主机的服务或者资源情况时:

    1. nagios运行check_nrpe插件,我们要在nagios配置文件中告诉它要检查什么.
    2. check_nrpe插件会通过SSL连接到远程的NRPE daemon.check_nrpe插件会通过SSL连接到远程的NRPE daemon.
    3. NRPE daemon会运行相应的nagios插件来执行检查本地资源或服务.NRPE daemon会运行相应的nagios插件来执行检查本地资源或服务.
    4. NRPE daemon将检查的结果返回给check_nrpe插件,插件将其递交给nagios做处理.NRPE daemon将检查的结果返回给check_nrpe插件,插件将其递交给nagios做处理.

    注意:NRPE daemon需要nagios插件和Nrpe一起安装在远程被监控linux主机上,否则,daemon不能做任何的监控. 别外因为它们间的通信是加密的SSL,所以需要安装SSL

    这个插件需要openssl的支持,没有就直接安装一下(yum install openssl-devel)
    1、远程主机设定(即被监控主机设定)这里仍然对mysql服务器进行监控,在mysql主机上进行如下操作:

    二、实验环境
    1、实验拓扑
    在这里插入图片描述
    2、虚拟机上的实验环境
    在这里插入图片描述
    三、实验步骤
    1、搭建nagios监控系统
    1)关闭防火墙
    在这里插入图片描述
    2)创建nagios用户和用户组
    在这里插入图片描述
    3)编译安装nagios(需要提前配置yum)
    安装支持包:
    在这里插入图片描述
    配置:
    在这里插入图片描述
    编译和安装:
    在这里插入图片描述
    注意:安装install-webconf是为了生成配置文件,后面在/etc/httpd/conf/httpd.conf最后添加的信息就不用手工打了,可以到/etc/httpd/conf.d/nagios.conf文件中复制。

    以上命令的解释:

    make install      //安装主程序,CGI和HTML文件
    make install-init  //在/etc/rc.d/init.d安装启动脚本
    make install-commandmode  //配置目录权限
    make install-config  //安装示例配置文件
    make install-webconf  //安装nagios的web接口,会在/etc/httpd/conf.d目录中创建nagios.conf文件。
    

    安装完成之后会在/usr/local/nagios目录下产生6个目录,下面分别解释一下。

    bin:nagios执行程序所在的目录,nagios文件即为主程序。
    etc:nagios配置文件目录,当make install-config完以后etc下面就会出现默认的配置文件。
    sbin:nagios CGI文件所在目录,这里存放的是一些外部命令执行程序。
    share:nagios网页文件目录,存放一些html文件。
    var:nagios日志文件、pid等文件目录。
    Libexec:系统默认插件的存储位置
    

    4)添加为系统服务器
    在这里插入图片描述
    5)安装nagios插件(监控功能通过插件完成)
    在这里插入图片描述
    编译并安装:
    在这里插入图片描述
    6)安装nrpe(为了监控远程服务器)
    在这里插入图片描述
    7)在/etc/httpd/conf/httpd.conf文件最后添加授权,我们可以到/etc/httpd/conf.d/nagios.conf文件中复制,不用手打。
    在这里插入图片描述
    使用:r导入即可(定位到文档的最后)
    在这里插入图片描述
    在这里插入图片描述
    导入即可,不用修改,保存退出。

    8)执行htpasswd命令添加一个访问nagios页面的授权用户
    在这里插入图片描述
    用户名和密码都是nagiosadmin

    9)启动nagios和httpd
    在这里插入图片描述
    10)在浏览器上访问nagios页面
    在这里插入图片描述
    在这里插入图片描述
    目前只能是打开网页,很多的监控选项不能看到,如果需要监控远程的服务器,还需要做很多配置,下面开始配置。

    2、配置nagios监控系统涉及知识点

    1)nagios的配置文件:
       Nagios.cfg:主配置文件,定义各种配置文件的名称和位置
       Cgi.cfg:控制CGI的配置文件
       Resource.cfg:资源文件,定义各种变量,以便于其他文件调用
       Objects:其他配置文件存放目录,此目录下主要有:
                 Command.cfg:命令配置文件,定义各种命令格式,以备其他文件调用
                 contacts.cfg:联系人和组,发邮件等告警信息时可以调用
                 localhost.cfg:监控本机的配置文件
                 timeperiods.cfg:定义监控时间的配置文件,便于其他文件调用
                 Hostgroups.cfg:定义监控的主机(组),需手动创建。
    

    2)配置文件之间的关系
    在nagios的配置过程中涉及的几个定义有主机、主机组、服务、服务组、联系人、联系人组、监控时间和监控命令等。从这些定义可以看出,nagios各个配置文件之间互为关联、彼此引用的。成功配置出一台nagios监控系统,必须要弄清楚每个配置文件之间依赖与被依赖的关系,最重要的有四点

    n  定义监控那些主机,主机组,服务和服务组
    n  定义这个监控要用什么命令实现
    n  定义监控的时间段
    n  定义主机或服务器出现问题时要通知的联系人和联系人组
    

    3)配置nagios
    为了能更清楚的说明问题,同时也为了维护方便,建议将nagios各个定义的对象创建独立的配置文件。

    n  创建conf目录来定义host主机
    n  创建hostgroups.cfg文件来定义主机组
    n  用默认的contacts.cfg文件来定义联系人和联系人组
    n  用默认的commands.cfg文件来定义命令
    n  用默认的timeperiods.cfg来定义监控时间段
    n  用默认的templetes.cfg文件作为资源引用文件
    

    3、配置nagios
    1)修改/usr/local/nagios/etc/nagios.cgf主配置文件
    在这里插入图片描述
    在这里插入图片描述
    2)修改/usr/local/nagios/etc/objects/commands.cfg
    在这里插入图片描述
    添加如下内容(定义check_nrpe监控命令)
    在这里插入图片描述
    3)修改/usr/local/nagios/etc/objects/contacts.cfg(定义监控服务器联系人)
    在这里插入图片描述
    在这里插入图片描述
    4)新建/usr/local/nagios/etc/objects/hostgroups.cfg(定义主机组)
    在这里插入图片描述
    5)在/usr/local/nagios/etc/conf下面新建192.168.1.20.cfg文件(用于监控192.168.1.20的主机存活,负载,进程)(所有内容需要手工输入)
    在这里插入图片描述
    在这里插入图片描述
    未完接下图:

    在这里插入图片描述
    命令解释:

    define host{ 
           use         linux-server  //定义使用的模板
           host_name   nagios  //被监控主机的名称,最好别带空格 
           alias         nagios  //别名       
           address      127.0.0.1  //被监控主机的IP地址       
           check_command    check-host-alive 
        normal_check_interval   3    //正常检测间隔时间
                     retry_check_interval    2     //重试检测间隔时间
           //监控的命令check-host-alive,这个命令来自commands.cfg,用来监控主机是否存活 
           max_check_attempts    5 //检查失败后重试的次数 
           check_period        24x7   //检查的时间段24x7,同样来自timeperiods.cfg中定义
    notification_interval  10  //提醒的间隔,每隔10秒提醒一次
    notification_period   24x7  //提醒的周期, 24x7,同样来自timeperiods.cfg中定义
    contact_groups   admins  //联系人组,上面在contactgroups.cfg中定义的admins
    notification_options            d,u,r  //指定什么情况下提醒
            } 
    当服务出现w-报警(warning),u-未知(unkown),c-严重(critical),或者r-从异常情况恢复正常,在这四种情况下通知联系人
    当主机出现d-当机(down),u-返回不可达(unreachable),r-从异常情况恢复正常,在这3种情况下通知联系人
    

    6)重启nagios服务
    在这里插入图片描述
    7)发现错误,提示没有添加联系人组,解决方法:在
    /usr/local/nagios/etc/objects/contacts.cfg文件的最后添加代码,如下图:
    在这里插入图片描述
    8)重启nagios服务器成功
    在这里插入图片描述
    9)访问网页查看状态
    (注意:关闭selinux或者开例外)
    在这里插入图片描述

    或者:
    如果你开启了selinux 需要配置如下二步:

    chcon -R -t httpd_sys_content_t /usr/local/nagios/sbin/
    chcon -R -t httpd_sys_content_t /usr/local/nagios/share/
    

    在这里插入图片描述
    点击上图中的localhost,可以查看本机的状态
    在这里插入图片描述
    4、配置被控端192.168.1.20(mysql和web)
    1)安装nagios插件

    yum  -y install  openssl  openssl-devel
    useradd  nagios  -s  /sbin/nologin
    tar   zxf  nagios-plugins-1.5.tar.gz
    cd   nagios-plugins-1.5
             ./configure  --prefix=/usr/local/nagios
        make  &&  make  install
    chown  -R   nagios:nagios  /usr/local/nagios
    tar  zxf  nrpe-2.15.tar.gz
    cd   nrpe-2.15
             ./configure  --prefix=/usr/local/nagios
      make all  &&  make install-plugin   &&  make install-daemon
      make   install-daemon-config
    

    2)安装完成之后,需要打开vim /usr/local/nagios/etc/nrpe.cfg
    添加nagios服务器的地址
    在这里插入图片描述
    3)启动nrpe
    在这里插入图片描述
    4)在nagios服务器上测试nrpe运行是否正常,出现下面的信息说明正确。
    在这里插入图片描述
    5)在浏览器上访问
    在这里插入图片描述
    在这里插入图片描述
    5、补充
    也可在services.cfg文件中添加192.168.1.20.cgf文件中的参数
    #vi /usr/local/nagios/etc/objects/services.cfg
    内容如下:
    在这里插入图片描述
    在这里插入图片描述

     - check_local_users!20!50  //监测远程主机当前的登录用户数量,如果大于20用户则报warning,如果大于50则报critical
     - check_local_disk!20%!10%!/   //如果可用空间低于20%会报Warning,如果可用空间低于10%则报Critical:
     - check_local_procs!250!400!RSZDT   //监测远程主机当前的进程总数,如果大于250进程则报warning,如果大于400进程则报critical,S(休眠)、R(运行)、Z(僵死)、D (不可中断)、T (停止)
     - check_load -w 5,4,3 -c 10,6,4这个命令的意义如下
     - 当1分钟多于5个进程等待,5分钟多于4个,15分钟多于3个则为warning状态
     - 当1分钟多于10个进程等待,5分钟多于6个,15分钟多于4个则为critical状态
     - 服务组并不是必须的,这是配合nagios的监控页面的显示
    
    展开全文
  • CAT分布式监控系统(一):CAT监控系统功能介绍 本文概要: 1、CAT监控系统是什么。 2、CAT监控系统能做什么,能监控些什么。 下面有些截图是CAT 2.0版本的,但和3.0版本没什么区别的。 一、简介 ...

    CAT分布式监控系统(一):CAT监控系统功能介绍

     

           本文概要:

                 1、CAT监控系统是什么。

                  2、CAT监控系统能做什么,能监控些什么。

           下面有些截图是CAT 2.0版本的,但和3.0版本没什么区别的。

     

    一、 简介

            CAT(Central Application Tracking)是美团开源的基于Java开发的实时分布式应用监控平台,提供了全面的监控服务和业务决策支持。

           CAT监控系统的定位:

    cat本质上一个实时监控系统,主要体现在监控报表Transaction、event、problem、heartbeat等,cat系统定制的监控模型以及定制的实时分析报表也是cat系统核心优势。

    logview是cat原始的log采集方式,cat的logview使用的技术是threadlocal,将一个thread里面的打点聚合上报,有一点弱化版本的链路功能,但是cat并不是一个标准的全链路系统,全链路系统参考dapper的论文,业内比较知名的鹰眼,zipkin等,其实经常拿cat和这类系统进行比较其实是不合适的。cat的logview在异步线程等等一些场景下,其实不合适,cat本身模型并不适合这个。在美团点评内部,有mtrace专门做全链路分析。

    也就是说:CAT定义了一个基本的监控模型,可以用来实时监控,至于要监控些什么可以自己定义,比如要做分布式全链路跟踪监控,可以自己埋点获取监控信息;

    怎么埋点也是有参考方案的,下篇博文将会介绍本人重新封装的客户端埋点SDK。

    另外,CAT倾向于指标、链路事件监控,不太适用于大量业务日志的场景,因为无法搜索、分析,CAT只看看到最新的样本数据和出问题的数据。大量业务日志的场景应该用ELK。

             github:https://github.com/dianping/cat

             官方DOME:http://unidal.org/cat/r/t?ip=All&queryname=&domain=cat

    二、系统/应用状态监控

            接入CAT客户端后,CAT客户端每分钟发送一次自身的状态信息。

            状态信息包括:服务器系统信息、JVM 内存/GC信息、线程信息、CAT监控使用信息等。详情如下图:

            状态信息的原始数据可以查看“Transaction“中的System类型信息,如下图:

            “Heartbeat”实时报表用来展示状态信息,可以看到当前项目下所有的部署机器(支付中心只有一台服务器),如下图:

            配置说明:这个功能无需其他配置,接入就自动上传状态监控信息。

     

    三、程序代码运行情况监控

            监控一段代码运行情况:运行时间统计、次数、错误次数等等。如下图:

            上面图一展示的是请求过程中监控的不同代码段类型的执行情况,不同类型表示范围不一样;图二展示方法类型里各方法的执行情况。一次请求过程原始监控数据如下(注意类型和上面图一对应):

            下面对图中报表进行解释:

                    a)Type统计界面

                    b)Name统计界面

                    c)一个小时内详细指标统计

                            1. Duration Distribution表示transaction的执行时间分布,这个图可以看出,大部分shopcheckin是在16-64毫秒完成,还有很少部分在512-1024毫秒完成。

                            2. HitOverTime、Averager Duration Over Time,Failures Over Time 纵轴都是以5分钟为单位,HitOverTime表示5分钟内的访问次数。

                            3. Averager Duration Over Time表示5分钟内的平均处理时间。

                            4. Failures Over Time表示5分钟内的Transaction失败次数。

     

                   配置说明:代码监控需要相关埋点配置,如方法监控可用包路径、或用@CatMethodMonitori注解配置,更多配置详情请参考《项目接入说明》。

    四、全链路监控分析

            上面我们也看到了一次请求过程的原始监控信息,包括URL、METHOD的耗时、参数、返回值等,如下:

            其中经历了一次跨服务调用service-ribbon à service-hi(注意:跨服务是图中第二个红框到第三个红框,而第一个红框到第二个红框是穿透Hystrix熔断器异步线程的),耗时图形分析如下:

            “Cross”报表展示了跨服务调用的情况,如下图:

            相关配置:默认开启,暂时支持该功能的通信组件:Spring Cloud Ribbon、Spring Cloud Feign(不兼容Sleuth)、Dubbo RPC,更多详情请参考《项目接入说明》。

    五、异常/错误等问题监控

            Problem记录整个项目在运行过程中出现的问题,包括一些错误、访问较长的行为。Problem的类型如下:

            1、“Problem”实时报表介绍

                    All的错误界面

                    错误一个小时内的实时趋势图

                    点击机器IP,进入某一台机器出现的具体问题,这个包括了All中出现的所有错误统计之外,还增加了以分钟和线程为单位的错误分布图,具体如下:

            2、“Problem”历史报表介绍

                    1)在选择了特定的域、报表类型、时间和IP之后,点击[:: show ::] 查看某一Type下的Problem出现次数的分布图。(当前这一天、上一天、上周这一天)

                    2)进一步,可以查看该Type下,某个Status的Problem出现次数的分布图。(当前这一天、上一天、上周这一天)

            相关配置:URL、方法监控会自动记录异常名称,如果需要集成日志框架(log4j、logback)打印上传错误信息,请参考《项目接入说明》。

    SQL执行监控

            SQL执行监控可以看到每个DAO方法执行解析的SQL语句、SQL语句执行时长、以及连接到哪个数据库(URL)执行;如果SQL执行出现异常,还会记录异常信息;另外还可以过滤出慢SQL。

            SQL监控执行整体情况如下:


     

           各DAO方法监控如下:

            测试一个方法里执行CURD的“Log View”信息如下:

           SQL类型(insert/select/update/delete)执行情况的统计如下:

            每个数据库执行情况的统计如下:

           另外,还可以在“Problem”标签页面过滤出慢SQL,如下图:

            相关配置:支持Mybatis的SQL监控,需要配置Mybatis监控插件,请参考《项目接入说明》。

    七、自定义监控/业务监控

            上面介绍这些功能主要是gc-cat-client SDK中实现的,稍微配置一下就可以使用。

            除此外,还有可以自定义监控以实现业务监控,CAT客户端本身提供了几种监控类型的API, CAT支持的监控消息类型包括:

                    1)、Transaction:适合记录跨越系统边界的程序访问行为,比如远程调用,数据库调用,也适合执行时间较长的业务逻辑监控,Transaction用来记录一段代码的执行时间和次数。

                    2)、Event:用来记录一件事发生的次数,比如记录系统异常,它和transaction相比缺少了时间的统计,开销比transaction要小。

                    3)、Heartbeat:表示程序内定期产生的统计信息, 如CPU%, MEM%, 连接池状态, 系统负载等。

                    4)、Metric:用于记录业务指标、指标可能包含对一个指标记录次数、记录平均值、记录总和,业务指标最低统计粒度为1分钟。

                            Metric一共有三个API,分别用来记录次数、平均、总和,统一粒度为一分钟:

                                   a).logMetricForCount:用于记录一个指标值出现的次数。

                                   b).logMetricForDuration:用于记录一个指标出现的平均值。

                                    c).logMetricForSum:用于记录一个指标出现的总和。

            看到这些类型名称,可知我们前面介绍的这些功能也是基于这几种监控消息类型的API实现的。

           一份埋点的样例:

                    Transaction:用来记录一段程序响应时间;Even:用来记录一行code的执行次数;Metric:用来记录一个业务指标。这些指标都是独立的,可以单独使用,主要看业务场景。

                    下面的埋点代码里面表示需要记录一个页面的响应时间,并且记录一个代码执行次数,以及记录两个业务指标,所有用了一个Transaction,一个Event,两个Metric。Transaction的埋点一定要complete,切记放在finally里面。

                   代码中自定义好业务指标监控后,然后运行测试上传一些监控数据,接着到“业务监控配置”页面(http://192.168.1.52:8888/cat/s/config? op=list)配置大盘显示和告警,然后就可以在“Business”而页面看到相关图表,如下:

    八、告警设置

            上面业务监控我们也说到业务指标也可以设置告警的,除此外,Transaction/Event/异常/心跳都可以设置告警,如下图所示:

            URL(/hi)执行次数告警测试:

    九、其他报表统计

            还有一些全局的报表统计,访问地址(比较隐蔽):http://192.168.1.52:8888/cat/r/overload

            如“全局统计异常”报表,看到各个项目的异常情况:

            “服务可用排行”报表,看到各服务可用情况:

            “线上容量规划”报表,看到各项目一些资源使用情况:

    十、总结

            以上总结了本人发现的且认为比较有用的CAT监控功能,基本能满足大部分监控需求,更多功能有待大家挖掘。

            另外,下篇博文将会介绍本人重新封装的CAT客户端埋点SDK,欢迎提出建议。

     

    【参考资料】

    1、 CAT相关文档

    2、 GitHub - dianping/cat: Central Application Tracking

    3、 深度剖析开源分布式监控CAT

    4、 大众点评网监控平台剖析

    5、 透过CAT,来看分布式实时监控系统的设计与实现

    6、 Dapper,大规模分布式系统的跟踪系统 by bigbully

    展开全文
  • 监控系统的设计

    万次阅读 2019-09-29 14:35:53
    经济高速发展的今天,我们处于信息大爆炸的时代。...就在这样一个纷繁复杂地环境下,监控系统粉墨登场了。 今天,我们会对 IT 监控系统进行介绍,包括其功能,分类,分层;同时也会介绍几款流行的监控平台...

    经济高速发展的今天,我们处于信息大爆炸的时代。随着经济发展,信息借助互联网的力量在全球自由地流动,于是就催生了各种各样的服务平台和软件系统。

    由于业务的多样性,这些平台和系统也变得异常的复杂。如何对其进行监控和维护是我们 IT 人需要面对的重要问题。就在这样一个纷繁复杂地环境下,监控系统粉墨登场了。

    今天,我们会对 IT 监控系统进行介绍,包括其功能,分类,分层;同时也会介绍几款流行的监控平台。

    监控系统的功能

    在 IT 运维过程中,常遇到这样的情况:

    • 某个业务模块出现问题,运维人员并不知道,发现的时候问题已经很严重了。
    • 系统出现瓶颈了,CPU 占用持续升高,内存不足,磁盘被写满;网络请求突增,超出网关承受的压力。

    以上这些问题一旦发生,会对我们的业务产生巨大的影响。因此,每个公司或者 IT 团队都会针对此类情况建立自己的 IT 监控系统。

     

    想吃透监控系统,就这一篇够不够?

     

     

    监控系统工作流程图

    其功能包括:

    • 对服务,系统,平台的运行状态实时监控。
    • 收集服务,系统,平台的运行信息。
    • 通过收集信息的分析结果,预知存在的故障风险,并采取行动。
    • 根据对风险的评估,进行故障预警。
    • 一旦发生故障,第一时间发出告警信息。
    • 通过监控数据,定位故障,协助生成解决方案。
    • 最终保证系统持续、稳定、安全运行。
    • 监控数据可视化,便于统计,按照一定周期导出、归档,用于数据分析和问题复盘。

    监控系统的分类

    既然监控系统对我们意义重大,针对不同场景把监控系统分为三类,分别是:

    • 日志类
    • 调用链类
    • 度量类

    日志类

    通常我们在系统和业务级别上加入一些日志代码,记录一些日志信息,方便我们在发现问题的时候查找。

    这些信息会与事件做相关,例如:用户登录,下订单,用户浏览某件商品,一小时以内的网关流量,用户平均响应时间等等。

    这类以日志的记录和查询的解决方案比较多。比如 ELK 方案(Elasticsearch+Logstash+Kibana),使用ELK(Elasticsearch、Logstash、Kibana)+Kafka/Redis/RabbitMQ 来搭建一个日志系统。

     

    想吃透监控系统,就这一篇够不够?

     

     

    ELK 结合 Redis/Kafka/RabbitMQ 实现日志类监控

    程序内部通过 Spring AOP 记录日志,Beats 收集日志文件,然后用 Kafka/Redis/RabbitMQ 将其发送给 Logstash,Logstash 再将日志写入 Elasticsearch。

    最后,使用 Kibana 将存放在 Elasticsearch 中的日志数据显示出来,形式可以是实时数据图表。

    调用链类

    对于服务较多的系统,特别是微服务系统。一次服务的调用有可能涉及到多个服务。A 调用 B,B 又要调用 C,好像一个链条一样,形成了服务调用链。

    调用链就是记录一个请求经过所有服务的过程。请求从开始进入服务,经过不同的服务节点后,再返回给客户端,通过调用链参数来追踪全链路行为。从而知道请求在哪个环节出了故障,系统的瓶颈在哪儿。

    调用链监控的实现原理如下:

    ①Java 探针,字节码增强

     

    想吃透监控系统,就这一篇够不够?

     

     

    Java 代码运行原理图

    在介绍这种方式之前,我们先来复习一下 Java 代码运行的原理。通常我们会把 Java 源代码,通过“Java 编译器”编译成 Class 文件。再把这个 Class 的字节码文件装载到“类装载器”中进行字节码的验证。

    最后,把验证过后的字节码发送到“Java 解释器”和“及时编译器”交给“Java 运行系统”运行。

    Java 探针,字节码增强的方式就是利用 Java 代理,这个代理是运行方法之前的拦截器。

    在 JVM 加载 Class 二进制文件的时候,利用 ASM 动态的修改加载的 Class 文件,在监控的方法前后添加需要监控的内容。

    例如:添加计时语句,用于记录方法耗时。将方法耗时存入处理器,利用栈先特性(先进后出)处理方法调用顺序。

    每当请求处理结束后,将耗时方法和入参 map 输出到文件中,然后根据 map 中相应参数,区分出耗时业务。

    最后将相应耗时文件取下来,转化为 xml 格式并进行解析,通过浏览器将代码分层结构展示出来。

     

    想吃透监控系统,就这一篇够不够?

     

     

    Java 探针工具原理图

    备注:ASM 是一个 Java 字节码操纵框架,它可以动态生成类或者增强既有类的功能。

    ASM 可以直接产生二进制 Class 文件,可以在类被载入 Java 虚拟机之前改变类行为。

    Java Class 被存储在 .class文件里,文件拥有元数据来解析类中的元素:类名称、方法、属性以及 Java 字节码(指令)。

    ASM 从类文件中读入信息后,能够改变类行为,分析类信息,甚至能够生成新类。

    ②拦截请求

    获取每次请求服务中的信息来实现跟踪的。这里以 Zipkin+Slueth 为例说明其原理。

    Sleuth 提供链路追踪。由于一个请求会涉及到多个服务的互相调用,而这种调用往往成链式结构,经过多次层层调用以后请求才会返回。常常使用 Sleuth 追踪整个调用过程,方便理清服务间的调用关系。

     

    想吃透监控系统,就这一篇够不够?

     

     

    Sleuth 服务调用追踪图例

    每次请求都会生成一个 Trace ID,如上图所示这个 Trace ID 在整个 Request 和 Response 过程中都会保持一致,不论经过了多少个服务。这是为了方便记录一次调用的整个生命周期。

    再看每次请求的时候都会有一个 Span ID,这里的 Span 是 Sleuth 服务跟踪的最小单元,每经过一个服务,每次 Request 和 Response 这个值都会有所不同,这是为了区分不同的调用动作。

    针对每个调用的动作,Sleuth 都做了标示如下:

    • Server Received 是服务器接受,也就是服务端接受到请求的意思。
    • Client Sent 是客户端发送,也就是这个服务本身不提供响应,需要调用其他的服务提供该响应,所以这个时候是作为客户端发起请求的。
    • Server Sent 是服务端发送,看上图SERVICE 3 收到请求后,由于他是最终的服务提供者,所以作为服务端,他需要把请求发送给调用者。
    • Client Received 是客户端接受,作为发起调用的客户端接受到服务端返回的请求。

    实际上 Sleuth 就是通过上述方式把每次请求记录一个统一的 Trace ID,每个请求的详细步骤记作 Span ID。

    每次发起请求或者接受请求的状态分别记录成 Server Received,Client Sent,Server Sent,Client Received 四种状态来完成这个服务调用链路的跟踪的。

     

    想吃透监控系统,就这一篇够不够?

     

     

    Sleuth 服务调用追踪图例

    在调用服务的链路上每个被调用的服务节点都会通过 Parent ID 来记录发起调用服务的 Span ID,由于 Span ID 是唯一确认最小服务单元的,所以知道了 Parent 的 Span ID 也就知道了谁调用自己了。

    度量类

    实现了时序数据库(TimeSeriesData,TSD)的监控方案。实际上就是记录一串以时间为维度的数据,然后再通过聚合运算,查看指标数据和指标趋势。说白了,就是描述某个被测主体在一段时间内的测量值变化(度量)。

    由于 IT 基础设施,运维监控和互联网监控的特性,这种方式被广泛应用。一般对时序数据进行建模分为三个部分,分别是:主体,时间点和测量值。

    通过这个例子来看一下,时序数据库的数学模型,例如:需要监控服务器的 In/Out 平均流量:

    • 整个监控的数据库称为“Metric”,它包含了所有监控的数据。类似关系型数据库中的 Table。
    • 每条监控数据,称为“Point”,类似于关系型数据库中的 Row 的概念。
    • 每个“Point”都会定义一个时间戳“Timestamp”,将其作为索引,表明数据采集的时间。
    • “Tag”作为维度列,表示监控数据的属性。
    • “Field”作为指标列,作为测量值,也就是测量的结果。

     

    想吃透监控系统,就这一篇够不够?

     

     

    时序数据库数据模型图例

    时序数据库的存储原理,关系型数据库存储采用的是 B tree,虽然降低了数据查询的磁盘寻道时间,但是无法解决大量数据写入时的磁盘效率。

    由于监控系统的应用场景,经常会遇到大批量的数据写入,所以我们会选择 LSMtree(Log Structured Merge Tree)存储时序数据库。

    LSMtree(Log Structured Merge Tree),从字面意义上理解,记录的数据按照日志结构(Log Structured)追加到系统中,然后通过合并树(Merge Tree)的方式将其合并。

    来看一个 LevelDB 的例子,方便我们理解,LSM-tree 被分成三种文件:

    • 接收写入请求的 memtable 文件(内存中)
    • 不可修改的 immutable memtable 文件(内存中)
    • 磁盘上的 SStable文件(Sorted String Table),有序字符串表,这个有序的字符串就是数据的key。SStable 一共有七层(L0 到 L6)。下一层的总大小限制是上一层的 10 倍。

     

    想吃透监控系统,就这一篇够不够?

     

     

    LSMtree LevelDB 存储示意图

    LSMtree 写入流程:

    • 将数据追加到日志 WAL(Write Ahead Log)中,写入日志的目的是为了防止内存数据丢失,可以及时恢复。
    • 把数据写到 memtable 中。
    • 当 memtable 满了(超过一定阀值),就将这个 memtable 转入 immutable memtable 中,用新的 memtable 接收新的数据请求。
    • immutablememtable 一旦写满了, 就写入磁盘。并且先存储 L0 层的 SSTable 磁盘文件,此时还不需要做文件的合并。

    每层的所有文件总大小是有限制的(8MB,10MB,100MB… 1TB)。从 L1 层往后,每下一层容量增大十倍。

    • 某一层的数据文件总量超过阈值,就在这一层中选择一个文件和下一层的文件进行合并。

    如此这般上层的数据都是较新的数据,查询可以从上层开始查找,依次往下,并且这些数据都是按照时间序列存放的。

    监控系统的分层

    谈完了监控系统的分类,再来聊聊监控系统的分层。用户请求到数据返回,经历系统中的层层关卡。

     

    想吃透监控系统,就这一篇够不够?

     

     

    监控系统分层示意图

    一般我们将监控系统分为五层来考虑,当然也有人分成三层,大致的意思都差不多,仅供参考:

    • 客户端监控,用户行为信息,业务返回码,客户端性能,运营商,版本,操作系统等。
    • 业务层监控,核心业务的监控,例如:登录,注册,下单,支付等等。
    • 应用层监控,相关的技术参数,例如:URL 请求次数,Service 请求数量,SQL 执行的结果,Cache 的利用率,QPS 等等。
    • 系统层监控,物理主机,虚拟主机以及操作系统的参数。例如:CPU 利用率,内存利用率,磁盘空间情况。
    • 网络层监控,网络情况参数。例如:网关流量情况,丢包率,错包率,连接数等等。

    流行的监控系统

    前面讲了监控系统的功能,分类,分层,相信大家对 IT 监控系统都有一定的了解了。

    接下来,我们来看看有哪些优秀实践。这里介绍两个比较流行的监控系统:

    • Zabbix
    • Prometheus

    Zabbix

    Zabbix 是一款企业级的分布式开源监控方案。它由 Alexei Vladishev 创建,由 Zabbix SIA 在持续开发和支持。

    Zabbix 能够监控网络参数,服务器健康和软件完整性。它提供通知机制,允许用户配置告警,从而快速反馈问题。

    基于存储的数据,Zabbix 提供报表和数据可视化,并且支持主动轮询和被动捕获。它的所有报告、统计信息和配置参数都可以通过 Web 页面访问。

    Zabbix 的 API 功能,完善度很高,大部分操作都提供了 API 接口,方便和现有系统整合。

    例如:通过历史数据查询 API,获取线上服务器使用情况,生成报表;设置条件,对问题服务器和问题业务进行筛选,加入告警。

    利用 Zabbix graph 的 API,生成关键指标趋势图,方便运维人员实时了解系统情况。利用告警添加 API,让监控系统和部署系统联动。

    比如新部署了一个新实例,那么自动添加所需要的监控策略;反之,下线一个实例,就删除关联的监控策略。

    Zabbix 由 Server,Agent,Proxy(可选项)组成:

    • Agent 负责收集数据,并且传输给 Server。
    • Server 负责接受 Agent 的数据,进行保存或者告警。
    • Proxy 负责代理 Server 收集 Agent 传输的数据,并且转发给 Server。Proxy 是安装在被监控的服务器上的,用来和 Server 端进行通信,从而传输数据。

     

    想吃透监控系统,就这一篇够不够?

     

     

    Zabbix 的部署模式

    Zabbix 的数据采集,主要有两种模式:Server 主动拉取数据和 Agent 主动上报数据。

    以 Server 拉取数据为例,用户在 Web-portal 中,设置需要监控的机器,配置监控项,告警策略。Zabbix-Server 会根据策略主动获取 Agent 的数据,然后存储到 MySQL 中。

    同时根据用户配置的策略,判定是否需要告警。用户可以在 Web 端,以图表的形式,查看各种指标的历史趋势。

    在 Zabbix 中,将 Server 主动拉取数据的方式称之为 Active Check。这种方式配置起来较为方便,但是会对 Zabbix-Server 的性能存在影响。

    所以在生产环境中,一般会选择主动推送数据到 Zabbix-Server 的方式,称之为 Trapper。

    即用户可以定时生成数据,再按照 Zabbix 定义的数据格式,批量发送给 Zabbix-Server,这样可以大大提高 Server 的处理能力。

    Proxy,作为可选项,起到收集 Agent 数据并且转发到 Server 的作用。

    当 Server 和 Agent 不在一个网络内,就需要使用 Proxy 做远程监控,特别是远程网络有防火墙的时候。同时它也可以分担 Server 的压力,降低 Server 处理连接数的开销。

    Prometheus(普罗米修斯)

    随着这几年云环境的发展,Prometheus 被广泛地认可。它的本质是时间序列数据库,而 Zabbix 采用 MySQL 进行数据存储。

    从上面我们对时间序列数据库的分析来看,Prometheus 能够很好地支持大量数据的写入。

    它采用拉的模式(Pull)从应用中拉取数据,并通过 Alert 模块实现监控预警。据说单机可以消费百万级时间序列。

    一起来看看 Prometheus 的几大组件:

    • Prometheus Server,用于收集和存储时间序列数据,负责监控数据的获取,存储以及查询。
    • 监控目标配置,Prometheus Server 可以通过静态配置管理监控目标,也可以配合 Service Discovery(K8s,DNS,Consul)实现动态管理监控目标。
    • 监控目标存储,Prometheus Server 本身就是一个时序数据库,将采集到的监控数据按照时间序列存储在本地磁盘中。
    • 监控数据查询,Prometheus Server 对外提供了自定义的 PromQL 语言,实现对数据的查询以及分析。
    • Client Library,客户端库。为需要监控的服务生成相应的 Metrics 并暴露给 Prometheus Server。
    • 当 Prometheus Server 来 Pull 时,直接返回实时状态的 Metrics。通常会和 Job 一起合作。
    • Push Gateway,主要用于短期的 Jobs。由于这类 Jobs 存在时间较短,可能在 Prometheus 来 Pull 之前就消失了。为此,这些 Jobs 可以直接向 Prometheus Server 端推送它们的 Metrics。
    • Exporters,第三方服务接口。将 Metrics(数据集合)发送给 Prometheus。
    • Exporter 将监控数据采集的端点,通过 HTTP 的形式暴露给 Prometheus Server,使其通过 Endpoint 端点获取监控数据。
    • Alertmanager,从 Prometheus Server 端接收到 Alerts 后,会对数据进行处理。例如:去重,分组,然后根据规则,发出报警。
    • Web UI,Prometheus Server 内置的 Express Browser UI,通过 PromQL 实现数据的查询以及可视化。

     

    想吃透监控系统,就这一篇够不够?

     

     

    Prometheus 架构图

    说完了 Prometheus 的组件,再来看看 Prometheus 的架构:

    • Prometheus Server 定期从 Jobs/Exporters 中拉 Metrics。同时也可以接收来自 Pushgateway 发过来的 Metrics。
    • Prometheus Server 将接受到的数据存储在本地时序数据库,并运行已定义好的 alert.rules(告警规则),一旦满足告警规则就会向 Alertmanager 推送警报。
    • Alertmanager 根据配置文件,对接收到的警报进行处理,例如:发出邮件告警,或者借助第三方组件进行告警。
    • WebUI/Grafana/APIclients,可以借助 PromQL 对监控数据进行查询。

    最后将两个工具进行比较如下:

     

    想吃透监控系统,就这一篇够不够?

     

     

    Zabbix 和 Prometheus 比较图

    从上面的比较可以看出:

    • Zabbix 的成熟度更高,上手更快。高集成度导致灵活性较差,在监控复杂度增加后,定制难度会升高。而且使用的关系型数据库,对于大规模的监控数据插入和查询是个问题。
    • Prometheus 上手难度大,定制灵活度高,有较多数据聚合的可能,而且有时序数据库的加持。
    • 对于监控物理机或者监控环境相对稳定的情况,Zabbix 有明显优势。如果监控场景多是云环境的话,推荐使用 Prometheus。

    总结

     

    想吃透监控系统,就这一篇够不够?

     

     

    监控系统思维导图

    监控系统对 IT 系统运维意义重大,从状态监控到收集/分析数据,到故障报警,以及问题解决,最后归档报表,协助运维复盘。

    监控系统分为三大类,日志类,调用链类,度量类,他们有各自的特点,且应用场景各不相同。

    因为要对整个 IT 系统进行监控,所以将其分为五层,分别是,客户端,业务层,应用层,系统层,网络层。

    Zabbix 和 Prometheus 是当下流行的监控系统,可以根据他们的特点选择使用。

    展开全文
  • 监控系统-小米监控

    千次阅读 2017-02-19 22:05:51
    小米监控系统部署文档:http://book.open-falcon.org/zh/quick_install/prepare.html github地址:https://github.com/XiaoMi/open-falcon 极客学院介绍监控系统视频:http://my.jikexueyuan.com/ulricqin/record/

    小米监控系统部署文档:http://book.open-falcon.org/zh/quick_install/prepare.html

    github地址:https://github.com/XiaoMi/open-falcon

    极客学院介绍监控系统视频:http://my.jikexueyuan.com/ulricqin/record/,http://www.jikexueyuan.com/course/1651_2.html

    展开全文
  • 浅谈监控系统

    千次阅读 2020-07-28 15:14:58
    众所周知,监控系统经历了从模拟监控系统到如今数字监控系统的转变。 最近因为在做一个相关项目,因此稍微查了一点资料,粗略的谈谈我的理解吧,我下面说的话,很可能 会有错误,希望大家本着挑刺的精神,谨慎观看,...
  • IT 监控系统介绍

    千次阅读 2019-09-30 14:40:29
    就在这样一个纷繁复杂地环境下,监控系统粉墨登场了。 今天,我们会对 IT 监控系统进行介绍,包括其功能,分类,分层;同时也会介绍几款流行的监控平台。 监控系统的功能 在 IT 运维过程中,常遇到这样的...
  • prometheus监控系统

    千次阅读 2018-06-18 00:55:51
    prometheus监控系统 一、什么是prometheus Prometheus 是由 SoundCloud 开发的开源监控报警系统和时序列数据库(TSDB),它按给定的时间间隔从配置的目标收集指标,评估规则表达式,显示结果,并且如果观察到...
  • 前端监控系统

    千次阅读 2019-05-08 18:34:41
    在开发项目的过程中,正式环境出现了浏览器crash,这种情况在开发过程中无法复现,是一个需要长期追踪的问题,因此项目中引入了前端监控系统。 资源加载出错的捕获方案 <img src="image.gif" onerror="myFuncti....
  • 简述舆情监控系统

    千次阅读 2019-06-03 21:44:04
    首先我们要知道什么是舆情监控系统,这个有什么用。 网络舆情是指在互联网上流行的对社会问题不同看法的网络舆论,是通过互联网传播的公众对现实生活中某些热点、焦点问题所持的有较强影响力、倾向性的言论和观点。...
  • 监控系统架构图

    千次阅读 2018-08-07 16:13:53
    日志分析服务,监控系统  
  • 数字监控系统是从视频编码,视频传输到控制存储都是数字信号的视频监控系统。是相对于模拟监控系统而言的。视频监控系统的进化经历了四代:  第一代:全模拟系统  模拟摄像机+磁带机 已被淘汰  第二代:半数字...
  • 分布式监控系统

    千次阅读 2016-06-12 13:22:32
    在一个大型分布式系统中(一个完备的...【在分布式监控系统比较低级时,比如只能监控某一个微服务的运行情况:这时就需要一些人力来保证整个链路的问题的及时发现,一个人维护100个系统的稳定性,知道哪个系统是否异
  • 远程屏幕监控系统

    千次阅读 2018-05-12 20:41:13
    远程屏幕监控系统 近期整理代码的时候,发现大二的时候(目前大三)做的几个课程设计还不错,所以把这部分的代码以及设计文档都开源出来,以供后者参考学习使用。 完整代码以及本文的word都在放在了Github上,...
  • 《Zabbix企业级分布式监控系统

    千次下载 热门讨论 2014-09-11 09:15:48
    第一本Zabbix中文图书,企业级开源监控系统必选
  • 实时监控系统介绍

    千次阅读 2018-03-23 11:52:08
    本文不会介绍这类实时监控的实现原理(有兴趣的可以去找相关开源软件,如OpenTSDB),只是从一个开发人员的角度阐述如何理解并正确使用这类监控系统。注:如果你有过使用这类监控系统的经历,可能会更清楚我要说明的...
  • Prometheus+Grafana搭建监控系统

    万次阅读 多人点赞 2017-11-15 09:28:30
    所以是时候搭建一套监控系统了。 由于是业余时间自己捯饬,所以神马业务层面的监控先不做,先用最简单的方式接入系统层面的监控,例如服务器、数据库等。 调研了一段时间,发现Prometheus+Grafana还是可以的。...
  • 机房动环监控系统

    千次阅读 2019-05-22 11:44:55
    现今,信息技术发展飞快,机房设备逐渐增多,许多企业开始逐步使用机房动环监控系统来监控重要的设备,以提高工作效率和保证安全性。那么,机房动环监控系统究竟是做什么的呢? 标准的机房动力环境监控系统必须包括...
  • redis监控系统

    千次阅读 2014-12-04 11:22:15
    Redis监控系统 系统项目可以从https://github.com/nkrode/RedisLive下载 git clone git@github.com:nkrode/RedisLive.git 这个系统是依据python写的需要安装一些python环境 tornado pip install tornado...
  • 监控系统的一般架构

    千次阅读 2017-07-21 14:16:42
    几年以来,个人对监控系统的接触比较多,像电力scada系统,自动化设备的上位机系统,无人机地面站等,到后来独立开发监控系统,慢慢的形成了自己对监控系统通用实现的一种理解。其实做这行软件开发的也都有一个架构...
  • influxdata监控系统简介

    千次阅读 2018-04-03 16:23:40
    influxdata是一个强大的实时监控系统,分为4个部分,系统架构图如下: TelegrafTelegraf负责收集监控数据,并将数据输出到influxDB数据库,它支持多种类型的数据输入,比如httpjson、mysql、rabbitMQ等等。...
  • 监控系统相关的常见面试问题1. 什么是监控系统2. 为什么需要监控系统3. 监控系统功能4. 监控系统趋势5. 如何选择监控系统 1. 什么是监控系统 互联网监控软件:分为单一监控程序和分布式监控程序 单一监控程序: win...
  • centos7部署zabbix监控系统

    千次阅读 2020-10-20 16:24:44
    zabbix监控系统 什么是zabbix监控系统? zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。 zabbix能监视各种网络参数,保证服务器系统的安全运营;并提供灵活的通知机制以让...
  • Prometheus 是一套开源的系统监控、报警、时间序列数据库的组合,最初有 SoundCloud 开发的,后来随着越来越多公司使用,于是便独立成开源项目。我们常用的 Kubernetes ...Prometheus+Grafana监控系统搭建并监控 Mysql
  • 使用Java实现简单的监控系统

    千次阅读 2020-05-05 15:15:36
    本文只是简单介绍了下监控系统实现的思路,具体还需根据自己需求实现。 前言: 目前存在一个后台服务系统,此时需要配套一个监控系统,对这个后台服务系统进行监控。下面会涉及到两个系统,后台服务系统(这是已经...
  • 大数据——舆情监控系统

    千次阅读 2018-12-05 10:23:59
    首先我们要知道什么是舆情监控系统,这个有什么用。 舆情系统最主要的就是满足用户对网络舆情监测和热点时间等专题追踪等需求,尤其是在二十一世纪这个信息爆炸的时代,我们必须快速获取到对自己有用的热点新闻。 ...
  • 原文:搭建前端监控系统(二)JS错误监控篇 Fundebug经授权转载,版权归原作者所有。 **背景:**市面上的监控系统有很多,大多收费,对于小型前端项目来说,必然是痛点。另一点主要原因是,功能通用,却未必能够...
  • MySQL监控系统Lepus

    千次阅读 2016-05-06 11:25:52
    现在流行的监控系统很多,选择一个合适自己的就可以了,例如Zabbix、Nagios;监控MySQL为主的有MySQLMTOP、Lepus。本文主要介绍快速部署lepus以及监控MySQL,因为作为DBA我们还是注重MySQL的监控,当然系统状态也...
  • 自用型监控系统方案设计

    千次阅读 2018-11-29 13:02:18
    一、监控系统整体概述 系统背景: 在当前项目中,当我们对特定流程注入故障后,如何评估故障的效果以及系统应对故障的表现?传统方式是用户需要登录线上机器或者各种监控系统去查看具体的指标信息,然后通过人工...

空空如也

1 2 3 4 5 ... 20
收藏数 91,039
精华内容 36,415
关键字:

监控系统