OK there seems to be consensus ... I'll make the changes to support
instance domains for event records.
On Thu, 2011-03-10 at 22:18 +1100, 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.
>
> > 2. Export one metric, with the stream id as the first parameter
> > of each event record. For example
> >
> > logger.events
> > [record]
> > logger.stream "/var/log/messages"
> > logger.param_string "some messages text"
> > [record]
> > logger.stream "/var/log/auth.log"
> > logger.param_string "some auth text"
> >
>
> This looks better, but still not great - has the downside that the
> "stream" string bloats out every event record, when its really more
> of a fixed up-front thing.
>
> > 3. Export one metric with one instance per stream. For example
> >
> > logger.event["/var/log/messages"]
> > [record]
> > logger.param_string "some messages text"
> > logger.event["/var/log/auth.log"]
> > [record]
> > logger.param_string "some auth text"
> >
> > I suspect 2. may be the most commonly used encoding for a PMDA
> > exporting multiple event stream.
> >
> > 1. and 2. work today. But 3. is not supported at the moment.
> >
> > So the discussion needs to be "should we support 3. as well?"
>
> It (3) does seem the cleanest representation to me (for some reason
> though, I thought we had claimed the indom field for something else
> in event record metrics, but might be misremembering that).
>
> The really good thing about 3 is that client tools should be able
> to make use of the existing indom profile concept to filter those
> streams ... which would seem a relatively common scenario, and it
> would be quite clunky (well, impossible?) in case 2.
>
> If that indom field is still unused and this is doable, I'd prefer
> option 3 to be available, for sure.
>
> cheers.
>
|