Issue #9687 has been updated by Wil Cooley.

James Turnbull wrote:
> Not a criticism Wil but does anyone other than Splunk use CIM?  Wouldn't it 
> be easier to build an upstream parser than change log output for everyone?

To be honest, I don't really care about CIM per se; I mostly just want 
structure to the messages to make parsing and classifying less of a chore.
Currently one has to catalog every message that one finds and then write a new 
rule to extract data for each one (and then continue to watch for new message 
types or changed formats, since new messages with new formats could appear at 
any time). Having inherent structure would make it possible to automatically 
classify the messages and extract relevant data with any number of tools.

I guess the first question to settle is whether or not more structure in log 
messages is a worthwhile goal; how that is accomplished is a matter for later.
----------------------------------------
Feature #9687: Improve structure of messages logged to syslog
https://projects.puppetlabs.com/issues/9687

Author: Wil Cooley
Status: Needs More Information
Priority: Normal
Assignee: Wil Cooley
Category: logging
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


It would be nice if the messages logged to syslog were more clearly structured 
for processing by log-analysis tools like Splunk.

The current messages are kinda parsable, but following CIM, Common Information 
Model, would be more readily machine-readable. Splunk automatically extracts 
key=value fields when it finds them in events, so structuring messages like 
this gets you a lot for free. I think this format would also be more amenable 
to searching & processing with basic Unix tools like grep and awk.

Here is a little, accessible doc about CIM from Splunk (at least Splunk Inc's 
notion of CIM); a lot of the information I've seen is 1000-ft DMTF gobbledygook:

http://docs.splunk.com/Documentation/Splunk/latest/Knowledge/UnderstandandusetheCommonInformationModel

And that's even more spec than I care about--the most important part
is that the messages are structured as a series of key=value pairs (and
that there is internal consistency with the keys).

Here are some examples of how one might restructure a few log messages:

Current:
    (//syslog::rsyslog/Service[rsyslog]) Triggering 'refresh' from 2 
dependencies

CIM:
    action=refresh resource_type=service resource_name=rsyslog 
class=syslog::rsyslog triggered_by=2

Current:
    (/File[/etc/rsyslog.d/30_forward.conf]) Filebucketed 
/etc/rsyslog.d/30_forward.conf to puppet with sum xxxxxx

CIM:
    action=filebucket resource_type=file 
resource_name=/etc/rsyslog.d/30_forward.conf buckethost=puppet md5sum=xxxxxx
    
Current:
    (//denyhosts/File[/var/lib/denyhosts/allowed-hosts]/mode) mode changed 
'400' to '444'

CIM:
    action=mode_change resource_type=file 
resource_name=/var/lib/denyhosts/allowed-hosts mode_from=400 mode_to=444


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

Reply via email to