The current brolley/multi-archive work requires metrics to preserve
their type across the individual archives (in a directory or list)
that span it. There are at least two problems with this.
- pmdas can change over time, changing the data types of their metrics
- pmlogrewrite rules may change over time. Old archives may have
had different types from newer ones (with a fresher pmlogrewrite
rules being applied), and rerunning pmlogrewrite on ancient archives
is not customarily done
- pmlogreduce widens the type of counters from 32->64 bits
All of these mean that asserting that data types are identical
across multiple archives is problematic. It means that multi-archive
operations will miss, perhaps quietly, those other archives.
(This comes up immediately with pmmgr/pmlogreduce/pmwebd graphs
that cross from the 15->14 day-age boundary.)
We should consider relaxing this constraint.
One way would be to have an initial metadata scan pass across the
multi-archive set, and look for data type changes. In the case of
any, arrange to widen, perhaps up to PM_TYPE_DOUBLE if necessary.
That would mean having to remap pmResults on the fly, would be
complicated ... but wonderful for generality.
Another way would be to have a pmlogrewrite rule that widens all
counters to 64 bits, to mesh pmlogreduce's policy, and encourage
the tooling to run pmlogrewrite right after pmlogger's done. This
would be simpler but would exclude currently-being-written pmlogger
files from a multi-archive.
Another way would be perhaps to change the pmlogreduce policy, and
represent potentiall large counter deltas/overflows some other way.
This would reduce the wide spread of this problem.