Zabbix::API::Action(3) Zabbix action objects

SYNOPSIS


use Zabbix::API::Action qw/ACTION_EVENTSOURCE_TRIGGERS
ACTION_EVAL_TYPE_AND
ACTION_CONDITION_TYPE_TRIGGER_NAME
ACTION_CONDITION_OPERATOR_LIKE
ACTION_OPERATION_TYPE_MESSAGE/;
# Create a new action: every time the trigger 'Another Trigger' toggles (from OK
# to PROBLEM or from PROBLEM to OK), send a message to the user with a short
# subject line and a slightly less short body
my $new_action = Zabbix::API::Action->new(root => $zabber,
data => {
name => 'Another Action',
eventsource => ACTION_EVENTSOURCE_TRIGGERS,
evaltype => ACTION_EVAL_TYPE_AND,
conditions => [ {
conditiontype => ACTION_CONDITION_TYPE_TRIGGER_NAME,
operator => ACTION_CONDITION_OPERATOR_LIKE,
value => 'Another Trigger' } ],
operations => [ {
operationtype => ACTION_OPERATION_TYPE_MESSAGE,
shortdata => '{TRIGGER.NAME}: {STATUS}',
longdata => 'Hey, look: {TRIGGER.NAME} is now {STATUS}' } ]
});
$new_action->push;

DESCRIPTION

Handles CRUD for Zabbix action objects.

This is a subclass of "Zabbix::API::CRUDE"; see there for inherited methods.

METHODS

collides()
Returns true if an action exists with this name, false otherwise.

EXPORTS

Many many constants that don't seem to be documented anywhere; see source for a complete list.

Nothing is exported by default; you can use the tags ":eventsources", ":condition_types", ":condition_operators", "operation_types" and "eval_types" (or import by name).

BUGS AND ODDITIES

The code in the SYNOPSIS works for creating actions, but not fetching them. I don't know if this is because of the specific data I'm sending; I can't see any obvious reason to be able to fetch some actions but not all, except possibly if the API user has no permissions on the triggers or other objects involved in the conditions. (Further experimentation reveals that even if I can pull the trigger set as a condition, I can't pull the action.)

Obviously this is problematic; in "CRUDE" we assume that if we can create an object we can also fetch it. This means we can't fetch back the action's ID, which in turns borks up the rest of the API.

As a very ugly workaround, you can set your API user as Super Admin (just Admin doesn't seem to work); apparently this issue then goes away. Without the workaround, this class will die with a meaningless exception in certain cases. Further input on what these cases are and why this happens is welcome.

Confirmed in 1.8.10.

AUTHOR

Fabrice Gabolde <[email protected]>

COPYRIGHT AND LICENSE

Copyright (C) 2011 Devoteam

This library is free software; you can redistribute it and/or modify it under the terms of the GPLv3.