On Thu, 2011-03-10 at 11:47 -0600, David Smith wrote:
> On 03/10/2011 05:18 AM, Nathan Scott wrote:
> >
> > ----- "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> wrote:
> >
> >> On Thu, 2011-03-10 at 08:57 +1100, Ken McDonell wrote:
> >> Further to my earlier mail, I think we should consider event records
> >> to belong to a "stream", where a stream may be a logfile (in David's
> >> case), or from a process/thread, or a session, or an event trace for
> >> an operation, or ...
> >>
> >> The options we have for a PMDA exporting multiple streams appear to
> >> be as follows.
> >>
> >> 1. Export one metric per stream, using the dynamic metric
> >> services to augment the namespace as needed. For example
> >>
> >> logger.var.log.messages
> >> [record]
> >> logger.param_string "some messages text"
> >> logger.var.log.auth.log
> >> [record]
> >> logger.param_string "some auth text"
> >
> > Doesn't seem a great option really, when spelled out like that.
> > Events are still quite unexplored, but historically metric names
> > that embed an instance like this make for difficult inclusion in
> > configuration languages for the tools like pmchart, pmie.
>
> For my purposes, I'll probably choose this solution (for now). In my
> case anyway, the list of logfiles will come from a config file consulted
> at startup, so I won't be using truly dynamic metrics. At startup, I'd
> read the config file and then create the metric table based on the
> config file's contents. Then the metrics would be static from that
> point out.
In this case the metrics are still considered dynamic ... the key is
that if the existence of the metrics is known only to the PMDA, then
PMCD cannot answer questions about metric names (more generally requests
against the Performance Metrics Name Space, or PMNS), and these requests
must be forwarded to the PMDA. It is this that makes the metrics
"dynamic", rather that they may appear or disappear in the life of the
PMDA (although this is also allowed for dynamic metrics).
|