On Mon, 2011-05-09 at 15:34 +1000, Nathan Scott wrote:
> ----- Original Message -----
> > Ouch. Sorry had not considered this. I'll undo those changes and leave
> > the hinv metrics alone.
> >
> > Special cases in QA is better than special cases in pmlogextract.
> >
> > We probably need to think more carefully about how metadata changes
> > could be made in general for established metrics ... at some point
> > someone will want to promote a metric from 32-bit to 64-bit, or Bytes
> > to
> > Mbytes, or ... so the problem is a latent one that will come back at
> > some point in the future.
>
> *nod* ... its not a future problem, happens semi-regularly... someone
> adds an application metric with incorrect metadata, someone else fixes
> it ... next app upgrade, *boom*. And if not picked up within the log
> rotation/culling window, data is lost (a whole day).
>
> I would love to see "harmless" metadata changes - like the 32/64 bit
> upgrades, this count vs none, maybe one or two others? automatically
> handled by logextract ... it goes beyond just this (good imo) change
> you have here, to a more general issue.
I agree. We just need some more coding pixies to throw at problems like
this.
|