nagios+influxdb+grafana的监控数据可视化流程
nagios介绍
nagios是一款开源监控的应用,可用于监控本地和远程主机的日志、资源、死活等等诸多功能。通过snmp协议和nrpe协议。
nagios的配置文件是由nconf上进行配置,然后点击生成至服务器,上面有各种模板,可以自己配,也可以用现有的。
nagios的搭建过程,自行百度。
下面是一个nagios配置文件的样例
nagios配置文件目录结构:
# ll /usr/local/nagios/etc/
total 152
-rw-rw-r-- 1 nagios nagios 12999 Apr 29 08:08 cgi.cfg
drwxr-xr-x 2 apache apache 4096 May 31 08:45 Default_collector <- 定义监视项的目录
drwxr-xr-x 2 apache apache 4096 May 31 08:38 global <- 全局参数的定义,checkcommand的定义
-rw-r--r-- 1 nagios nagios 50 Apr 29 08:12 htpasswd.users
-rw-rw-r-- 1 nagios nagios 46169 May 3 01:37 nagios.cfg <- nagios的配置文件
-rw-rw-r-- 1 root root 44816 Apr 29 08:58 nagios.cfg.29-04-18
-rw-r--r-- 1 root root 2358 May 2 10:48 NagiosConfig.tgz
drwxr-xr-x 2 nagios nagios 4096 May 8 11:59 nrpe
-rw-r--r-- 1 nagios nagios 7217 Apr 29 08:45 nrpe.cfg <- nrpe的通信配置
-rwxr-xr-x 1 nagios nagios 7217 Apr 29 08:38 nrpe.cfg.save
drwxrwxr-x 2 nagios nagios 4096 Apr 30 02:19 objects
-rw-rw---- 1 nagios nagios 1312 Apr 29 08:08 resource.cfg
vim /usr/local/nagios/etc/Default_collect/services.cfg
define service {
service_description check_proc_nagios <- 页面上显示出的监控项的名字,在这里定义
check_command check_remote_procs!nagios!8!1:8 <- 执行的check command,这个配置是监控的主要命令,几乎靠着个命令才能监控到是否OK,靠着“!”作为参数分隔符
host_name host名 <- 写出监控哪一台服务器,前提是和nagios server是可以通信的
check_period 24x7 <- 监控的时间
contact_groups +admins <- 联系组,联系人,出错发给谁
event_handler_enabled 0
use generic-service <- 采用的哪个现有模板(nconf上配置)
}
vim /usr/local/nagios/etc/Default_collect/hosts.cfg
define host {
host_name ********** <- 定义的host名主要显示在监控页面上
alias ***サーバ <- 定义的别名
address ***-b-**-***-**.stage-***-org.fastretailing.cn <- 这一行定义的是主要去通信的IP地址
_graphiteprefix graphite_host
icon_image_alt Linux
icon_image base/linux40.gif
statusmap_image base/linux40.gd2
check_command check-host-alive
check_period 24x7
notification_period 24x7
contact_groups +admins
use generic-host,linux-server
}
vim /usr/local/nagios/etc/global/checkcommands.cfg
define command {
command_name check_local_disk
command_line $USER1$/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ <- 在services.cfg中,check_command参数中,用“!”分割的就是“$ARG$”的参数之间间隔
}
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
define command {
command_name check_remote_procs
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_procs -a "-C $ARG1$ -w $ARG2$ -c $ARG3$" <- 这一行监视的配置内容是监视远程的进程
}
以上,配置好监控项。
influxdb介绍
influxdb,中文名时序数据库,
时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线,往过去看可以做成多纬度报表,揭示其趋势性、规律性常性;往未来看可以做大数据分析,机器学习,实现预测和预警。
时序数据库就是存放时序数据的数据库,并且需要支持时序数据的快速写入、持久化、多纬度的聚合查询等基本功能。
对比传统数据库仅仅记录了数据的当前值,时序数据库则记录了所有的历史数据。同时时序数据的查询也总是会带上时间作为过滤条件。
influxdb主要配置
vim /etc/influxdb/influxdb.conf
[meta]
# Where the metadata/raft database is stored <- 元数据存放位置
dir = "/var/lib/influxdb/meta"
[data]
# The directory where the TSM storage engine stores TSM files. <- 最终数据
dir = "/var/lib/influxdb/data" # The directory where the TSM storage engine stores WAL files. <- wal数据为预写数据
wal-dir = "/var/lib/influxdb/wal"
nagios将数据存入influxdb的过程
nagios将监视出的数据,通过graphios,来存放到influxdb,为了方便日后再grafana上进行可视化。
流程
1、nagios的执行命令的输出结果,写到一个文件,然后对这个文件进行mv,存放在一个目录下。
具体配置如下
# vim /usr/local/nagios/etc/global/misccommands.cfg
define command {
command_name graphios_perf_host
command_line /bin/mv /usr/local/nagios/var/host-perfdata /var/spool/nagios/graphios/host-perfdata.$TIMET$ <- mv 命令的主要执行
} define command {
command_name graphios_perf_service
command_line /bin/mv /usr/local/nagios/var/service-perfdata /var/spool/nagios/graphios/service-perfdata.$TIMET$ <- mv 命令的主要执行
}
上面配置文件中,要求的是mv /usr/local/nagios/var/host-perfdata /var/spool/nagios/graphios/host-perfdata.$TIMET$
然后我们就会面临这几个问题:
1、复制源是怎么生成的?
2、复制源中的文件长什么样?
3、又是在哪里配置的?
上面这几个问题需要看如下的配置文件。
首先看 nagios 的主配置文件 nagios.cfg,从这个文件可以看出上面问题中的:3、复制源是哪里配置的。
# vim /usr/local/nagios/etc/nagios.cfg
process_performance_data=1
service_perfdata_file=/usr/local/nagios/var/service-perfdata <- 这行指定的是复制源的文件,就是nagios监视的命令执行结果输出到哪个文件,在这里指定。
service_perfdata_file_template=DATATYPE::SERVICEPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tSERVICEDESC::$SERVICEDESC$\tSERVICEPERFDATA::$SERVICEPERFDATA$\tSERVICECHECKCOMMAND::$SERVICECHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tSERVICESTATE::$SERVICESTATE$\tSERVICESTATETYPE::$SERVICESTATETYPE$\tGRAPHITEPREFIX::$_SERVICEGRAPHITEPREFIX$\tGRAPHITEPOSTFIX::$_SERVICEGRAPHITEPOSTFIX$\tMETRICTYPE::$_SERVICEMETRICTYPE$
上面这行配置,配置的是把输出结果的文件格式化,为了方便后面的graphios来存放到influxdb中做准备
service_perfdata_file_mode=a
service_perfdata_file_processing_interval=15
service_perfdata_file_processing_command=graphios_perf_service
host_perfdata_file=/usr/local/nagios/var/host-perfdata
host_perfdata_file_template=DATATYPE::HOSTPERFDATA\tTIMET::$TIMET$\tHOSTNAME::$HOSTNAME$\tHOSTPERFDATA::$HOSTPERFDATA$\tHOSTCHECKCOMMAND::$HOSTCHECKCOMMAND$\tHOSTSTATE::$HOSTSTATE$\tHOSTSTATETYPE::$HOSTSTATETYPE$\tGRAPHITEPREFIX::$_HOSTGRAPHITEPREFIX$\tGRAPHITEPOSTFIX::$_HOSTGRAPHITEPOSTFIX$\tMETRICTYPE::$_HOSTMETRICTYPE$
host_perfdata_file_mode=a
host_perfdata_file_processing_interval=15
host_perfdata_file_processing_command=graphios_perf_host
看到这里,最基本的配置了解了,那么下面的问题就是1、复制源是怎么生成的?2、复制源中的文件长什么样?
复制源生成很简单,nagios监视页面上的数据,其实是基于nagios自身执行的命令,然后返回到页面,再供给我们进行观看是否是OK或者DOWN
# /usr/local/nagios/libexec/check_nrpe -H 10.**.58.*** -c check_disk -a "-w 20% -c 10%"
DISK OK - free space: /dev 1873 MB (99.99% inode=100%); /dev/shm 1882 MB (100.00% inode=100%); / 499479 MB (99.15% inode=100%);| /dev=0MB;1498;1685;0;1873 /dev/shm=0MB;1505;1693;0;1882 /=4259MB;403068;453452;0;503836
以上是输出结果,这个输出结果会输入到/usr/local/nagios/var/service-perfdata里面,这个配置在上面的nagios.cfg中配置好了的。
但仔细看,会发现上面的nagios.cfg中还有一个设置项:service_perfdata_file_template,就是很长很长的那一段,这一个设置项的内容是格式化上面的那条输出结果。
下面看个格式化完成了的例子。
# vim /var/spool/nagios/graphios/service-perfdata.1528256154
DATATYPE::SERVICEPERFDATA TIMET::1528256140 HOSTNAME::************ SERVICEDESC::LOAD SERVICEPERFDATA::load1=0.000;2.000;4.000;0; load5=0.000;2.000;4.000;0; load15=0.000;2.000;4.000;0; SERVICECHECKCOMMAND::check_remote_load! HOSTSTATE::UP HOSTSTATETYPE::HARD SERVICESTATE::OK SERVICESTATETYPE::HARD GRAPHITEPREFIX::grafana GRAPHITEPOSTFIX::load METRICTYPE::$_SERVICEMETRICTYPE$
DATATYPE::SERVICEPERFDATA TIMET::1528256145 HOSTNAME::************ SERVICEDESC::Swap-Usage SERVICEPERFDATA::swap=2047MB;1433;1023;0;2047 SERVICECHECKCOMMAND::check_remote_swap! HOSTSTATE::UP HOSTSTATETYPE::HARD SERVICESTATE::OK SERVICESTATETYPE::HARD GRAPHITEPREFIX::logaggregator GRAPHITEPOSTFIX::swap METRICTYPE::$_SERVICEMETRICTYPE$
DATATYPE::SERVICEPERFDATA TIMET::1528256146 HOSTNAME::************ SERVICEDESC::Swap-Usage SERVICEPERFDATA::swap=2047MB;1433;1023;0;2047 SERVICECHECKCOMMAND::check_remote_swap! HOSTSTATE::UP HOSTSTATETYPE::HARD SERVICESTATE::OK SERVICESTATETYPE::HARD GRAPHITEPREFIX::jenkins GRAPHITEPOSTFIX::swap METRICTYPE::$_SERVICEMETRICTYPE$
看到上面这个配置文件,就会有个疑问:为什么要把文件改成这种格式?
原因其实就是,nagios的数据想要传送到influxdb上,需要graphios来充当一个搬运工的角色,graphios的代码是python编写的,其中有一段代码设计好了要取这样格式的数据。
graphios的代码可以在https://github.com/shawn-sterling/graphios/blob/master/graphios.py 查看
之后的事情就很简单了,在graphios配置中,开启如下配置
vim /etc/graphios/graphios.cfg enable_influxdb09 = True # Extra tags to add to metrics, like data center location etc.
# Only valid for 0.9
#influxdb_extra_tags = {"location": "la"} # Comma separated list of server:ports
# defaults to 127.0.0.1:8086 (:8087 if using SSL).
influxdb_servers = 127.0.0.1:9096 # SSL, defaults to False
#influxdb_use_ssl = True # Database-name, defaults to nagios
influxdb_db = nagios # Credentials (required)
influxdb_user = influxdb
influxdb_password = influxdb
以上配置,配置成功后,
# /etc/init.d/graphios start
# /etc/init.d/nagios start
以上配置,作为一个笔记,大致流程 nagios -> graphios -> influxdb
最后在grafana上面生成图表,生成图表方式自行百度
nagios+influxdb+grafana的监控数据可视化流程的更多相关文章
- Nagios+InfluxDB+Grafana
1. 概述 Nagios负责收集数据,是一款开源的免费网络监视工具. influxDB负责存储数据,是一个开源的时间序列数据库.比较适合存储监控或者部署记录这些时序数据. Grafana负责数据的图形 ...
- 性能工具之JMeter+InfluxDB+Grafana打造压测可视化实时监控【转】
概述 本文我们将介绍如何使用JMeter+InfluxDB+Grafana打造压测可视化实时监控. 引言 我们很多时候在使用JMeter做性能测试,我们很难及时察看压测过程中应用的性能状况,总是需要等 ...
- 基于Grafana的监控数据钻取功能应用实践
互联网企业中,随着机器规模以及业务量的爆发式增长,监控数据逐渐成为一种大数据,对监控大数据的分析,包括数据采集.数据缓存.数据聚合分析.数据存储.数据展现等几个阶段.不同阶段有不同的解决方案及支撑工具 ...
- jmeter+influxdb+grafana性能测试监控
背景: 话说Jmeter原生的监控确实太丑了,听大佬们在讨论Jmeter+InfluxDb+Grafana的监控,于是,为了有一个漂亮的测试报告,就手动开始进行部署. 安装步骤: 1.influxdb ...
- influxDB1.6版安装与配置(windows环境)、Jmeter+influxDB+Grafana性能监控
influxDB1.6版安装与配置(windows环境).Jmeter+influxDB+Grafana性能监控 来源:https://blog.csdn.net/SwTesting/article/ ...
- 基于InfluxDB+Grafana打造大数据监控利器--转
这是一个大数据爆发的时代.面对信息的激流.多元化数据的涌现,我们在获取.存储.传输.理解.分析.应用.维护大数据时,无疑需要一种便捷的信息交流通道,以便快速.有效.准确地理解和驾驭这个过程.本文将通过 ...
- Spring Boot 2.x监控数据可视化(Actuator + Prometheus + Grafana手把手)
TIPS 本文基于Spring Boot 2.1.4,理论支持Spring Boot 2.x所有版本 众所周知,Spring Boot有个子项目Spring Boot Actuator,它为应用提供了 ...
- SpringBoot 2.0 + InfluxDB+ Sentinel 实时监控数据存储
前言 阿里巴巴提供的控制台只是用于演示 Sentinel 的基本能力和工作流程,并没有依赖生产环境中所必需的组件,比如持久化的后端数据库.可靠的配置中心等.目前 Sentinel 采用内存态的方式存储 ...
- Spring Boot Actutaur + Telegraf + InFluxDB + Grafana 构建监控平台之应用数据分析
本节将引入完美的granafa仪表板,在上节的基础上,并提出自己的一些监控数据的总结和看法 你可以有一个类似于这个的Dashboard,会引入监控Zimbra协作 本节环境采用的是centos7系统, ...
随机推荐
- java代码=--数组复制
总结:arraycopy注意数组定义的长度.不足会补0 package clientFrame; //数组的复制arraycopy() public class Xiang { public stat ...
- java冒泡排序算法例子
总结:运行显示数组下标越界说明,数组长度a.length.表示数组的长度,但索引值是要减一的.勿忘 package com.c2; //冒泡排序 //从小到大的顺序排列 public class MA ...
- Git 学习小问题记录
最近一直使用Git在管理代码,但是的确不规范,今天开始恶补Git常用命令.实际今天的任务是需要从master牵出一条branch.心想着这个简单只补一下创建分支以及merge的这边的命令就可以了,于是 ...
- JavaScript笔记——正则表达式
正则表达式(regular expression)是一个描述字符模式的对象.JavaScript的 RegExp 类 表示正则表达式,而 String 和 RegExp 都定义了使用正则表达式进行强大 ...
- java多态介绍温故而知新
多态是同一个行为具有多个不同表现形式或形态的能力. 多态就是同一个接口,使用不同的实例而执行不同操作. 多态性是对象多种表现形式的体现. 现实中,比如我们按下 F1 键这个动作: 如果当前在 Flas ...
- MFC 文档/视图
1.文档修改后,关闭时需要保存,主要用到2个函数,在需要更改文档内容的函数里调用SetModifiedFlag(TRUE),另一个就是SaveModified()函数,简单的例子: BOOL CMFC ...
- GNS3连接虚拟机
打开GNS3,拖一台路由器和主机 右击主机,选择配置 添加虚拟机的网卡为主机网卡,(选择VM1或VM8) 路由器选择虚拟机网卡连接 打开虚拟机在导航栏找到“虚拟机”-->“设 ...
- 12-EasyNetQ之消息版本控制
为了能够支持消息版本控制,你需要确保这个必要的组件已配置.最简单的实现是这样的: var bus = RabbitHutch.CreateBus("host=localhost", ...
- Spring Cloud Eureka 4 (高可用服务注册中心)
在微服务这样的分布式环境中,我们需要充分考虑发生故障的情况,所以在生产环境中必须考虑对各个组件进行高可用部署,对于服务注册中心也是一样. Eureka Server 的高可用实际上就是讲自己作为服务向 ...
- Spring项目的发展历史和SpringBoot的发展历史
Spring项目的发展历史和SpringBoot的发展历史 在Java做web应用的服务端开发领域,一直存在着两套技术体系,一套是Sun公司官方推出的JavaEE,另一套是Spring.Spring ...