As you may know, there are several syslog RFCs. RFC 6587 covers, amongst other things, something called octet-framing. Previous versions of Log Insight only supported non-transparent-framing. Log Insight 4.0 adds support for octet-framing. Read on to learn more!
One question I get asked from time to time is why Log Insight has a syslog drop system notification, but it does not have an API drop system notification. In this post, I will explain the difference. Read on to learn more!
The event forwarder feature of Log Insight is powerful for a variety of reasons (several covered in this post). When it comes to event forwarding over the syslog protocol (i.e. to a third-party destination), some people have commented on the prefix Log Insight adds to forwarder events. It turns out this is true for event forwarding as well as for the Log Insight agent. In this post, I would like to discuss the prefix and why it exists. Read on to learn more!
Log Insight has featured Event Forwarding since Log Insight 2.5. In Log Insight 3.0 a couple small, but important changes were made. Read on to learn more!
As you may know, there is a NSX for vSphere content pack available for Log Insight. Of course in order for the content pack to work you need to configure NSX to point to Log Insight. This requires configuring three different locations in two different way so I figured I would put a quick post together. Read on to learn more!
In my last post, I talked about the differences between how events are displayed over the syslog protocol, which has a strict format structure, and the ingestion API, which sends events as-is. In this post, I would like to talk about the differences between using the syslog protocol versus the ingestion API when it comes to the Log Insight agent and the Log Insight forwarder.
As you know, Log Insight introduced an ingestion API with the 2.0 release. This ingestion API can be used by anyone, but is leveraged by default by the Log Insight agent available for Windows as of 2.0 and Linux as of 2.5. The ingestion API is powerful because it provides functionality beyond what the syslog RFC defines, but it is important to note that events received over each protocol may look different. Read on to learn more.
If you are upgrading or have upgraded to vSphere 6.0, you should be aware of a couple syslog gotchas. These will be especially important if you are running a central logging system like vRealize Log Insight. Read on to learn more.
Now that I have talked about the new forwarding feature in Log Insight 2.5, I would like to discuss why you should consider using it if you are not already.
I frequently get questions around how to forward only certain log files from ESXi or how to collect a log file that is missing. I get the question so frequently that it warrants a quick post. The title of this post says it all – it’s all or nothing. If you configure remote syslog on ESXi then you will get all configured logs files from ESXi. There is no supported way today to customize what logs files are stored locally versus sent remotely. The only customization that you can make is what severity logs messages are forwarded to the remote syslog destinations by changing log verbosity, however this is not recommended (read here for more information).