Most enterprises already have a reliable logging and monitoring system in place, so why should you worry about it in the context of Kubernetes? Well, traditional logging and monitoring tools are designed for stable infrastructure and application deployments. Cloud native environments, on the other hand, are highly dynamic. The IT world has changed and so must your toolkit.
A key challenge is that traditional systems rely on anchors like IP or machine addresses, but in a cloud native setting, these factors are continuously changing. Containers are spun up and down, and redeployed on different VMs. The same applies to VMs which are redeployed on different node pools and even in different segments. To keep track of all this, you need a new breed of logging and monitoring system, one that is cloud native.
You do have a few options which we’ll categorize into four groups:
- Managed log collection and monitoring services: There are a number of available tools on the market. Some focus purely on log collection, others on metrics collection, while others do both. Datadog is a good example of the latter and probably the most popular managed logging and monitoring tool for Kubernetes clusters.
- Custom built or pre-existing log collection and monitoring framework. Some companies may already have a cloud native compatible system in place. If that’s the case, you’ve got a winner.
- Cloud-hosted logging and monitoring: All major clouds offer their own solution. Google has Stackdriver, Azure has Azure Monitor, and AWS has CloudWatch.
- Self-managed logging and monitoring: Tools that are either built into, compatible with, or integrated with the tools you use to manage your containerized apps. Ideally based on open-source projects such as Prometheus and Elasticsearch.
While managed solutions are easier and faster to set up, reducing time to market, you are also giving a third-party access to your logs. If you’re dealing with sensitive data, this is not an option. If data sensitivity isn’t an issue and you select a managed solution, you’ll need to integrate it with your app and infrastructure lifecycle practices. Meaning, as soon as a cluster is created, logging and monitoring must be automatically triggered. Otherwise, it’ll be a manual process and, as we all know, manual processes are error-prone.
In case you have a custom-built or pre-existing log collection and monitoring framework and are introducing a container orchestration platform into your technology stack, you need to consider and plan for the integration of these technologies. Make sure they really are compatible.
Cloud-hosted logging and monitoring are really convenient and cost-effective. If all your apps are running in a single cloud and you have no intention to change that in the near future, this is likely your best option. But beware, if you do decide to move to a different cloud, you won’t be able to migrate your system. A lot of work and effort will be involved.
We generally recommend the fourth category as it provides the flexibility to switch vendors or environments without having to reinvest into a new logging and monitoring solution. Some vendors, Kublr included, leverage popular open source projects such as Prometheus, Grafana, and Elasticsearch, which you can continue using even if you switch platforms. If provided by a vendor, it will already be pre-configured (e.g. the ability to scrape metrics, query, summarize, define custom dashboards and reports, etc.), speeding up your adoption of the cloud native stack.
The real value of open source tools such as Prometheus, Grafana, and Elasticsearch comes at a higher level, though. When building your own application alerts, dashboard, and charts, you can easily migrate them from one environment to another without losing all the work you’ve already done. There is a real opportunity here not to lock you in, and we believe you should take it.
#kubernetes #logging & monitoring system #self-managed logging and monitoring
