3 ms·
That's why you aggregate logs in a central service. I was writing about sending logs to a central service and not about how your disks fill up with more logs. T
by buster 10y ago
That's why you aggregate logs in a central service. I was writing about sending logs to a central service and not about how your disks fill up with more logs. There is log rotation for that and usually your logs will have been sent way before any log rotates. If your log rotation deletes logs before you aggregated them or if you let your disks fill up with logs you have a much bigger problem you should fix, of course.
- AYBABTME 10y agoThat's again the same problem; if your centralized service isn't reachable for whatever reason, your nodes can buffer for a while (in memory or on disk) but eventually the problem always will boil down to 'drop' or 'block'. However you construct it, somewhere you need to make that call. They made the call to drop logs, it's totally fine.
- buster 10y agoIf your central infrastructure is down for many days you have other problems. Buffering logs on disks. Rotating and zipping files doesn't take much space. You can buffer a lot before you run into trouble. That's my point. You sound like buffering on the node is only possible for seconds whereas in real world scenarios log files are written for days, weeks or even months. Even in very large deployments and lots of logs. You would make the decision to don't use this advantage and throw logs away for no good reason.