----- "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.
--
Nathan
|