本文主要阐述监控系统的发展历程、监控系统的原理,以及监控系统的项目实践,目的是让大家全面了解监控系统。
表1 部分常见的监控指标
本地存储。使用本地磁盘,基于文件的方式存储。
使用时序数据库进行数据存储,如古老的环状数据库(Round Robin Database, RRD)等。近年来,随着时序数据技术的不断发展,出现了比较成熟的时序数据库,如OpenTSDB(底层存储基于HBase)、Graphite、InfluxDB、Prometheus等,与直接使用文件的存储方式相比,这些时序数据库更加高效。目前时序数据库领域相关技术的发展速度较快,应用的生态也逐步完善,基于时序数据库的监控系统会逐渐增多。从长远角度来看,使用时序数据库存储监控数据,是必然的发展趋势。
使用数据库管理系统(DatabaseManagement System)进行数据存储,如常见的MySQL、Oracle、SQL Server等。使用这种数据库来存储监控数据,当数据量达到一定规模时,其读/写效率均会显著下降,数据库的压力比较大,通常优化方案思路有3种,一是减少数据的存储量;二是优化数据库本身,调整配置参数,优化运行环境;三是使用分布式数据库和数据库集群技术方案。故使用DBMS作为数据存储的监控系统,对数据库本身的掌握程度决定了监控系统能否在大规模环境下良好工作。
使用NoSQL数据库进行数据存储。NoSQL相对于DBMS这种传统的数据库有着一些天然的优势,单机的QPS通常较高。但NoSQL本身并不是为监控系统设计的,在数据结构存储方面存在一些缺陷,故直接采用NoSQL作为监控数据存储的监控系统产品较少。
使用列存储数据库进行数据存储。列存储数据库由于其设计之初专为大数据而有所考虑,故无须担心其存储容量,底层均有良好的解决方案。但由于其部署、运维均较为复杂,故一般监控系统也不会常采用这种技术作为数据库存储。这方面的数据库代表为HBase。
使用全文搜索引擎数据库进行监控数据存储。这方面的代表是Elasticsearch,其作为
分布式架构是首要考虑因素。要求系统架构具备分布式的设计,原则是将中心节点压力分散在各边缘节点上,使其尽可能监控更多的设备。
数据存储扩展的问题。节点数量增加到一定规模后,给监控数据的存储带来了十分严峻的挑战,数据存储扩展的问题是整个监控系统能否正常工作的前提条件。
高可用性和健壮性、稳定可靠的系统架构、冗余的灾备,是大型监控系统必备条件。
提供API的能力,易于与第三方集成。在大型环境中,一个孤立的监控系统会给其他业务系统造成很大的麻烦,通常需要花费更多的精力进行改造,使其为其他系统提供所需的数据。
具备自动化功能。自动化是解放繁重的体力劳动最有效的方式,未来的运维一定更智能、更偏向于业务,以业务为核心,而不是仅仅解决系统的底层问题。
日志流监控,监控应用设备和应用软件的日志,并从日志中提取相关的指标进行分析,其实现方式有开源的套件ELK等。
可信的数据源,为周边系统提供支撑数据。
梳理现有环境——知己知彼:在接手监控系统构建项目之前,需要梳理现有的环境,从基础设施、应用系统、日志分析、应用性能等多个维度进行分析。
确定监控目标——愿景宏大:确定监控系统的目标,是监控网络设备、服务器还是应用,以便采取相应的策略。
项目规划蓝图——循序渐进:在确定目标后,需要对整个系统进行详细规划,可以对目标进行一个明确的规划,比如什么时候取得什么样的成绩,交付什么样的功能,最终建立一个什么样的监控系统。
功能逐步深入——精益求精:采用精益的思维模式,先从小的功能做起,解决当前环境中的主要矛盾,然后逐步扩大环境,从本团队做起,再推广到其他团队,最后推广至全公司。
吸取百家之长——资源整合:与其他系统进行整合,比如与CMDB整合、与ITSM服务流程整合、与自动化运维工具整合、与代码发布整合。
不断总结成长——取长补短:通过对环境的不断验证,总结过去的经验,不断简化整个监控流程,并定制出符合实际需求的监控功能。
联系客服