Ever wondered why after all this years Windows still doesn't support syslog? This is why; read a very comprehensive answer by Eric Fitzgerald, who "owns" Windows logging. There is also a very lively discussion that ensued, which includes things like "my blood boils and a halo of pink steam forms around my head, throbbing the the gnashing of my teeth and the kodo drum-like thudding of my overworked heart. " :-) /guess who said this/
Overall, it pains me to say this, but Eric's answer actually makes sense. Still, having a little tiny-teeny option to send a filtered subset of Windows events tout via UDP 514 in an "official" manner would be nice...
7 comments:
So the reason why Microsoft doesn't provide syslog support is because its not in their best interest? That's the exciting real reason? I could of told you that.
Well, I read it differently: "not seen as needed" as opposed to "seen as NOT needed/harmful to MS"
I kinbda doubt this is an anti-Unix/anti-Linux action ...
I don't see names of any Microsoft employees concerning logging in any of the IETF RFC's, drafts, or working groups.
Because of this, it appears that they would like to replace network log consolidation with their own proprietary formats in order to corner a market - or that they simply don't care about logging at all enough to put any research into it.
Sounds anti-competitive and business-creepy to me, but I still do like Microsoft these days. Even though I'm using Linux to post this.
Also - I don't see anything wrong with Syslog as long as it's wrapped in SSL and the listeners are only listening to localhost or similar I have often setup environments with Syslog (especially environments where wrapping syslog in SSL or IPSec was impossible or infeasible) where the traffic went to a router null interface, and was sniffed in transit and dissected to get the actual messages - because that was the safest way for the packets to travel over the network without being subverted along the way. It would be nice if syslog supported similar features out of the box, but it's just one of those "ancient Unix things that still happens to be around".
In special regards to Cisco devices, I personally choose to leave syslog in the buffer log only, and to send the messages syslog would normally send through SNMP INFOM's (v2 TRAP's) (over IPSec or SNMPv3 if I can). It's not only because of security, but also because of consolidation / aggregation of data both over the network and to have to deal with on the NMS side.
>I don't see names of any Microsoft
>employees concerning logging in any
>of the IETF RFC's, drafts, or
>working groups.
Well, Eric was/is is involved in some ...
>Also - I don't see anything wrong with Syslog
GoooooooooOod, No! There is EVERYTHING wrong with it even if it is TCP and SSL. Specifically, the messages are basically bad human-readable text, not structured in any way (beyond system+date/time); it is a dog to analyze...
Syslog vs SNMP: I dunno, SNMP might be a bit better stuctured, but it has a bit more overhead...
"the messages are basically bad human-readable text, not structured in any way (beyond system+date/time); it is a dog to analyze..."
Network Intelligence seem to have it pinned down OK...
Well, and so are most other related vendors, LogLogic included. But overall, it is an extra chore imposed on vendors ...
>have it pinned down OK...
Also, there is nobody in the world who have SEEN every possible syslog message; not even every possible syslog message format. I know a person who sits on all syslog messages he collected from 1986 (or so) - he counted over 50,000 types and he is probably not done yet...
So, while many folks have it somewhat under control; nobody in my estimation have it "pinned down."
Post a Comment