There are only a few metrics in zbxORA. So if you want to track something more specific, you might want to add some more. How to do this? No easier way than to give an example.
Let’s track the usage of the Flash Recovery Area:
select space_limit, space_used, space_reclaimable, number_of_files
from v$recovery_file_dest
this simple query will do. In zabbix terms, this query returns 4 items, 1 for every column. Those items have to be stored somewhere in zabbix and for that zabbix uses keys and hosts. A zabbix host can be anything and in this case, an Oracle database will be a zabbix host. So we can add the items to a host we already have in zabbix. This however takes a way a very powerful feature of zabbix: templates. Chances are that you want to track the FRA usage for multiple databases and having to add those items to each and every host/database what you want to track is not my idea of having a good time.
receiving side
template
So, instead, create a template and create your items in a template and assign the template to your hosts that you want to track. Templates are created in the Configuration/Templates menu
At the right hand side you find the Create Template button.
Use that to create a brand new template to contain the latest and greatest items to track. The Add button is found on the bottom of the page.
This gives us an nice clean template:
It has no Applications, Items, Triggers, it is completely empty, as expected. It is also not - yet - linked to any host.
create items
Select the Items link to get into the items create area.
Again, on the right side is the Create button, this time for the Items.
Now comes the hard part, thinking about names.
name
Give the item a name and a key. They can be the same and personally, I keep them the same, this saves having to think about new names. The key is important, since the data will be uploaded to zabbix using a host, key and value set for every item. The host is not known at this moment, that comes after having added the template to a host.
Type
Also important is the Type, default ‘Zabbix Agent’ but in our case this needs to be changed to ‘Zabbix Trapper’. Zabbix Trapper items are items that can be uploaded using zabbix_sender, a tool that zbxORA does use for this purpose.
Type of Information
Most of the times this will be a choice of Numeric (unsigned) or Numeric (Float). Use what best fits the data, Numeric(unsigned) when possible.
Data Type
in our case this will be Decimal.
Units
Since the usage is specified in Bytes, this will be ‘B’ If your query happen to return MB instead of simple bytes, you still use ‘B’ and use the ‘Use Custom Multiplier’ to fix that.
Use Custom Multiplier
if you did return MB, enter 1048567 (being the product of 1024 * 1024), if you returned Bytes, just leave this empty. When the data is in, zabbix uses this to make a human readable display of the amounts. GB worth of Bytes will be shown as GB and not as a huge amount of Bytes.
The remainder of the fields are nice to play with enough is written about their usage.
query results
The query returns 1 row with 4 columns. This needs to be changed to 4 rows of 2 columns, first column will be the item key and the second column will be the value. Here is the relation between items and the query.
one way to rewrite this query can be:
select 'fra[limit]', space_limit from v$recovery_file_dest def
union all
select 'fra[used]', space_used from v$recovery_file_dest def
union all
select 'fra[reclaimable]', space_reclaimable from v$recovery_file_dest def
union all
select 'fra[files]', number_of_files from v$recovery_file_dest def
I have chosen the items keys ‘fra[limit]’, ‘fra[used]’, ‘fra[reclaimable]’ and ‘fra[files]’. The keys can be anything, as long as they are the same in zabbix as in the query result. Spaces are allowed but in that case the query also has to generate the surrounding quotes because otherwise zabbix_sender won’t see the key as a single column.
in my case the output is:
fra[limit] 5368709120000
fra[used] 83856719872
fra[reclaimable] 78523662336
fra[files] 326
Enter the 4 items
In the end the items show:
Don’t forget: the used and reclaimable columns are percentages and need a float as data type. Limit and files can do with integers.
Now the template is ready, assign it to the hosts, the databases that you want to monitor. In this example I use testhost.
There are more ways to assign a template to a host …. The receiving side is ready now. Time to find a way to send the data, from the sending side.
sending side
On the sending side, you already have zbxORA running. If not, here http://ronr.blogspot.nl/2015/09/install-python-without-root-access-to.html is a description of how to get zbxORA running.
zbxORA uses a simple file structure and a simple configuration for the connections. In the connection part of the configuration you define the username, password and connect url for the database but also the name of site specific checks files that you might want to use.
The connection part is in etc/zbxORE.{db_name}.cfg
and the checks are located in etc/zbxora_checks/oracle/
$>ls etc/zbxora_checks/oracle/
asm.11.cfg ebs.cfg primary.11.cfg sap.cfg standby.11.cfg
asm.12.cfg ebs.cfg.example primary.12.cfg sap.cfg.example standby.12.cfg
Here is were the default checks are and here is where you can add your ‘my_super_checks.cfg'
Of course, if you find that your checks should be included in the project, feel free to push them back using git, in that case make sure you prepare them for inclusion into the files where they belong, according to their version and the database role where you want to monitor.
Now add them to my_super_checks.cfg:
[super_checks]
minutes: 05
my_qry1: select 'fra[limit]', space_limit from v$recovery_file_dest def
union all
select 'fra[used]', space_used from v$recovery_file_dest def
union all
select 'fra[reclaimable]', space_reclaimable from v$recovery_file_dest def
union all
select 'fra[files]', number_of_files from v$recovery_file_dest def
The format is very similar to an old init style of format and don’t forget to forget the terminating ‘;’ it is not needed. Also keep the indentation as shown, the parsing of the file will fail if you SQL continues on the start of a next line.
There is a requirement for a section name and every section should have a minutes parameter where is defined how big the monitoring interval should be. In this case that is every 5 minutes but it could also have been 1 minute, or 13, or 123 minutes, just what you want.
There is one special case of minutes: the 0 minutes case
startup section
If you want some queries to only run when zbxORA successfully connected to the database, give it an minutes parameter with value 0. This causes the checks in the mentioned section to be run only once every connection.
special section names
section names almost have no meaning. There is one exception, that is sections with ‘discover’ in their name. All other sections have simple data returning queries in them, the discover sections have the magical zabbix LLD queries in them. LLD is short for Low Level Discovery. In the discovery you pass to zabbix the dynamic contents of databases where you want to generate items for. The default set of checks are full of them. As you can imagine, the resulting data is treated slightly different and is passed as json arrays to zabbix, using same mechanism as the data. The key that is mentioned in the LLD part of the template is the same the name for the discovery queries in the checks files. For the discovery this is a requirement.
re-reading config
Now your checks are in place. zbxORA still does not know about them. The process is already running and checking the files that were known at connection time for changes. If it finds a file changed, zbxORA wil re-read the files and start using the changes right away. Now you added a new file so you need to make this fact known to zbxORA. For that we have the site_checks parameter in the connection parameter file. There just add:
site_checks: my_super_checks
mostly the base name part of your file.
There are 2 ways to make zbxORA to re-read the complete config. One is to kill and restart the process, the other is to kill the currently running Oracle session that zbxORA uses. In both cases it will re-read the config in order to find the needed parameters to build a new connection.
zabbix_sender
Make sure you have zabbix_sender installed on your system and that zbxORA has it in the PATH of the runtime environment.
The easiest way to send the data to zabbix is using the following config:
hostname: testhost
checks_dir: etc/zbxora_checks
out_dir: $HOME/zbxora_out
site_checks: my_super_checks
to_zabbix_method: zabbix_sender
to_zabbix_args: zabbix_sender -z 127.0.0.1 -T -i
The easiest way and when there is just one database. This causes a new zabbix_sender process every time data is to be sent to zabbix. This already is in batches but one batch for every database, one zabbix_sender for every database. If you have a lot of databases, more efficient is to disable zabbix_sender from zbxORA and use zbxora_sender to combine the data for all databases. This example assumes that your zbxORA process[es] are running on the zabbix server or on a zabbix proxy. This might be different in your case but having them on a proxy might be a good location. If it is different, change the -z parameter to whatever address the proxy or server is running on. The parameter to_zabbix_args is not parsed by zbxORA, it is just passed as is to zabbix_sender.
For now, I think this is enough to get one started. If you hit any problems, feel free to contact. Downloading and using zbxORA is free, clone it from github
The Add button is found on the bottom of the page.
Een opmerking toevoegen