Search Exchange
Search All Sites
Nagios Live Webinars
Let our experts show you how Nagios can help your organization.Login
New ListingsDirectory Tree
Monitor DB2 with Nagios
Current Version
Beta
Last Release Date
2014-09-20
Compatible With
- Nagios 3.x
Owner
License
Apache
Hits
51333
Meet The New Nagios Core Services Platform
Built on over 25 years of monitoring experience, the Nagios Core Services Platform provides insightful monitoring dashboards, time-saving monitoring wizards, and unmatched ease of use. Use it for free indefinitely.
Monitoring Made Magically Better
- Nagios Core on Overdrive
- Powerful Monitoring Dashboards
- Time-Saving Configuration Wizards
- Open Source Powered Monitoring On Steroids
- And So Much More!
All scripts return Performance Data to see the evolution of the values across the time.
This set of scripts is in continuous development, thus new scripts are being developed and new ones have been planned. If you want to share your own modifications, you can share it in GitHub (Pull request).
The whole documentation is on the Wiki: [https://github.com/angoca/monitor-db2-with-nagios/wiki]
Example of usage, output and performance data are also availables: [https://github.com/angoca/monitor-db2-with-nagios/wiki/Scripts]
For the moment, you can monitor:
* Quantity of connexions, filtered by many criteria (machines, users) and showing their status.
* Checks if a connection to the database can be established.
* Checks the database size. Based on the Storage management utility.
* Checks the HADR status, by analyzing peer status and calculating the difference between primary et standby (logs et pages)
* Checks if the instance is active.
* Keeps a history of last backups (full, delta, incremental) and could throw an alert if the backup is too old.
* Checks the locks looking for long term lock waits, returning with process is holding the locks.
* Checks the log consumption per day. Allows you identify the most expensive transaction measured by logs produced.
* Log usage, that allows you identify how many primary and secondary logs are being used during the day.
* Open files by the db2sysc process.
* Performance of the IO Cleaners by identifying the percentage of Bad Page Cleaner Triggers (PBPDT).
* Quantity of message in the db2diag.log. Useful to detect alerts that are not part of any output.
* Tablespace: Use and state (normal, backup, etc.)
* Utilities: Allows you to identify which utilities could impact the normal db usage.
The scripts have been adapted to be used with Check_MK (The output was changed.)
The project is hosted in the GitHub forge. You can improve the provided scripts, or create your own based on these scripts. If you want to contribute to the project with your own scripts, your code is welcome.
The whole documentation is on the Wiki: [https://github.com/angoca/monitor-db2-with-nagios/wiki]
Example of usage, output and performance data are also availables: [https://github.com/angoca/monitor-db2-with-nagios/wiki/Scripts]
For the moment, you can monitor:
* Quantity of connexions, filtered by many criteria (machines, users) and showing their status.
* Checks if a connection to the database can be established.
* Checks the database size. Based on the Storage management utility.
* Checks the HADR status, by analyzing peer status and calculating the difference between primary et standby (logs et pages)
* Checks if the instance is active.
* Keeps a history of last backups (full, delta, incremental) and could throw an alert if the backup is too old.
* Checks the locks looking for long term lock waits, returning with process is holding the locks.
* Checks the log consumption per day. Allows you identify the most expensive transaction measured by logs produced.
* Log usage, that allows you identify how many primary and secondary logs are being used during the day.
* Open files by the db2sysc process.
* Performance of the IO Cleaners by identifying the percentage of Bad Page Cleaner Triggers (PBPDT).
* Quantity of message in the db2diag.log. Useful to detect alerts that are not part of any output.
* Tablespace: Use and state (normal, backup, etc.)
* Utilities: Allows you to identify which utilities could impact the normal db usage.
The scripts have been adapted to be used with Check_MK (The output was changed.)
The project is hosted in the GitHub forge. You can improve the provided scripts, or create your own based on these scripts. If you want to contribute to the project with your own scripts, your code is welcome.
Reviews (4)
byaryv, March 4, 2022
Check_database_connection :
Any idea what the -a represents on the below command which is used on the check_database_connection script .
COMMAND_CONNECTABLE="db2 -a connect to ${DATABASE_NAME}"
Any idea what the -a represents on the below command which is used on the check_database_connection script .
COMMAND_CONNECTABLE="db2 -a connect to ${DATABASE_NAME}"
byPrema, June 8, 2021
Hi angoka,
The scripts are great, but doesn't support db2 V11.1.
Is there any chance that this script can be re-written for db2 11.x ?
The scripts are great, but doesn't support db2 V11.1.
Is there any chance that this script can be re-written for db2 11.x ?
bydrekhkraft, April 8, 2020
Hi Angoca,
Thank you for these scripts,I have a question regarding the check_log_usage plugin.
when i run this
./check_log_usage -i /files/db2/db2inst1 -d db
i get
The transaction log utilization is OK.|'Log_qty_used'=53214;278528;1916928;0;3555328
The top for the moment has been 14086655.|'Max_used'=14086655
but when i specify the warning and critical levels to test a critical message it does not seem to work
./check_log_usage -i /files/db2/db2inst1 -d db -w 10 -c 5
Usage: check_log_usage { -i instanceHomeDirectory -d databaseName [-c][-f][-w][-K] | -h
| -V } [-T][-v]
Warning threshold should be less than critical threshold.
Threshold should be greater than 0.
Note: The test was not executed.|
If you could be so kind and let know what i am missing, I would greatly appreciate it.
Thanks,
Karthik
Thank you for these scripts,I have a question regarding the check_log_usage plugin.
when i run this
./check_log_usage -i /files/db2/db2inst1 -d db
i get
The transaction log utilization is OK.|'Log_qty_used'=53214;278528;1916928;0;3555328
The top for the moment has been 14086655.|'Max_used'=14086655
but when i specify the warning and critical levels to test a critical message it does not seem to work
./check_log_usage -i /files/db2/db2inst1 -d db -w 10 -c 5
Usage: check_log_usage { -i instanceHomeDirectory -d databaseName [-c][-f][-w][-K] | -h
| -V } [-T][-v]
Warning threshold should be less than critical threshold.
Threshold should be greater than 0.
Note: The test was not executed.|
If you could be so kind and let know what i am missing, I would greatly appreciate it.
Thanks,
Karthik
bySetti, February 2, 2015
1 of 1 people found this review helpful
I found it very useful, but found some errors:
in check_hadr_status, line n. 290 is wrong: COMMAND_HADR="db2pd -db wfscpd -hadr" should be:
COMMAND_HADR="db2pd -db ${DATABASE_NAME} -hadr".
On all plugins, you don't return the name of the database, but if you want to run many checks at the same time with check_by_ssh plugin, you will absolutley need to know which control gives which result.
To do so, i modified line 360 adding ${DATABASE_NAME} before ${OUTPUT}, but i think you can find a better solution to that.
in check_hadr_status, line n. 290 is wrong: COMMAND_HADR="db2pd -db wfscpd -hadr" should be:
COMMAND_HADR="db2pd -db ${DATABASE_NAME} -hadr".
On all plugins, you don't return the name of the database, but if you want to run many checks at the same time with check_by_ssh plugin, you will absolutley need to know which control gives which result.
To do so, i modified line 360 adding ${DATABASE_NAME} before ${OUTPUT}, but i think you can find a better solution to that.
Owner's reply
Hi @Setti, thank you for the feedback. I have not realized the problem you noticed.
I have corrected the database name problem.
For the other case, I do not know why do you need the database name. You are passing this value as parameter, with NRPE or with SSH execution. If you want to discuss more about this issue, please create a ticket at: https://github.com/angoca/monitor-db2-with-nagios/issues
Finally, I am working in a new set of Nagios plugins for DB2: https://github.com/angoca/db2-jnrpe This has a better structure, historical information and less overhead.
