telegraf 使用 inputs.exec插件收集监控数据

telegraf (v1.5.2)虽然好用但是默认情况下并不能帮你收集好所有你需要的数据,比如io数据,默认情况下只收集了iotime, iops_in_process, weighted_io_time, read, write等相关数据,并不能收集到每个盘的iops, await, svctm, util 等数据,最近正好有这个需求,查了下官网telegraf可以支持用户自定义脚本收集监控数据上传到infulxdb,下面直奔主题吧

1,自己写脚本收集好每块盘的iops, await, svctm, util , collect_iostat.sh脚本内容如下

#/bin/bash

devname=(`lsblk| grep ‘disk‘|awk ‘{print $1}‘`)
dirname=(`lsblk| grep ‘disk‘|awk ‘{if ($7=="") print "/";else print $7}‘`)
#当时想用字典格式存储这些目录名,后来改为变量方式,shell的[ ] { } * @ $特殊字符会让你抓狂
#declare -A devdict
devnum=`expr ${#devname[@]} - 1`
for i in `seq 0 $devnum`;do
  if [-z "${dirname[$i]}" ];then
    eval ${devname[$i]}="/"
  else
    eval ${devname[$i]}="${dirname[$i]}"
  fi
  #devdict+=([${devname[$i]}]="${dirname[$i]}")
done
#echo ${!devdict[*]}
#echo ${devdict[*]}

ioarry=`iostat -x | grep sd|awk ‘{print "datadir=${"$1"}@r="$4",w="$5",await="$10",svctm="$11",util="$12}‘`
for i in ${ioarry[@]};do
  eval temp="${i}"
  #替换特殊字符@,shell中空格会截断为两个元素
  temp=${temp/@/ }
  echo "exec,${temp}"
  #保证最后输出如下格式,第一个字端是measurements名,如果inputs.exec插件中有配置name_suffix会自动加上后缀
  #输出格式为measurements名, 逗号, tag keys(逗号分隔),空格,filed keys(逗号分隔)
  #数据格式输出不匹配会导致telegraf解析不了数据上到influxdb失败,调试的时候卡了很久,没细看官网给自己挖的坑
  #exec,datadir=/data/data11 r=4.1,w=6.1,await=0.83,svctm=1.35,util=1.46"
done #echo ${devdict[@]}

2,telegraf.conf文件中新增[[inputs.exec]]的插件

[[inputs.exec]]
  ##Commands array
  commands = ["bash /appcom/telegraf/collect_iostat.sh",]
  timeout=‘5s‘
  ##measurements 的后缀
  name_suffix="_collectiostat"
  data_format="influx"

3,可以telegraf --debug一下结果

4,启动telegraf后,去influxdb中查看结果即可

原文地址:https://www.cnblogs.com/tommyjiang/p/10926484.html

时间: 2024-11-01 19:06:37

telegraf 使用 inputs.exec插件收集监控数据的相关文章

使用hyperpacer实现监控数据的同步收集

逐渐要把性能自动化建立起来了,发现一些关键的监控数据就需要和脚本一起调度才可以.自己写了一些shell脚本,脚本运行的同时,也会分别调度各个服务器上的shell脚本去收集数据,但是总觉得还是有些麻烦,如果可以集成在hyperpacer脚本里,同步把数据全都收集过来就好了,这样监控结果整理也容易,分析也方便.于是决定自己做一个脚本的模版,把一些常用的监控都预置进来.说干就干,花了一上午的时间,终于搞了一个自己比较满意的模版: 这里主要通过JMX资源监视器和数据库资源监视器实现的,技术实现本身并不复

Zabbix结合插件percona监控mysql数据

按道理来说zabbix就自带的MySQL插件来监控mysql数据库,但是你会发现,自带的mysql监控项是很少的,根本满足不了公司的需求. 由于它本身自带的模板太过简单了,所以需要做更详细的监控,而percona就提供了这个详细监控的模版以及脚本,解决了监控不全面的问题.. 1.percona插件安装: [[email protected] ~]# cd /usr/local/src/ 官网下载percona的rpm包,我这里是下载的是1.1.7版本的 [[email protected] sr

flume使用之exec source收集各端数据汇总到另外一台服务器

转载:http://blog.csdn.net/liuxiao723846/article/details/78133375 一.场景一描述: 线上api接口服务通过log4j往本地磁盘上打印日志,在接口服务器上安装flume,通过exec source收集日志,然后通过avro sink发送到汇总服务器上的flume:汇总服务器上的flume通过avro source接收日志,然后通过file_roll sink写到本地磁盘. 假设:api接口服务器两台 10.153.140.250和10.1

XenApp/XenDesktop监控数据查询、提取

在XenDesktop中,Director为管理员提供了整个平台的监控和健康状态的信息,让管理员方便的了解Citrix的平台的运行状态以及实时发生的故障.这些监控数据从哪儿来?在XenDesktop的先前版本中,Director中的大多数数据都是通过直接访问Broker Service API来检索的.使用此API的缺点是此服务不包括对使用的历史信息的检索,即只能检索实时会话信息.如果管理员需要向以前的监控组件Edgesight那样检索历史数据,比如管理员可能想知道目前有多少会话处于活动状态,以

如何从Zabbix数据库中获取监控数据

做过Zabbix的同学都知道,Zabbix通过专用的Agent或者SNMP收集相关的监控数据,然后存储到数据库里面实时在前台展示.Zabbix监控数据主要分为以下两类: 历史数据:history相关表,从history_uint表里面可以查询到设备监控项目的最大,最小和平均值,即存储监控数据的原始数据. 趋势数据:trends相关表,趋势数据是经过Zabbix计算的数据,数据是从history_uint里面汇总的,从trends_uint可以查看到监控数据每小时最大,最小和平均值流量. Zabb

MS SQL 监控数据/日志文件增长

前几天,在所有数据库服务器部署了监控磁盘空间的存储过程和作业后(MS SQL 监控磁盘空间告警),今天突然收到了两封告警邮件,好吧,存储规划是一方面,但是,是不是要分析一下是什么原因造成磁盘空间不足的呢?会不会是因为突然暴增的日志文件,抑或是系统业务猛增导致数据量暴增,还是历史数据累计原因....分析总得有数据来支撑吧,但是现在只有那些数据文件的当前大小信息,没有数据文件的历史增长变化信息,所以,今天就想实现这么一个功能,每天(频率可以调整)去收集一下数据文件的信息,放到一个表里面,这样方便我们

zabbix企业应用之定时获取监控数据做报表

最近某项目突然提出一个新需求,需要每周五14点,获取他们监控项目每天20-24点监控平均数据,以小时为单位的,输出文件是excel的,要求以每天为单位单独一个sheet,汇总邮件转给业务. 他们主要是做业务使用量报表,每周周报使用,虽然需求困难,但作为运维也得解决,下面是邮件的效果图. 可以看到邮件标题是带有项目名称与时间,收集人是业务与我. 下面是excel的格式 每天一个sheet,获取这些项目自己每天20-24点的监控平均数据,以小时为单位. 主要是使用sql查看上面的监控数据,并通过py

zabbix3.0.4使用percona-monitoring-plugins插件来监控mysql5.6的详细实现过程

因为Zabbix自带的MySQL监控没有提供可以直接使用的Key,所以一般不采用,业界的同学们都使用Percona Monitoring Plugins 监控 MySQL的方式 Percona 为 MySQL 数据库服务器进行了改进,在功能和性能上较 MySQL 有着很显著的提升.该版本提升了在高负载情况下的 InnoDB 的性能.为 DBA 提供一些非常有用的性能诊断工具:另外有更多的参数和命令来控制服务器行为. 对线上的MySQL服务器实现监控,percona监控插件是php开发,因此要在a

Facebook 被指收集用户数据:通过照片和文本

北京时间5月25日消息,在加利福尼亚州进行的对Facebook泄露用户信息一案中,法院对Facebook提起一项新的诉讼,指控该公司通过App收集了用户及他们朋友的信息. 上周向加利福尼亚州圣马特奥市高级法院提起的该项诉讼是2015年由现已停止运营的创业公司Six4Three向Facebook提起诉讼的一部分. 据卫报报道,Facebook的高级管理人员的机密邮件和消息中泄露了该公司的信息.这些指控称,Facebook使用了几种方法来收集用户信息,从而用于商业目的.据报告,这些方法包括追踪用户的