您的位置:首页 > 运维架构

关于监控方案的一点想法供参考

2017-12-11 16:55 357 查看
Author:Skate

Time:2017/12/11

关于监控方案的一点想法供参考

 

 

1.监控目标:

 

监控的直接目标:及时、准确的发现潜在事件,并辅助运维人员处理生产事件,消除生产事件专家和高手与一线员工的区别;

监控的增值目标:通过高度的可视化展示提供整体的运行情况、业务监控服务、趋势分析

 

监控是值班运维的窗口,预警信息要能能告知我们哪个系统、哪个应用、哪个模块、哪个负责人、出了什么问题,可能是什么原因,建议如何应急。

监控还能将一些标准化程度很高的报警自动关闭,并告知值班人员监控做了什么,实现故障自愈。

 

 

2. 以人员角色多维度展示:

一线人员:看预警、看当天趋势,巡检、故障定位、应急处理等

二线人员:看性能趋势,分析数据

业务人员/管理层:看整体应用可用性(可以收关键业务的用户视觉报警,其他不需关心)

 

3.监控解决的问题:

发现问题:通过监控最快的发现问题

定位问题:复杂的架构环境下,辅助快速定位问题

应急解决问题:定位问题后,需要应急恢复,监控可以帮助人工或自动恢复

分析问题:建立各种模型、分析模型、可视化的展示分析数据

 

4.监控的内容总结:

基础监控:如服务器、OS等各方面的性能,包括:CPU、MEM、IO、宕机等

应用系统监控:从多种类型、多模块存活性,性能、系统运行逻辑进行监控

主要包括:

Ø  端口、服务的存活性,进程个数、进程重启状态、dump事件等;

Ø  方法监控,针对服务内部的方法(方法响应、次数、可用率等)进行监控

业务监控:从业务层面按业务进行全流程监控,对业务数据、业务功能进行监控,实时收集业务数据进行配置监控

 

基础监控、应用监控和业务监控错误可以说明系统有错误需要处理,但是如果都正常就不能说明系统是正常的,我们需要有用户视觉的角度来监控,

只有这个才是最正确的,比如下几种情况可以不用及时或半夜起来处理

 

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

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

 

实施用户视角的监控方法

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

(2)引入第三方监控

 

 

5.监控常见问题

误报:当有告警时,可以多次、多路径验证

漏报:可以多方位监控,多IDC分别独立部署监控系统,再加上第三方等来解决

多报;可以通过重定监控基线、汇总、聚合等方法,实现比较难

全业务流程监控手段不够丰富:可以通过日志,应用程序埋点、用户反馈来解决

 

 

6.监控数据的消费场景

监控数据可以用于资源的扩容建议、应用系统的运行情况了解等,也是运维自动化的纽带

 
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: