Blocked sessions not monitored (was Discovery Rules for Zabbix 3.2)

[nickwe3]

Hello Jan,

Thanks a a lot for your work!

Here are my findings:

I'm new to Zabbix and new to OE, but our DBA ask us to monitor their Progress DB, so I went with OESNMP and Zabbix.

I don't know for the previous version of Zabbix, but on version 3.2, the discovery rules must have the following syntax:

discovery[{#MACRO1}, oid1, {#MACRO2}, oid2, …,]

https://www.zabbix.com/documentation/3.2/manual/discovery/low_level_discovery#discovery_of_snmp_oids

So I had to put theses for the "SNMP OID" in the "discovery rules" of your templates:

Appservers => discovery[{#SNMPVALUE},SNMPv2-SMI::enterprises.42674.0.2] OpenEdge Databases => discovery[{#SNMPVALUE},SNMPv2-SMI::enterprises.42674.2.3] OpenEdge Latches => discovery[{#SNMPVALUE},SNMPv2-SMI::enterprises.42674.3.2.2] OpenEdge Working Dirs => discovery[{#SNMPVALUE},SNMPv2-SMI::enterprises.42674.4.2.1]

For the "OpenEdge Blocked Sessions", it should then be

OpenEdge Blocked Sessions => discovery[{#SNMPVALUE},SNMPv2-SMI::enterprises.42674.3.3.1]

But the OID .3.3.1 doesn't exist :-( .3.2 and .3.4 exist, but nothing for .3.3 :-(

snmpwalk -v 2c -c public db1.qadriver2 SNMPv2-SMI::enterprises.42674.3 ... SNMPv2-SMI::enterprises.42674.3.2.12.14.100.114.105.118.101.114.45.77.84.76.95.83.69.81 = INTEGER: 0 SNMPv2-SMI::enterprises.42674.3.2.12.14.100.114.105.118.101.114.45.77.84.76.95.84.88.81 = INTEGER: 0 SNMPv2-SMI::enterprises.42674.3.2.12.14.100.114.105.118.101.114.45.77.84.76.95.84.88.84 = INTEGER: 0 SNMPv2-SMI::enterprises.42674.3.2.12.14.100.114.105.118.101.114.45.77.84.76.95.85.83.82 = INTEGER: 0 SNMPv2-SMI::enterprises.42674.3.2.12.15.100.114.105.118.101.114.45.77.84.76.95.76.72.84.50 = INTEGER: 0 SNMPv2-SMI::enterprises.42674.3.2.12.15.100.114.105.118.101.114.45.77.84.76.95.76.72.84.51 = INTEGER: 0 SNMPv2-SMI::enterprises.42674.3.2.12.15.100.114.105.118.101.114.45.77.84.76.95.76.72.84.52 = INTEGER: 0 SNMPv2-SMI::enterprises.42674.3.2.12.15.100.114.105.118.101.114.45.77.84.76.95.76.82.85.50 = INTEGER: 0 SNMPv2-SMI::enterprises.42674.3.4.1.1 = STRING: "driver-1" SNMPv2-SMI::enterprises.42674.3.4.1.2 = STRING: "driver-2" SNMPv2-SMI::enterprises.42674.3.4.1.3 = STRING: "driver-3" SNMPv2-SMI::enterprises.42674.3.4.2.8.100.114.105.118.101.114.45.49 = Counter32: 106053192 SNMPv2-SMI::enterprises.42674.3.4.2.8.100.114.105.118.101.114.45.50 = Counter32: 106053228 SNMPv2-SMI::enterprises.42674.3.4.2.8.100.114.105.118.101.114.45.51 = Counter32: 0 SNMPv2-SMI::enterprises.42674.3.4.3.8.100.114.105.118.101.114.45.49 = Counter32: 847543 SNMPv2-SMI::enterprises.42674.3.4.3.8.100.114.105.118.101.114.45.50 = Counter32: 847543 SNMPv2-SMI::enterprises.42674.3.4.3.8.100.114.105.118.101.114.45.51 = Counter32: 0 SNMPv2-SMI::enterprises.42674.3.4.4.8.100.114.105.118.101.114.45.49 = Counter32: 23904 ...

On your documentation of the OID's, the 3.3 should be the waiting session and not the Blocking session as in your template: .1.3.6.1.4.1.42674.3.3 = Waiting sessions .1.3.6.1.4.1.42674.3.3.1 = “db name” + type of wait .1.3.6.1.4.1.42674.3.3.2 = number of sessions waiting for this type

Regards,

Nicolas.

[jankeirse]

Waiting sessions are currently not monitored because we had database crashes and it appeared to have been caused by iterating the _connect table. It has been a long time since I implemented that return, so I'm not entirely sure that's still relevant today with the current OE releases (I would hope not but don't really want to test it out on our environment at this point.) https://github.com/jankeirse/oesnmp/blob/ee4ac9e64c1e1d4918fd409cdb46f46856dcaa46/deploy/pexportvst.p#L92
You could remove that check and test in your environment, but best do that on a test environment first!

[jankeirse]

ps.: Does the rest work? If so, could you share your template for zabbix 3.2?

[jankeirse]

Looking at the code I also noticed that the items will only show up in the snmp tree if there are waiting sessions, never if there are none, so this is going to be annoying with autodiscovery if you only have waiting sessions occasionally (which should be the norm) so it it would probably best to revisit that code. The metrics should be 0 instead of missing if no sessions are waiting.

[jankeirse]

RD-773 internally

[nickwe3]

Hi Jan,

Sorry for the late reply, for the moment I just have asbman and vst working, but I can't make promon to work :-(

The following command does work and finished correctly:

./promon.exp /file/to/my.db | tail Minimum time to nap at first -spin exhaustion (-nap):10 Maximum time to nap at -spin exhaustion (-napmax):250 Login Governor (-nGovernor):0 of 41 Servers:1 Users:6 Local:6 Remote:0 Batch:6 Apws:2 latchtimeouts:254

but call trough promon.sh, it hangs, probably because of the < /dev/zero input :-(

./promon.sh /file/to/my.db parent: waiting for sync byte parent: telling child to go ahead parent: now unsynchronized from child spawn: returns {27918}

expect: does "" (spawn_id exp6) match glob pattern "*5. Activity"? no

So promon.py hangs too, even when I remove the </dev/zero from promon.sh

I don't know python, so it's very frustrating...

If you have any ideas...

Regards,

Nicolas.

[jankeirse]

just a wild guess, what happens if you modify promon.sh to use /bin/bash instead of /bin/sh?

[nickwe3]

exactly the same as: ls -l /bin/sh lrwxrwxrwx 1 root root 4 Nov 9 2015 /bin/sh -> bash

But I figure out it would be too complicated to make it work so I'm in the process of using zabbix_sender to populate zabbix with the result of promon.exp