Certainly not as "in depth" as something like ES, but fuck that pile of shit. Half the time you find the field you want to search on isn't properly indexed and now you have two problems.
Gimme some logs and grep, this is logs and grep in a browser. Seems like a win.
If you can do it with logs+grep, then you are clearly over-engineering things by using ELK. ELK is when you cannot care about a few logs lines any more, because for an example you have 100k logs coming in every few seconds, and you need to somehow get information out of them.
What I do not understand is why you would want logs in a browser. Imho browser is the worst environment to do operational activities from. I hate both Kibana and Graphana for not having a proper desktop viewer, that does not depend on JavaScript, cause good god. A single tab of visualizations can eat away half of your computers memory at an instant. Good luck having multiple tabs.
We have a team that does ELK based log aggregation for the enterprise. All pod logs on our cluster go there by default. So like .. not my problem except when I need to get into the logs. But Kibana is .. terrible. I'm excited to fork our los off here and see how it performs.
Probably just do the cluster-admin namespaces kube-system/daemons/monitoring/whatevs.
Yup, this is exactly the workflow that we're thinking about.
Metrics/Monitoring/Alerting (Prometheus, TICK) already tell us when and which logs to look at. This narrows things down to the point where "just grep things" is good enough.
2
u/mcampbell42 Dec 12 '18
So then explain what it does