大数据监控平台实践之路

大家好，又见面了，我是你们的朋友全栈君。

大数据监控平台实践之路

一、监控体系
- 业务层：
- 应用层：
- 系统层：
二、架构设计
- Telegraf：
- - input：
  - output：
  - 调度频率：
  - 服务启动：
- InfluxDB：
- - 服务启动：
  - 常用命令：
- Grafana：
- - Grafana主要特性：
  - 简单使用介绍：

原文地址：

大数据监控平台实践之路

一、监控体系

监控粒度、监控指标完整性、监控实时性是评价监控系统的三要素。从分层体系可以把监控系统分为三个层次：

业务层：

业务系统本质目的是为了达成业务目标，因此监控业务系统是否正常最有效的方式是从数据上监控业务目标是否达成。对业务运营数据进行监控，可及时发现程序bug或业务逻辑设计缺陷，比如注册失败率、登录失败率、付款失败率等。业务系统的多样性决定了应由各个业务系统实现监控指标开发。

应用层：

对应用的整体运行状况进行了解、把控，如果将应用当成黑盒子，开发、运维就无从知晓应用当前状态，不能及时发现潜在故障。应用监控不应局限于业务系统，还包括各种中间件、计算引擎，如Spark、Jstorm、redis、zookeeper、kafka等。常用监控数据：JVM堆内存、GC、CPU使用率、线程数、TPS、吞吐量等。一般通过抽象出的统一指标收集组件，收集应用级指标，比如不管是支付系统还是交易系统，都要监控jvm内存使用。

系统层：

实时掌握服务器工作状态，留意性能、内存消耗、容量和整体系统健康状态，保证服务器稳定运行。监控指标：内存、磁盘、CPU、网络流量、系统进程等系统级性能指标

二、架构设计

工欲善其事必先利其器，根据对现有监控产品的调研，以及我们对监控的分层介绍、所需解决的问题，可以发现监控系统从收集到分析的流程架构：采集－存储－展示－告警：

Telegraf：

插件化的指标收集和指标报告服务，能定制化开发并轻松添加所需插件。已经内置了很多常用服务的插件，这也是我们选择telegraf的原因之一，不用再重复造轮子。

Go语言编写的插件化指标收集agent，编译成一个没有外部依赖的二进制文件，安装部署很便捷，直接下载、解压就行，默认配置文件在$TELEGRAF_HOME/etc/telegraf/telegraf.conf目录下。telegraf插件分为两大类：input、output。

input：

收集inputs配置的所有指标，已内置的input插件：elasticsearch、redis、jolokia等。也可直接收集运行agent server的各种指标，比如内存、cpu、磁盘、磁盘IO、进程、swap等。input配置都很简明易用，一般只需配置服务IP地址就可以，如redis指标收集配置：

如果没有内置收集插件，有两种实现方案：

开发input插件，但这需要有GO语言基础
借助于httpjson input插件，该插件请求http url，返回json格式。url配置为自定义指标收集服务，在指标收集服务内实现指标收集功能，然后指标封装成json返回或指标数据直接在服务内入库。我们监控Kettle Carte、spark、jstorm等用的这种实现思路。