We’re excited to announce the launch of the LogDNA Configuration API, expanding on our existing API to allow users to manage their Views and Alerts programmatically. Use the new Configuration API to increase automation on LogDNA’s logging platform.
Keeping track of what’s going on in Kubernetes isn’t easy. It’s an environment where things move quickly, individual containers come and go, and a large number of independent processes involving separate users may all be happening at the same time. Container-based systems are by their nature optimized for rapid, efficient response to a heavy load of requests from multiple users in a highly abstracted environment and not for high-visibility, real-time monitoring.
Kubernetes is a container orchestration tool, but its functionality extends far beyond just orchestrating containers in a narrow sense. It offers a range of additional features that—to a limited extent—address needs such as load balancing, access control, security policy enforcement, and even logging and monitoring. Indeed, Kubernetes’s broad functionality has led some folks to call it an “operating system” in its own right.
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.
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.
