ELK is expensive, in terms of hardware and time to configure/manage. But it does scale to large volumes in a way that your current ad hoc 1970s logging will no

ELK is expensive, in terms of hardware and time to configure/manage. But it does scale to large volumes in a way that your current ad hoc 1970s logging will not. I had a good experience with a local decentralized logging system, essentially daemontools-style service logs, that then fed in to ELK. ELK provided the bulk storage and analysis; and the local daemontools logs provided the immediate on-machine per-individual-service recent log access, and decoupled logging from the network connection to logstash. * http://jdebp.uk./Softwares/nosh/guide/commands/export-to-rsyslog.xml http://jdebp.uk./Softwares/nosh/guide/commands/export-to-rsy... * http://jdebp.uk./Softwares/nosh/guide/commands/follow-log-directories.xml http://jdebp.uk./Softwares/nosh/guide/commands/follow-log-di... One of the advantages of this approach is that one can do the daemontools-style logging first, very simply, without centralization, and with comparatively minor expense; and then tack on ELK later, when volume or number of services gets large enough, without having to alter the daemontools-style logging when doing so. Of course, it can be something else other than ELK, fed from the daemontools-style logs. One thing that I recommend against, ELK or no, is laboriously re-treading the path of the late 1970s and the 1980s, starting from that "logging straight to a file". Skip straight through to the 1990s. (-: * http://jdebp.uk./FGA/do-not-use-logrotate.html http://jdebp.uk./FGA/do-not-use-logrotate.html