关于监控—从原理说起,其实就这么简单

前言监控系统 , 是通过持续信息采集、收敛、分析来发现问题 , 并对解决问题提供数据依赖的一种科学技术 。通过监控技术可以实现对故障进行 “事前预警 , 事后追踪” 。
监控 , 是运维工作中的重要技术 , 如果没有监控 , 运维人员就相当于盲人摸象 , 发现问题会变得很被动;监控也是整个产品生命周期中最重要的一环 , 如果没有监控 , 产品中存在的问题就只能等用户反馈(客诉) , 严重降低用户体验 。
目前 , 互联网行业的监控技术已经很成熟 , 业界有很多不错的开源产品可供选择 , 运维在开展监控工作时 , 选择一款开源监控系统 , 是一个省时省力 , 效率最高的方案 。
监控目的监控的目的是通过采集准确的监控指标、配置合理的告警机制 , 提前或者尽早发现问题 , 并做出响应、解决问题 , 进而保证产品的稳定性 , 提升用户体验 。
具体可分为以下几方面:

  1. 对系统持续实时监控:指硬件系统 , 如服务器、路由器、交换机等;
  2. 对应用持续实时监控:指业务运行依赖的基础服务 , 如数据库、中间件等;
  3. 对业务持续实时监控:指产品运行情况 , 如状态码、接口响应时间、异常信息等 。
监控方法在了监控的重要性及监控目的之后 , 我们来聊聊到底如何做监控 。
关于监控—从原理说起,其实就这么简单

文章插图
 
  1. 确定监控对象:明确是系统监控 , 还是应用监控 , 或者是业务监控;
  2. 确定监控指标:确定监控对象之后 , 需要明确具体监控指标 , 如果监控对象为服务器 , 那么监控指标有CPU、磁盘、内存等;
  3. 确定告警格式:监控的目的之一就是发出告警 , 所以 , 告警信息的格式要做到统一、简洁明了;
  4. 确定告警阈值:泛滥的告警就像”狼来了“ , 所以要设定合理的阈值 , 确保告警准确、有效;
  5. 确定负责人:确定监控指标后 , 明确告警负责人 , 可以让运维或测试人员更快的将事件分发到具体的业务负责人 , 以提升故障处理效率 , 同时降低对其他人的打扰;
  6. 确定事件处理流程:对于告警 , “事事有回音 , 件件有着落” 很重要 , 让每个事件构成一个闭环 。
监控指标【关于监控—从原理说起,其实就这么简单】监控指标是立足于监控对象至上的 , 如何确定监控指标?
监控指标 , 即监控对象相关的关键性指标 。
那么 , 哪些算是关键性指标呢?
这个仁者见仁智者见智 , 在我看来 , 对服务稳定运行带来严重影响的才算关键指标 。
那么 , 怎么算严重影响呢?
这个问题可以通过用户体验来反推 , 哪些问题能带来用户体验的不适?比如 , 请求响应慢、请求错误、请求报异常等等 。
在我看来 , 站在用户体验的角度来反推监控指标是一个不错的办法 。
常规监控指标以下监控指标仅供参考 。
监控对象监控指标硬件CPU温度、主板温度、物理磁盘、磁盘阵列等系统CPU负载、磁盘使用率、内存使用率、网络带宽等应用状态(端口)、进程、应用内部指标(如MySQL、redis连接数、内存使用)等业务API、状态码、QPS等日志访问日志、错误日志、运行日志、网络日志等
监控工具确定监控指标后 , 遍可以奔着高效、可用的原则来选择监控工具了 。
目前业界监控工具很多 , 常用的开源监控工具:Zabbix、Open-falcon、Prometheus、Grafana(图)等 。
关于监控—从原理说起,其实就这么简单

文章插图
 
相关的文章太多了 , 在此不做赘述 , 想要学习推荐官方网站 。
监控方案了解了监控指标、监控工具之后 , 接下来就需要确定一个合理、可行的监控方案了 。如何确定监控方案?
  1. 首先 , 要了解公司的技术栈;
  2. 然后 , 对涉及到的各种组件进行全面了解;
  3. 其次 , 确定详细的监控指标 , 目前各种应用的官网基本都有提供监控相关的metrics;


    推荐阅读