{"id":401,"date":"2010-09-04T11:24:57","date_gmt":"2010-09-04T19:24:57","guid":{"rendered":"http:\/\/raffy.ch\/blog\/?p=401"},"modified":"2010-09-04T11:24:57","modified_gmt":"2010-09-04T19:24:57","slug":"logging-formats-and-standards","status":"publish","type":"post","link":"https:\/\/raffy.ch\/blog\/2010\/09\/04\/logging-formats-and-standards\/","title":{"rendered":"Logging Formats and Standards"},"content":{"rendered":"

\"cee I have discussed the topic of logging standards multiple times<\/a> on this blog. Some recent developments in the logging space urged me to give an update and provide my opinion:<\/p>\n

Yet another vendor just released a “standard” log format (note the quotes around standard). It’s called UCF, the Universal Collection Framework\u2122 (UCF). This is how the vendor describes it:<\/p>\n

UCF is the first WAN-aware, store-and-forward, encrypted, compressed IT data transport. It allows customers to gather IT data, increase resilience, reduce network chatter and encrypt from almost any device, anywhere, quickly and easily. UCF leverages a new transport and store protocol that LogLogic intends to open source in the near future. <\/p><\/blockquote>\n

Sounds a whole lot like syslog. (syslog-ng<\/a> and rsyslog<\/a> seem to support exactly this!) Okay, let’s just look at this description: WAN aware? What the heck is that supposed to mean? You mean it won’t work well on a LAN? Does that mean it knows the Internets? That’s just a strange description to start with. Oh, and it’s the first property mentioned! The rest of the description sounds like a transport protocol. Interesting. Why not stick with syslog that is well known, has proven to work, and has integration libraries built already. I never understood why vendors implemented their own transport protocols. They are hard (very hard) to implement and even harder for producers and consumers to adopt to. Oh well.<\/p>\n

When people talk about UCF, they keep bringing up ArcSight’s CEF. Well, I am greatly responsible for that specification. But guess what? It’s not a transport protocol! It’s a syntax definition. It tells a log producer how to format their log file. Not how to transport it. Because, there is always syslog that a lot of machines have installed already and it’s easy to use. (And in newer versions you get encryption, caching, etc.).<\/p>\n

Now, my last point about standards. Why do vendors keep trying to come up with standards by themselves? It just doesn’t make any sense. How is going to adapt it? At ArcSight, about 4 years ago, we came up with CEF because CEE<\/a> didn’t move fast enough and we wanted something that our partners could easily use. An analyst wrote that ArcSight is planning to take CEF to the IETF. I hope they are not going to do that. I don’t have any control over that anymore, but that would be stupid. We rather push CEE through IETF. If you have a chance, compare the CEE syntax proposal with CEF. Notice something? Yes. It’s very similar. Again, I might have had something to do with that. Anyways. Vendors should not define logging standards!<\/p>\n

On a good note: CEE is moving forward and just released the architecture overview<\/a> for public commentary. Check them out!<\/p>\n","protected":false},"excerpt":{"rendered":"

I have discussed the topic of logging standards multiple times on this blog. Some recent developments in the logging space urged me to give an update and provide my opinion: Yet another vendor just released a “standard” log format (note the quotes around standard). It’s called UCF, the Universal Collection Framework\u2122 (UCF). This is how […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-401","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t