Áú»¢¶Ä²©

2 Plugins

Overview

Plugins provide an option to extend the monitoring capabilities of Áú»¢¶Ä²©. Plugins are written in Go programming language and are supported by Áú»¢¶Ä²© agent 2 only. Plugins provide an alternative to loadable modules (written in C), and other methods for extending Áú»¢¶Ä²© functionality.

The following features are specific to agent 2 and its plugins:

• support of scheduled and flexible intervals for both passive and active checks;
• task queue management with respect to schedule and task concurrency;
• plugin-level timeouts;
• compatibility check of Áú»¢¶Ä²© agent 2 and its plugins on start up.

Since Áú»¢¶Ä²© 6.0.0, plugins don't have to be integrated into the agent 2 directly and can be added as loadable plugins, thus making the creation process of additional plugins for gathering new monitoring metrics easier.

This page lists Áú»¢¶Ä²© native and loadable plugins, and describes plugin configuration principles from the user perspective. For instructions about writing your own plugins, please see Plugin development guidelines. Metrics collection process provides a detailed description of the entire metrics collection process including the methods applied and the connection diagram.

Configuring plugins

This section provides common plugin configuration principles and best practices.

All plugins are configured using Plugins.* parameter, which can either be part of the Áú»¢¶Ä²© agent 2 configuration file or a plugin's own configuration file. If a plugin uses a separate configuration file, path to this file should be specified in the Include parameter of Áú»¢¶Ä²© agent 2 configuration file.

Each plugin parameter should have the following structure:

Plugins.<PluginName>.<Parameter>=<Value>

Parameter names should adhere to the following requirements:

• it is recommended to capitalize the names of your plugins;
• the parameter should be capitalized;
• special characters are not allowed;
• nesting isn¡¯t limited by a maximum level;
• the number of parameters is not limited.

Hardcoded defaults

If a parameter required for authentication is not provided in an item key or in the named session parameters, the plugin will use a hardcoded default value.

Named sessions

Named sessions represent an additional level of plugin parameters and can be used to define separate sets of authentication parameters for each of the instances being monitored. Each named session parameter should have the following structure:

Plugins.<PluginName>.<SessionName>.<Parameter>=<Value>

A session name can be used as a connString item key parameter instead of specifying a URI, username, and password separately. In item keys, the first parameter can be either a connString or a Uri. If the first key parameter matches a session name specified in the configuration file, the check will be executed using named session parameters. If the first key parameter doesn't match any session name, it will be treated as a Uri.

Note, that:

• when providing a connString (session name) in key parameters, key parameters for username and password must be empty;
• passing embedded URI credentials is not supported, consider using named sessions instead;
• in case an authentication parameter is not specified for the named session, a hardcoded default value will be used.

The list of available named session parameters depends on the plugin, see individual plugin configuration files for details.

Example: Monitoring of two instances ¡°MySQL1¡± and ¡°MySQL2¡± can be configured in the following way:

Plugins.Mysql.Sessions.MySQL1.Uri=tcp://127.0.0.1:3306
       Plugins.Mysql.Sessions.MySQL1.User=<UsernameForMySQL1>
       Plugins.Mysql.Sessions.MySQL1.Password=<PasswordForMySQL1>    
       Plugins.Mysql.Sessions.MySQL2.Uri=tcp://127.0.0.1:3307   
       Plugins.Mysql.Sessions.MySQL2.User=<UsernameForMySQL2>
       Plugins.Mysql.Sessions.MySQL2.Password=<PasswordForMySQL2>

Now, these names may be used as connStrings in keys instead of URIs:

mysql.ping[MySQL1]
       mysql.ping[MySQL2]

Parameter priority

Since version 6.4.3, Áú»¢¶Ä²© agent 2 plugins search for connection-related parameter values in the following order:

1. The first item key parameter is compared to session names. If no match is found it is treated as an actual value; in this case, step 3 will be skipped. If a match is found, the parameter value (usually, a URI) must be defined in the named session.
2. Other parameters will be taken from the item key if defined.
3. If an item key parameter (for example, password) is empty, plugin will look for the corresponding named session parameter.
4. If the session parameter is also not specified, the value defined in the corresponding default parameter will be used.
5. If all else fails, the plugin will use the hardcoded default value.

Example 1

Monitoring of two instances ¡°MySQL1¡± and ¡°MySQL2¡±.

Configuration parameters:

Plugins.Mysql.Sessions.MySQL1.Uri=tcp://127.0.0.1:3306
       Plugins.Mysql.Sessions.MySQL1.User=mysql1_user
       Plugins.Mysql.Sessions.MySQL1.Password=unique_password
       Plugins.Mysql.Sessions.MySQL2.Uri=tcp://192.0.2.0:3306
       Plugins.Mysql.Sessions.MySQL2.User=mysql2_user
       Plugins.Mysql.Sessions.MySQL2.Password=different_password

Item keys: mysql.ping[MySQL1], mysql.ping[MySQL2]

Example 2

Providing some of the parameters in the item key (supported since Áú»¢¶Ä²© 6.4.2).

Configuration parameters:

Plugins.Postgres.Sessions.Session1.Uri=tcp://192.0.2.234:5432
       Plugins.Postgres.Sessions.Session1.User=old_username
       Plugins.Postgres.Sessions.Session1.Password=session_password

Item key: pgsql.ping[session1,new_username,,postgres]

As a result of this configuration, the agent will connect to PostgreSQL using the following parameters:

• URI from session parameter: 192.0.2.234:5432
• Username from the item key: new_username
• Password from session parameter (since it is omitted in the item key): session_password
• Database name from the item key: postgres

Example 3

Collecting a metric using default configuration parameters.

Configuration parameters:

Plugins.Postgres.Default.Uri=tcp://192.0.2.234:5432
       Plugins.Postgres.Default.User=zabbix
       Plugins.Postgres.Default.Password=password

Item key: pgsql.ping[,,,postgres]

As a result of this configuration, the agent will connect to PostgreSQL using the parameters:

• Default URI: 192.0.2.234:5432
• Default username: zabbix
• Default password: password
• Database name from the item key: postgres

Connections

Some plugins support gathering metrics from multiple instances simultaneously. Both local and remote instances can be monitored. TCP and Unix-socket connections are supported.

It is recommended to configure plugins to keep connections to instances in an open state. The benefits are reduced network congestion, latency, and CPU and memory usage due to the lower number of connections. The client library takes care of this.

Plugins supplied out-of-the-box

All metrics supported by Áú»¢¶Ä²© agent 2 are collected by plugins.

The following plugins for Áú»¢¶Ä²© agent 2 are available out-of-the-box:

Built-in

The following plugins for Áú»¢¶Ä²© agent 2 are available out-of-the-box. Click on the plugin name to go to the plugin repository with additional information.

Loadable

Click on the plugin name to go to the plugin repository with additional information.

See also: Building loadable plugins.