kubectl-sudo VS loki

With the kubectl-sudo plugin, kubectl commands that require more extensive rights can be executed explicitly as a member of the admin group. This reduces the chance of accidentally modifying or deleting resources on the cluster, for example when running scripts or being in the wrong namespace.

Bootkube - bootkube - Launch a self-hosted Kubernetes cluster kubectx + kubens - Switch faster between clusters and namespaces in kubectl kube-shell - Kubernetes shell: An integrated shell for working with the Kubernetes kuttle: kubectl wrapper for sshuttle without SSH - Kubernetes wrapper for sshuttle kubectl sudo - Run kubernetes commands with the security privileges of another user K9s - Kubernetes CLI To Manage Your Clusters In Style! Ktunnel - A cli that exposes your local resources to kubernetes KubeOperator - Run kubectl command in Web Browser. https://kubeoperator.io/ Vimkubectl - Manage any Kubernetes resource from Vim https://www.vim.org/scripts/script.ph KubeHelper - KubeHelper - simplifies many daily Kubernetes cluster tasks through a web interface.

It's like Prometheus, but for logs. Okay it's not really to do with the Norse or Greek gods, instead Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by the open source project Prometheus. Built by Grafana Labs, Loki is designed for ease of use. Instead of indexing the contents of the logs, Loki provides a set of labels for each log stream. The latest update includes query acceleration with Bloom filters, native OTel support, Helm charts, and more. Check out the changelog for all the major changes and deprecations.

I also needed to make a small patch to Promtail to make this work: https://github.com/grafana/loki/pull/10256

We don't pull logs, we forward logs to a centralized logging service.

Over the past few months, I've been spending a lot of time creating dashboards on Grafana using Loki for MyUnisoft (the company I work for).

For log systems you generally don't migrate data. Logs lose value over time. What you want to do is to go ahead and start ingesting data into the new system (OpenObserve in this case) and slowly, the data in the old system will become stale and then you can retire it. However if you need to export logs anyhow, there is no straightforward way in loki to do this. You could run a script to query loki and export it to a file. If found this thread with a sample script - https://github.com/grafana/loki/issues/409

That snap is woefully out of date. The upstream repo was recently updated to 2.8.2, but the snap stable channel has 2.4.1 from 18 months ago. https://github.com/grafana/loki/releases/tag/v2.8.2

Loki