[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20050830: pqbinstats replacement?

David,

We probably do more monitoring of the IDD than anyone and we don't use
pqbinstats(1) at all.

If you don't want to use rtstats(1), then you could always copy the
pqbinstats(1) program from the previous installation to the current
"bin/" directory.

Regards,
Steve Emmerson

NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.

------- Original Message

>To: Unidata Support <address@hidden>
>From: David Wojtowicz <address@hidden>
>Subject: pqbinstats replacement?
>Organization: UCAR/Unidata
>Keywords: 200508292252.j7TMq2jo010404


I've upgraded to LDM 6.4.1 at the request of Gilbert.  Now I see that  
pqbinstats is no longer just deprecated, but rather gone entirely.   
We were processing the .stats files to monitor the timeliness of our  
feeds and set off alarms as appropriate.   And for manual viewing,   
ldmprods was not entirely useful in itself due to the hour  
boundaries, but modifications of it to span files worked reasonably  
well.   I looked through the documentation as to what the replacement  
was, but found nothing helpful.

rtstats sends something in an underdocumented format to you where it  
is compiled into not very useful web pages... nothing in a consise  
tabular format like ldmprods, but rather maps like the giant globe on  
the stats page with mostly empty space and lots of uninterpretable  
overlaid lines across the conus or gnuplot graphs (which don't show  
the difference between 1 second latency and 60 seconds latency if  
there is a spike somewhere in the history that changes the scaling)  
and can't be automatically monitored to send alerts.

I understand that you can send rtstats to yourself, and ingest them  
and the process them with something, but that seems a roundabout way  
of doing it.  It is also "in-band", which means that problems might  
keep the information that would show the problem from getting through.

Am I missing something?... there really should be a way of locally  
determining one's performance.

------- End of Original Message