共计 14518 个字符，预计需要花费 37 分钟才能阅读完成。
##################################
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”: “0424bd59b807674191e7d77572075f33”,
“id”: 1
}
* 获取 hosts 信息
{
“jsonrpc”: “2.0”,
“method”: “host.get”,
“params”: {
“output”: [
“hostid”,
“host”
],
“selectInterfaces”: [
“interfaceid”,
“ip”
]
},
“id”: 2,
“auth”: “0424bd59b807674191e7d77572075f33”
}
本例使用可用的用户认证令牌通过 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”: “0424bd59b807674191e7d77572075f33”,
“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”: “038e1d7b1735c6a5436ee9eae095879e”,
“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”: “0424bd59b807674191e7d77572075f33”
}
返回结果如下，包含的不是 result 属性而是 error 属性
{
“jsonrpc”: “2.0”,
“error”: {
“code”: -32602,
“message”: “Invalid params.”,
“data”: “No groups for host \”Linux server\”.”
},
“id”: 3
}
对于获取监控数据来说，比较关心的应该是 history.get 这个方法。这种方式实际上最终还是由后台数据库获取的。方法提供了丰富的参数，使用非常灵活。但对于一次性大规模的取出大量主机大量监控项的大批数据不太适合。
参考：
https://www.zabbix.com/documentation/2.4/manual/api
一些 Zabbix 相关教程集合：
安装部署分布式监控系统 Zabbix 2.06 http://www.linuxidc.com/Linux/2013-07/86942.htm
《安装部署分布式监控系统 Zabbix 2.06》http://www.linuxidc.com/Linux/2013-07/86942.htm
CentOS 6.3 下 Zabbix 安装部署 http://www.linuxidc.com/Linux/2013-05/83786.htm
Zabbix 分布式监控系统实践 http://www.linuxidc.com/Linux/2013-06/85758.htm
CentOS 6.3 下 Zabbix 监控 apache server-status http://www.linuxidc.com/Linux/2013-05/84740.htm
CentOS 6.3 下 Zabbix 监控 MySQL 数据库参数 http://www.linuxidc.com/Linux/2013-05/84800.htm
64 位 CentOS 6.2 下安装 Zabbix 2.0.6 http://www.linuxidc.com/Linux/2014-11/109541.htm
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2014-12/110450p2.htm
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 可获得实时的数据。可根据工具的特点选择适合的场景。
参考：
https://www.zabbix.com/documentation/2.4/manpages/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 的详细介绍：请点这里
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”: “0424bd59b807674191e7d77572075f33”,
“id”: 1
}
* 获取 hosts 信息
{
“jsonrpc”: “2.0”,
“method”: “host.get”,
“params”: {
“output”: [
“hostid”,
“host”
],
“selectInterfaces”: [
“interfaceid”,
“ip”
]
},
“id”: 2,
“auth”: “0424bd59b807674191e7d77572075f33”
}
本例使用可用的用户认证令牌通过 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”: “0424bd59b807674191e7d77572075f33”,
“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”: “038e1d7b1735c6a5436ee9eae095879e”,
“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”: “0424bd59b807674191e7d77572075f33”
}
返回结果如下，包含的不是 result 属性而是 error 属性
{
“jsonrpc”: “2.0”,
“error”: {
“code”: -32602,
“message”: “Invalid params.”,
“data”: “No groups for host \”Linux server\”.”
},
“id”: 3
}
对于获取监控数据来说，比较关心的应该是 history.get 这个方法。这种方式实际上最终还是由后台数据库获取的。方法提供了丰富的参数，使用非常灵活。但对于一次性大规模的取出大量主机大量监控项的大批数据不太适合。
参考：
https://www.zabbix.com/documentation/2.4/manual/api
一些 Zabbix 相关教程集合：
安装部署分布式监控系统 Zabbix 2.06 http://www.linuxidc.com/Linux/2013-07/86942.htm
《安装部署分布式监控系统 Zabbix 2.06》http://www.linuxidc.com/Linux/2013-07/86942.htm
CentOS 6.3 下 Zabbix 安装部署 http://www.linuxidc.com/Linux/2013-05/83786.htm
Zabbix 分布式监控系统实践 http://www.linuxidc.com/Linux/2013-06/85758.htm
CentOS 6.3 下 Zabbix 监控 apache server-status http://www.linuxidc.com/Linux/2013-05/84740.htm
CentOS 6.3 下 Zabbix 监控 MySQL 数据库参数 http://www.linuxidc.com/Linux/2013-05/84800.htm
64 位 CentOS 6.2 下安装 Zabbix 2.0.6 http://www.linuxidc.com/Linux/2014-11/109541.htm
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2014-12/110450p2.htm
