This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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