We examined best practices for logging in a prior series. However, how can you apply those best practices in real life? Let’s dive into how you could use LogDNA in an opinionated manner to utilize best practices to bring value to your DevOps-focused projects. How can we ensure we follow best practices and keep our logs secure and compliant as noted in the previous series? Let’s pretend we’re setting up centralized log management with LogDNA for a new team and project.

It’s one thing to build a Kubernetes log management strategy that only needs to support Kubernetes. But most organizations don’t have that luxury. They have log management practices already in place for other types of platforms or infrastructure, and they need to extend them to support Kubernetes. How can you do that in an efficient way? Keep reading for tips on integrating Kubernetes logging data into your existing log management workflow without rebuilding from the ground up.

With more engineering teams adopting Kubernetes as their container orchestration platform, new challenges emerge in giving your entire team visibility into Kubernetes for monitoring, debugging, and deployment. We’ve heard consistent feedback from developers and infrastructure teams about the observability gaps that exist between underlying Kubernetes infrastructure and deployed services.

Isn’t all logging pretty much the same? Logs appear by default, like magic, without any further intervention by teams other than simply starting a system… right?

Isn’t all logging pretty much the same? Logs appear by default, like magic, without any further intervention by teams other than simply starting a system… right? While logging may seem like simple magic, there’s a lot to consider. Logs don’t just automatically appear for all levels of your architecture, and any logs that do automatically appear probably don’t have all of the details that you need to successfully understand what a system is doing.