The pursuit of Digital Transformation and DevOps practices has led to several benefits such as increased deployment rates and better collaboration across teams. However, it has also led to endless abstraction, an increase in responsibilities, and many new tools (Kubernetes, hybrid-clouds and all their services, etc.). This increase in complexity has turned observability into an essential component of all ecosystems. Yet when we bring up O11y, we seem to focus on the operational side of the house; looking at uptime and outages. Ensuring our systems stay online is crucial, but what other things should we be talking about to ensure the applications and services that run on these systems behave as they should?
LogDNA has extensively focused on what we think is the most important of The Three Pillars of Observability—logging! As a modern logging solution, our focus is on allowing ops to accelerate troubleshooting time and developers to increase their efficiency, all the while ensuring the ability to control log intake quickly. Our platform serves as a definitive source of truth by collecting data from ALL sources while providing an easily accessible, robust UI that offers benefits that include but aren’t limited to:
Still, we often encounter customers and prospects who use the terminal as a way of getting access to their logs. Does that seem old-school? Not at all! If you have a log-aggregation tool in place, does it not make more sense to use it rather than a Command Line Interface (CLI)? Maybe, but knowing which tool to use and when is an art form. The question then becomes, with all the advantages a centralized logging solution brings, why would someone choose to remain within their terminal? It ultimately comes down to context-switching, also known as the “silent killer of productivity.” Various studies and books dive into the time-management aspect, from “Making Work Visible” to “Value Stream Mapping.” Rather than force you to read all the studies in their entirety, here’s the TLDR, which I particularly relate to the following two quotes:
These findings are now even more evident in a post-COVID, remote-driven world. With all the distractions out there (e.g., kids, Slack, the overall existence of the internet), a simple switch from my IDE to a completely different platform can, and likely will, negatively impact my focus, train of thought, and overall performance.
Let’s run through a developer-focused exercise and see why utilizing the CLI makes sense.
While the above seems straightforward, we don’t do these steps just once. We do it multiple times and run it through different debugging variations (e.g., status checks, simulation tests, operational tests with other internal/external services, etc.). Suddenly, our desire to stay within our IDE and not context-switch backfires and begins impacting our performance.
Manually running commands over and over is time-consuming and error-prone. It works okay for isolated pods, but we often don’t have that luxury because most microservices interact with other services across various infrastructures. In the long run, debugging becomes a burdensome project in itself, and we begin encountering the following pain points:
While this situation can leave one feeling stuck between a rock and a hard place, another choice brings the best of both worlds, the benefits of a logging platform without the need to context-switch. The LogDNA CLI is an extension of the LogDNA platform, which allows us to access any data collected across all our sources from the comfort of our desired IDE. Let’s address how the LogDNA CLI solves our previous pain points:
As explained, LogDNA and its CLI extension quickly enhance your debugging practices by providing immediate access in an easily readable format to ALL the logs that matter to YOU.
While utilizing a web UI is commonplace for most software products, developers have to battle between using a built-in terminal constantly, context-switching into an unfamiliar app, or even having to wait for another team to email them a zip archive of logs. Through our CLI, LogDNA can streamline development workflows and bring the power of LogDNA’s search query capability directly into their IDEs. Ultimately, developers want to spend their time writing code and focusing on feature releases. That’s where LogDNA fits in.