##################################
Zabbix Basic Architecture
##################################
1.Server
Zabbix system core processes, polling and capturing data, sending notifications, and more. is the Zabbix agent and Zabbix proxy reporting data objects. The server itself can remotely detect network services. All front-and back-end configuration, statistics, and actionable data are stored here. Contains server, front-end interface, and backend db sections.
2.Agent
Deployed on monitored hosts to monitor local resources and applications and report results to Zabbix server. It is very efficient to use local system calls. There are two modes of detection: active and passive. In passive mode, the agent returns data based on a specific request from the server or proxy. Active mode proactively gets the list of monitoring items from the server before detecting and returning new data. The use of active or passive detection depends on the configuration of the corresponding monitoring item.
3.Proxy
You can freely choose to deploy or not deploy, primarily to share server load. It is a good solution for centralized monitoring of remote locations, branches, and network scenarios. The data that is collected from the monitored device is cached on the proxy locally and passed to the Zabbix server to which it belongs. Proxy requires a separate database.
4.Java Gateway
The Java-implemented daemon is used to monitor JMX-type applications.
5.Sender
The command-line tool, Zabbix_sender, is used to send performance data and availability data to Zabbix server. Many are used by user scripts to send data to the server periodically.
Such as:
shell> CD Bin
shell>./zabbix_sender-z zabbix-s "Linux DB3"-K Db.connections-o 43
6.Get
The command-line tool, Zabbix_get, is used to obtain data from the agent in communication with the agent. Can be used for the troubleshooting of Zabbix agents.
Such as:
shell> CD Bin
shell>./zabbix_get-s 127.0.0.1-p 10050-k "SYSTEM.CPU.LOAD[ALL,AVG1]"
####################################
#zabbix术语表
####################################
Host
Devices that need to be monitored, such as switches, routers, Web servers, DB servers, etc.
Host Group
A logical grouping of monitored devices, such as a DB server group, a Web server group, and so on. Can contain hosts and templates. for permission control
Item
Items that need to be monitored, such as CPU idle rate, usage of a piece of disk, etc.
Trigger
A logical expression used to evaluate whether the received monitoring value exceeds the set threshold value
Event
Noteworthy events such as trigger state change
Action
Pre-defined series of operations responding to an event
Escalation
Executes a custom scenario for operations in action; a sequence of sending notifications, executing remote commands
Media
The way to pass notification
Notification
Messages sent to the user via media about an event
Remote command
Pre-defined commands that are triggered and automatically executed on the monitored machine
Template
Used to simplify and accelerate deployment of large-scale monitoring tasks on the host. Contains a range of items, such as items, triggers, graphs, screens, applications, low-level discovery rules
Application
A group of items in a logical group
Web Scenario
One or more HTTP request to check the availability of Web sites
Frontend
Zabbix's web interface
Zabbix API
Allows you to create, update, and get Zabbix objects such as hosts, items, graphs, and others through the JSON RPC protocol. or perform other tasks
Zabbix Server
Zabbix core, perform monitoring, interact with Zabbix proxies, Zabbix client, calculate trigger, send notification, store data, etc.
Zabbix Agent
Deployed on monitored hosts for monitoring on-premises resources and applications
Zabbix Proxy
Data sharing processing load can be collected on behalf of Zabbix server
######################################
#zabbix配置
######################################
Configurable through a web interface or template
Required configuration content includes users, user groups, hosts, host groups, items, Triggers, Events, notification, templates, visualisation, and more.
The final configuration is stored in the backend database.
Reference:
Https://www.zabbix.com/documentation/2.4/manual/config
#####################################
Zabbix method of fetching numbers
####################################
1.zabbix API
Web-based APIs that get or change the Zabbix configuration through the JSON PRC protocol and can be used to obtain historical monitoring data. Request and response between clients and API are in JSON format. Contains a range of methods that can be functionally divided into different groups.
The format of the originating HTTP request is similar to the following:
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": {}}
Where http://company.com/zabbix/is the address of the Zabbix frontend, Content-type must indicate and be application/json-rpc, Application/json or application/ One of the three jsonrequest. {"JSONRPC": "2.0", "Method": "Apiinfo.version", "id": 1, "auth": null, "params": {}} is the specific content of the request.
Some examples:
* Login Authentication
{
"Jsonrpc": "2.0",
"Method": "User.login",
"Params": {
"User": "Admin",
"Password": "Zabbix"
},
"id": 1,
"Auth": null
}
which
JSONRPC: Indicates the JSON-RPC protocol version, here is version 2.0
Method: Indicates the calling API methods, here is the user login
Params: parameters that need to be passed to the API method, here is the user name and password
ID: identifier for this request
Auth: User authentication token, not yet null
If the parameter is correct response will contain the user authentication token, such as:
{
"Jsonrpc": "2.0",
"Result": "0424bd59b807674191e7d77572075f33",
"id": 1
}
* Get hosts Information
{
"Jsonrpc": "2.0",
"Method": "Host.get",
"Params": {
"Output": [
"HostID",
"Host"
],
"Selectinterfaces": [
"InterfaceID",
"IP"
]
},
"id": 2,
"Auth": "0424bd59b807674191e7d77572075f33"
}
This example uses the available user authentication token to obtain information such as the ID, name, etc. of the configured host through the Host.get method, and returns the following
{
"Jsonrpc": "2.0",
"Result": [
{
"HostID": "10084",
"Host": "Zabbix Server",
"Interfaces": [
{
"InterfaceID": "1",
"IP": "127.0.0.1"
}
]
}
],
"ID": 2
}
To consider the performance impact, try to list only the required items instead of returning all the data
* Create new monitoring items
For example, to establish a new monitoring entry on the host acquired in the previous step, to monitor the remaining space of the/home/joe/directory
{
"Jsonrpc": "2.0",
"Method": "Item.create",
"Params": {
"Name": "Free disk space on $",
"Key_": "Vfs.fs.size[/home/joe/,free]",
"HostID": "10084",
"Type": 0,
"Value_type": 3,
"InterfaceID": "1",
"Delay": 30
},
"Auth": "0424bd59b807674191e7d77572075f33",
"ID": 3
}
Several key parameters in the params parameter have the following meanings:
Name: the names of the monitoring items, which can be flexibly defined, where the $ $ represents the first parameter in Key_, which is/home/joe/
KEY_: Pre-defined monitoring items, Zabbix provides a series of such monitoring content, where you choose from.
HostID: HostID obtained from the previous step
Value_type: The type of the monitoring data value, the different numbers represent the different types, where 3 represents the integral type
Delay:zabbix take a few time intervals, here 30 seconds
The returned results are as follows:
{
"Jsonrpc": "2.0",
"Result": {
"Itemids": [
"24759"
]
},
"ID": 3
}
Itemid the ID of the monitored item that was generated
* Get Historical data:
Get 10 records from the history table in descending order of itemids by clock 23296
Possible values for the history parameter
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
}
return Result:
{
"Jsonrpc": "2.0",
"Result": [
{
"Itemid": "23296",
"Clock": "1351090996",
"Value": "0.0850",
"NS": "563157632"
},
{
"Itemid": "23296",
"Clock": "1351090936",
"Value": "0.1600",
"NS": "549216402"
},
...]
}
* Error Handling
The following example forgets the groups parameter
{
"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"
}
The result is returned as follows, not the result property but the error property
{
"Jsonrpc": "2.0",
"Error": {
"Code":-32602,
"Message": "Invalid params.",
"Data": "No groups for host \" Linux Server\ "."
},
"ID": 3
}
For the acquisition of monitoring data, it should be more concerned about history.get this method. This approach is actually eventually acquired by the backend database. The method provides a rich range of parameters and is very flexible to use. But for a one-time large-scale removal of large number of host large number of monitoring items of data is not suitable.
Reference:
Https://www.zabbix.com/documentation/2.4/manual/api
2.zabbix_get:
Command-line tool to get data from a remote Zabbix agent
Zabbix_get [-HV] [-S -S,--host -P,--port <port number>
-I.,--source-address <IP address>
-K,--key <item key>
-H,--help
-V,--version.
such as: Zabbix_get-s 127.0.0.1-p 10050-k SYSTEM.CPU.LOAD[ALL,AVG1]
The Zabbix API obtains historical data from the database, and zabbix_get can get real-time data. The suitable scene can be selected according to the characteristics of the tool.
Reference:
Https://www.zabbix.com/documentation/2.4/manpages/zabbix_get
3.zabbix databases:
Historical data is obtained directly from the Zabbix background database. For large-scale removal of large numbers of host large number of monitoring items of large amounts of data.
* Related tables
History Series Tables store historical data for different data types, respectively
Data in table with update interval as time 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_ Series tables store different types of historical data statistics
The data in the table is measured in hours, and the minimum, maximum, and average hourly values are stored
Zabbix.trends-numeric (float)
Zabbix.trends_unit-numeric (unsigned intergers)
Character\log\text\ type no historical statistics results
The History series table contains only itemid, clock, value, etc.
Trends series table contains only Itemid, clock, value_min, Value_avg, Value_max and other data
History, trends need to be associated with items, hosts, hosts_groups, groups tables to get the item name, host name, group, and so on.
* Tables and important table fields
Hosts
Hosts.hostid Host ID
Hosts.host Host Name
Hosts.status Host status 0 is normal monitoring, 1 is off, 3 means it is a template,5 is unclear.
Hosts_group
Hosts_group.hostid Host ID
Hosts_group.groupid belongs to group ID
Groups
Groups.groupid Group ID
Groups.name Group Name
Items
Items.itemid Monitoring Item ID
Items.hostid Monitor key host ID
Items.name Monitoring Item Aliases
ITEMS.KEY_ Monitoring Item Standard name
Items.value_type Value Types
Items.delay take a few time intervals
Items.history History table Data Retention days
Items.trends Historical Statistics data retention days
Item.units Data Units
The correspondence between Value_type and history in the items table
(primarily for access efficiency, different value types exist in different history tables)
Value_type History Table
0 history
1 history_str
2 History_log
3 History_uint
4 History_text
History
Hisrtory.itemid Monitoring Item ID
Trends
Trends.itemid Monitoring Item ID
Zabbix backend system involves a large number of tables, take historical data words concerned about the few can
* Monitoring Rules interpretation
A configuration item similar to the following is present in the Zabbix.items table (such as network NIC monitoring, disk monitoring, etc.):
Name Key_
Free disk space on $ vfs.fs.size[/,free]
free disk space on/(percentage) Vfs.fs.size[/,pfree]
Free disk space on $ vfs.fs.size[/boot,free]
Free disk space On/boot (percentage) Vfs.fs.size[/boot,pfree]
Free disk space on $ vfs.fs.size[/data,free]
Free disk space On/data (percentage) Vfs.fs.size[/data,pfree]
Free disk space on vfs.fs.size[{#FSNAME},free]
Free disk space on {#FSNAME} (percentage) vfs.fs.size[{#FSNAME},pfree]
A configuration similar to the following is provided by the Zabbix low-level discovery configuration, which is used to automatically create monitoring items for automatic discovery of monitoring items with multiple disks, multiple directories, multi-block network cards, and other types
You can think of {#FSNAME} as a template that can match all of the related items that are configured, such as:
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]
Similar to the following:
Incoming network traffic on $ net.if.in[{#IFNAME}]
Outgoing network traffic on $ net.if.out[{#IFNAME}]
Io.util. {#DISK_NAME} io.util[{#DISK_NAME}]
Wait a minute
In the example above, the parameter positions of $, $, etc. correspond to KEY_, for example
Free disk space on $ vfs.fs.size[/,free]
On behalf of/, free disk space on $ equivalent to free disk space on/And so on
