On Nov 8, 2007 8:22 AM, Jeff Gribbin, EDS <[EMAIL PROTECTED]> wrote: > Regarding the, "problem" of perhaps wishing to only collect a subset of > the monitor records for, "MONWRITE" / post-processing activities while > still needing a fuller set of records for realtime monitoring, it is > really a trivial exercise to write a PIPE that collects MONITOR records (a > la MONWRITE) and, of course, it would be equally trivial to code a filter > into that pipe to drop the records that were only of, "real time" interest.
That's a completely fair requirement, and has been forever. Different roles have different needs. Folks dealing with capacity planning and charge back need not much detail but do need full data (which is not trivial to do with monitor data). For diagnosing a problem, you need very detailed performance data, but maybe not all and probably only for a short while. And for trend analysis and performance forensics, you need all the "interesting" data for as long as you can afford (to answer questions like "does process xyz always use this much CPU on the 3rd thursday of the month") You can condense monitor data with 1-minute granularity into "pseudo raw" data with for example 15 minute granularity. It's not trivial, but it can be done (ESALPS does so for folks who need to post-process raw data elsewhere). But raw monitor data is not the most economic format to archive performance data, and certainly not a practical one to extract data for analysis and reporting. That's why we have our own performance database to keep "interesting" data with required granularity and retention (and can feed enterprise planning tools with that data). Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
