Integration of Monitoring-Tool into OTRS
Dear List,
I've some generel question about the integration of
Monitoring-Systems into OTRS.
We are using a network-based host- and service-monitoring
tool that sends different notifications via email (or
anything else that can be written into a shell-skript).
As every incoming email generates a new ticket in OTRS
I want some integration that the monitoring server does
not sends mails, but opens new tickets, inserts follow-
ups and also closes tickets (on recovery of a problem, e.g.)
As I drawed already a compley picture of such a setup
in my mind I just wanted to ask / discuss:
- if somebody has experiences on such a task here?
- if it is the best way to (mis-)use the GenericAgent
for such a job?
- does the GenericAgent can create new tickets at all,
or does the GenericAgent is always based on already
existing tickets?
- should I write a whole OTRS-LowLevel-Module which
analyses the incoming events and inserts directly
into the database?
- is there any better (generic) API available for OTRS?
Thanks for all input!
Matthias Eichler
--
Matthias Eichler
On Friday, May 07, 2004 3:29 PM
Matthias Eichler
As every incoming email generates a new ticket in OTRS
Not quite true. Incoming emails that are identified as follow-ups to existing tickets won't create a new ticket, but will in fact be added to the existing one.
I want some integration that the monitoring server does not sends mails, but opens new tickets, inserts follow- ups and also closes tickets (on recovery of a problem, e.g.)
Despite the latter, this weren't a problem. OTRS' core function is to open up tickets on receival of new emails and add follow-ups to existing ones, ie. track tickets. Closing tickets via email isn't impossible at all, but requires coding.
- if it is the best way to (mis-)use the GenericAgent for such a job?
Strike through the (mis-), as GA is meant for performing tasks like these.
- does the GenericAgent can create new tickets at all, or does the GenericAgent is always based on already existing tickets?
No, GA can't, and yes, GA can. GA runs on existing tickets, but you may well run shell scripts from within GA, from within you may send an email which opens up a new ticket, if you want.
- should I write a whole OTRS-LowLevel-Module which
Depends on your demand. Why not? A maximum of flexibility combines with the highest complexity, though. See below. Btw, what are low-level modules? Or better: what were high-level modules then?
analyses the incoming events and inserts directly into the database?
No, under seldom circumstances only you should write a thing directly to the DB. Try to prevent it wherever possible. Use Procmail (or your mail server directly) or the lightweight, but integrated version: OTRS' PostMaster::PreFilterModule capabilities. grep Kernel/Config/Defaults.pm for them. You are allowed to set X-OTRS-headers from within Procmail or the PreFilter modules.
- is there any better (generic) API available for OTRS?
We believe our model to be quite sophisticated and usuable. No, there's no hidden connec to OTRS than the documented one. Regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
As every incoming email generates a new ticket in OTRS Not quite true. Incoming emails that are identified as follow-ups to existing tickets won't create a new ticket, but will in fact be added to the existing one.
Ok, this was already clear to me, but I meant it in combination with the notification of our monitoring server, which does not know anything about any Ticket-IDs, so no follow-ups can be created without any coding-work to do.
I want some integration that the monitoring server does not sends mails, but opens new tickets, inserts follow- ups and also closes tickets (on recovery of a problem, e.g.)
Despite the latter, this weren't a problem. OTRS' core function is to open up tickets on receival of new emails and add follow-ups to existing ones, ie. track tickets.
But therefor I need a stage between the monitoring server which notifies about a problem, a (to code) application which analyses these notifications and holds a state for rewriting the notification- mails, so OTRS can recognize a follow-up.
Closing tickets via email isn't impossible at all, but requires coding.
But GA is a good way for this, isn't it?
- if it is the best way to (mis-)use the GenericAgent for such a job? Strike through the (mis-), as GA is meant for performing tasks like these.
My problem is only that GA is running in cron-mode and not as a daemon which is always running through all incoming mails, e.g. So I need a pre-stage in OTRS again in which all notifications come in and though which OTRS-GA is running and maybe deleting on some defined criterias.
- does the GenericAgent can create new tickets at all, or does the GenericAgent is always based on already existing tickets? No, GA can't, and yes, GA can. GA runs on existing tickets, but you may well run shell scripts from within GA, from within you may send an email which opens up a new ticket, if you want.
Do you mean I create a search pattern in GA on which GA will never find any ticket and then running a shell script? Or would GA not run the script when not finding any existing ticket? Because if it just works when finding a ticket it wouldn't make sense to let GA send a new mail, when a mail was already received by OTRS before...
- should I write a whole OTRS-LowLevel-Module which Depends on your demand. Why not? A maximum of flexibility combines with the highest complexity, though. See below. Btw, what are low-level modules? Or better: what were high- level modules then?
I was thinking of an easy module which maybe can be written already by my person (a non-coder), maybe through a existing, documented framework. Because it would make no sense (or better: it would cost to many ressources) to get a coder who first has to read, under- stand OTRS in all its functions to write a module for our functionality.
No, under seldom circumstances only you should write a thing directly to the DB. Try to prevent it wherever possible.
Ok, thats what I am thinking too about this way ;-)
Use Procmail (or your mail server directly) or the lightweight, but integrated version: OTRS' PostMaster::PreFilterModule capabilities. grep Kernel/Config/Defaults.pm for them. You are allowed to set X-OTRS-headers from within Procmail or the PreFilter modules.
That sounds very good for me!
Maybe I just let the monitoring server write the important
criteria (like system hostname, notification status, into the
X-OTRS-headers). Then the PreFilter would search through these
infos and sorts depending on the X-OTRS-headers and creates a
follow-up or closes a ticket depending on these infos.
Thank you for your very nice input!
Matthias
--
Matthias Eichler
On Monday, May 10, 2004 2:37 PM
Matthias Eichler
I want some integration that the monitoring server does not sends mails, but opens new tickets, inserts follow- ups and also closes tickets (on recovery of a problem, e.g.)
Despite the latter, this weren't a problem. OTRS' core function is to open up tickets on receival of new emails and add follow-ups to existing ones, ie. track tickets.
But therefor I need a stage between the monitoring server which notifies about a problem, a (to code) application which analyses these notifications and holds a state for rewriting the notification- mails, so OTRS can recognize a follow-up.
So you're thinking of s.th. similar to this? a) "I'm server A, I'm down" -> OTRS creates Ticket#123 b) "I'm server A, I'm still down" -> OTRS creates a FollowUp to Ticket#123 c) "I'm server A, I'm up" -> OTRS closes Ticket#123 This were tasks to be performed the time the email is received. See below.
Closing tickets via email isn't impossible at all, but requires coding.
But GA is a good way for this, isn't it?
No, it isn't, as GA doesn't receive a mail. It were the PostMasterFilter or Procmail you need to configure.
- does the GenericAgent can create new tickets at all, or does the GenericAgent is always based on already existing tickets? No, GA can't, and yes, GA can. GA runs on existing tickets, but you may well run shell scripts from within GA, from within you may send an email which opens up a new ticket, if you want.
Do you mean I create a search pattern in GA on which GA will never find any ticket and then running a shell script? Or would GA not run the script when not finding any existing ticket? Because if it just works when finding a ticket it wouldn't make sense to let GA send a new mail, when a mail was already received by OTRS before...
To repeat, GA doesn't receive a mail and requires a ticket to work on. In opposite to that, GA can also start shell scripts of your choice - these can perform whatever you like and need not rely on a ticket.
Use Procmail (or your mail server directly) or the lightweight, but integrated version: OTRS' PostMaster::PreFilterModule capabilities. grep Kernel/Config/Defaults.pm for them. You are allowed to set X-OTRS-headers from within Procmail or the PreFilter modules.
That sounds very good for me! Maybe I just let the monitoring server write the important criteria (like system hostname, notification status, into the X-OTRS-headers).
Go, go, go! ;)
Then the PreFilter would search through these infos and sorts depending on the X-OTRS-headers and creates a follow-up or closes a ticket depending on these infos.
The PreFilter cannot close a ticket (as long you don't use a shell script again), he only sets certain headers. If you set these headers via the Monitor, you need no PreFilter nor Procmail anymore. What's still open: How do you inform the webserver about the ticket number? You will have to let him know "his" ticket number, otherwise you'll end up with what you have: Every eMail creates a new ticket. One might think about a "single-ticket" solution, ie., if a customer (webserver) has an existing ticket, every incoming eMail will be regarded as being a Follow-Up to that existing ticket. Another idea were to write a new PostMaster module that scans an email and recognizes the monitor's output. We're moving towards an asset management or similar, I believe. Regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
participants (2)
-
Matthias Eichler -
Robert Kehl