Operations | Monitoring | ITSM | DevOps | Cloud

Log files are infamous for being “noisy”. Without the right management solution, trying to find a specific piece of information or using them to reproduce a critical error is a complex undertaking. If you’re working with CI/CD, how do you attribute new errors to a particular release? How do you investigate those errors and make sure that your customers aren’t being impacted? Faster releases mean shorter development and testing cycles before new code reaches production.

Many businesses use cloud services on AWS and also run workloads on Kubernetes and Knative. Today, it’s difficult to integrate events from AWS to workloads on a Rancher cluster, preventing you from taking full advantage of your data and applications. To trigger a workload on Rancher when events happen in your AWS service, you need an event source that can consume AWS events and send them to your Rancher workload.

In an ideal world where we reached 100% test coverage, our error handling was flawless, and all our failures were handled gracefully — in a world where all our systems reached perfection, we wouldn’t be having this discussion. Yet, here we are. Earth, 2020. By the time you read this sentence, somebody’s server failed in production. A moment of silence for the processes we lost.

As a Customer Advocate, I talk to a lot of prospective Honeycomb users who want to understand how observability fits into their existing Site Reliability Engineering (SRE) practice. While I have enough of a familiarity with the discipline to get myself into trouble, I wanted to learn more about what SREs do in their day-to-day work so that I’d be better able to help them determine if Honeycomb is a good fit for their needs.