Re: Re: Syslog and Windows

On 6/22/07, Tina Bird <[email protected]> wrote:
>
>
> It is, as far as I've seen, clear that syslog *server* implementations for
> UNIX variants offer far more features and robustness than the syslog
> servers
> for Windows, although I must confess to little experience with Windows
> syslog servers. Mostly I'd worry about their ability to perform under
> load,
> especially if they're moving syslog data into the pre-Vista Event Log
> service.


Logs are not pushed into the existing .EVT format, if that's what you mean.
They're pushed to a flat file: RAW just like on xNix, Webtrends format,
custom, or Adiscon's proprietary format for use with some of their other
products.

Believe it or not, because of the rules-based engine, Adiscon's products
allows at least as much functionality as any xNix variant I've seen. You can
log an event to multiple destinations (and multiple local files), route to
destination them based on IP, facility, severity, priority, keyword content,
etc.. There really is a very full feature set available.

AVAILABILITY of Windows should be the primary concern when logging to a
Windows box. I live in the Windows security space (I'll never go hungry),
and availability is nowhere near what can be done in the xNix space. This is
why DNS is critical to using Windows for a log destination - for planned
outages you can change the DNS entry to point to a backup server.

Windows CLIENT agents (e.g. the ones that convert from .EVT to syslog
format) are also a problem here since the only one that allows for multiple
syslog destinations, is the old NTSYSLOG service which is no longer being
maintained. You can bring up multiple Lasso or Monitorware servers to do
remote eventlog collection (ensuring at least 2 collections sources), but
remote collection is much more expensive from a processing and network
standpoint than a locally installed agent. Unlike xNix, you can't have
multiple instances of the same service running on windows boxes, and having
2 eventlog to syslog agents is unstable (yes, I've tested it - though by
accident since I forgot to uninstall one before testing another).

NUDGE FOR ANTON CHUVAKIN: If Lasso allowed multiple destinations, that would
be great.


> Of course, it's hard to centralize cos it doesn't support syslog; it's
> more
> work for developers precisely because it's more structured; and it takes a
> bit more effort to get it out of the GUI and into a form that can be used
> by
> grep :-)


I'd add to this that most of the eventlog to syslog agents have a periodic
problem since the eventlog field data is store separatly from the message in
Windows. When you look at the eventlog and see "Logon Successful: taylorgo",
the "Logon Successful:" part is stored in a language file (to allow the
eventlogs to be read in any language) while the "taylorgo" (along with
eventid, date/time, etc) are in the .EVT file. The problem happens when the
eventlog language file is locked by another process, the syslog agents only
collect the field-level data.

The result ends up being that you'll see the same event id represented two
different ways in syslog: one with the full-text formatting, and another
with just the field level data. Makes parsing infinitely more complex (you
really have to expect to parse each event twice). Lasso (and I think
MonitorWare) get around this by keeping a locally cached copy of the
language files and refreshing them every X minutes (configurable). It's
really the only way to do it reliably.

Vista/Longhorn are supposed to be better because they store everything in
XML format, so at least shouldn't be anymore messing around with the
language files.

_______________________________________________
LogAnalysis mailing list
[email protected]
http://www.loganalysis.org/mailman/listinfo/loganalysis