RT2 Stats

Hi All,

A while ago there were a few discussions on this list about a stats
system for RT2, to pull out things like average time to resolution etc

Does anyone have any information or even better links to stuff that has
actually been done that is publicly available ?

Or … is anyone writing a system that they may need help developing or
writing or testing ?

And if not … I’m being seriously pressured to write something, so
would anyone else be interested in collaboration or testing or
assistance ?

Thanks,

Simon.

Simon,

I have not done much, but will need to do more on stats with RT. All I have
done is some queue-specific interface work for queue users that are not
interested in even approaching the full functionality of RT. I also took
Jesse’s HeadsUp stuff and tweaked it just a little bit. That gave me a minimal
amount of experience writing RT extensions/modifications using Mason. BTW,
this ability to extend and modify RT at will is a huge reason for using an
open product; it’s also one of the big reasons my group is switching to RT
from another internally developed application.

I would like to hear about which stats, specifically, you are looking for. If
we have the same needs, I’ll be glad to work with you and/or share what I come
up with.

Matt Disney

Simon Woodward writes:

On: Thu, 18 Oct 2001 12:21:29 CDT Matt Disney wrote:

Simon,

I have not done much, but will need to do more on stats with RT. All I have
done is some queue-specific interface work for queue users that are not
interested in even approaching the full functionality of RT. I also took
Jesse’s HeadsUp stuff and tweaked it just a little bit. That gave me a minimal
amount of experience writing RT extensions/modifications using Mason. BTW,
this ability to extend and modify RT at will is a huge reason for using an
open product; it’s also one of the big reasons my group is switching to RT
from another internally developed application.

I’ve been developing a reporting infrastructure on top of RT that can be
accessed via the web by manager-types. Currently it produces mostly
timing information, i.e. time spent per queue per month (or per year, or
for the months of Sep and Oct, etc), time spent per ticket per month,
blah blah. The focus right now is on timing information only because
that’s what people want right now. There are also command line scripts
that access the same reporting modules, so one isn’t bound to the web.

I’m writing this stuff pretty generally, though, so it is easy to expand
in the future.

If there are others out there that would like to collaborate, I’d be
more than happy to get involved.

–kip

I’ve been developing a reporting infrastructure on top of RT that can be
accessed via the web by manager-types. Currently it produces mostly
timing information, i.e. time spent per queue per month (or per year, or
for the months of Sep and Oct, etc), time spent per ticket per month,
blah blah. The focus right now is on timing information only because
that’s what people want right now. There are also command line scripts
that access the same reporting modules, so one isn’t bound to the web.

I’m writing this stuff pretty generally, though, so it is easy to expand
in the future.

If there are others out there that would like to collaborate, I’d be
more than happy to get involved.

I’d love to see your code. Do you have a CVS repository somewhere?

srl
Shane Landrum (srl AT boston DOT com) Software Engineer, boston.com

I’ve actually started on one of these too :wink:

ftp://ftp.fsck.com/pub/rt/contrib/2.0/rt-addons/HeadsUp

This is the basis of the managment reporting tools that will be included
in 2.2. If folks want to put their energy into extending it, I’d be thrilled.

-jOn Thu, Oct 18, 2001 at 02:36:41PM -0400, Shane Landrum wrote:

On Thu, Oct 18, 2001 at 02:03:05PM -0400, Kip Cranford (kip.cranford@pgamapd.com) wrote:

I’ve been developing a reporting infrastructure on top of RT that can be
accessed via the web by manager-types. Currently it produces mostly
timing information, i.e. time spent per queue per month (or per year, or
for the months of Sep and Oct, etc), time spent per ticket per month,
blah blah. The focus right now is on timing information only because
that’s what people want right now. There are also command line scripts
that access the same reporting modules, so one isn’t bound to the web.

I’m writing this stuff pretty generally, though, so it is easy to expand
in the future.

If there are others out there that would like to collaborate, I’d be
more than happy to get involved.

I’d love to see your code. Do you have a CVS repository somewhere?

srl

Shane Landrum (srl AT boston DOT com) Software Engineer, boston.com


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.

On: Thu, 18 Oct 2001 14:36:41 EDT Shane Landrum wrote:

I’d love to see your code. Do you have a CVS repository somewhere?

srl

Shane Landrum (srl AT boston DOT com) Software Engineer, boston.com

Just my local CVS stuff. I’m in the middle of some coding right now, so
it’s kind of broken, but I’d be happy to post some of it when I feel
it’s worthy.

When I do, I’ll send out a link to where you can get it.

–kip

Jesse Vincent writes:

I’ve actually started on one of these too :wink:

ftp://ftp.fsck.com/pub/rt/contrib/2.0/rt-addons/HeadsUp

This is the basis of the managment reporting tools that will be included
in 2.2. If folks want to put their energy into extending it, I’d be thrilled.

I’m working on some report queries, and I’d love to be able to use the
existing HeadsUp-style reports. The problem that I’m facing is that to get
the kinds of reports I want, it seems to be much more efficient to write
queries direct to the database. Skipping the official interfaces isn’t
ideal though, and so I’m hoping that I’m just missing something.

Here’s one simple example, though I have other reports that use similar
methods:

Instead of iterating over the set of all tickets (or even a large subset)
and counting up the number of tickets created and resolved in each month, I
just have the database do it, returning an answer in seconds even on a
fairly large database:

select count(*), year(Created), month(Created) from Tickets where Status
!= ‘dead’ and Queue = ? and id = EffectiveId group by year(Created),
month(Created)

select count(*), year(LastUpdated), month(LastUpdated) from Tickets where
Status = ‘resolved’ and Queue = ? and id = EffectiveId group by
year(LastUpdated), month(LastUpdated)

Jesse (or others), if you think that the existing search API can do this
sort of thing, please let me know. What method do you recommend?
Thanks,
-Matt

Thanks for all that replied to this …

Sorry it took me a few days to respond, just been very busy.

I am going to have to move ahead on this, as its becoming more of a
requirement in an environment that must be monitored and targets set and
met, (oh god, now I sound like them as well ack :wink: ).

Would people be interested in a discussion on this list about what this
kind of system should show / do, ideas how to go about it, suggestions
all that, or if you want I could set up another list, where any parties
interested in commenting or collaborating could then subscribe and we
could go from there ?

Simon.

Would people be interested in a discussion on this list about what this
kind of system should show / do, ideas how to go about it, suggestions
all that, or if you want I could set up another list, where any parties
interested in commenting or collaborating could then subscribe and we
could go from there ?

Its no difference to me, but I’m definitely interested in this topic,
seeing that people are hounding me for the same information :slight_smile: I’ve
got a few ideas on which direction we’d like to go, and I’m sure others
would find it of value as well…

Dewet

Dewet Diener dewet@itouchlabs.com -o)
Systems Administrator iTouch Labs /
Self-confessed geek and Linux fanatic __v

SYN! … SYN! ACK! … ACK!
The mating call of the internet

Simon Woodward wrote:

Does anyone have any information or even better links to stuff that has
actually been done that is publicly available ?

My own stuff is available at http://peabody.itd.uts.edu.au/rt-stats/

It’s written as a straight CGI, but it works, and it’s fast. Feel free to
hack at it, of course.

T�o de Hesselle, \ One possible reason that things
Unix Systems Administrator \ aren’t going according to plan
\ is that there never was a plan
University of Technology, Sydney \ in the first place.