[logs] CEE - a new logging standard

[Tom Le]

 I personally don't believe the fruits of this effort, even if a standard
were available *today*, will make it's way to the industry for many years.
Why?  Cost, legacy, competitive advantages, and the "mandate paradox".

Cost - For the vast majority of vendors (especially the big ones), logging
is one of the least important aspects of their development process.   There
are different groups responsible for different components.  If normalizing
logging internally adds cost and time to development, I don't see vendors
fixing their existing logging issues and on top of that compiling with a new
standard.  One could argue that by providing the standard, we give vendors a
road map for fixing internal logging issues.  True, but vendors must first
commit to the process which is expensive.  It's like watching Oprah and Dr.
Phil and having the roadmap to fixing your life.  If it's too expensive, or
too much effort, you'll never get started.  The best we can hope for is the
new standard will be adopted for new device development where the
incremental cost to "do logging right" is small if it is introduced at
project inception.

Legacy issues - Vendors (especially the big ones) have a lot of logging
"history" based on nuance & convention.  To change their logging format,
content, or transport will not only involve new product development efforts,
but downstream effects to any part of the business that the logs
touch: support issues, training courses, certifications, books,
vendors/partners, etc.  The only way to introduce a drastic change in
logging and maintain legacy support is to do both in parallel and allow
users to choose either logging format (i.e. this is how SNMPv2 and v3
adoption happened).  This means added cost.  There are also legacy issues in
the open source community that will have resistance to a new logging format
.  E.g. Unix logs stand to benefit the most from a new standard, but that
community may be the most likely to resist.  Not to mention the many
different components with diverse origins and contributors.  (Note: I've
been talking for awhile about an opportunity today for a mid-tier
application to take existing logs and transform them to some standard, but
this only addresses what content is available today what is logged today,
not what should be logged but isn't.)

Competitive advantages - Paul Melson accurately wrote in his blog (in
commenting on CEE) that "It costs SIM vendors a decent chunk of change in
development and support cost to spin up support for new products.  Standards
make this proposition cheaper: one set of code to maintain, potentially
hundreds of products supported."  This is precisely the reason why you WON'T
see the largest vendors evangelizing any new log standard.  It's a huge
barrier to entry (in their favor).  I'm not just talking SIM vendors but any
log management company or managed security services provider who has already
invested in normalizing and building content around log messages -- they have
a huge competitive advantage.  Even Anton's company and it's competitors
would be inviting competition if a new log standard was adopted overnight.
Imagine how easy it would be to build a new log-centric product or service if
you didn't have to spend as much time building support for a hundred vendor
devices (e.g. an MSSP that support a million log events).

A mandate paradox - Device vendors support standards when it is in their
best interest to do so (whether you're talking about logging or
authentication, or any other standard).  If you are a network device vendor,
you build (proper) SNMP support such that your customers using HP Openview
won't disqualify your device from consideration.  What is the incentive for
existing vendors (especially the big ones) to change their logging format?
The big players in the log derivative industry (SIM, log management,
enterprise monitoring, reporting/analysis apps, service providers, etc.)
already support the existing format and content for the top X vendors.
There is no incentive or mandate for existing device vendors to change their
logging format.  You need the log derivative industry to first build support
for the new standard before existing vendors will consider investing in
change.  But these log derivative vendors already have a competitive
advantage but NOT doing so.  The only players jumping on this new standard (at
least in the early stages) will be small ones.

IMHO, the only way you'll see the big device vendors jumping on a new log
standard is if you see the big log derivative players drawing a line in the
sand.  But that's like saying the vultures can tell the lions what to do.
The log derivative industry exists because they live off the logs produced
by the device industry.  Will there ever be a log derivative player large
enough to push around the device players?  Perhaps HP Openview, but they
will be pushing a narrow framework that supports their own best interests.
Besides, Openview is the king of modules and plugins - a huge competitive
advantage to deal with a heterogeneous logging universe.

Another issue regarding the log derivate industry - by the definition of
what they do, and in order to maintain their competitive advantage, these
vendors will always be supporting existing & legacy formats.  The reality is
by adding a new standard you require these vendors to do more work, not
less, as they have to support both until the existing logging formats are
truly EOL'ed.

Considering that the new logging standard is still in-process, and the
issues mentioned above, I just don't see adoption for this happening any
time soon.  In fact, I speculate that you are are more likely to see IPV6
widely deployed before a new log standard such as CEE.

Having said that, you have to start somewhere.  So I welcome the effort, but
am also a realist. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.loganalysis.org/pipermail/loganalysis/attachments/20070421/cc649db9/attachment-0001.html