This module has been implemented for a migration project with the purpose to replace a BMC Event Manager installation. It therefore does not aim to be a one-size-fits-all solution.
...serves the following purposes:
- provide a drop-in replacement for
msend(via the msend module) - sync issues from SCOM
- sync objects from the Icinga IDO
- provide Hooks to allow to implement various kinds of back-channels
In said project, we used the following modules combined with this one:
- BEM module: an integration with the BMC (ProactiveNet) Event Manager©. Originally used to send events to BMC, still in use to prove that EventTracker behaves the same way BMC used to work
- iET module: hooks
into various modules:
- as an Import Source into Icinga Director
- as Host/ServiceAction into the Monitoring module (to create tickets)
- as an EventAction into the EventTracker, mainly to create Operational Requests
- msend module: This module will receive Icinga Alerts via msend from the BMC (ProactiveNet) Event Manager©)
This module allows Operators to track Events from various sources in a single place. It provides Hooks allowing Third-Party modules to trigger custom actions, with Ticket/Issue-Creation being the most obvious use-case.
There are also hooks for a back-channel, providing information regarding created tickets and acknowledged or resolved problems to various Event senders.
To get this up and running, please:
- create a MySQL/MariaDB database
- apply the provided schema file in
schema/mysql.sql - define a related DB resource in Icinga Web 2
Now you're ready to populate /etc/icingaweb2/modules/eventtracker/config.ini:
[db]
resource = "Event Tracker"Per default, this module shows all problems starting from a warning level.
Filters are customizable in the UI, you can optionally customize the
default setting as follows:
[default-filters]
severity = emergency, alert, critical, errorThis module replicates available Icinga Object names from the IDO database, and optionally also fetches Custom Variables. In case you need such, please define then:
[ido-sync]
vars = location, priority
; Optionally look up hostnames with this domain:
; search_domain = example.comNote This is a temporary, experimental feature. It will soon be superseded and replaced by a better implementation. Use at your own risk, it might be removed without pre-announcement at any time.
To set a list of Hosts in maintenance, you can provide a JSON-encoded host list file. Tell the Eventtracker about its existence:
[maintenance]
host_list = "/etc/icingaweb2/modules/eventtracker/host_maintenance_list.json"
; hostname_property = "hostname"It must contain a list of objects, and could look as follows:
[
{"hostname": "sample1.example.com", "address": "192.0.2.11"},
{"hostname": "sample2.example.com", "address": "192.0.2.12"}
]Optionally you can define which property to use as your hostname, this defaults
to hostname. If configured, Eventtracker will complain about a missing file
or invalid JSON encodings or content lines.
The easiest way to create such a file is leveraging the Import Source functionality of the Icinga Director. Pick any Import Source by ID, and let a Cron job write it's content to disk:
*/5 * * * * /usr/bin/icingacli director importsource fetch --id YOUR_ID \
> /etc/icingaweb2/modules/eventtracker/host_maintenance_list.json
Note Adding entries to this list has no effect on already created issues, unless a new related event arrives
DEPRECATED: this still works, but the msend receiver has been moved to the msend module. Please expect this to be removed in future versions.
[msend-severity-map]
CRITICAL = alert
MAJOR = critical
MINOR = error
WARNING = warning
INFORMATIONAL = informational
INFO = informational
NORMAL = informational
OK = informationalForwarding msend-like parameters via HTTP might become tricky, that's why we
provide a script that behaves like msend in contrib/msend-eventtracker. In
case you need to wrap this in a custom script and face encoding issues, logging
every single command might help:
[msend]
force_log = yesIt might be desirable to disable some of the provided features. Currently this
is possible only for the part that deals with the owner of your issues:
[features]
disabled = ownerIn case you want to periodically replicate issues from SCOM, please add a dedicated section:
[scom]
db_resource = "MSSQL SCOM"
; query_file = "scom_alerts.sql"
; simulation_file = /tmp/scomtest.json
; poll_interval = 5
; cmd_ticket_ref = "/usr/bin/ssh icinga@scom.example.com 'c:\\Scripts\\UpdateScomAlertTicketIdV1.ps1' '{sender_event_id}' '{ticket_ref}' '{owner}'"
; cmd_close = "/usr/bin/ssh icinga@scom.example.com 'c:\\Scripts\\ResetScomMonitorV3.ps1' '{sender_event_id}'"You might want to enrich issues with custom attributes:
[scom_attributes]
my_SPECIAL = "https://wiki.example.com/RedirectPage.aspx?id=Windows-{rule_monitor_id:lower}"Usually you want to fetch from the MSSQL database populated by SCOM, so please
provide a related db_resource. For testing reasons one might also want to use
a JSON-encoded file, that's what the simulation_file setting is for.
You might want to automatically close issues in SCOM once they're being closed in the EventTracker or to update a reference to created tickets when this module creates such.
Currently the following settings are available:
[ui]
; Allow no more than X issues to be selected at once. Defaults to 50:
; multiselect_max_issues = 50
;
; Set to yes to disable the Web frontend:
; disabled = no- BREAKING: Change default severities for BMC Event Manager (#12)
- FIX: Better title for issues without host (#13)
- FIX: Deal with empty attributes not stored as NULL (#14)
- FIX: IssueHeader links to host only if there is such (#15)
- FEATURE: msend/push has been deprecated in favor of the msend module (#16)
- FIX: exception when accessing attributes (#18)