监控CMDB等全面方式

1.监控源：从层次上来分，大致可以分为三层，业务应用层、中间件层、基础设施层业务应用层主要包括应用软件、企业消息总线等中间件层包括数据库、缓存、配置中心、等各种系统软件基础设施层主要有物理机、虚拟机、容器、网络设备、存储设备等等。

2.数据采集：

数据源如此多样，数据采集的任务自然轻松不了。数据采集从指标上划分可以分为业务指标、应用指标、系统软件监控指标、系统指标。指标内容如图所示

从采集方式来说分为接口采集、客户端agent采集、通过网络协议主动抓取（http、snmp等）

3.数据存储：

采集到的数据一般都会存储到文件系统（如HDFS）、索引系统（如elasticsearch）、指标库（如influxdb）、消息队列（如kafka，做消息临时存储或者缓冲）、数据库（如mysql）

4.数据分析：
针对采集到的数据，进行数据的处理。处理分两类：实时处理和批处理。技术包括Map/Reduce计算、全日志检索、流式计算、指标计算等，重点是根据不同的场景需求选择不同的计算方式。

－－ 实时和 跑批

5.数据的表现途径

展现：
将处理的结果进行图表展现，在多屏时代，跨设备的支持必不可少。

.预警：
如果在数据处理过程发现了问题，则需要进行异常的分析、风险的预估以及事件的触发或告警。

CMDB(企业软硬件资产管理):
CMDB在统一监控平台中是很重要的一环，监控源虽然种类繁多，但是他们大都有着关系，如应用运行在运行环境中，应用的正常运行又依赖网络和存储设备，一个应用也会依赖于其他的应用（业务依赖），一旦其中任何一个环节出了问题，都会导致应用的不可用。CMDB除了存储软硬件资产外，还要存储这样一份资产间的关联关系，一个资产发生了故障，要能根据这个关系迅速得知哪些其他的资产会被影响，然后逐一解决问题。

－－－这个很重要的－－有无开源系统

cmdb抓取服务信息的方式有很多种，可以使用自动化工具saltstack、ansible、puppet，或者使用其它模块直接ssh远程连接抓取服务器信息。这里记录一下用ansible的API接口调用setup模块抓取。

－－－

一个高效、好用的配置管理数据库(Configuration Management Database，CMDB)需满足以下6条重要标准，即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。

＝＝＝

数据采集：

                  系统监控数据采集一般分为两种方式：主动采集、客户端采集。主动采集一般是通过SNMP、ssh、telnet、IPMI、JMX等手段进行远程采集，客户端采集则是需要在每一个要监控的主机中部署一个客户端进行数据采集并发送到远程服务端进行接收。

数据缓冲：
                  和日志监控一样，在面临海量监控时， 考虑到网络的压力和数据处理的瓶颈，可以在数据存储前先经过一层数据缓冲，将采集到的数据先放置到消息队列中，然后再从分布式队列中读取数据并存储。如果数据量不大的话，则可以不考虑此层。

数据存储：
                  对于系统监控数据，通常采用时序数据库来存储，时序数据库全称为时间序列数据库。时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。如influxdb和opentsdb，是其中翘楚。

展示－－告警：

                  在日志监控的分享中，确实没有对告警进行说明。像Zabbix、Nagios、Open-Falcon、Prometheus等开源监控软件，都是有些自己的告警能力的。如果你采用了他们作为监控平台，实际上告警能力就已经有了。如果是纯自建统一监控平台的话，也可以自己实现告警中心。我们自己的做法是，在数据处理时，根据配置的事件触发规则，生成相应事件扔到kafka中，事件处理引擎监听kafka中的事件数据，进行解析并根据事件处理策略进行告警通知等处理。

＝＝＝

Zabbix重要组件说明：
1）zabbix server:负责接收agent发送的报告信息的核心组件，所有配置、统计数据及操作数据都由它组织进行；
2）database storage：专用于存储所有配置信息，以及由zabbix收集的数据；
3）web interface：zabbix的GUI接口；
4）proxy：可选组件，常用于监控节点很多的分布式环境中，代理server收集部分数据转发到server，可以减轻server的压力；
5）agent：部署在被监控的主机上，负责收集主机本地数据如cpu、内存、数据库等数据发往server端或proxy端；

＝＝＝＝＝

优点：
1.All in One：部署相当便捷
2.Server对宿主机性能要求很低。
2.自动发现服务器与网络设备
3.分布式监控，以及WEB集中管理功能
4.同时支持agent采集和无agent采集，主机通过agent 或者ipmi采集数据，网络设备、存储设备等通过 SNMP 客户端采集数据，agent支持常用的UNIX和Windows操作系统
5.功能全面，数据采集、数据存储、数据展现、事件告警。
6.开放式接口，扩展性强，插件编写容易

＝ ＝ ＝ ＝ ＝ ＝  ＝ ＝＝  ＝＝ 

Open-Falcon是小米运维部门开源出来的互联网企业级监控系统，Open-Falcon 整体可以分为两部分，即绘图组件、告警组件。

包括小米、金山云、美团、京东金融、赶集网等都在使用Open-Falcon

＝＝＝＝＝

通常一套监控报警系统会包括这么几个模块：

1. 指标数据收集
2. 指标数据存储
3. 指标数据展示
4. 监控报警

我们在进行技术选型时主要考虑的是希望各组件专注做一件事情并把它做好。基于这点，我们选择了 collectd 进行数据收集，Graphite 进行数据存储， Grafana 进行数据展示，icinga2 进行监控报警。基本的架构如图所示：

数据存储

Graphite是一个很受欢迎的指标收集平台。其主要组件包括：

• carbon: 监控数据接收组件
• whisper: 监控数据存储组件
• Graphite     Web: 监控数据查询及展示组件

在实际使用中只是使用部分的功能／前期可能zabbix会是较好的选择。

Graphite-Web提供的展示功能并不是特别的方便，因此我们选用 Grafana 进行展示。大家可以在 http://play.grafana.org/ 这里试玩下，体验下 grafana 提供的展示能力。

Grafana主要拥有如下优势：

1. Dashboard 配置方便，可以随意通过拖拽方式进行变动，调换；配置好之后还能够导出模板分享给他人使用；
2. 支持多种后端，包括 Graphite, Elasticsearch, InfluxDB 等等，也可以通过编写 plugin 支持一些特别的后端；
3. 支持认证，支持 LDAP、Basic Auth；

Lain 是一个基于 docker 的 PaaS 系统。

+

设计目标包括但不限于：

• 降低系统管理复杂度
• 简化服务的部署管理
• 优化基础服务的调配
• 提高资源的使用效率
• 统一开发测试生产三环境
• 持续交付工作流的良好支持