监控完整性

从用户访问我们云端服务的完整链路来看,为了保障监控的完整性,监控应该覆盖"云、管、端"三个环节.

云监控

环境层监控(environment)

监控业务所在机器/容器的环境,及时感知机器/容器层面的异常:一般包括的监控项目有,磁盘空间,CPU利用率,内存利用率,网卡IO,磁盘IO,机器死机,容器runtime环境异常。

类型监控项是否强制参考阈值(各业务请跟进实际情况设置)
环境监控磁盘空间
  • ROOT分区使用量超过95%发出报警
  • HOME分区使用量超过95%发出报警
CPU利用率
  • 持续3分钟CPU_IDLE<5%发出报警
内存利用率
  • 持续3分钟MEM_USED_PERCENT>95%发出报警
网卡IO
  • 持续3分钟NET_MAX_NIC_INOUT_PERCENT>95%发出报警
机器僵死
  • 持续3分钟机器状态‘HOST_UNREACHABLE’发出报警
  • 持续3分钟机器状态'HOST_ZOMBIE'发出报警
磁盘IO
  • CPU_WAIT_IO>50发出报警

系统inode利用率

  • 超过90%一个周期内(10s)立即告警

实例层监控(application instance)

监控单个实例是否正常运行:分为进程资源类,程序性能类,程序功能类,状态类

  • 进程资源类: 进程的CPU,内存,网络连接数是否超限,出core
  • 程序性能类:程序的平响异常,pv异常(超过压测的实例极限值)
  • 功能类:语义异常,pvlost异常,超时数,wf数,error数,下游依赖的异常
  • 状态类:端口异常
类型类别监控项是否强制

采集项命名

最低要求
实例监控

进程类

10s

进程存活监控

bin文件名字

 

  • 持续3分钟进程数/线程数<=0发出报警
  • 如果服务实例数足够冗余,允许设置异常到达一定比例才发出报警
core自动生成
  • 一个周期内检测core >0 发出告警
进程CPU监控自动生成
  • 物理机:持续3分钟超过实例的CPU限制的90%(程序限制了进程数比机器核数小,整机CPU还有空余,但是程序的进程数限制智能占用N核)发出报警
  • 容器:持续3分钟超过实例的CPU限制的90%发出报警
进程内存监控自动生成
  • 物理机:持续3分钟超过实例的内存限制的90%发出报警
  • 容器:持续3分钟超过实例的内存限制的90%发出报警
进程网络句柄数监控自动生成
  • 物理机/容器:持续3分钟超过实例的网络句柄数限制发出报警
    网络句柄数告警阈值可以通过观察常态的均值,在异常时往往会突增较大

性能类

 

 

pv

总pv:pv

分功能的:xxx_pv。比如入口集群里公交的pv:bus_pv

  • 持续3分钟qps超过警戒阈值发出报警
  • 警戒阈值根据服务压测数据确定,可让QA同学提供
  • 无特殊需求,不配置pv过低报警
平均响应时间

总响应时间:cost

分功能的 :xxx_cost。比如入口集群里公交功能的cost:bus_cost

  • 平均响应时间指标默认只监控,不设置报警
  • 警戒阈值可以观察历史趋势决定
功能类

 

 

超时

总超时:timeout

分功能的:xxx_gt_xxs

  • 持续3分钟平均响应时间超过警戒阈值报警
  • 警戒阈值可以观察历史趋势决定

异常日志

总wf监控:wf

总fatal/error:fatal/error

细分wf:xxx_wf。比如连接下游公交的wf:bus_wf

细分fatal/error:xxx_fatal/xxx_error。比如连接下游公交的fatal/error:bus_fatal/bus_error

  • 持续3分钟warning/fatal/error日志滚动条数超过警戒阈值发出报警
errno监控

errno_xxx

比如errno 2:errno_2
  • 可以通过设定errno比率高警戒阈值来设置报警,比例通过Noah自定义计算配置。
HTTP状态码webserver服务强制

总:200,3xx,4xx,5xx

分功能:xxx_4xx。比如入口集群里公交的4xx:bus_4xx

  • 持续3分钟5XX请求数超过警戒阈值,发出报警
  • 持续3分钟4XX请求数超过警戒阈值,发出报警
  • 警戒阈值可以观察历史趋势决定

依赖服务

异常监控

连接

  • db类服务(mysql/redis/mongodb)
  • 消息推送类服务(nmq/kafka)
  • 第三方调用(passport)

服务强制

总mysql wf:

mysql_wf

总mysql fatal:mysql_fatal

其它子类在添加一个单词,比如模块A mysql异常:A_mysql_wf

  • 对于依赖服务连接异常/读写超时/返回数据异常等情况,必须在warning日志中打出
  • 通过设定异常出现次数来设置报警
  • 警戒阈值可以观察历史趋势决定
pvlost

总pvlost:pvlost

分功能的:xxx_pvlost。比如入口集群里公交的pvlost:bus_pvlost

  • 每个模块都必须定义自己的pvlost(可以从访问日志里把超时和异常匹配出来)
  • 通过自定义计算配置pvlost/pv的比例值,1. 比例值超过警戒值并且,2.pv大于阈值时(避免无流量时的抖动),发出告警
  • 警戒阈值可以观察历史趋势决定
端口语义有http接口的强制

简短描述

比如导航:multinav

  • 建议端口服务添加实例语义,反映实例是否工作正常。
  • noah不支持的协议,可以采用自行的语义监控脚本实现
状态类端口监控有端口的服务强制

静态端口:端口号_port。比如8888端口:8888_port

动态端口:main_port

  • 持续3分钟端口连接拒绝/连接超时/端口不存在,发出报警

业务层监控(business logic)

监控业务的整体情况,反应业务当前是否正常,单个机器或者实例的异常并不一定会影响业务整体的可用性(上游的负载均衡或者重试策略),所以业务层的整体监控在判断业务告警的影响范围时尤其重要,参考《Google SRE》有如下四大黄金指标:

  • 流量监控:业务整体流量的突增突降
  • 容量监控:业务整体流量是否超过集群的阈值
  • 可用性监控:业务整体可用性是否有突降(可以区分核心与非核心)
  • 平响监控:业务整体的平响是否上升

网络监控

依据用户访问我们服务中间所有经过的网络链路,分为三部分:外网-》接入层-》内网

  • 外网:指运营商网络,用户客户端发出请求后先经过运营商的网络才能到百度的接入层
  • 接入层:指域名的各个vip
  • 内网:各个idc的连通性

外网监控

  • 运营商联通性:联通 移动 铁通(pc 无线) 等运营商的用户访问服务端的连通性

接入层监控

  • vip流量:服务入口ip的流量 
  • 域名联通性:域名是否可以正确解析并访问
  • dns域名解析正确性:各个地域核心域名的dns解析正确性
  • cdn:CDN的图片缓存命中率是否符合预期

内网监控

  • 网络连通性:机房间网络连通性 交换机的网络连通性
  • 网络带宽容量:机房带宽容量是否拥塞
  • 交换机上联带宽打满 :底层交换机的上联带宽拥塞情况(网络敏感服务关注)

客户端监控

原理 端监控指从客户端的角度对稳定性, 用户体验等指标进行监控. 目前监控手段主要有两种:

  • 日志回传, 通过某种方式将客户端的信息回传到后端服务. 监控方式主要是: 端上行为> 行为编码/加密->后端接口->后端服务日志.
    • NA:NA端目前采用离线日志回传的方式监控, 具体方式为: 客户端通过js函数addLog(), 记录日志在本地存储, 日志组件择时(延迟3-30秒)将本地存储中的日志加密上传至后端lbslogger服务的接口, 通过lbslogger服务的日志记录端上信息.对页面错误率的统计和对页面打开性能的统计依赖业务方对框架接口的正常调用
      • 页面加载速度
      • 页面加载成功率
      • 页面加载内容正确性
      • app crash率
    • PC/WAP端监控采用js脚本调用后端服务的方式, 目前主要覆盖以下几类异常:
      • 页面JS报错
      • 页面发送请求报错
      • 页面操作触发报错.
  • 请求模拟, 通过模拟用户的实际请求监控线上服务可用性.

results matching ""

    No results matching ""