Feature request: detect connection error

[bilbolodz]

Now I'm fighting with:

psycopg2.OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections"

Maybe it could be a good idea to catch that exception and "send to zabbix" some:

• psq.connection_not_on 1

"alarm"?
Or at least return other return code on connection error?

[bilbolodz]

I've implemented in shell script parameter:

• psql.last_run 0/1
  when pgzabbix returns error code other than 0

but I think it's a good idea to have information that zabbix failed do connect to postgres at all.

[Spindel]

Seems like a reasonable request. It could be implemented in a few different ways:

• success flag after done
• count on how many values were gathered total
• errors A count flag for amount of errors during processing.

I'm inclined towards count and then you can simply set an trigger/error if it's zero, however, that'd require some further refactoring, as connection style errors would happen earlier in the process.

Return code should definitely be 0 normally and error otherwise though

[bilbolodz]

Some background info about my setup: I'm NOT using "systemd" timer as you proposed but I'm triggering update by requesting "special zabbix" item which run script thats send values by zabbix_sender. In my opinion it's better idea because I can play with frequency of running measures from zabbix server without modification any files on host.
There is one drawback of these method: sometimes when host is more busy and there are more databases and more tables I've got zabbix timeout (max timeout is 30s). Now I'm thinking about running pgzabbix script in background by in that case I will not able to send any status/info about outcome fro script.

• count - actually I've implemented these my self by getting value "good items send (and accepted) from zabbix_sender process. I also implemented another item (psql.last_run 0/1) which is set if script detects non 0 return code from pgzabbix

• success - I thing it should be rather "status" because it could happened that pgzabbix sends some values to the server and that stop because of error. By the way maybe it's a good idea to catch an error (set flag that was an error) and try to send rest of item. In my opinion status is better because it's important to differentiate that zabbix miss some items (important or less important) or can't connect to database at all (rather critical situation)

• error - fine but for me less important