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 DevoteamThis library is free software; you can redistribute it and/or modify it under the terms of the GPLv3.