A quick Google search reveals a whopping seven million blogs are published every day and 500 hours of video content are uploaded to YouTube — every single minute! That’s a lot of bits and bytes to sort through to find the good stuff!
Experts help spotlight A-list content by posting links on social media but we all know how much time that takes and how easy it is to scroll and miss something interesting or important. So, chances are some of the good stuff isn’t shared enough. We’re hoping to change that by showcasing what Cisco AppDynamics’ subject matter experts are consuming and since OpenTelemetry is a hot topic, it’s a perfect starting point.
We hope you enjoy the information and if it’s helpful, in open source fashion — please share!
OpenTelemetry A-list content recaps
Severin Neumann has 20 years of expertise in software engineering and currently leads Cisco AppDynamics’ contributions to the Open Source Project and Community.
OpenTelemetry Collector Deployment Patterns
OpenTelemetry collectors are essential for building modern observability pipelines. Yes, there can be more than one collector. Actually, there can be as many collectors you want and you might need. This video will introduce you to basic deployment models and deliver more complex examples to outline what’s possible with the OpenTelemetry collector.
Application Monitoring: Closing observability gaps with custom metrics
Metrics are often used as the prime example of “old school” monitoring. However, observability is about making good use of all the data sources you have: traces, logs and metrics. The key point is that you need to collect the right metrics that can help quantify the impact of an issue and provide evidence for the root cause of your issue. This article gives a great overview of valuable metrics that go beyond USE (utilization, saturation, errors) and RED (rate, errors, duration): network activity, resource usage, user, business transactions, database connections, data consumption, cache health and external services are different sources you can and should leverage.
Observability won’t replace monitoring (because it shouldn’t)
A deep dive into observability. It’s not a replacement for monitoring, it’s an extension for the production time it takes debugging complex dynamic and distributed microservices. And observability is not about MELT telemetry only. It’s about making sense of it by following calls and dependencies across the stack.
This article explains why collecting telemetry at scale is challenging but storing it for analysis is even harder. But making sense of the data is the only surefire way to align business goals with user needs to drive priorities and therein lies the challenge. Monitoring is defined as “detecting health problems” of the system which is a vital component to ensuring good health across the entire business. Technologists must understand if the business is healthy or not (monitoring) and then investigate where and why not (observability). Modern systems, made up of microservices and when not working correctly, the issues are challenging to pinpoint due to the nature of microservices turning off-and-on conditionally. Solid telemetry is what solves for that and delivers the information needed to enable understanding of the context in which a failure occurs.
SRE Google: Alerting on SLOs
All modern systems have errors and it will remain so. The core idea here is to ensure you have a manageable level of errors and the system warns teams only when you have too many of them, in an effort to avoid alert fatigue.
Notes on the Perfidy of dashboards
This article looks at dashboards and explains why they’re great for high level health assessment, but with a modern, highly distributed and dynamic microservice environment, they can’t go deeper for troubleshooting. Thus they are the start of the journey, not all of it.
Added bonus: Learn more from Severin on the AppDynamics blog:
AppDynamics for OpenTelemetry: Accelerating innovation across software development ecosystems.