本文内容:创业型公司如何快速搭建可扩展,可落地的立体化监控平台

一、需求缘起

创业型公司有系统监控么?来看两个case:

case 1:CXO大群内贴了一张“用户微信投诉”的截图

(1)CXO大群内贴了一张“用户微信投诉”的截图

(2)技术反馈“正在跟进”

(3)10分钟之后,CXO询问进度,技术反馈“正在解决”

(4)60分钟之后,CXO说怎么还没有解决,技术反馈“正在解决”

实际上,可能还没有找到问题在哪里。

case 2:用户通过客服反馈功能不可用

(1)用户反馈到客服,不能下单

(2)客服 -> 产品 -> 测试 -> 技术

(3)技术:站点层 -> 服务层1 -> 服务层2 -> 数据层

可能2个小时过去了,技术还没有定位到问题在哪一层。

存在的问题:技术被动

(1)出了问题成为最后知晓者,用户受影响周期长

(2)查找问题路径长,定位和修复问题时间久,用户受影响周期长

所有系统负责人能快速回答这两个问题么

(1)所负责的系统现在运行是否正常

(2)如果不正常,问题大致在哪里

今天的主题是“创业型公司如何快速解决这两个问题”

二、解决方案:立体化监控

怎么知道系统运行是否正常?

回答:监控

什么是立体化监控?

回答:多维度监控

监控维度有哪些?

回答:(1)机器、操作系统层面

(2)进程、端口层面

(3)日志层面

(4)接口层面

(5)用户层面

三、创业型公司如何快速实现立体化监控

【如可快速实现机器、操作系统级别的监控?】

回答:zabbix,用过的都说好

不足:CPU,LOAD,内存,网络,磁盘异常说明系统一定异常,但这些参数正常并不能说明系统正常,例如:进程挂了,端口挂了,通过这些参数就检测不到

【如何快速实现进程、端口级别的监控?】

两类实现思路:分发型监控 + 汇总型监控

分发型监控

命令由监控中心分发到各个被监控机器的agent上,agent执行监控,实现要点:

(1)监控中心要实现扩展性较强的配置,方便扩展“监控哪个ip上哪个进程或者端口的存活性”

(2)对于进程与端口的监控,甚至无需agent来执行,直接使用带超时的端口连接或者telnet就能快速实现

汇总型监控


命令由agent在各台机器上执行,将结果汇总上报到监控中心接口,实现要点:

(1)agent必须能够快速部署到所有的机器

(2)agent如何快速从监控中心获取需要监控的进程和端口,必须要保证扩展性

(3)agent如何快速的执行本地检测,例如:进程监控用ps?端口监控用netstat?

进程与端口监控的不足:进程与端口异常说明系统一定异常,但它们正常并不能说明系统正常,例如:进程和端口都在,但ERROR日志狂刷

【如何快速实现日志的监控?】

两类实现思路:ERROR日志的监控 + 日志关键字监控

这两类实现又有“日志各机器单独监控”与“日志汇总到中心监控”两种方法,暂时不展开。

ERROR日志监控快速实施要点

(1)日志分级规范非常重要,需要进行日志按照级别分离,ERROR日志单独拿出来一个文件是最好的

(2)日志切分规范也很重要,建议按照小时切分

(3)1和2的目的,是为了保证扩展性,并减少扫描的日志量,做到了1和2之后,例如用一个crontab,设定一定阈值,每分钟wc -l ERROR文件,超过阈值就可以报警

(4)简易的配置与良好的扩展性,需要支持方面的增加“某一台机器”“某一个路径”“ERROR每分钟超过多少”的报警配置

日志关键字监控

和ERROR日志监控的思路是类似的,当日志中出现一些事先设定的关键字(或者出现频率超过一定阈值),例如exception、timeout就报警,这种报警能够报出比ERROR更精准的系统异常

ERROR日志监控与日志关键字监控的不足:ERROR日志超过阈值说明系统一定异常,不超过阈值并不能说明系统正常,例如:进程死锁,此时并不会刷ERROR日志

【如何快速实现接口的监控】

有两种常见的快速实现思路:统一keepalive接口 + 接口处理时间统一上报

统一keepalive接口快速实施要点

(1)在站点框架与服务框架层面统一实现一个keepalive接口

(2)监控中心统一调用站点、服务的keepalive接口

(3)简易的配置与良好的扩展性

接口处理时间统一上报快速实施要点

(1)在站点框架和服务框架层面统一实现处理时间的收集

(2)由于并发量很大,需要在本地进行初步汇总

(3)或者使用upd上报

(4)时间上报需要异步,不要因为这个而增加业务处理时间

(5)良好的配置与扩展性,监控中心统一配置报警(绝对时间,或者处理时间环比增长报警)

统一keepalive接口与接口处理时间统一上报的不足:上报异常说明系统一定异常,上报正常不能说明系统正常,例如:某个服务后端的数据库挂了,此时这个服务的keepalive接口返回其实是正常的,接口的处理时间可能会比平常要快很多(原来数据库还要执行一个sql,现在连接都拿不到,立马就返回了)

【到底什么样的监控,才能说明系统是正常的呢?】

郁闷了,上述多个维度的监控,都不能完全说明系统正常,怎么办?

回答:只有站在调用者的角度,对被调用方的可用性可靠性的评判才是最准确的

思路:模拟调用方调用站点、服务,来对站点和服务进行监控

通用接口监控分层架构图


如上图所示,实现“模拟调用方对站点和服务进行监控”的分层架构

被监控层:被监控的站点和服务,例如A,B,C

发包层:模拟站点和服务调用方的发包器,例如A-sender,B-sender,C-sender

监控中心:调度发包层对站点和服务进行监控,对结果进行管理,对阈值进行判断与实施报警

监控中心又分为这么几个部分:

(1)集群管理:每个被监控服务有哪些ip

(2)监控项管理:监控哪个服务、调度频率、防抖动配置、责任人

(3)责任人管理:责任人、邮箱、手机号、微信号

(4)调度中心:隔多长时间调度每个监控项

(5)发包层通信:获取发包层的监控结果与异常信息

监控流程,用伪代码描述吧:

for(每一个监控项里被监控的服务){ // 其实是并行执行的,并不是for

for(这个服务所对应集群里的每个ip){

调度发包层,对服务进行发包;

收集发包层的监控结果与异常信息

if(异常次数超过我们设定的阈值){

找到服务对应的责任人;

异常信息发短信;

发邮件;

发微信;

}

其他实践:

(1)一个服务提供的接口很多,可以选取最核心的接口进行发包监控

(2)写接口可能会对数据产生污染,建议选取读接口进行监控

(3)如果一定要对写接口进行监控,务必插入操作和删除操作要是成对进行的(还是会对业务数据统计产生污染)

(4)发包层的sender程序可以复用接口测试的代码

(5)发包器的结果校验要进行业务校验,例如一个http请求仅仅检查返回码是200是不够的,还要检测返回的html或者json的内容是更准确的

【什么样的监控,能决定凌晨收到报警而不起床处理呢?】

回答:用户视角的监控

“模拟调用方调用站点、服务,来对站点和服务进行监控”的方法,可以精确的判断有问题的是哪一个ip上的哪一个服务上的哪一个接口,理论上应该是粒度最细的监控了,为什么还需要用户视角的监控呢?

回答

(1)架构是做了可用性保证的,一个服务挂了,用户视角的监控没有报警,说明对用户没有影响,如果此时凌晨收到报警,也是不需要马上起床来处理的

(2)用户是在全国各地进行访问的,很有可能某个地域的网络出问题,此时只有在全国布点的用户视角监控才能发现

如何快速的实施用户视角的监控:

(1)复用接入层的接口监控,只是,不对每一个web-server的站点ip实施监控,而是对nginx反向代理层实施监控

(2)引入第三方监控

四、总结

创业型公司快速实施立体化多维度监控总结:

(1)机器、操作系统维度监控:zabbix

(2)进程、端口维度监控:分发型监控 + 汇总型监控

(3)错误日志与关键字维度监控

(4)keepalive接口与所有接口统一处理时间统一上报监控

(5)模拟调用方调用站点、服务,来对站点和服务进行监控

以上内容均来自微信公众号“架构师之路”胡剑老师的文章,欢迎关注。

创业公司快速搭建立体化监控之路(WOT2016)的更多相关文章

  1. Telegraf+InfluxDB+Grafana快速搭建实时监控系统 监控postgresql

    Telegraf+InfluxDB+Grafana快速搭建实时监控系统  监控postgresql

  2. docker-compose(grafana influxdb) + telegraf 快速搭建简单监控

     灵活实现方案:   1:     telegraf 为go 语言写得占用内存小 收集主机各项监控数据 定时写入 时序DB   influxdb ------------------------&qu ...

  3. ubuntu之路——day11.2 快速搭建系统并进行迭代、在不同的划分上进行训练和测试

    快速搭建系统并进行迭代 1.建立dev/test set,并确定你的目标 2.快速建立初始化的系统 3.使用前面提到的bias/variance分析和错误分析来进行模型优化和迭代 针对以上的过程,An ...

  4. koa2+koa-generator+mysql快速搭建nodejs服务器

    koa2+koa-generator+mysql快速搭建nodejs服务器 用koa的脚手架koa-generator可以快速生成项目骨架,可以用于发开或者测试接口 https://github.co ...

  5. WAMP Server助你在Windows上快速搭建PHP集成环境

    WAMP Server助你在Windows上快速搭建PHP集成环境 原文地址 我想只要爬过几天网的同学都会知道PHP吧,异次元的新版本就是基于PHP的WordPress程序制造出来的,还有国内绝大部分 ...

  6. [原创] zabbix学习之旅五:如何快速搭建一个报警系统

    通过之前的文章,我们已搭建好zabbix server.agent和mail客户端,现在万事俱备,只差在server的界面中进行相应配置,即可快速搭建一个报警系统.总的来说,快速搭建一个报警系统的顺序 ...

  7. 基于 Jenkins 快速搭建持续集成环境--转

    源地址:http://www.ibm.com/developerworks/cn/java/j-lo-jenkins/ 持续集成是一种软件开发实践,对于提高软件开发效率并保障软件开发质量提供了理论基础 ...

  8. Jenkins 快速搭建持续集成环境

    持续集成概述 什么是持续集成 随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题.尤其是近些年来,敏捷(Agile) 在软件工程领域 ...

  9. logstash+elasticsearch+kibana快速搭建日志平台

    使用logstash+elasticsearch+kibana快速搭建日志平台   日志的分析和监控在系统开发中占非常重要的地位,系统越复杂,日志的分析和监控就越重要,常见的需求有: 根据关键字查询日 ...

随机推荐

  1. mac下selenium+python环境搭建

    selenium2+python的环境搭建主要需要python和selenium 1.python mac下自带了python,可以查看版本.当然可以选择安装其它版本的python. 2.seleni ...

  2. 动态加载js css 插件

    简介 动态加载js,css在现在以及将来肯定是很重要的.目前来看前端代码编写的业务量已经远远超过后端编写的.随着对用户体验度逐渐增强,前端业务复杂,加载速度变得很慢很慢.为了解决这个问题,目前出现的两 ...

  3. ajax事件请求

    首先,ajax是什么? ajax是一种在无需重新加载整个网页的情况下,能够更新部分网页的技术. ajax是一种用于创建的快速动态网页的技术. 当async:true时,表示异步执行ajax代码:当as ...

  4. 在ASP.NET开发中一些单词的标准缩写

    有些词可能共用一些缩写.带星号的缩写或词来源于PeopleSoft标准. The following standard word abbreviations should be used in nam ...

  5. python基础-------函数(二)

    闭包函数与装饰器 一.闭包函数 闭包函数:函数内部定义函数,成为内部函数,该内部函数包含对外部作用域,而不是对全局作用域名字的引用那么该内部函数成为闭包函数 name='alex' # def fun ...

  6. SSM所需的jar

    首先去找struts的. http://struts.apache.org/ 下载最新的struts 2.3.7. http://www.springsource.org/spring-framewo ...

  7. Android Task 任务

    关于Android中的组件和应用,之前涉及,大都是静态的概念.而当一个应用运行起来,就难免会需要关心进程.线程这样的概念.在Android中,组件的动态运行,有一个最与众不同的概念,就是Task,翻译 ...

  8. 【架构研习】欲善其事先利其器-Robot Framework实战演练之框架的选择

    (原创文章,转载请注明出处.) 之前有提到过,自己曾基于公司业务系统从无到有码过一套测试框架,但由于开发时的思想同时受限于公司业务及框架的适用性上,导致最终虽然框架可完美支持业务,但在易用性.兼容性及 ...

  9. alex python of day3

    集合 # author:"Jason lincoln" list_1={1,4,5,7,3,6,7,9} list_1=set(list_1) #把集合变成列表 去重复 list_ ...

  10. Kaggle实战之二分类问题

    0. 前言 1. MNIST 数据集 2. 二分类器 3. 效果评测 4. 多分类器与误差分析 5. Kaggle 实战 0. 前言 "尽管新技术新算法层出不穷,但是掌握好基础算法就能解决手 ...