Integrating Hobbit with Ticketing system(s) / Feature Request
Some time ago (years actually), I integrated Big Brother with "Request Tracker", which is a popular open source helpdesk ticketing system. This was done by CCing hobbit alerts to the ticketing system, and the creation of a custom plugin that parsed the incoming mails and automatically created a ticket for red alerts. The plugin was "smart" enough so that when a recovery message arrived, it would auto-resolve the initial ticket created from the first alert.
I am now looking again at integrating Hobbit with a ticketing system,
but this time with "Jira" (http://www.atlassian.com/software/jira/).
Jira has a very useful API as well as an RCP/SOAP interface, so doing
something similar to what I did with RT should be relatively simple.
However, in going over the code in my head (I havn't written it yet), I see a problem. I believe that Hobbit is different from BB in that recovery pages are not sent with an ID (and I think if you forced it with a script the ID is "-1") which makes it impossible to relate them to the origional alert. Is there any simple way that we could have access to this ID number, or does Hobbit simply not track it?
Otherwise I may have to do something like query hobbitboard and look for a hostname.service that matches the resolved message, and I'd rather not do that as it will just slow things down and add extra complexity.
-Charles
On Mon, Jan 14, 2008 at 10:05:24AM -0700, Charles Jones wrote:
However, in going over the code in my head (I havn't written it yet), I see a problem. I believe that Hobbit is different from BB in that recovery pages are not sent with an ID (and I think if you forced it with a script the ID is "-1") which makes it impossible to relate them to the origional alert. Is there any simple way that we could have access to this ID number, or does Hobbit simply not track it?
Hobbit doesn't track it. The core Hobbit services only knows about hosts and services - alert handling is a separate utility, and is done entirely within the hobbitd_alert module. And there is no interface into the innards of hobbitd_alert.
I can see that some way of identifying an alert - both initially, when the alert is repeated, and when the issue ends - could be useful, especially for the task you've taken to integrate it with ticketing systems. The only unique identity of an event is the combination of hostname+testname+eventstarttime - this is also persistent throughout the life of an incident.
So how about stuffing all of this into an MD5 hash value, and use that as the event ID ?
Patch attached ... applies against the current snapshot, but it can easily be retrofitted onto the 4.2.0 code.
Regards, Henrik
participants (2)
-
henrik＠hswn.dk
-
jonescr＠cisco.com