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!
On the statistics page of Log Insight, you may have noticed a column that speaks about API dropped (in previous versions was called API rejected):
What does this mean? It means that Log Insight could not process the API request and reported back to the originator a rejection. It is important to note that an API drop is not the same as a syslog drop. In the case of syslog, if an event cannot be processed, then Log Insight is forced to drop the event. In the case of a syslog drop, the originator of the event is not notified of the drop, and as a result, the event is lost. With API drops, since the originator of the event is notified, the originator can try to resend the API request again.
Though the originator is notified of the API drop, it is up to the originator what to do about the drop. If the originator is configured to do so, it may attempt to retransmit the request (e.g., Log Insight forwarder or Log Insight agent). Like the destination it is trying to send to, the originator may be overloaded to the point where it cannot retransmit the request. When this happens, the originator, like the destination, is forced to drop the event. This means it is critical to report syslog drops, but not critical to report API drops (unless on a configured event forwarder — more on this in a future post). This also means that you need to enable notifications on all devices that could drop requests. In the case of Log Insight, this means every Log Insight instance, including forwarding clusters, must be configured to send system notifications.
© 2016 – 2021, Steve Flanders. All rights reserved.
