Description

This project aims to provide a set of open source tools to monitor DB2. The monitoring is limited to control that a value is between a range. The output of the scripts, allows you to create graphs and see the behavior of the monitored elements.

Open source

There are many tools or programs in the market that allow you to monitor DB2. There are a few that are really good, and you can understand what is happening inside DB2, and then you can take the best decisions.

However, these software is not free, and something the licenses are expensive. If you took the way to use DB2 Express-C, it is because your current plan is not to pay for the database software (probably you are testing a new feature, you have a small set of data, etc.), and in the same way you are not going to pay for the monitoring software for that database.

With this is mind, this is the reason this project is open source, to allow people to have a basic monitoring for their DB2 databases.

Bash script

The decision to create the scripts in shell was to not depend in a compiler, such as Java or C, or interpreters like Perl or Python. Bash is independent, and ready to use if bash is available.

Why bash and not korn? well, it was because it is included in all Linux and it is becoming important. It is not probably the best, but many people know how to use it.

Independent scripts (no architecture)

This set of script was born as an extension ad improve to a set of scripts hosted in dbatodba. It took the same basis, and after that, we see that each script could be modified independently. This provide a lot of flexibility, because a modification does not impact the other scripts.

The lack of architecture could be an issue. But the initial aim was to provide a simple set of scripts to monitor DB2.

The similarity of the scripts is guided by a template that already has the basic structure for all scripts. This template has a specific space for the specific part to be monitored, with many validations done before. You will see that all scripts are based on the template.

We are currently thinking to create a new project / branch to have an architecture. It will be very different from this project, because the scripts will share code, but it will reduce the impact of connection per script, with an asynchronous check. It could probably use jNRPE, and the aim is to keep an active connection to the database, in order to reduce the connection establishment for each check.

Extensibility

You can modify any script to your own requirements, you just have to edit the file and that is all.

You can also create you own scripts, based on template, just by copying the template.sh file. The benefict of writing a new script based on template, is that your script will be Nagios complaint.

Support

This is an open source project, and no support is provided. However, you can write an issue here, and we will try to help you.

Also, if you create your own set of plugins or you corrected the existing ones, share them with us. The community will see the benefit of this collaboration.

Installation

This is the procedure to install this set of scripts to monitor DB2.

Requirements

The requirements are:

• DB2 (These scripts have been tested in b9.7 and v10.5, and many scripts could work in v9.5)
• Nagios (In v3 has been tested)
• Linux / Unix with Bash
• Optional: Check_MK

Retrieving scripts

The only way to get the binaries is via this forge.

• You can download a generated zip containing all files.
• Cloning the git repository.

The first option allows you have a snapshot copy of all scripts. This is useful if you cannot access GitHub from the Nagios or DB2 server, and you have to download to an stage area (i.e. your own PC) and then copy to the target server. With this option you have to repeat the process in order to get the new versions.

The second option is the easiest and it is recommended. As scripts are sources, the best is to provide a mechanism designed to manage source files. When you clon this repository, you will get the most recent version of all scripts. If you want to update to a newest version, you just have to pull the new sources git pull. If you modified the scripts for your own requirements, you can create a branch for edit purposes, and other for the original scripts.

Configuration

Each script has to be configured individually. Each script is autonomous, and they do not require configuration files, of similar thing.

In order to add this set of scripts to your Nagios installation, you can open each script and see the documentation. Each script contain examples of the parameters to put in the configuration file.

The default configuration probably will not work with your requirements, and for this reason you have to tune the warning and critical parameters, in order to not receive "false positives" (You do not want to be waked up at midnight for an alarm that does not really exists.)

Usage

Most of the scripts need the instance directory where they are going to be executed.

Let's suppose we are going to use check_instance_up. You will need to pass the directory instance with the parameter -i. The directory instance is the home directory of the user that executes the instance.

You can get the instances of a server by running db2greg -dump

/opt/ibm/db2/V9.7/bin/db2greg -dump

The output is similar to

S,DB2,9.7.0.7,/opt/ibm/db2/V9.7,,,7,0,,1361790210,0
V,DB2GPRF,DB2SYSTEM,DB2META-10,/opt/ibm/db2/V9.7,
V,DB2GPRF,DB2ADMINSERVER,dasusr1,/opt/ibm/db2/V9.7,
I,DB2,9.7.0.7,db2inst1,/home/db2inst1,,1,0,/opt/ibm/db2/V9.7,,

The lines starting by I indicate an instance in the server. You can get the home directory of a given user by

echo ~db2inst1

One you have the home directory

./check_instance_up -i /home/db2inst1

If something is wrong, you will get the error message

./check_instance_up
Usage: check_instance_up { -i instanceHomeDirectory # -h # -V } [ -v ]
Note: The test was not executed.|
|