j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
2015-06-29 3:09 GMT+02:00 Nick Coghlan email@example.com:
On 29 Jun 2015 1:50 am, "Ludovic Gasc" firstname.lastname@example.org wrote:
In fact, the issue shouldn't be our brains, but it was clearly a time consuming task, and we have too much directly paid-work to take care.
Don't be wrong: I don't say that ELK doesn't work, only it's time consuming with a high level of logs. I'm pretty sure that a lot of people are happy with ELK, it's cool for them ;-)
It's like Oracle and PostgreSQL databases: Where with Oracle you need a full-time DBA, with PostgreSQL: apt-get install postgresql With this last sentence, I'm totally caricatural, but only to show where I see an issue that should be fixed, at least for us. (FYI, in a previous professional life, I've maintained Oracle, MySQL and PostgreSQL servers for several clients, I know a little bit the subject).
This discrepancy in manageability between services like PostgreSQL & more complex setups like the ELK stack is why Red Hat started working on Nulecule as part of Project Atomic: http://rhelblog.redhat.com/2015/06/23/announcing-yum-rpm-for-containerized-a...
Thanks for the link, I didn't know, I'll keep an eye on that.
There's still some work to be done making sure the related tools support Debian and derivatives properly, but "the ELK stack is too hard to install & maintain" is a distro level software management problem to be solved, rather than something to try to work around at the language level.
As you can imagine, I want to finish to dig around journald before to change the strategy. Thanks for your time and your remarks.
Have a nice day.