From this post and the video, you’ll learn about the possibilities of database monitoring using out-of-the-box Zabbix functionality without having to install additional tools, additional applications, or additional software that might not be allowed by your company.
Contents
I. Classic ODBC monitoring (0:22)
II. Synthetic MySQL monitoring (11:13)
III. DB monitoring with Zabbix Agent 2 (13:48)
IV. LLD for DB monitoring (17:03)
V. Questions & Answers (21:09)
Classic ODBC monitoring
What is ODBC?
ODBC stands for open database connectivity. There are a couple of ODBC drivers available for different database management systems (DBMS):
-
- Oracle,
- PostgreSQL,
- MySQL,
- Microsoft SQL Server,
- Sybase ASE,
- SAP HANA,
- DB2.
All of these databases have different ODBCs specifically tailored for them. They offer slightly different functionality. So, even if you have set up the database monitoring for one database it might not necessarily work just as good for the other, as the functionality used to monitor one database might not exist for the other. In addition, as different technologies have different capabilities, most ODBC drivers do not implement all functionality defined in the ODBC standard.
What to monitor?
When we are planning to use ODBC for monitoring, what kind of data we can expect to receive? The answer ultimately depends on your own preferences, needs, or your proficiency in a specific database. You can monitor any possible database performance metrics and incidents using Zabbix templates.
Generally, monitoring of the following areas is of interest:
-
- database performance
- engine availability
- configuration changes that you need to be aware of
To make the process easier, we provide ready-to-use templates, which can be applied to a host where your database is deployed. You can browse a full list of available metrics in these templates’ descriptions. So, you don’t have to perform configuration completely from scratch, which is good news.
How does it work?
Without diving too deep into the transport layer and all of the technical details, the ODBC driver accesses the database over the network using the database API. So, there is no direct connection between Zabbix and the database. Zabbix only creates a query passed to the ODBC manager for processing, which then moves the request over to the ODBC driver that connects to the database management system and then executes the query. Here, Zabbix does not limit the query execution timeout, and the timeout parameter is used as the ODBC login timeout.
Chain of processes
ODBC configuration is based on two files:
- odbc.ini — holds a list of installed ODBC database drivers, which are used for specific communication.
- odbcinst.ini — holds the definitions of data sources so that we know to which database we are going to connect.
Where to start?
What do we need to do in order to start using this ODBC monitoring approach?
- First, we will need to install the ODBC driver relevant to the database we are going to monitor. A simple yum command will suffice if we’re working with CentOS.
# yum -y install unixODBC unixODBC-devel
- Then we need to specify the package (driver) we want to install and modify the ODBC driver files.
- odbc.ini:
[root@localhost ~]# cat /etc/odbc.ini [MySQL] Description=NewDatabase Driver=MariaDB Server=localhost User=root Password=VerySecurePassword Port=3306 Database=DatabaseName
- odbcinst.ini:
[root@localhost ~]# cat /etc/odbcinst.ini [MySQL] Description=ODBC for MySQL Driver=/usr/lib/libmyodbc5.so Setup=/usr/lib/libodbcmyS.so Driver64=/usr/lib64/libmyodbc8a.so Setup64=/usr/lib64/libmyodbc8a.so FileUsage=1
Then we need to populate them with the necessary information. So, in this case, DSN (data source name) is used to call a specific connection. We need to get this part correctly, otherwise, the connection will not work out, for instance, in case of a typo.
- After we have installed the ODBC driver and configured the configuration files, we don’t really need to go ahead into Zabbix to create a new item and see if it works. We can test the ODBC configuration using isql to connect or at least attempt to connect to a particular database using the specified configuration.
Using isql to test ODBC configuration
If we receive an output that you have been connected then the communication is correct. You can also execute a sort of query, for instance, select some information from the database. If you get the result, then you do have the necessary permissions to access that data, and the connection, that is the ODBC driver, is working fine. Then you can proceed to the frontend.
- In the frontend, we will need to create an item of the ‘Database monitor’ type on a particular host or a template and specify one of the two keys available for ODBC monitoring: db.odbc.select or db.odbc.get.
Creating ‘Database monitor’ item
The difference between these item keys is pretty simple — select will return only one value and get will return values in bulk. So, get is more efficient and allows for reducing the load on the database if we are working with a lot of data. Within the key parameters, we need to specify the same DSN that we have defined in our odbc.ini file.
We need to make sure that the first parameter is unique so that this particular item key is unique and does not duplicate anything else, and the second parameter is the DSN.
- After we have specified everything, we specify the query, which is a part of the item configuration.
- We test the item using the test form in the Zabbix frontend. If the test form returns a value or does not return an error message, then everything is fine and we can proceed with this item or create more items.
Testing the item
ODBC templates
- There are a couple of built-in templates. If the metrics obtained through these templates are sufficient, we obviously don’t need to create these items from scratch or configure them. We can simply assign the templates we need to the host, on which we are monitoring the database. All we need to do is to tweak a little, if necessary, modify the macro related to the DSN, and then start monitoring.
Assigning a template
NOTE. The easiest way to get the templates is to upgrade to the latest Zabbix with our official templates already built in. If you don’t have the needed templates for any reason, you can download them from Zabbix official repository or Zabbix integrations. If you still need a specific template, you can definitely check out the community-created templates.
- Finally, we can execute discovery rules:
and check the Latest data:
Synthetic MySQL monitoring
Synthetic MySQL monitoring approach is using capabilities of the Zabbix Agent. Though that is not something that Zabbix Agent is doing out of the box, still we don’t need to install anything or perform some super difficult manipulations to make it work as it is a part of Zabbix functionality.
As you might already know, the Zabbix Agent functionality can be extended using custom UserParameters and then used for database monitoring.
- So, we can create new UserParameters, which invoke native MySQL administration client commands providing output, which can then be used to calculate performance metrics.
UserParameter=mysql.ping[*], mysqladmin -h"$1" -P"$2" ping UserParameter=mysql.get_status_variables[*], mysql -h"$1" -P"$2" -sNX -e "show global status" UserParameter=mysql.version[*], mysqladmin -s -h"$1" -P"$2" version UserParameter=mysql.db.discovery[*], mysql -h"$1" -P"$2" -sN -e "show databases"
- It is a good practice to test the commands themselves to make sure that they work and to test the UserParameter keys, for instance using the zabbix_get utility.
- Then you might want to use our official MySQL monitoring template by creating an additional file .my.cnf under /var/lib/zabbix (default location) as follows:
[client] user='zbx_monitor' password='<password>'
- Then we need to provide credentials for the user to confirm that the user has the necessary permissions to access the database.
- If everything is working, assign MySQL by Zabbix agent template.
In this case, we are not actually logging in to the database. We execute commands from the terminal by using Zabbix Agent and extending the functionality beyond the built-in functions.
DB monitoring with Zabbix Agent 2
Why Zabbix Agent 2?
What are the benefits of Zabbix Agent 2 in relation to database monitoring?
- Zabbix Agent 2 is the improved version of our original Zabbix Agent, which is now written in Go.
- Zabbix Agent 2 is more efficient and supports some new functions that Zabbix Agent 1 does not, for instance, custom intervals with active checks as Zabbix Agent 2 is using the Scheduler plugin and is capable of keeping track of time when certain checks need to be executed;
- Older configuration is also supported. So, if we switch from Zabbix Agent 1 to Zabbix Agent 2, we do not need to rewrite the whole configuration file in order for Zabbix Agent 2 to work.
- Zabbix Agent 2 is installed simply with one-line command just like Zabbix Agent 1, we need just to specify a different package.
# yum -y install zabbix-agent2
- Zabbix Agent 2 is based on plugins, so you do not need to install it with ODBC drivers, as plugins do the work, or anything extra as Zabbix Agent 2 has out-of-the-box database-specific plugins to monitor your database, including MySQL, Oracle, and PostgreSQL.
- Plugins are also written in Go.
- We have created Zabbix Agent 2-specific templates, which we can assign to the host. So, if you decide to use Zabbix Agent 2, you need to perform even fewer manipulations in order to get your database monitored by Zabbix.
Built-in Zabbix Agent 2 templates
Configuration
The configuration is very simple. We need to decide whether we specify the necessary parameters within the item keys or, if we prefer named sessions, we edit the configuration file of Zabbix Agent 2 to define those and use the session name as the first parameter of the key.
- So, we specify the key according to the documentation page. In the first case, we can specify essentially the location of our database and provide the credentials.
In the second case, we simply need to provide the DSN in order to connect to the database using Zabbix Agent 2 built-in plugins.
Plugins.Mysql.Sessions.Prod.Uri=tcp://192.168.1.1:3306 Plugins.Mysql.Sessions.Prod.User=<UserForProd> Plugins.Mysql.Sessions.Prod.Password=<PasswordForProd>
- After we have created these items or applied a template, we can definitely test them out and see whether they are working fine.
NOTE. Check available MySQL-related item keys documentation page.
LLD for DB monitoring
Why LLD?
Finally, you can definitely use low-level discovery for database monitoring. LLD is a very efficient and powerful tool within Zabbix. You can definitely use either built-in discovery keys, which utilize Zabbix Agent, or other sources such as custom scripts to pass the payload to your low-level discovery rule.
LLD:
-
- Automatically creates items, triggers, and graphs from different entities on a host.
- Parses data received in Zabbix-specific JSON format.
- Different sources for LLD can be used, such as:
- Built-in discovery keys,
- Dependent on a built-in item key,
- Dependent on a custom script/custom UserParameter.
Here we have a script providing our JSON-formatted payload, which is sent by the Data sender Zabbix utility to the Master trapper item within our Zabbix instance, while our LLD rule depends on this particular Master trapper item.
So, we just populate this trapper item with the JSON payload, LLD rule creates new entities based on the prototypes, and then the items created by those prototypes are collecting the data from that master trapper item each time a new payload comes in.
How to configure custom LLD?
In general, to create LLD from scratch:
- First, you will need to decide on the actual payload delivery method (Zabbix Agent, script, Zabbix sender, or UserParameter).
- Make sure that your payload is in JSON that is structurally sound so that Zabbix can accept and parse it.
[{"{#DATABASE}":"information_schema"},{"{#DATABASE}":"mysql"},{"{#DATABASE}":"p erformance_schema"},{"{#DATABASE}":"sys"},{"{#DATABASE}":"zabbix"}]
- Create LLD rule with type according to delivery method.
- Test the rule (if available for passive checks) to see JSON you receive.
- Create filters or overrides, if necessary.
- Create prototypes, based on which your entities will be created.
If we don’t want to create LLD rules from scratch, we can definitely modify the built-in templates without wasting time creating custom LLD rules:
-
- Modify/create new entities;
- Clone the templates;
- Refer to templated discovery rule configuration.
Modifying LLD rules of official templates
Questions & Answers
Question. Can we monitor the database using active checks or passive checks?
Answer. As I have mentioned, everything depends on your preferences and, ultimately, on the way you want to pass this output to Zabbix Server. If we’re talking about active checks, you can utilize Zabbix sender, for instance. So, it will be a trapper item on the Zabbix Server side waiting for data. In case of passive checks, we can use Zabbix Agent. So, we can use both types of checks for database monitoring.
Question. Can we establish a secure connection between the ODBC gateway and the database, which is somewhere on a distant machine?
Answer. Yes, this can be done though it does require a little bit of finesse. It is an extensive topic, and the security of the connection is highly dependent on the driver, which should support a secure connection. Some older databases might not have this functionality.
Question. Are ODBC checks influencing the performance of the master server?
Answer. It depends on what kind of data you are collecting. If you have a lot of items utilizing db.odbc.get item key, which retrieves just one value from the database, this might impact your database performance. You might not notice this impact if your hardware is powerful enough. However, it is advisable to use the odbc.select key in order to collect this information in bulk. Otherwise, you might be locking up some entries within your database that could potentially lead to problems.
Question. So, we provide two solutions with one of them using ODBC agentless checks ODBC. In addition, we have the agent tool. Will you briefly describe the advantages of ODBC and Agent checks?
Answer. If we’re talking about the ODBC database monitoring method, the most obvious difference is that you don’t need to install an agent. From the data collection perspective, there is not much difference. Everything depends on your specific needs.
