Editors note: We recorded a webinar on this very topic. Scroll to the bottom of this post to view the webinar.
Developers are building and deploying to production with greater frequency. Elite organizations are deploying to production multiple times per day. All the while we continue to distribute our applications even wider with the adoption of micro-services, and global deployments. This consistent churn and increasing code complexity create the perfect storm that makes finding problems even harder.
How do you know the changes just committed actually deployed? How do you know the changes worked?
Today, the hardest thing about debugging systems is no longer understanding how the code runs but finding where in your system is the code with the problem. We have traditionally tried to solve this using monitoring platforms, that look at known dimensions for unknown state. This is called monitoring your known-unknowns. Debugging this way depends on your prior knowledge of the system, which may no longer have relevance with the current state because of new code.
Observability is how you explain unknown-unknowns. It’s about exploration and debugging instead of dashboards and pattern matching. Being able to ask a question of any dimension, with any cardinality, form a thesis, ask another question, confirm (or deny) that thesis, and continue asking more questions creating a core analysis loop.
Developers need to understand their application across any dimension, including unique ones. The observability platform needs to work with raw data, ensuring we aren’t aggregating away the details. This allows us to understand why our systems behave the way they do. Tracking down application issues, like requests originating from us-west-2, for new users, of tenant type enterprise, breaking on an autosave feature. These debugging paths are not pre-conceived. You will not find the answer on a dashboard created based on prior knowledge of a service to understand how new functionality behaves.
With a strong observability platform and CI/CD pipeline in place, we can combine the developer toolchain, and deploy with confidence. During the deployment phase, annotating your observability platform with markers and indicators allows users to understand the exact moment the change took place and can understand if our change actually worked as intended in real-time.
Honeycomb enables developers to gain observability into their applications. The data storage and query engine was built to work with raw events that have high cardinality dimensions and no pre-aggregation of the data. The platform is exploratory by nature allowing developers to create a thesis about their application’s behavior and ask iterative questions to validate that thesis honoring the core analysis loop. Combined with integration into the Codefresh pipeline, organizations can deploy to production with confidence multiple times a day.
Watch the webinar on the topic now:
