Devops下的分布式监控方案

2019独角兽企业重金招聘Python工程师标准>>>

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查询语句当然是最酷的了；

现在我们来看时序界目前的排名，内容取自

http://db-engines.com/en/ranking/time+series+dbms

 

Influxdb:项目创建于2013年，使用golang语言编写，也算是go语言中比较著名的一个，在很多golang的沙龙或者文章中基本上都以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万指标

每秒并发数：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数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。这类数据库主要用于社交网络，推荐系统，专注于构建关系图谱。

 

 

互动：常用的NoSQL有哪些类型？redis,mongodb,kafka,zookeeper,elasticsearch分别属于哪种类型的nosql数据库？

 

 

2.2采集器选型

2.2.1指标类采集器：

指标采集器的选型最初选用的是cadvisor，这个采集器是google公司为容器用户提供监控容器资源使用和性能特征而开发，后续也支持非容器类的指标采集，但仅限于常规采集，所能够支持的应用类型比较少，按照我们上面的监控平台设计原则，后面经过跟基础运维部沟通决定使用influxdata公司的Telegraf采集器代替cadvisor进行大部分的指标类采集器，下面简单介绍下telegraf采集器：

Telegraf是一个插件驱动的服务器代理软件，用于收集和报告各种指标。它的特点如下：

a.     使用go语言编写，占用内存极小；

b.     插件系统允许用户非常容易添加各种采集类型，对于没有集成的应用监控支持自定义监控api;

c.      市面上流行的应用软件和服务已经添加至系统代码中；

d.     输出到数据库支持多种类型，包括influx,kafka,graphite,opentsdb等常规时序数据库或者NoSQL数据库；

目前支持的监控类型有：

System(cpu,内存，磁盘，网络，内核等)

Docker，MySQL，haproxy，nginx，redis，kafka，elasticsearch，Ceph，tomcat，apache,php-fpm，http-json，http_response，IPMI_sensor，snmp，telnet，tcp_lister，mesos，ping，rabbitMQ，zookeeper，win_perf，sh服务等等；

业务应用类的指标使用自研agent上报指标到influxdb数据库中，agent在服务中进行埋点，后续支持业务型指标输出到数据库中；

日志类采集器：日志类采集器包括系统日志，应用日志，业务日志；

系统日志使用filebeat采集器将操作系统的日志和应用本身的日志输出到es集群，业务日志使用自研的agent采集器将业务本身的日志输出到kafka后，通过transfer写入到es集群中；

 

 

 

2.2.2展示器选型

收集到数据之后，我们如何按照我们想要的规则进行展示呢？下面由展示展示神奇grafana登场。

在2014年开始我逐渐使用grafana用来展示zabbix中的指标和自研业务监控中的数据展示，从最初的2.0版本到现在4.2版本，grafana  github社区经常有我的身影，因为它在展示界实在是太强大了，以至于BAT大佬们也喜欢用它来做运维展示。

按照官方的说法，grafana的宗旨是提供一套强大而又优雅的方式来创建探索数据和展示世界；

Grafana具有可插拔的面板，多种数据源支持，非常丰富的全功能图形面板和聚合计算公式，它的特点如下：

a.     丰富的图形—-完全的交互式，多轴刻度和选项

b.     混合造型—支持混合型，混合数据库查询，混合堆叠，混合正则表达式；

c.      模板变量—-最大的亮点就在于它了，支持sql查询值作为自动填充的变量称之为模板，可以在任意地方使用这个模板，包括面板，行，单个图形，单个指标中；

d.     验证授权—–支持ldap验证，权限管理和多租户隔离管理；

e.     快照功能——此也是它的一大亮点之一，当你需要向别人查看临时数据而对方又无账号时，这个功能可以满足你的需求；

f.       注释功能——-可以使用自定义的行注释，来作为问题追踪的的追踪线路；

g.     API输出——-完整的api，企业可以根据自定义开发属于自己的展示UI；

 

 

2.2.3其他支撑组件

查询组件

Kibana—这是一个开源的分析和可视化平台，一般与elasticsearch配合工作，它可以用来查询ela索引中的数据轻松的展示您所需要的数据，图表，或者高级分析。

 

 

告警组件

指标告警—chronograf+kapacitor

Influxdata公司为了提供1整套的基础监控平台，在influx得到大力推广后，逐渐开发了chronograf和kapacitor这两个组件，；

Chronograf的最初的目标是成为像grafana那样的优秀的展示平台，遗憾的是冰冻三尺非一日之寒，它的版本在不断的更新和重写，最新的版本是v1.2，它推翻了之前所有的代码，并且与告警组件kapacitor紧密的集成在一起，作为influx进军基础监控平台的一大利器；

 

 

日志告警—-judge alarm

日志告警是由我们平台开发部自主研发的一套告警模块，它支持关键词+维度告警模式，目前支持邮件告警和短信告警；

 

 

消息队列组件

Kafka+zookeeper组合

Kafka与zk不用过多的介绍，现在在互联网应用当中已经被非常广泛的使用，它是一种高吞吐量的分布式发布订阅消息系统，我这里简单介绍下kafka的特点：

a.     通过01的磁盘数据结构提供消息存储，这种最原始的消息存储能够保持长时间的稳定性能；

b.     使用廉价硬盘也可以支持每秒百分级消息速度；

c.      生产消息和消费消息模块可以通过集群来隔离，无限制的扩展了它的宽度；

Broker：Kafka集群包含一个或多个服务器，这种服务器被称为broker。

Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上，但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）。

Partition：Partition是物理上的概念，每个Topic包含一个或多个Partition。

Producer：负责发布消息到Kafka broker。

Consumer：消息消费者，向Kafka broker读取消息的客户端。

Consumer Group：每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。

 

Kafka交互流程

Kafka是一个基于分布式的消息发布-订阅系统，它被设计成快速、可扩展的、持久的。与其他消息发布-订阅系统类似，Kafka在主题当中保存消息的信息。生产者向主题写入数据，消费者从主题读取数据。由于Kafka的特性是支持分布式，同时也是基于分布式的，所以主题也是可以在多个节点上被分区和覆盖的。

信息是一个字节数组，程序员可以在这些字节数组中存储任何对象，支持的数据格式包括String、JSON、Avro。Kafka通过给每一个消息绑定一个键值的方式来保证生产者可以把所有的消息发送到指定位置。属于某一个消费者群组的消费者订阅了一个主题，通过该订阅消费者可以跨节点地接收所有与该主题相关的消息，每一个消息只会发送给群组中的一个消费者，所有拥有相同键值的消息都会被确保发给这一个消费者。

Kafka设计中将每一个主题分区当作一个具有顺序排列的日志。同处于一个分区中的消息都被设置了一个唯一的偏移量。Kafka只会保持跟踪未读消息，一旦消息被置为已读状态，Kafka就不会再去管理它了。Kafka的生产者负责在消息队列中对生产出来的消息保证一定时间的占有，消费者负责追踪每一个主题(可以理解为一个日志通道)的消息并及时获取它们。基于这样的设计，Kafka可以在消息队列中保存大量的开销很小的数据，并且支持大量的消费者订阅。

 

Zookeeper是一个优秀的分布式应用程序协调服务，也是hadoop和HBase的重要组件，它主要是为分布式的应用提供一致性的调度服务，例如配置维护，分布式同步，组服务等；

这里我简单介绍下zookeeper的工作原理：

选主过程：选举有2种方式，一种叫做basic paxos，另一种叫做fast paxos;

大家都知道zk的核心是原子广播，这个机制保证了每个server之间的同步，这个机制叫做zab协议，为了保证事物的顺序一致性，zk采用一种递增的事物ID号（zxid）来标识，前面32位用来标识leader关系是否改版，后面32位用于递增计数；

Basic paxos选举的流程是怎样的呢，我用自己的方式来讲，就好比一个班上要选举班长，我是第一个推荐人，推荐小王当班长，然后宣布出来，问一遍其他同学同意的举手，如果超过半数的人同意，那我的推荐人就当上班长，同时跟着他一起学习；

Fast paxos选举的流程又是怎样的呢，比如说我要当班长，我直接在班上说我要当班长，其他人跟着我同步，没有人反对我就如愿的当上了这个班长；

日志转发组件

自研Elasticsearch Transfer

前端负载

Haproxy:主要用来做ES集群的查询负载和API接口虚拟端点；

Nginx:主要用来代理grafana和influxdb的https接口，提高对外的安全性和接口速度；

权限组件:LDAP与SSO

3基础监控的架构实施

3.1生产环境架构图

服务器配置：

全局服务器：

a. 前端负载nginx（双机）—负责2台grafana和influxdb负载，并代理https后端请求；

b. 前端负载haproxy（双机）—负责es存储集群的负载，并代理https后端请求；

c. 全局展示grafana（双机）—负责展示所有的指标监控和日志监控；

 

指标：

d. 采集器telegraf—安装在每个虚拟机当中的采集器插件；

e. 时序数据库influxdb（3台）—负责所有指标类存储，2台唯一机房，1台阿里云机房；

f. 容量管理chronograf—展示每个数据库当中的服务器概况；

g. 告警模块kapacitor—负责从数据库中定时查询指标并输出告警邮件等；

 

日志：

h. 日志采集器—业务日志采集器和系统日志采集器，在每个服务器中进行埋点；

i. 消息队列kafka+zookeeper(3台)—负责将日志采集器上报的agent暂存；

j. 转发模块transfer(2台)—负责消费kafka的数据写入到ES集群中；

k. 前端存储elasticsearch(7台)—负责存储所有来自agent上报的系统日志，业务日志，其中2台master,5台data;

l. 后端存储HDFS—接入大数据部门的HDFS，负责永久存储过期日志；

m. 日志查询kibana（2台）—负责对es集群数据的日志展示；

 

 

3.2指标监控部署实施：

具体应用部署文档可以参见tapd

a.Inflxudb服务器：

推荐采用rpm yum安装，便于后续稳定升级到最新版本，默认会生成8083（web界面端口）和8086端口（http api接口），api接口推荐使用https方式接入公网认证的安全证书；

 

b.telegraf采集器：

使用salt批量推送安装包和配置文件到服务器，为了方便运维人员安装方便，采集器编写了一键安装脚本，只需要使用salt批量执行sh脚本即可完成初始化配置，对应的采集配置使用单个文件推送到采集器配置文件夹；

Telegraf的采集器配置主要分为3部分：

A1.全局配置

[global_tags]  #全局tags设置

rack = “aliyun”  #设置属于哪个机房

company = “xx”  #设置属于哪个公司

department = “sql”
 #设置属于哪个项目或者部门

 

# Configuration for telegraf agent

[agent]        #采集器采集配置

interval =
“60s”  #采集器采集频率,默认为10，根据自己的项目可以修改为任意数值

round_interval = true #采集器是否轮询上述间隔

metric_batch_size = 1000
 #采集器每次发生指标个数限制

metric_buffer_limit =
10000  #采集器缓存指标个数总限制

collection_jitter =
“0s”  #采集器频率抖动时间差，可用来做随机采集

flush_interval =
“61s”    #刷新数据写入到output时间间隔

flush_jitter =
“0s”    #刷新数据写入随机抖动时间

precision = “”
 #采集器最小时间单位，默认为ns

debug = false  #是否运行debug，默认不允许

quiet = false  #是否安静模式运行，不输出日志等

hostname = “”
 #采集器主机名称，不指定则为主机名

omit_hostname = false

 

A2.数据库输出配置：

#Configuration for influxdb server to
send metrics to

[[outputs.influxdb]]

urls =
[“http://10.27.xx.19:8086”] #influxdb地址

database =
“telegraf_ali” # required  #influxdb数据库

retention_policy =
“”    #数据保留策略

write_consistency =
“any”  #数据写入策略，仅适用于集群模式

timeout = “5s”
    #写入超时策略

username =
“telegraf_ali”  #数据库用户名

password =
“gP2Zbeh” #数据库密码

 

A3.采集插件配置：

采集器插件配置有公用的采集配置，例如操作系统层面，有特殊的采集配置，例如数据库需要采集MySQL，docker主机需要采集容器信息(以下仅是部分采集配置代码）；

# Read metrics
about cpu usage

[[inputs.cpu]]

percpu = true

totalcpu = true

fielddrop = [“usage_guest*”]

 

[inputs.haproxy]

interval = “600s”

servers =
[“/var/run/haproxy.sock”]

 

[[inputs.http_response]]

address = “http://abc.com”

response_timeout = “5s”

method = “GET”

follow_redirects = true

 

[[inputs.ping]]

urls = [“www.qq.com”]

count = 1

ping_interval = 0.0

timeout = 0.0

interface = “eth0”

 

[[inputs.docker]]

interval = “5m”

endpoint = “unix:///var/run/docker.sock”

container_names = []

timeout = “10s”

perdevice = true

total = false

 

d.  展示器部署

 

Grafana安装比较简单，用户操作文档和管理员操作文档可以参见tapd：

 

e.  告警组件部署

用户操作：

管理员：需要负责整个平台每个应用的配置和优化，自动化脚本的编写，数据的分析SQL编写，数据展示的模板制作，告警的模板配置；

二级维护员：需要负责采集器部分的推送和安装，数据展示部分的需求梳理，告警级别的梳理；

普通用户：只需要在展示平台中查看你所需要的数据；

中高层领导：查看展示平台推送过来的报表图形；

 

性能优化部分：

数据库优化：因influxdb的高性能TSM引擎特性，最好使用ssd硬盘来存储，平均可以达到每秒百万指标写入（换算成IOPS大概为多少），并且wal和data目录使用不同的硬盘，以此来达到读写IO互不干扰；数据库本身的优化主要在于批量读写队列的配置优化和内存优化，因官方有相关的指导说明，在此不再赘述。

 

3.3日志监控部署实施：

详细部署文档请参见tapd:

ES集群部署：省略

Kafka集群部署：省略

Zookeeper集群部署：

Transfer部署：省略

Jugle alarm部署：省略

Kibana部署：省略

 

用户操作：

管理员：ES集群的版本维护，优化，升级；日志采集器的批量安装脚本，kafka与zk集群的优化，日志采集器批量安装；

普通用户：kibana的查询使用操作

性能优化部分：

ES集群的查询性能瓶颈分析，es查询语句汇总

4.开源

为什么要使用开源？

开源能给企业和员工带来什么？

开源的缺点是什么？

 

互联网企业为什么要使用开源，因为他们生产的就是软件产品，如果他们的原材料都是需要付费的，或者使用别人的现成产品，那他们便只是一个软件代理或者软件包装者，这里面最大的一个原因就是成本了；

传统的闭源商业产品都是在企业或者组织机构内部流行，而开源不一样，开源是一群技术爱好者们共同去维护一个共同的项目，任何一个人可以在任意时间加入进来并且修改其中的一个功能，为其锦上添花，这里面的原因就是开源的创新更大更快；

开源虽然好，但并不是完美的，开源的软肋在哪呢；

开源允许技术人员任意直接修改源代码，问题就在于这里，它就需要技术人员掌握它的基础知识和代码组成，这带来的就是人力学习成本，开源软件这么多，任意一个类型都有好多种选择，如何选型和评估为第一道工作，如何根据选择的软件进行定制化开发成为第二道工作，其实从技术人员的角度来讲更希望企业使用开源软件，因为开源是一种趋势，这条路或者这件事是正确的方向，人生的意义就在于用正确的方式走正确的路并且正确的完成；路是正确的，剩下的就是如何用正确的方式去正确的完成了；

但是开源的路很多，怎样选择哪条路，这个取决于团队自身的技术阶段和应用价值，比如说做运维的比较熟悉python，shell，ruby这些语言，但是如果选择一个开源平台的语言是java或者C语言，这个技术是不能被cover住的，所以选择哪一个，要看我们自身是否能够cover住这个平台本身，其次是选择的开源的平台的价值，比如说我们花了很多时间将这个平台二次开发完了，但是在实际推广中其实应用价值不大或者价值不被认可，这个也是不行的；

转载于:https://my.oschina.net/kevin728971010/blog/1486138