Hi all,
I’m starting to look at patching outage tracking functionality onto RT
2.0.13. I thought I’d ask if anyone else had done any work on this before
I get knee deep in source.
Basically, the idea I’m running from is to have a section in WebRT where
one could select a ‘system’, an optional ‘application’ (both being fed from
keywords), a start date+time, an end date+time, and a boolean flag for
whether or not the outage was SLA impacting.
Given this data, you could do a SQL query for each reporting period to be
able to compute outage information.
As I begin on this – has anyone started any effort on something
similar? If not, any advice/ideas on what else this should include?
Thanks in advance
–D
At 5/28/2002 03:33 PM, you wrote:
(gratituitous snippage below… watch out for paper cuts)
“Started”!
“Due”!. Maybe you would relabel the field for convenience; that’s the
ankles-deep part. 
Keyword!
I’d recommend an RT query – that’s what published APIs are for
It sounds like you’re done.
That seems like something that would work in some cases. But, the
flexibility I’m looking for is for a ticket to be able to list [0…n]
outages. Imagine a WAN where a single fiber cut could cause many, many
circuits to be down – you would not want to open a different ticket for
each as it’s all the same fiber cut – but you would want to track which
circuits were down and for how long. (And hopefully be able to report to
each customer which circuits of theirs were affected)
Of course, something similar to this could be accomplished with the fields
you suggested and parent/child relationships.
Thanks for the ideas!
–D
Duane Waddle wrote:
That seems like something that would work in some cases. But, the
flexibility I’m looking for is for a ticket to be able to list [0…n]
outages. Imagine a WAN where a single fiber cut could cause many, many
circuits to be down – you would not want to open a different ticket for
each as it’s all the same fiber cut – but you would want to track which
circuits were down and for how long. (And hopefully be able to report to
each customer which circuits of theirs were affected)
Of course, something similar to this could be accomplished with the fields
you suggested and parent/child relationships.
Or with “Multiple” type keyword selections in one ticket.
dwaddle@charter.net wrote a 1.1KB message. i replied …
That seems like something that would work in some cases. But, the
flexibility I’m looking for is for a ticket to be able to list [0…n]
outages. Imagine a WAN where a single fiber cut could cause many, many
circuits to be down – you would not want to open a different ticket for
each as it’s all the same fiber cut – but you would want to track which
circuits were down and for how long. (And hopefully be able to report to
each customer which circuits of theirs were affected)
I agree that ‘Started’ is a good move in the right direction.
This is similiar to a problem that i’m facing with my MON->SOAP->RT ticket
manipulation dealie (a crude thing which opens a RT ticket based upon
network outages) . .
State needs to be maintained in the monitoring system (probably not in RT)
to know whether to create a new ticket for an outage, or to update an
existing issue based upon the current criteria.
I suspect that it might be easy enough using only a few variables in
your ticket creation environment (network group name,host name,service name)
which you’d need to store and reload on the server somewhere so that
you don’t mistakenly create new tickets instead of updating current ones
with each monitoring system reboot. Perhaps using something like MDBM or
MLDBM?
gzcat whoami,
_M.
Michael Jastremski openphoto.net
Senior Network Admin aim:xunixx
GovernmentLiquidation.com Washington DC
Hi all,
I’m starting to look at patching outage tracking functionality onto RT
2.0.13. I thought I’d ask if anyone else had done any work on this before
I get knee deep in source.
Ankles, maybe…
Basically, the idea I’m running from is to have a section in WebRT where
one could select a ‘system’,
Keyword!
an optional ‘application’ (both being fed from keywords),
Keyw… yeah, what HE said.
a start date+time,
“Started”!
an end date+time,
“Due”!. Maybe you would relabel the field for convenience; that’s the
ankles-deep part.
and a boolean flag for whether or not the outage was SLA impacting.
Keyword!
Given this data, you could do a SQL query for each reporting period to be
able to compute outage information.
I’d recommend an RT query – that’s what published APIs are for
As I begin on this – has anyone started any effort on something
similar? If not, any advice/ideas on what else this should include?
It sounds like you’re done.
-Rich
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------