zoukankan      html  css  js  c++  java
  • 无监控,不运维

      监控系统俗称“第三只眼“,正所谓【无监控,不运维】,监控系统的地位不言而喻。没有了监控,不管什么基础运维、业务运维都是“瞎子”。

    监控系统的作用:

    • 实时采集监控数据:包括硬件、操作系统、中间件、应用程序等各个维度的数据。
    • 实时反馈监控状态:通过对采集的数据进行多维度统计和可视化展示,能实时体现监控对象的状态是正常还是异常。
    • 预知故障和告警:能够提前预知故障风险,并及时发出告警信息。
    • 辅助定位故障:提供故障发生时的各项指标数据,辅助故障分析和定位。
    • 辅助性能调优:为性能调优提供数据支持,比如慢SQL,接口响应时间等。
    • 辅助容量规划:为服务器、中间件以及应用集群的容量规划提供数据支撑。
    • 辅助自动化运维:为自动扩容或者根据配置的SLA进行服务降级等智能运维提供数据支撑。

    监控问题:有没有做监控?监控是否及时?监控信息是否有助于快速定位问题?

    如何使用监控系统:

    • 了解监控对象的工作原理:要做到对监控对象有基本的了解,清楚它的工作原理。比如想对JVM进行监控,你必须清楚JVM的堆内存结构和垃圾回收机制。
    • 确定监控对象的指标:清楚使用哪些指标来刻画监控对象的状态?比如想对某个接口进行监控,可以采用请求量、耗时、超时量、异常量等指标来衡量。
    • 定义合理的报警阈值和等级:达到什么阈值需要告警?对应的故障等级是多少?不需要处理的告警不是好告警,可见定义合理的阈值有多重要,否则只会降低运维效率或者让监控系统失去它的作用。
    • 建立完善的故障处理流程:收到故障告警后,一定要有相应的处理流程和oncall机制,让故障及时被跟进处理。

    监控对象

      硬件监控

      包括:电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态
      服务器基础监控
      CPU:单个CPU以及整体的使用情况
      内存:已用内存、可用内存
      磁盘:磁盘使用率、磁盘读写的吞吐量
      网络:出口流量、入口流量、TCP连接状态
     
      数据库监控
     
      包括:数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询
     
      中间件监控
     
      Nginx:活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率
      Tomcat:最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时
      缓存 :成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率
      消息队列:连接数、队列数、生产速率、消费速率、消息堆积量
     
      应用监控
     
      HTTP接口:URL存活、请求量、耗时、异常量
      RPC接口:请求量、耗时、超时量、拒绝量
      JVM :GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数
      线程池:活跃线程数、任务队列大小、任务执行耗时、拒绝任务数
      连接池:总连接数、活跃连接数
      日志监控:访问日志、错误日志
      业务指标:视业务来定,比如PV、订单量等
     
    监控的基本流程:
     
    • 数据采集:采集的方式有很多种,包括日志埋点进行采集(通过Logstash、Filebeat等进行上报和解析),JMX标准接口输出监控指标,被监控对象提供REST API进行数据采集(如Hadoop、ES),系统命令行,统一的SDK进行侵入式的埋点和上报等。
    • 数据传输:将采集的数据以TCP、UDP或者HTTP协议的形式上报给监控系统,有主动Push模式,也有被动Pull模式。
    • 数据存储:有使用MySQL、Oracle等RDBMS存储的,也有使用时序数据库RRDTool、OpentTSDB、InfluxDB存储的,还有使用HBase存储的。
    • 数据展示:数据指标的图形化展示。
    • 监控告警:灵活的告警设置,以及支持邮件、短信、IM等多种通知通道。

    主流监控优劣势

      Zabbix 的优势:

      产品成熟:由于诞生时间长且使用广泛,拥有丰富的文档资料以及各种开源的数据采集插件,能覆盖绝大部分监控场景。
      采集方式丰富:支持Agent、SNMP、JMX、SSH等多种采集方式,以及主动和被动的数据传输方式。
      较强的扩展性:支持Proxy分布式监控,有agent自动发现功能,插件式架构支持用户自定义数据采集脚本。
      配置管理方便:能通过Web界面进行监控和告警配置,操作方便,上手简单。
     
      Zabbix 的劣势:
     
      性能瓶颈:机器量或者业务量大了后,关系型数据库的写入一定是瓶颈,官方给出的单机上限是5000台,个人感觉达不到,尤其现在应用层的指标越来越多。虽然最新版已经开始支持时序数据库,不过成熟度还不高。
      应用层监控支持有限:如果想对应用程序做侵入式的埋点和采集(比如监控线程池或者接口性能),zabbix没有提供对应的sdk,通过插件式的脚本也能曲线实现此功能,个人感觉zabbix就不是做这个事的。
      数据模型不强大:不支持tag,因此没法按多维度进行聚合统计和告警配置,使用起来不灵活。
      方便二次开发难度大:Zabbix采用的是C语言,二次开发往往需要熟悉它的数据表结构,基于它提供的API更多只能做展示层的定制。
     
      好吧,我目前就只用过zabbix,,,,,,
     
     
    注:本文主要用於個人學習與知识總結,如有錯誤期待各位大佬的指導!
     
  • 相关阅读:
    Uva1595 对称轴
    Uva712 S树
    Uva673 平衡的括号
    leetcode102 二叉树的层次遍历
    Uva10191 复合词
    C++ multimap的用法
    Uva1103 古代象形符号
    UVa10763 交换学生
    C++ 优先级队列 priority_queue
    ios,zepto穿透解决方案
  • 原文地址:https://www.cnblogs.com/shiqing-zhang/p/13539598.html
Copyright © 2011-2022 走看看