监控系统的设计指导与框架模型
监控设计指导
为了能够清楚意识到任何微小的延迟都可能预示着明天的局部停机或者系统瘫痪，遵循通用监控系统设计的指导思想，需要进行对业务系统的划分：
面向IaaS平台：包括但不限于硬件底层、操作系统主机、数据库、网络等;
面向PaaS平台：如SOA公共框架(SOA框架、Dubbo服务等)、公共组件(缓存Redis组件、消息队列RabbitMQ组件等)，公共服务子系统或公共服务平台等;
面向SAAS服务：如提供业务服务的HTTP、API、SDK、APP、SOCKET等;
遵循分层的设计原则，企业级监控系统的采集周期(频次)必须能够细化到秒级甚至毫秒级别，监控数据必须完整覆盖天、周、月、年的单位，历史监控数据必须完整存储超过3年以上的时间，这也是对重要监控系统最基本的需求。其中，所设计的监控系统要面向的目标对象(Goal Object)必须能够准确反映出可用性状况、性能瓶颈指标、对外提供服务的SLA指标(ART&EST)等，如果是面向应用型监控系统，不仅仅能够完整的显示出应用中间件或容器的JVM等各类指标，包括但不限于GRP:GlobalRequestProcessor，BusyThread，JCA:JavaConnectionAvailable，MaxReuqestTime，AverageResponeTime等)，而且可以捕捉到WebServer在运行过程中，应用系统中各方法类的性能开销状态，出现故障如果可以进行做追述和定位的时候，还能细化到开销方法的全栈追踪到每个数值，那这样的业务应用监控架构的设计就非常的完整，即通常我们所描述的监控系统的颗粒细度以及能够对重要的系统、业务、安全等指标进入预测分析。
图二：通用监控系统设计指导思想
企业监控框架
对于企业内部趋向于成熟的监控框架通常会来行业通用的结构来部署，这个结构需要将监控、分析与控制完成三位一体的无缝融合。本人的切身感受而言，一个好的监控架构不仅仅能够建设基于现状及未来发展提供有效的监控预警支撑，而且可以通过平台内实时或积累的系统或业务监测数据进行联动分析，找出问题的瓶颈点或未来的增长点，提供系统成长重要的数据决策支撑。
简单来说，监控系统框架分为如下三个部分：
统一监控：
1)基础层面的监控：通过选取开源或主流的监控系统，完成公共设施或系统运维方面的有效监控，如OpenNMS-Cacti聚焦网络层面; Zabbix/Hyerpic HQ聚焦IaaS公共层面;监控宝聚焦网站、API等。无论何种监控系统只是一种实现系统生命周期的有效运维工具，对工具本身的热爱及对工具所涉及的技术选型最好的依据主要是能够融会贯通，举一反三。因为没有任何一款监控工具都适用于所有公司的监控需求，基于量体裁衣以及在主流被广泛使用的系统，同时兼顾了为日后统一监控中心的数据融合所准备的，能够通过DevOps结合的监控系统才是最适合自己的。
2)有效的应用性能监控：除了WebServer的各层基础运行指标，因代码BUG或者程序设计不当所引发的各种级别故障越来越多，对于企业来讲，业务代码的变更需经过严格的覆盖测试，甚至会在对外发布后进行全回归覆盖测试及在必要的时候进行性能压力测试，但漏网之鱼依然存在，而且企业通常很难做到7*24小时的实时业务性能检测分析，特别是在多业务复用的情况下，具体引发的问题根源无法在短时间内被快速定位和追踪到，这也是过往业务监控的一个短板，如何准确定位到业务代码级别的故障和异常，捕捉的信息能够直接为开发工程师提供第一手的信息反馈，确保业务高峰来临前能够被准确的发现修复，我将在下文通过透视宝的实践操作来加深这方面的介绍。
3)统一的业务日志平台：ELK(Elastic+Logfluent+Kibana)已然成为行业的标杆或首选，尽管市面上有很多主流的商业化产品，但对本人而言，更加青睐自身DevOps研发建设出一套大数据如日志监控系统，因为这也是作为一家互联网科技公司的技术标配，这样不仅能够个性化定制和配置，还能无缝对接集团或公司业务的特殊监控诉求。
4)开放的API监控：能够完成如业务API的有效性监控，做到接口数据相关的故障分析，实现对系统的弹性预测、耗损/过期分析、颗粒细度的定位等。
