As Balazs Scheidler has pointed out, it can be useful in complex
configurations to know the path over which syslog messages have
traveled. I think this would be a valuable addition to the COOKED
profile, but I'd like to bounce a few ideas off to see what
people think.
One possibility is to have something like
<entry deviceFQDN="..." facility="..." ...
path="relay1.example.com firewall.dev.example.com server.dev.example.com">
Problem with server!</entry>
This has the obvious problem that the attribute could get
really, really long. It also necessitates parsing the entire
entry to figure out how to change it properly. It's also hard
to extend later.
Another possibility is to have
<entry ...>
<received .../>
<received .../>
Replacement found
</entry>
This is going to be prone to problems like
<entry ...>
<received .../>
Replacement
<received .../>
in nostril
<received .../>
</entry>
because I don't think there's any way to avoid that in XML.
Another possibility is
<entry ...>
<received ... />
<received ... />
<received ... />
<message> Replacement found in nostril </message>
</entry>
which has the problem that in the simpler cases, <message> is
just plain overhead.
The choice I like best so far is
<trace>
<received .../>
<received .../>
<entry ...> replacement found </entry>
</trace>
That is, adding a top-level <trace> element, with <received> in
reverse order (first <received> is most recent), one for each
relay through which the entry passed. This gives obvious places
where the protocol can be extended, eliminates the need to do
a lot of sophisticated XML parsing on each hop (if you trust
the implementation on the other end), and provides a simple
separation between important content and operational/debugging
content.
I'll be adding this last option into the spec, but I'd like
comments on the general approach.
--
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
The tragedy of the commons applies to monitizing eyeballs, too.
