I want to clarify some confusion here. Use of TCP will only help to prevent the loss of a packet once it is sent over the network. It does not prevent any loss of data the agent hasn't sent. That's a separate issue.
UDP is used because the agent sends data at random times to the server, and the cost of setting up a TCP link for each event becomes too high. Same reason syslog uses UDP. However, to gain that performance, we lose the ability to confirm delivery of the packet (at least at the network layer), so it would be possible that events could be lost in- transit to the server. What Stefano is asking about, in my opinion, is what does the agent do when it wants to send an event, but knows it cannot because the server's offline? In this case, the agent will not send a packet because it knows it will not be received, so the UDP/TCP choice is irrelevant. So the question is, how does the agent handle this situation? Daniel's explanation is a little unclear (Sorry dcid). I understand the agent doesn't hold those events in memory, and I understand an agent reboot would lose those events. But I'm unclear if the agent actually catches up when the server comes back online. It's also unclear with things such as Windows events, where the agent is not looking at a file, but instead uses an API. Does it catch up with these as well?
