Ⅰ 监控常用的应用软件有什么
常用的有:
1.cactio
实际上cacti不是监控工具，而是个依赖于SNMP的数据采集和数据呈现的工具。但是很多人喜欢用来当监控(因为其功能可以很好的完成这个工作)
功能:数据采集、 保存数据[SQL, txt].
数据展示(rrdtool 绘图)。
数据分析和报警(很一般)。
2. nagios。
功能:数据报警(报警功能是Nagios的特色功能) [ 故障触发，故障恢复都可以。
依赖分析报警(能自动的识别到关键设备的故障，关联设备不会报警)。
数据采集(采集的数据是弱项，他只关心警戒位，只关心正常与否的状态，状态转换时可以实现报警，所以它采集的数据不需要保存)，当然也有插件弥补这个不足，如PNP4Nagios。
3. zabbix (php)(推荐)
Nagiostcacti整合互相弥补不足!I
nagios和 cacti不适合超大规模的监控、由于大规模的带宽和网络限制,会导致监控的延迟等问题,所以有很多是 nagios+ cacti整合,但是依然不适合在大规模的环境中,不适合分布式部署, Nagios在大规模中就会出现延迟,失
去 Nagios本事的特色。
那么 zabbix同时整合了 cacti和 Nagios特点的工具,而且还具有了前两者不具有的工具,支持分布式等等。
4. 补充工具:
netdata:托管在github上的一款类型zabbix的开源监控工具https:/
/github. com/firehol/netdata
open- falcon:小米公司开源的企业级监控工具(python)(推荐)
Ganglia类似于 zabbix,大型分布式监控系统
开源监控工具对比http://www.oschina.net/news/67525/monitoring-tools
5. 监控软件数据采集的方式
SNMP 协议。
agent 代理的方式去采集数据。
shell 脚本api 接口
6. 数据展示方式
php html app
7. 数据告警
mail，msm，微信，电话，钉钉机器人
Ⅱ zabbix API如何不打log日志
请明确下具体是哪方面日志，如果是Debug的话，可以直接在Server配置中关闭。如果是Web日志的话，因为你这个是正常的API（Web）访问，只能配置禁止记录。如果是Nginx，可以参考这样：
location = /zabbix/api_jsonrpc.php{
access_log off;
log_not_found off;
}
Ⅲ 如何超链接到zabbix的screen页面
使用方式如下：
python ./screen_host.py -H 主机列表 -n screen名称 -G graph名称
具体的脚本：
#!/usr/bin/env python
import urllib2
import sys
import json
import argparse
def requestJason(url,values):
data = json.mps(values)
req = urllib2.Request(url, data, {'Content-Type': 'application/json-rpc'})
response = urllib2.urlopen(req, data)
data_get = response.read()
output = json.loads(data_get)
print output
try:
message = output['result']
except:
message = output['error']['data']
quit()
print json.mps(message)
return output
def authenticate(url, username, password):
values = {'jsonrpc': '2.0',
'method': 'user.login',
'params': {
'user': username,
'password': password
},
'id': '0'
}
idvalue = requestJason(url,values)
return idvalue['result']
def getHosts(hostname,url,auth):
host_list = []
values = {'jsonrpc': '2.0',
'method': 'host.get',
'params': {
'output': ["hostid","host"],
'filter': {
'host': hostname
}
},
'auth': auth,
'id': '2'
}
output = requestJason(url,values)
for host in output['result']:
host_list.append(host['hostid'])
return host_list
def getGraphs(host_list,name_list, url, auth, columns, graphtype=0 ,dynamic=0):
if (graphtype == 0):
selecttype = ['graphid']
select = 'selectGraphs'
if (graphtype == 1):
selecttype = ['itemid', 'value_type']
select = 'selectItems'
values = ({'jsonrpc': '2.0',
"method": "graph.get",
"params": {
select: [selecttype,"name"],
"output": ["graphid","name"],
"hostids": host_list,
"filter":{'name':name_list},
"sortfield":"name",
},
"auth": auth,
"id": '3'
})
print values
output = requestJason(url,values)
bb = sorted(output['result'],key = lambda x:x['hosts'][0]['hostid'])
output['result'] = bb
graphs = []
if (graphtype == 0):
for i in output['result']:
print i
graphs.append(i['graphid'])
if (graphtype == 1):
for i in output['result']:
if int(i['value_type']) in (0, 3):
graphs.append(i['itemid'])
graph_list = []
x = 0
y = 0
print graphs
for graph in graphs:
print "x is " + str(x)
print "y is " + str(y)
graph_list.append({
"resourcetype": graphtype,
"resourceid": graph,
"width": "500",
"height": "100",
"x": str(x),
"y": str(y),
"colspan": "0",
"rowspan": "0",
"elements": "0",
"valign": "0",
"halign": "0",
"style": "0",
"url": "",
"dynamic": str(dynamic)
})
x += 1
print type(x)
print type(columns)
if x == int(columns):
x = 0
y += 1
print graph_list
return graph_list
def screenCreate(url, auth, screen_name, graphids, columns):
columns = int(columns)
if len(graphids) % columns == 0:
vsize = len(graphids) / columns
else:
vsize = (len(graphids) / columns) + 1
values = {"jsonrpc": "2.0",
"method": "screen.create",
"params": [{
"name": screen_name,
"hsize": columns,
"vsize": vsize,
"screenitems": []
}],
"auth": auth,
"id": 2
}
for i in graphids:
values['params'][0]['screenitems'].append(i)
output = requestJason(url,values)
def main():
url = 'http://xxxx/api_jsonrpc.php'
username = 'xxxx'
password = 'xxxx'
auth = authenticate(url, username, password)
host_list = getHosts(hostname,url,auth)
print host_list
graph_ids = getGraphs(host_list,graphname, url, auth, columns)
screenCreate(url, auth, screenname, graph_ids, columns)
if __name__ == '__main__':
parser = argparse.ArgumentParser(description='Create Zabbix screen from all of a host Items or Graphs.')
parser.add_argument('-G', dest='graphname', nargs='+',metavar=('grah name'),
help='Zabbix Host Graph to create screen from')
parser.add_argument('-H', dest='hostname', nargs='+',metavar=('10.19.111.145'),
help='Zabbix Host to create screen from')
parser.add_argument('-n', dest='screenname', type=str,
help='Screen name in Zabbix. Put quotes around it if you want spaces in the name.')
parser.add_argument('-c', dest='columns', type=int,
help='number of columns in the screen')
args = parser.parse_args()
print args
hostname = args.hostname
screenname = args.screenname
columns = args.columns
graphname = args.graphname
if columns is None:
columns = len(graphname)
print columns
main()
Ⅳ zabbix 3版本 需要什么php版本
php的，用了thinkphp框架，i wipe，又造一遍轮子，之前和小伙伴@淑高用python弄过一个简单的运维后台，集成了saltstack和ansible，后来离职了就没搞了），现在想在cmdb系统中显示服务器的一些基本监控情况，这里用到zabbix api来获取服务器信息。
zabbix api 需要post过去的数据格式如下
Shell
{
"jsonrpc": "2.0",
"method": "method.name",
"params": {
"param_1_name": "param_1_value",
"param_2_name": "param_2_value"
},
"id": 1,
"auth": "",
}
Ⅳ 如何通过Zabbix获取监控数据
##################################
zabbix基本架构
##################################
1.Server
zabbix系统核心进程，轮询并捕获数据、发送通知等。是zabbix agent和zabbix proxy汇报数据的对象。server自身可远程检测网络服务。所有的前后端配置、统计信息、可操作数据存储于此。包含server、前段界面和后端DB几部分。
2.Agent
部署在被监控主机上用于监控本地资源和应用并向zabbix server汇报结果。使用本地系统调用故非常高效。有主动和被动两种检测模式。被动模式下agent根据server或proxy的具体请求来返回数据。主动模式下先主动由server获取监控项列表在检测并返回新的数据。采用主动或被动检测取决于相应监控项的配置。
3.Proxy
可以自由选择部署或者不部署，主要用于分担server的负载。在集中化监控远程位置、分支、网络的场景中是很好的解决方案。可从被监控设备收集数据缓存在proxy本地后传递给其所属的zabbix server。proxy需要单独的数据库。
4.java gateway
java实现的守护进程用于监控JMX类型的应用程序。
5.Sender
命令行工具zabbix_sender，用于向zabbix server发送性能数据和可用性数据。多用于用户脚本定期向server发送数据。
如：
shell> cd bin
shell> ./zabbix_sender -z zabbix -s "Linux DB3" -k db.connections -o 43
6.Get
命令行工具zabbix_get，用于同agent通信从agent获取数据。可用于zabbix agents的troubleshooting。
如：
shell> cd bin
shell> ./zabbix_get -s 127.0.0.1 -p 10050 -k "system.cpu.load[all,avg1]"
####################################
#zabbix术语表
####################################
host
需要被监控的设备，如交换机、路由器、WEB服务器、DB服务器等
host group
被监控设备的逻辑分组，如DB服务器一组、WEB服务器一组等。可包含主机和模板。用于权限控制
item
需要被监控的项，如CPU空闲率、某一块磁盘的使用率等
trigger
用于评估收到的监控值是否超出设定的阈值的逻辑表达式
event
如trigger状态改变等值得注意的事件
action
预先定义的响应event的一系列operations
escalation
执行action中的operations的定制场景；一连串的发送通知、执行远程命令
media
传递notification的方式
notification
通过media发送给用户的关于某个event的消息
remote command
在被监控机器上触发并自动执行的预定义命令
template
用于简化和加速主机上大规模监控任务的部署。包含一系列项目，如items, triggers, graphs, screens, applications, low-level discovery rules
application
逻辑组中的一组items
web scenario
一个或多个HTTP request用以检查web站点可用性
frontend
zabbix的web界面
zabbix api
允许通过JSON RPC 协议创建、更新和获取zabbix对象如，hosts, items, graphs and others。或者执行其他任务
zabbix server
zabbix核心，履行监控，与zabbix proxies、zabbix client交互、计算trigger、发送notification、存储数据等任务
zabbix agent
部署在被监控主机上用于监控本地资源和应用
zabbix proxy
可代zabbix server收集数据分担处理负载
######################################
#zabbix配置
######################################
可通过WEB界面或者模板进行配置
需配置内容包括users、user groups、hosts、host groups、items、Triggers、Events、notification、templates、visualisation等。
最终配置会被存储在后端database中。
#####################################
zabbix取数方式
####################################
1.zabbix api
基于WEB的API，通过JSON PRC协议获取或更改zabbix配置，并可用于获取历史监控数据。clients和API间的request和response使用JSON格式。包含一系列可从功能上分为不同组别的方法。
发起HTTP请求的格式类似如下：
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{"jsonrpc":"2.0","method":"apiinfo.version","id":1,"auth":null,"params":{}}
其中http://company.com/zabbix/是zabbix前端的地址；Content-Type必须指明且为application/json-rpc, application/json or application/jsonrequest三者之一。{"jsonrpc":"2.0","method":"apiinfo.version","id":1,"auth":null,"params":{}}是请求的具体内容。
一些实例：
*登录认证
{
"jsonrpc": "2.0",
"method": "user.login",
"params": {
"user": "Admin",
"password": "zabbix"
},
"id": 1,
"auth": null
}
其中：
jsonrpc:指明JSON-RPC协议版本，这里是2.0版本
method:指明调用的API方法，这里是用户登录
params:需要传递给API method的参数，这里是用户名和密码
id:本次请求的标识符
auth:用户认证令牌，目前尚无所以为null
若参数无误response将会包含用户认证令牌，如：
{
"jsonrpc": "2.0",
"result": "",
"id": 1
}
*获取hosts信息
{
"jsonrpc": "2.0",
"method": "host.get",
"params": {
"output": [
"hostid",
"host"
],
"selectInterfaces": [
"interfaceid",
"ip"
]
},
"id": 2,
"auth": ""
}
本例使用可用的用户认证令牌通过host.get方法获取所配置的主机的ID 、name等信息，返回如下
{
"jsonrpc": "2.0",
"result": [
{
"hostid": "10084",
"host": "Zabbix server",
"interfaces": [
{
"interfaceid": "1",
"ip": "127.0.0.1"
}
]
}
],
"id": 2
}
为了考虑性能影响、尽量仅列出所需项而非返回所有数据
*创建新监控项
例如在上一步获取的host上建立新的监控项、监控/home/joe/目录的剩余空间
{
"jsonrpc": "2.0",
"method": "item.create",
"params": {
"name": "Free disk space on $1",
"key_": "vfs.fs.size[/home/joe/,free]",
"hostid": "10084",
"type": 0,
"value_type": 3,
"interfaceid": "1",
"delay": 30
},
"auth": "",
"id": 3
}
其中params参数中的几个关键参数含义如下：
name：监控项的名称，这个可以自己灵活定义，其中的$1代表key_中的第一个参数，此处为/home/joe/
key_:预定义的监控项，zabbix提供了一系列此类监控内容，此处需从其中进行选择。
hostid：即上步获得的hostid
value_type:监控数据值的类型，不同的数字代表不同的类型，此处的3代表整型
delay：zabbix取数时间间隔，此处为30秒取一次
返回结果如下：
{
"jsonrpc": "2.0",
"result": {
"itemids": [
"24759"
]
},
"id": 3
}
itemid为生成的监控项的id
*获取历史数据：
从历史记录表获取itemids为23296的按clock降序排列的十条记录
history参数可能的取值
0 - float;
1 - string;
2 - log;
3 - integer;
4 - text.
{
"jsonrpc": "2.0",
"method": "history.get",
"params": {
"output": "extend",
"history": 0,
"itemids": "23296",
"sortfield": "clock",
"sortorder": "DESC",
"limit": 10
},
"auth": "",
"id": 1
}
返回结果：
{
"jsonrpc": "2.0",
"result": [
{
"itemid": "23296",
"clock": "1351090996",
"value": "0.0850",
"ns": "563157632"
},
{
"itemid": "23296",
"clock": "1351090936",
"value": "0.1600",
"ns": "549216402"
},
...]
}
*错误处理
下例忘记了groups这个参数
{
"jsonrpc": "2.0",
"method": "host.create",
"params": {
"host": "Linux server",
"interfaces": [
{
"type": 1,
"main": 1,
"useip": 1,
"ip": "192.168.3.1",
"dns": "",
"port": "10050"
}
]
},
"id": 3,
"auth": ""
}
返回结果如下，包含的不是result属性而是error属性
{
"jsonrpc": "2.0",
"error": {
"code": -32602,
"message": "Invalid params.",
"data": "No groups for host \"Linux server\"."
},
"id": 3
}
对于获取监控数据来说，比较关心的应该是history.get这个方法。这种方式实际上最终还是由后台数据库获取的。方法提供了丰富的参数，使用非常灵活。但对于一次性大规模的取出大量主机大量监控项的大批数据不太适合。
2.zabbix_get:
命令行工具，可从远程的zabbix agent获取数据
zabbix_get [-hV] [-s <host name or IP>] [-p <port number>] [-I <IP address>] [-k <item key>]
-s, --host <host name or IP>
-p, --port <port number>
-I, --source-address <IP address>
-k, --key <item key>
-h, --help
-V, --version.
如：zabbix_get -s 127.0.0.1 -p 10050 -k system.cpu.load[all,avg1]
zabbix api获取到的是数据库中的历史数据，zabbix_get可获得实时的数据。可根据工具的特点选择适合的场景。
3.zabbix databases:
直接由zabbix后台数据库获取历史数据。适用于一次性大规模的取出大量主机大量监控项的大批数据。
*相关表
history系列表分别存储不同数据类型的历史数据
表中数据以update interval为时间间隔
zabbix.history -numeric(float)
zabbix.history_log -log
zabbix.history_str -character(up to 255 bytes)
zabbix.history_text -text
zabbix.history_unit -numeric(unsigned intergers)
trends_系列表存储不同类型的历史数据统计结果
表中数据以小时为时间间隔，存储每小时的最小、最大和平均值
zabbix.trends -numeric(float)
zabbix.trends_unit -numeric(unsigned intergers)
character\log\text\类型无历史统计结果
history系列的表只包含itemid、clock、value等数据
trends系列的表只包含itemid、clock、value_min、value_avg、value_max等数据
history、trends需与items、hosts、hosts_groups、groups表关联来获取item名称、host名称、组别等。
*表及重要的表字段
hosts
hosts.hostid 主机id
hosts.host 主机名
hosts.status 主机状态 0为正常监控，1为关闭，3表示是个Template，5尚不不清楚。
hosts_group
hosts_group.hostid 主机id
hosts_group.groupid 所属组id
groups
groups.groupid 组id
groups.name 组名
items
items.itemid 监控项id
items.hostid 监控项所在主机id
items.name 监控项别名
items.key_ 监控项标准名称
items.value_type值类型
items.delay 取数时间间隔
items.history 历史表数据保留天数
items.trends 历史统计表数据保留天数
item.units 数据单位
items表中value_type与history的对应关系
(主要为了存取效率将不同值类型存在不同的history表中)
value_type history表
0 history
1 history_str
2 history_log
3 history_uint
4 history_text
history
hisrtory.itemid 监控项id
trends
trends.itemid 监控项id
zabbix后台系统的涉及到大量的表，取历史数据的话关心这几个即可
*监控项规则解读
zabbix.items表中存在类似于如下的配置项(如网络网卡监控、磁盘监控等)：
name key_
Free disk space on $1 vfs.fs.size[/,free]
Free disk space on / (percentage) vfs.fs.size[/,pfree]
Free disk space on $1 vfs.fs.size[/boot,free]
Free disk space on /boot (percentage) vfs.fs.size[/boot,pfree]
Free disk space on $1 vfs.fs.size[/data,free]
Free disk space on /data (percentage) vfs.fs.size[/data,pfree]
Free disk space on $1 vfs.fs.size[{#FSNAME},free]
Free disk space on {#FSNAME} (percentage) vfs.fs.size[{#FSNAME},pfree]
其中类似于如下的配置是zabbix提供的low level discovery配置方式，用于自动创建监控项适用于有多块磁盘、多个目录、多块网卡等类型情形下监控项的自动发现
可以把{#FSNAME}看做是模板可以匹配配置好的所有的相关项比如：
Free disk space on {#FSNAME} (percentage) vfs.fs.size[{#FSNAME},pfree]
Free disk space on /data (percentage) vfs.fs.size[/data,pfree]
Free disk space on /boot (percentage) vfs.fs.size[/boot,pfree]
Free disk space on / (percentage) vfs.fs.size[/,pfree]
类似的还有：
Incoming network traffic on $1 net.if.in[{#IFNAME}]
Outgoing network traffic on $1 net.if.out[{#IFNAME}]
IO.util.{#DISK_NAME} IO.util[{#DISK_NAME}]
等等
而上边例子中的$1、$2等对应key_的参数位置，例如
Free disk space on $1 vfs.fs.size[/,free]
中$1就代表/ ,Free disk space on $1相当于Free disk space on /依次类推
Ⅵ 主流的开源的网络摄像机搭载的WEB界面软件有哪几个
1. 开源网络监控工具： NetXMS
NetXMS 提供了企业级开源网络管理和监控程序，它在Windows和Linux上有一个简单的用户界面。
NetXMS通过相对简单的安装过程为IT基础架构的所有层提供了分布式网络监控、自动化网络发现和详细报告。
此外，服务器设备和代理对于这样一个全面的产品来说是相当轻量级的。
2. 开源网络监控工具: Pandora FMS
定位于企业级， Pandora FMS 提供了一个时尚且整洁的用户体验，提供了易于阅读的快速洞察工具以及重要的网络统计信息，例如网络状态、已上报的告警、已部署的代理数量和其他最近执行任务的列表。
Pandora FMS可以在无需外部访问的情况下执行网络诊断，这意味着用户可以更快地响应任何网络问题。事实上，FMS声称，在代理模式下的器监控系统响应速度约为10秒。
3. 开源网络监控工具: Cacti
最初发布于2001年， Cacti 是一款开源的基于Web的网络监控和专为数据记录而设计的图形化工具。它可以用于实时显示网络数据，如CPU负载或带宽利用率。
Cacti是RRDtool的前端应用程序，RRDtool是一种用于存储实时变化数据的开源数据库工具，其使用SNMP作为其默认收集算法，但如果你喜欢本地Perl的PHP脚本，那么你也可以使用它们。
其最新版本0.8.8h于2016年5月发布，主要功能包括无限图形项目、图形自动填充支持、图形数据处理、自定义数据采集脚本、内置SNMP支持、图形模板、数据源模板、主机模板和基于用户的管理。
4. 开源网络监控工具: GroundWork Monitor Core
GroundWork Monitor Core 是监控网络、应用和云计算使用情况的平台。开源版本包含最多可监控50个设备和基于社区的支持的许可证，该软件还有其对应的商业版本。
在其网络管理功能方面，GroundWork提供网络和设备的自发现和维护、拓扑、报警控制、通过API/SNMP/IPMI的数据收集和对OpenDaylight SDN的支持等功能。
GroundWork还提供了存储管理，支持大规模的企业级供应商，如NetApp和EMC，以及从磁盘、块或对象存储的数据收集和存储缓冲以及中断可视化。
由于GroundWork的一站式网络管理方法，这种套件可能更适合那些寻找成熟品牌的大型商业和企业，而不是以开发人员为重点的工具，如Big Brother或Big Sister。
5. 开源网络监控工具：Hyperic
VMware的 Hyperic 工具用于在物理、虚拟或云环境下监控Web应用程序及其性能。 它适用于应用程序服务器，web服务器，数据库，操作系统，虚拟机管理程序，消息传递服务和目录服务器。
Hyperic提供基础架构和操作系统监控，详细的报告，应用程序和中间件监控，警报和修复工作流程以及通用可扩展的API。
该网络监控工具提供了企业版本，可以提高网络警报功能，并且能更好地创建基准。
6. 开源网络监控工具: Observium
基于Linux的 Observium 是一个自动监测的网络监控工具。 据该网站介绍，“该工具是由一批经验丰富的专业网络工程师和系统管理员开发和维护的，Observium是一个由用户自己设计和构建的平台。”
Observium提供社区版本和专业版，使用RRDTool进行缓冲存储和图形化功能，并具有易于使用的用户界面和报告功能。 但是，它没有报告导出功能，这可能对商务应用来讲会是一个问题。
社区版本将为用户提供对所有支持设备或指标的完整 自动监测功能， 通过自动发现协议进行网络映射， 自动识别数百种设备，并且每六个月发布一个新版本。
而专业版用户将获得所有社区版本的功能并且还将获得实时软件更新和修复功能，基于规则的自动分组功能，网络阈值和状态警报系统以及流量统计系统。
7. 开源网络监控工具: Zabbix
Zabbix 作为企业级的网络监控工具，通过从服务器，虚拟机和网络设备收集的数据提供实时监控，自动发现，映射和可扩展等功能。
Zabbix的企业级监控软件为用户提供内置的Java应用服务器监控，硬件监控，VMware监控和CPU，内存，网络，磁盘空间性能监控。
Ⅶ zabbix 通过什么方式监控vmware
Zabbix通过专用的Agent或者SNMP收集相关的监控数据，然后存储到数据库里面实时在前台展示。Zabbix监控数据主要分为以下两类：
历史数据：history相关表,从history_uint表里面可以查询到设备监控项目的最大，最小和平均值,即存储监控数据的原始数据。
趋势数据：trends相关表,趋势数据是经过Zabbix计算的数据，数据是从history_uint里面汇总的，从trends_uint可以查看到监控数据每小时最大，最小和平均值，即存储监控数据的汇总数据。
Zabbix可以通过两种方式获取历史数据：
1.通过Zabbix前台获取历史数据
通过Zabbix前台查看历史数据非常简单，可以通过Monitoring->Lastest data的方式查看。也可以点击右上角的As plain test按钮保存成文本文件。
2.通过前台获取的数据进行处理和二次查询有很多限制，因此可以通过SQL语句直接从后台DB查询数据。
首先大家应该熟悉SQL语句Select 常用用法：
SELECT [ALL | DISTINCT] Select_List [INTO [New_Table_name]
FROM { Table_name | View_name} [ [,{table2_name | view2_name}
[,…] ]
[ WHERE Serch_conditions ]
[ GROUP BY Group_by_list ]
[ HAVING Serch_conditions ]
[ ORDER BY Order_list [ASC| DEsC] ]
说明：
1)SELECT子句指定要查询的特定表中的列，它可以是*，表达式，列表等。
2)INTO子句指定要生成新的表。
3)FROM子句指定要查询的表或者视图。
4)WHERE子句用来限定查询的范围和条件。
5)GROUP BY子句指定分组查询子句。
6)HAVING子句用于指定分组子句的条件。
7)ORDER BY可以根据一个或者多个列来排序查询结果，在该子句中，既可以使用列名，也可以使用相对列号，ASC表示升序，DESC表示降序。
8）mysql聚合函数：sum()，count()，avg()，max()，avg()等都是聚合函数，当我们在用聚合函数的时候，一般都要用到GROUP BY 先进行分组，然后再进行聚合函数的运算。运算完后就要用到Having子句进行判断了,例如聚合函数的值是否大于某一个值等等。
分享
本回答由电脑网络分类达人 化晓峰认证
其他类似问题
2015-05-26如何通过Zabbix获取监控数据
2015-02-03如何从Zabbix数据库中获取监控数据
2014-12-24zabbix对zabbix错误日志进行监控求助
2014-11-06Zabbix 如何监控服务器硬件信息
2015-04-26zabbix怎么监控nginx
更多关于zabbix 通过什么方式监控vmware的问题>>
为您推荐：
2015-01-03 10:22提问者采纳
##################################
zabbix基本架构
##################################
1.Server
zabbix系统核心进程，轮询并捕获数据、发送通知等。是zabbix agent和zabbix proxy汇报数据的对象。server自身可远程检测网络服务。所有的前后端配置、统计信息、可操作数据存储于此。包含server、前段界面和后端DB几部分。
2.Agent
部署在被监控主机上用于监控本地资源和应用并向zabbix server汇报结果。使用本地系统调用故非常高效。有主动和被动两种检测模式。被动模式下agent根据server或proxy的具体请求来返回数据。主动模式下先主动由server获取监控项列表在检测并返回新的数据。采用主动或被动检测取决于相应监控项的配置。
3.Proxy
可以自由选择部署或者不部署，主要用于分担server的负载。在集中化监控远程位置、分支、网络的场景中是很好的解决方案。可从被监控设备收集数据缓存在proxy本地后传递给其所属的zabbix server。proxy需要单独的数据库。
4.Java gateway
java实现的守护进程用于监控JMX类型的应用程序。
5.Sender
命令行工具zabbix_sender，用于向zabbix server发送性能数据和可用性数据。多用于用户脚本定期向server发送数据。
如：
shell> cd bin
shell> ./zabbix_sender -z zabbix -s "Linux DB3" -k db.connections -o 43
6.Get
命令行工具zabbix_get，用于同agent通信从agent获取数据。可用于zabbix agents的troubleshooting。
如：
shell> cd bin
shell> ./zabbix_get -s 127.0.0.1 -p 10050 -k "system.cpu.load[all,avg1]"
####################################
#zabbix术语表
####################################
host
需要被监控的设备，如交换机、路由器、WEB服务器、DB服务器等
host group
被监控设备的逻辑分组，如DB服务器一组、WEB服务器一组等。可包含主机和模板。用于权限控制
item
需要被监控的项，如CPU空闲率、某一块磁盘的使用率等
trigger
用于评估收到的监控值是否超出设定的阈值的逻辑表达式
event
如trigger状态改变等值得注意的事件
action
预先定义的响应event的一系列operations
escalation
执行action中的operations的定制场景；一连串的发送通知、执行远程命令
media
传递notification的方式
notification
通过media发送给用户的关于某个event的消息
remote command
在被监控机器上触发并自动执行的预定义命令
template
用于简化和加速主机上大规模监控任务的部署。包含一系列项目，如items, triggers, graphs, screens, applications, low-level discovery rules
application
逻辑组中的一组items
web scenario
一个或多个HTTP request用以检查web站点可用性
frontend
zabbix的web界面
zabbix api
允许通过JSON RPC 协议创建、更新和获取zabbix对象如，hosts, items, graphs and others。或者执行其他任务
zabbix server
zabbix核心，履行监控，与zabbix proxies、zabbix client交互、计算trigger、发送notification、存储数据等任务
zabbix agent
部署在被监控主机上用于监控本地资源和应用
zabbix proxy
可代zabbix server收集数据分担处理负载
######################################
#zabbix配置
######################################
可通过WEB界面或者模板进行配置
需配置内容包括users、user groups、hosts、host groups、items、Triggers、Events、notification、templates、visualisation等。
最终配置会被存储在后端database中。
#####################################
zabbix取数方式
####################################
1.zabbix api
基于WEB的API，通过JSON PRC协议获取或更改zabbix配置，并可用于获取历史监控数据。clients和API间的request和response使用JSON格式。包含一系列可从功能上分为不同组别的方法。
发起HTTP请求的格式类似如下：
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{"jsonrpc":"2.0","method":"apiinfo.version","id":1,"auth":null,"params":{}}
其中http://company.com/zabbix/是zabbix前端的地址；Content-Type必须指明且为application/json-rpc, application/json or application/jsonrequest三者之一。{"jsonrpc":"2.0","method":"apiinfo.version","id":1,"auth":null,"params":{}}是请求的具体内容。
一些实例：
*登录认证
{
"jsonrpc": "2.0",
"method": "user.login",
"params": {
"user": "Admin",
"password": "zabbix"
},
"id": 1,
"auth": null
}
其中：
jsonrpc:指明JSON-RPC协议版本，这里是2.0版本
method:指明调用的API方法，这里是用户登录
params:需要传递给API method的参数，这里是用户名和密码
id:本次请求的标识符
auth:用户认证令牌，目前尚无所以为null
若参数无误response将会包含用户认证令牌，如：
{
"jsonrpc": "2.0",
"result": "",
"id": 1
}
*获取hosts信息
{
"jsonrpc": "2.0",
"method": "host.get",
"params": {
"output": [
"hostid",
"host"
],
"selectInterfaces": [
"interfaceid",
"ip"
]
},
"id": 2,
"auth": ""
}
本例使用可用的用户认证令牌通过host.get方法获取所配置的主机的ID 、name等信息，返回如下
{
"jsonrpc": "2.0",
"result": [
{
"hostid": "10084",
"host": "Zabbix server",
"interfaces": [
{
"interfaceid": "1",
"ip": "127.0.0.1"
}
]
}
],
"id": 2
}
为了考虑性能影响、尽量仅列出所需项而非返回所有数据
*创建新监控项
例如在上一步获取的host上建立新的监控项、监控/home/joe/目录的剩余空间
{
"jsonrpc": "2.0",
"method": "item.create",
"params": {
"name": "Free disk space on $1",
"key_": "vfs.fs.size[/home/joe/,free]",
"hostid": "10084",
"type": 0,
"value_type": 3,
"interfaceid": "1",
"delay": 30
},
"auth": "",
"id": 3
}
其中params参数中的几个关键参数含义如下：
name：监控项的名称，这个可以自己灵活定义，其中的$1代表key_中的第一个参数，此处为/home/joe/
key_:预定义的监控项，zabbix提供了一系列此类监控内容，此处需从其中进行选择。
hostid：即上步获得的hostid
value_type:监控数据值的类型，不同的数字代表不同的类型，此处的3代表整型
delay：zabbix取数时间间隔，此处为30秒取一次
返回结果如下：
{
"jsonrpc": "2.0",
"result": {
"itemids": [
"24759"
]
},
"id": 3
}
itemid为生成的监控项的id
*获取历史数据：
从历史记录表获取itemids为23296的按clock降序排列的十条记录
history参数可能的取值
0 - float;
1 - string;
2 - log;
3 - integer;
4 - text.
{
"jsonrpc": "2.0",
"method": "history.get",
"params": {
"output": "extend",
"history": 0,
"itemids": "23296",
"sortfield": "clock",
"sortorder": "DESC",
"limit": 10
},
"auth": "",
"id": 1
}
返回结果：
{
"jsonrpc": "2.0",
"result": [
{
"itemid": "23296",
"clock": "1351090996",
"value": "0.0850",
"ns": "563157632"
},
{
"itemid": "23296",
"clock": "1351090936",
"value": "0.1600",
"ns": "549216402"
},
...]
}
*错误处理
下例忘记了groups这个参数
{
"jsonrpc": "2.0",
"method": "host.create",
"params": {
"host": "Linux server",
"interfaces": [
{
"type": 1,
"main": 1,
"useip": 1,
"ip": "192.168.3.1",
"dns": "",
"port": "10050"
}
]
},
"id": 3,
"auth": ""
}
返回结果如下，包含的不是result属性而是error属性
{
"jsonrpc": "2.0",
"error": {
"code": -32602,
"message": "Invalid params.",
"data": "No groups for host \"Linux server\"."
},
"id": 3
}
对于获取监控数据来说，比较关心的应该是history.get这个方法。这种方式实际上最终还是由后台数据库获取的。方法提供了丰富的参数，使用非常灵活。但对于一次性大规模的取出大量主机大量监控项的大批数据不太适合。
2.zabbix_get:
命令行工具，可从远程的zabbix agent获取数据
zabbix_get [-hV] [-s <host name or IP>] [-p <port number>] [-I <IP address>] [-k <item key>]
-s, --host <host name or IP>
-p, --port <port number>
-I, --source-address <IP address>
-k, --key <item key>
-h, --help
-V, --version.
如：zabbix_get -s 127.0.0.1 -p 10050 -k system.cpu.load[all,avg1]
zabbix api获取到的是数据库中的历史数据，zabbix_get可获得实时的数据。可根据工具的特点选择适合的场景。
3.zabbix databases:
直接由zabbix后台数据库获取历史数据。适用于一次性大规模的取出大量主机大量监控项的大批数据。
*相关表
history系列表分别存储不同数据类型的历史数据
表中数据以update interval为时间间隔
zabbix.history -numeric(float)
zabbix.history_log -log
zabbix.history_str -character(up to 255 bytes)
zabbix.history_text -text
zabbix.history_unit -numeric(unsigned intergers)
trends_系列表存储不同类型的历史数据统计结果
表中数据以小时为时间间隔，存储每小时的最小、最大和平均值
zabbix.trends -numeric(float)
zabbix.trends_unit -numeric(unsigned intergers)
character\log\text\类型无历史统计结果
history系列的表只包含itemid、clock、value等数据
trends系列的表只包含itemid、clock、value_min、value_avg、value_max等数据
history、trends需与items、hosts、hosts_groups、groups表关联来获取item名称、host名称、组别等。
*表及重要的表字段
hosts
hosts.hostid 主机id
hosts.host 主机名
hosts.status 主机状态 0为正常监控，1为关闭，3表示是个Template，5尚不不清楚。
hosts_group
hosts_group.hostid 主机id
hosts_group.groupid 所属组id
groups
groups.groupid 组id
groups.name 组名
items
items.itemid 监控项id
items.hostid 监控项所在主机id
items.name 监控项别名
items.key_ 监控项标准名称
items.value_type值类型
items.delay 取数时间间隔
items.history 历史表数据保留天数
items.trends 历史统计表数据保留天数
item.units 数据单位
items表中value_type与history的对应关系
(主要为了存取效率将不同值类型存在不同的history表中)
value_type history表
0 history
1 history_str
2 history_log
3 history_uint
4 history_text
history
hisrtory.itemid 监控项id
trends
trends.itemid 监控项id
zabbix后台系统的涉及到大量的表，取历史数据的话关心这几个即可
*监控项规则解读
zabbix.items表中存在类似于如下的配置项(如网络网卡监控、磁盘监控等)：
name key_
Free disk space on $1 vfs.fs.size[/,free]
Free disk space on / (percentage) vfs.fs.size[/,pfree]
Free disk space on $1 vfs.fs.size[/boot,free]
Free disk space on /boot (percentage) vfs.fs.size[/boot,pfree]
Free disk space on $1 vfs.fs.size[/data,free]
Free disk space on /data (percentage) vfs.fs.size[/data,pfree]
Free disk space on $1 vfs.fs.size[{#FSNAME},free]
Free disk space on {#FSNAME} (percentage) vfs.fs.size[{#FSNAME},pfree]
其中类似于如下的配置是zabbix提供的low level discovery配置方式，用于自动创建监控项适用于有多块磁盘、多个目录、多块网卡等类型情形下监控项的自动发现
可以把{#FSNAME}看做是模板可以匹配配置好的所有的相关项比如：
Free disk space on {#FSNAME} (percentage) vfs.fs.size[{#FSNAME},pfree]
Free disk space on /data (percentage) vfs.fs.size[/data,pfree]
Free disk space on /boot (percentage) vfs.fs.size[/boot,pfree]
Free disk space on / (percentage) vfs.fs.size[/,pfree]
类似的还有：
Incoming network traffic on $1 net.if.in[{#IFNAME}]
Outgoing network traffic on $1 net.if.out[{#IFNAME}]
IO.util.{#DISK_NAME} IO.util[{#DISK_NAME}]
等等
而上边例子中的$1、$2等对应key_的参数位置，例如
Free disk space on $1 vfs.fs.size[/,free]
中$1就代表/ ,Free disk space on $1相当于Free disk space on /依次类推
Ⅷ zabbix jsrpc.php 什么东西
“jsonrpc”: “2.0”-这是标准的JSON RPC参数以标示协议版本。所有的请求都会保持不变。
“method”: “method.name”-这个参数定义了真实执行的操作。例如：host.create、item.update等等
“params”-这里通过传递JSON对象来作为特定方法的参数。如果你希望创建监控项，”name”和”key_”参数是需要的，每个方法需要的参数在Zabbix API文档中都有描述。
“id”: 1-这个字段用于绑定JSON请求和响应。响应会跟请求有相同的”id”。在一次性发送多个请求时很有用，这些也不需要唯一或者连续
“auth”: “″-这是一个认证令牌【authentication token】用以鉴别用户、访问API。这也是使用API进行相关操作的前提-获取认证ID。
Ⅸ 如何通过zabbix 获取监控数据
zabbix基本架构：
1.Server
zabbix系统核心进程，轮询并捕获数据、发送通知等。是zabbix agent和zabbix proxy汇报数据的对象。server自身可远程检测网络服务。所有的前后端配置、统计信息、可操作数据存储于此。包含server、前段界面和后端DB几部分。
2.Agent
部署在被监控主机上用于监控本地资源和应用并向zabbix server汇报结果。使用本地系统调用故非常高效。有主动和被动两种检测模式。被动模式下agent根据server或proxy的具体请求来返回数据。主动模式下先主动由server获取监控项列表在检测并返回新的数据。采用主动或被动检测取决于相应监控项的配置。
3.Proxy
可以自由选择部署或者不部署，主要用于分担server的负载。在集中化监控远程位置、分支、网络的场景中是很好的解决方案。可从被监控设备收集数据缓存在proxy本地后传递给其所属的zabbix server。proxy需要单独的数据库。
4.Java gateway
java实现的守护进程用于监控JMX类型的应用程序。
5.Sender
命令行工具zabbix_sender，用于向zabbix server发送性能数据和可用性数据。多用于用户脚本定期向server发送数据。
如：
shell> cd bin
shell> ./zabbix_sender -z zabbix -s "Linux DB3" -k db.connections -o 43
6.Get
命令行工具zabbix_get，用于同agent通信从agent获取数据。可用于zabbix agents的troubleshooting。
如：
shell> cd bin
shell> ./zabbix_get -s 127.0.0.1 -p 10050 -k "system.cpu.load[all,avg1]"
#zabbix术语表：
host
需要被监控的设备，如交换机、路由器、WEB服务器、DB服务器等
host group
被监控设备的逻辑分组，如DB服务器一组、WEB服务器一组等。可包含主机和模板。用于权限控制
item
需要被监控的项，如CPU空闲率、某一块磁盘的使用率等
trigger
用于评估收到的监控值是否超出设定的阈值的逻辑表达式
event
如trigger状态改变等值得注意的事件
action
预先定义的响应event的一系列operations
escalation
执行action中的operations的定制场景；一连串的发送通知、执行远程命令
media
传递notification的方式
notification
通过media发送给用户的关于某个event的消息
remote command
在被监控机器上触发并自动执行的预定义命令
template
用于简化和加速主机上大规模监控任务的部署。包含一系列项目，如items, triggers, graphs, screens, applications, low-level discovery rules
application
逻辑组中的一组items
web scenario
一个或多个HTTP request用以检查web站点可用性
frontend
zabbix的web界面
zabbix api
允许通过JSON RPC 协议创建、更新和获取zabbix对象如，hosts, items, graphs and others。或者执行其他任务
zabbix server
zabbix核心，履行监控，与zabbix proxies、zabbix client交互、计算trigger、发送notification、存储数据等任务
zabbix agent
部署在被监控主机上用于监控本地资源和应用
zabbix proxy
可代zabbix server收集数据分担处理负载
#zabbix配置：
可通过WEB界面或者模板进行配置
需配置内容包括users、user groups、hosts、host groups、items、Triggers、Events、notification、templates、visualisation等。
最终配置会被存储在后端database中。
参考：
https://www.zabbix.com/documentation/2.4/manual/config
zabbix取数方式
1.zabbix api
基于WEB的API，通过JSON PRC协议获取或更改zabbix配置，并可用于获取历史监控数据。clients和API间的request和response使用JSON格式。包含一系列可从功能上分为不同组别的方法。
发起HTTP请求的格式类似如下：
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{"jsonrpc":"2.0","method":"apiinfo.version","id":1,"auth":null,"params":{}}
其中http://company.com/zabbix/是zabbix前端的地址；Content-Type必须指明且为application/json-rpc, application/json or application/jsonrequest三者之一。{"jsonrpc":"2.0","method":"apiinfo.version","id":1,"auth":null,"params":{}}是请求的具体内容。
一些实例：
*登录认证
{
"jsonrpc": "2.0",
"method": "user.login",
"params": {
"user": "Admin",
"password": "zabbix"
},
"id": 1,
"auth": null
}
其中：
jsonrpc:指明JSON-RPC协议版本，这里是2.0版本
method:指明调用的API方法，这里是用户登录
params:需要传递给API method的参数，这里是用户名和密码
id:本次请求的标识符
auth:用户认证令牌，目前尚无所以为null
若参数无误response将会包含用户认证令牌，如：
{
"jsonrpc": "2.0",
"result": "",
"id": 1
}
*获取hosts信息
{
"jsonrpc": "2.0",
"method": "host.get",
"params": {
"output": [
"hostid",
"host"
],
"selectInterfaces": [
"interfaceid",
"ip"
]
},
"id": 2,
"auth": ""
}
本例使用可用的用户认证令牌通过host.get方法获取所配置的主机的ID 、name等信息，返回如下
{
"jsonrpc": "2.0",
"result": [
{
"hostid": "10084",
"host": "Zabbix server",
"interfaces": [
{
"interfaceid": "1",
"ip": "127.0.0.1"
}
]
}
],
"id": 2
}
为了考虑性能影响、尽量仅列出所需项而非返回所有数据
*创建新监控项
例如在上一步获取的host上建立新的监控项、监控/home/joe/目录的剩余空间
{
"jsonrpc": "2.0",
"method": "item.create",
"params": {
"name": "Free disk space on $1",
"key_": "vfs.fs.size[/home/joe/,free]",
"hostid": "10084",
"type": 0,
"value_type": 3,
"interfaceid": "1",
"delay": 30
},
"auth": "",
"id": 3
}
其中params参数中的几个关键参数含义如下：
name：监控项的名称，这个可以自己灵活定义，其中的$1代表key_中的第一个参数，此处为/home/joe/
key_:预定义的监控项，zabbix提供了一系列此类监控内容，此处需从其中进行选择。
hostid：即上步获得的hostid
value_type:监控数据值的类型，不同的数字代表不同的类型，此处的3代表整型
delay：zabbix取数时间间隔，此处为30秒取一次
返回结果如下：
{
"jsonrpc": "2.0",
"result": {
"itemids": [
"24759"
]
},
"id": 3
}
itemid为生成的监控项的id
*获取历史数据：
从历史记录表获取itemids为23296的按clock降序排列的十条记录
history参数可能的取值
0 - float;
1 - string;
2 - log;
3 - integer;
4 - text.
{
"jsonrpc": "2.0",
"method": "history.get",
"params": {
"output": "extend",
"history": 0,
"itemids": "23296",
"sortfield": "clock",
"sortorder": "DESC",
"limit": 10
},
"auth": "",
"id": 1
}
返回结果：
{
"jsonrpc": "2.0",
"result": [
{
"itemid": "23296",
"clock": "1351090996",
"value": "0.0850",
"ns": "563157632"
},
{
"itemid": "23296",
"clock": "1351090936",
"value": "0.1600",
"ns": "549216402"
},
...]
}
*错误处理
下例忘记了groups这个参数
{
"jsonrpc": "2.0",
"method": "host.create",
"params": {
"host": "Linux server",
"interfaces": [
{
"type": 1,
"main": 1,
"useip": 1,
"ip": "192.168.3.1",
"dns": "",
"port": "10050"
}
]
},
"id": 3,
"auth": ""
}
返回结果如下，包含的不是result属性而是error属性
{
"jsonrpc": "2.0",
"error": {
"code": -32602,
"message": "Invalid params.",
"data": "No groups for host \"Linux server\"."
},
"id": 3
}
对于获取监控数据来说，比较关心的应该是history.get这个方法。这种方式实际上最终还是由后台数据库获取的。方法提供了丰富的参数，使用非常灵活。但对于一次性大规模的取出大量主机大量监控项的大批数据不太适合。
Ⅹ zabbix3.0需要php什么版本
php的，用了thinkphp框架，i wipe，又造一遍轮子，之前和小伙伴@淑高用python弄过一个简单的运维后台，集成了saltstack和ansible，后来离职了就没搞了），现在想在cmdb系统中显示服务器的一些基本监控情况，这里用到zabbix api来获取服务器信息。
zabbix api 需要post过去的数据格式如下
Shell
{
"jsonrpc": "2.0",
"method": "method.name",
"params": {
"param_1_name": "param_1_value",
"param_2_name": "param_2_value"
},
"id": 1,
"auth": "",
}