Devops下的分布式监控⽅案
1基础监控的设计需求
现在devops，云计算，微服务，容器，⼤数据等理念正在逐步落地和⼤⼒发展，企业的服务器越来越多，架构越来越复杂，相应的应⽤运⾏基础环境越来越多样化，服务越来越微化，带来的监控压⼒也越来越⼤；
如何在错综复杂的监控源⾥⾯，到他们的类⽐关系，在其中⼀个监控源发送告警的时候，就可以快速定位并且提前知晓可能会产⽣的“蝴蝶效应”呢？
监控采集器种类繁多，要⾃定义的应⽤监控根据企业⾃⾝的需求也变成各种特殊需求，如何保证统⼀视⾓，采集到我们想要的数据？监控的数据量越来越⼤，如何保证所有数据的采集，发送，存储和展⽰持续稳定，并保持⾼效运⾏？
数据采集到了，也采集全了，如何让公司的各个部门的⼈员能够利⽤这些数据做⼀些有意义的事情呢？
需求调研
⼀个⾜够强⼤的监控平台应当具备以下能⼒：
1.    采集器⾼度抽象模型，兼容所有扩展指标；
2.    数据分析引擎⾜够强⼤，在海量的数据中得到以秒为最⼩集合单位的数据加⼯，强⼤的分析引擎才能处理，并且迅速输出直观的结果；
3.    数据展⽰报表功能维度多，不仅可以展⽰饼图，折线，仪表盘等，并且⽀持各种聚合计算公式以及正则
4.    多采集器，多存储器的混合使⽤，能够在复杂的监控中取长补短；
5.    多告警机制：邮件，短信，，语⾳，结合不同业务场景选择不同的报警机制；
6.    全路径跟踪：⼀个问题的分析牵扯到数个系统，数⼗个接⼝，能够根据中间任意⼀个节点的问题暴露，进⾏全路径的跟踪；
在设计⼀套完整的之前需要考量以下⼏个⽅⾯：
a.    海量数据
海量数据的来源–从数据源的层次上来分，⼤致可以分为以下⼏层：业务应⽤层，中间件层，基础设施层；
业务应⽤层主要包括应⽤软件（例如tomcat,nginx等），企业总线（dobble等），内部应⽤系统（ovirt,kvm,git）；
中间件层主要包括数据库（mysql,mongodb等），缓存（redis），消息队列（kafka,zookeeper等），
操作系统层主要包括服务器基础指标（cpu，内存，磁盘，⽹络等），服务器系统⽇志等；
基础设施层主要包括物理机，远程控制卡IPMI，⽹络设备系统，底层存储系统等；
b.  兼容协议
上⾯说了数据源的多样性，数据的采集任务⾃然压⼒⼤，采⽤的协议也会⽐较多，从采集的指标上可以分为以下⼏个⽅⾯:
应⽤监控指标：例如需要监控haproxy，就需要采集吞吐量，并发数，响应时间，等待数，资源请求队列等；
业务监控指标：例如我们需要监控平台运营指标，就需要采集订单量，请求量，⽤户数，订单耗时，请求耗时等；
系统监控指标：例如我们需要监控1个普通的虚拟服务器，就需要采集cpu负载，内存，磁盘IO状态，⽹络IO状态，tcp连接数等；
⽇志监控指标：例如我们需要监控系统⽇志，就需要采集/var/log下所有⽇志，例如我们需要监控应⽤服务⽇志，就需要采集应⽤的logs⽂件夹⽇志实时输出；
物理机监控指标：例如我们需要监控1台常规的虚拟化物理机，就需要采集它的IPMI指标，包括电源，电流，风扇转速，温度，湿度，通风情况等；
度，通风情况等；
为了能够达到所有采集指标的完整性，我们采⽤的协议肯定需要多种，例如agent，ssh，snmp，http，socket，每⼀种协议可以⽀持不同程度的采集内容和采集程度，就⽐如agent⼀项，特殊的采集需要所使⽤的语⾔可能会不同，包括go,java,Python,shell等，来⽀持采集器的完整采集。
c.    易⽤性
对于监控平台的维护者来说，所需要的专业度较⾼，但是最终给⽤户的平台，功能完整简单易⽤的特性不能少，⽤户的学习成本越低，说明平台的成熟度越⾼，反之亦然；因此对于后台的成熟度和前台的UI改造，对于平台设计者来说，是需要考量的⼀个较⼤因素；
d.  强⼤售后
⼀般企业内部使⽤都会采⽤开源的⽅案来进⾏⼆次开发或者整合，因此选择的每个开源组件的成熟度以及开发团队的⽀撑需要进⾏考量，尽可能的选择社区活跃度⾼的开源组件，因为道理很简单—众的眼睛是雪亮的。
2基础监控的架构组成
2.1数据库选型
2.1.1时间序列数据库选型
什么是，上⾯的解释是—⽤来存储时序列（time-series）数据并且以时间time（点point或者标签tags）建⽴索引的软件。
其实做互联⽹的想到时序数据库，不就是运维在做监控才使⽤的吗，确实，时序数据库在最近⼏年特别流⾏，如何定义时序数据库呢；
时序数据库可以定义如下：
a.    可以唯⼀标识的序列名称（⽐如cpu.load.1）及meta-data;
b.    对应的数据点{timestamp,value}
c.      数据结构简单，数据量⼤
因此从定义上来看，时序数据库可以理解为某⼀度量指标在某⼀时间的值，没有复杂的结构（像MySQL当中的嵌套，层次等）和关系（关联，主外键等）。
时序数据库的特点：
a.    写多于读，95%的操作在于写操作；
b.    实时写⼊，追加写⼊；
c.      顺序读取，时间范围⼤；
如何选择⼀款适合的时序数据库呢，从以下⼏个⽅⾯去考虑：
a.    读写性能，特别是写⼊性能，因此时序数据库的硬件依赖最好使⽤SSD；
b.    存储引擎，不同的⽅案构建的引擎，它的读写性能，集扩展，运维复杂度可能会有百倍的差别；
c.      Api和查询语⾔，如果能⽀持传统的sql查询语句当然是最酷的了；
现在我们来看时序界⽬前的排名，内容取⾃
：项⽬创建于2013年，使⽤golang语⾔编写，也算是go语⾔中⽐较著名的⼀个，在很多golang的沙龙或者⽂章中基本上都以influxdb为标杆来做介绍，它的主要特点包括以下：
influxdb为标杆来做介绍，它的主要特点包括以下：
a.    ⽆结构数据，可以是任意数量的列；
b.    强⼤的TSM引擎
c.      集成数据采集，存储，可视化功能；’
d.    ⾼压缩⽐算法，⽀持连续降权存储，存储策略；
Opentsdb：项⽬创建于2010年，使⽤java语⾔编写，它的特点与influxdb类似，都是⽆结果，⽀持tag维度的概念，与influx不同的特性在于：
a.    后端存储使⽤HBase，兼容cassandra和bigtable，部署没有influxdb⽅便
b.    主要以数据存储和查询为主，本⾝不集成内置的采集器和告警组件等；
c.      天⽣⽀持集模式，⽐influxdb商业化才⽀持集，这点⽐较好；
d.    性能⽅⾯⽐influxdb稍差；
Influxdb与opentsdb的性能测试本⼈亲⾃测试，以下为测试结果：
测试环境：ovirt虚拟机—4vcpu,8G内存
测试取样：10台服务器的cpu采样数据；
Tags:3个，rack,company,department
Field:20个类型，包括cpu空闲，cpu⽤户使⽤，cpu使⽤时间
Time：每秒采样1次，采样24⼩时；
Value：系统随机写⼊
合计数据量为：10*3*24*3600*24=5200万指标
leveldb使用
每秒并发数：720
测试结果：
资源使⽤：influxdb:CPU维持在15%左右，opentsdb  CPU维持在80%左右；
查询：查询1个⼩时内(group by time 1s)cpu⽤户使⽤百分⽐的其中3台服务器展⽰耗时：
Influxdb:0.3s
opentsdb:2.5s
在资源和性能查询上，两个都使⽤最新版本，可以看到相差度还是很⾼的，但是influxdb在集⽅⾯暂时不开源，只能使⽤多复制的⽅案代替；
Prometheus：项⽬创建于2012年，是⼀个集成采集，存储，分析，告警的开源平台，最近2年也很流⾏，跟influxdb,opentsdb相⽐，promethueus的特点如下；
多维数据模型（由metric名称和⼀组key/value组成）
可以通过中间⽹关进⾏时序数据推送
⾃带可视化和仪表盘⽀持，集成告警插件
缺点是安装部署复杂，学习成本较⾼；
Graphite：项⽬创建于2006年，是最早的时序数据，也是被应⽤最早的时序数据库，我在13年的时候曾经使⽤过1年多，⾄今也有很多传统⼤型企业在沿⽤这个分⽀，社区活跃度也较⼤；
与其他时序数据库相⽐，它的特点如下；
根据请求对数据进⾏可视化画图
存储数值型序列数据，容易扩展
提供强⼤的web api，适合做接⼝开发
它的本⾝不带数据采集，主要由3个模块组成：
Whisper：创建更新RRD⽂件
Carbon：接收数据并且写⼊到⽂件
Graphite-web:⽤于读取和展⽰web界⾯
最强引擎influxdb的发展史：
Influxdata公司将⽬前它们的数据引擎技术称之为TSM，其实看起来还是⾮常类似于LSM树，因为它有⼀个预写⽇志和只读数据⽂件的集合，这些⽂件在定义上类似于LSM的sstables.
Influxdb在最初发⾏时的⼏个版本中使⽤过多个存储引擎，包括levelDB,RocksDB,HyperlevelDB和LMDB，这个⼀直沿⽤到v0.9版本之前，
LevelDB最⼤的特点就是写⼊吞吐量很⼤和内置压缩⽐⾼，它是google为构建LSM Tree开源项⽬⽽产⽣的，
但是levelDB也有致命的弱点，它不⽀持热备份，如果想要做备份需要先停⽌服务，这个是⽣产环境所不能接受的，后来为了解决这个这个问题，使⽤了RoctsDB和hyperlevelDB解决了这个热备份的问题，但是还有⼀个问题得不到解决，就是⾃动管理数据保留的机制，如果没有这个机制，⽤户就需要去⼿动删除过期的数据，对于⼀天达到数亿指标的数据库来说，⼀次删除30天左右的数据这个过程是很痛苦的，这个我们之前就把这个坑踩的很深，⽽且确实很痛苦；
后来在0.9版本之后，influx公司采⽤了数据分⽚（shard）的功能，也就是说将连续时间的数据放置成⼀个分⽚，如果需要删除这个数据，只需要删除这⼀个⽂件即可，⽽且⽀持⽤户⾃定义，⽐如我设置
为最⼩分⽚单位为⼀个⼩时，那么半年之后，这个分⽚数量将达到系统的⽂件句柄数，这个坑我们也踩过，表现的结果就是当你的展⽰器想要查询最近半年的数据并⽣成折线图的时候，数据库崩溃了；
再后来influx公司决定将引擎迁移到BoltDB，⼀个由C语⾔编写的B+ Tree数据库，BoltDB数据库使⽤单个⽂件作为数据库，解决了热备问题，⽂件限制问题，系统稳定问题之后，⼜回到了原来的⼤吞吐写⼊问题，因为使⽤BoltDB，在单个⽂件达到⼏个G之后，写⼊操作将开始增加IOPS，关于为什么会出现这样的问题我们可以在线下去仔细分析它的原理，在这⾥就不赘述。当时我们为了解决这个问题，开始使⽤最好的SSD磁盘并且使⽤Raid10来解决IOPS慢的问题；
在15年9⽉份研发中⼼的⼀个⼯程师可能是灵光⼀现，它计划在BoltDB前⾯写⼀个写钱记录（WAL），这样来减少到键空间的随机插⼊数量，然后来缓存很多个彼此相邻的写⼊，然后在达到⼀定值的时候去熟悉它们，经过测试发现，使⽤WAL的性能实在是太好了，导致使⽤索引的速度都没有它快，由此⼀个类似于LSM Tree的TSM就形成了；
为了让⼤家能够对这个TSM更加深⼊的了解，我简单介绍下这⽅⾯的知识；
我们都知道磁盘的随机读写和顺序读写的写⼊速度根本不是⼀个量级，两者相差⾄少3个数量级（也就是1000倍），我们想要让⼀个数据达到⾮常好的性能，最简单是设计⽅式就是避免随机读写，尽量使⽤顺序读写；
如何尽量的使⽤顺序读写，⼀个好的⽅式就是将写⼊之前的数据⾮常简单的加⼊到⽂件中（也就是我们所说的sstables），因为⽂件是有序的，所以以后查也很快，⽽且这些值永远不会被更新，新的更新操作只会顺序的写到新的⽂件中，同时，当⽂件更新操作到达⼀定量时，他们会被写⼊到内存缓存，使⽤memtable来保持树结构的有序，当查询数据时使⽤的memtables中的数据，因此查询性能并未受影响，如果memtables中没有，它会从sstable重新去加载，同时，memtable会通过写WAL的⽅式写⼊到磁盘防⽌数据丢失，当memtable数据达到⼀定值时，系统会将内存中的数据与缓存中的数据进⾏合并持久化的写⼊到磁盘中，因为sstables没有被改变，只是简单的⽣成新的⽂件，因此系统将使⽤顺序读写的⽅式写⼊到磁盘中，具体的过程可以见下图：
插话：在此基础之上，有什么物理优化⽅式可以让性能提⾼⼀倍？
⽽influxda的最新版本在此基础之上做了内核的优化，使得在同等的基础之上提升了50%以上的读写性能，因此相较于B+
Tree，influx可以达到50倍左右的压缩率，100倍的写⼊速度，这也是为什么influxdb可以每秒百万指标的性能极限；
2.1.2NoSQL数据库选型
什么是Nosql数据库，百度百科上解释：泛指⾮关系型数据库；
传统关系型数据库在应付web2.0⽹站，特别是超⼤规模和⾼并发的sns类型的纯动态⽹站显得不⾜，凸显出了难以克服的问题，⽽⾮关系型数据库解决了这个痛点；
NoSQL的特点：
1.    不需要预定义模式，包括数据模式，表结构等。数据中的每条记录都可能有不同的属性和格式；
2.    弹性可扩展，可以动态增加或者删除节点，不需要停机维护，数据可以⾃动迁移；
3.    分区块存储，数据进⾏分区，分散在多个节点上⾯，并且通过内置传送⽅式进⾏分区复制，提⾼并⾏性能且保障单点失效问题；
4.    异步复制，基于⽇志的异步复制模式，
NoSQL的分类：
A．键值存储数据库
这⼀类数据库主要会使⽤到⼀个哈希表，这个表中有⼀个特定的键和⼀个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。这类数据库主要⽤于内容缓存，⽇志系统，处理⼤量数据的⾼负载访问和查询；
B．列存储数据库
这部分数据库通常是⽤来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。这类数据库主要⽤于分布式的⽂件系统。
C．⽂档性数据库
⽂档型数据库的灵感是来⾃于Lotus Notes办公软件的，⽽且它同第⼀种键值存储相类似。该类型的数据模型是版本化的⽂档，半结构化的⽂档以特定的格式存储。这列数据库主要⽤于web应⽤，查询性能不⾼的web应⽤；
D．    图形数据库
图形结构的数据库同其他⾏列以及刚性结构的SQL数据库不同，它是使⽤灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。