Observability vs. monitoring debate: An irreverent view
1–10 of 19 posts
Re: Observability vs. monitoring debate: An irreverent view
#2I see OpenTelemetry as an application of the same idea pushed by Google via the k8s revolution.
Create a great vendor-agnostic open source tech. Get everyone riled up about the dangers of vendor-locking solutions. Use the new tech to carve yourself a piece of the market from the current incumbent.
It is pretty great and all, but sometimes it is easier to build your app with a simple vendor-locked tech than a super generic agnostic technology.
Re: Observability vs. monitoring debate: An irreverent view
#3Both concepts are related but separate. I'd argue that monitoring is the act of alerting or taking action when some metric is out of bounds with normal values. Those values are based on absolute thresholds, or some changing thresholds based on historical values. Observability is the ability to see what's happening across and between multiple systems so that any issues raised by monitoring can be diagnosed quickly. "I know theres a problem vs I know which part of the system its happening in"
Re: Observability vs. monitoring debate: An irreverent view
#4I see it as a tiered approach - Detailed Process Logs saved to a db, Audits, Regular logs streamed to your favorite log dump, Monitoring, Health Checks, Metrics, and Usage Statistics are all part of Observability.
If it is a critical process, use detailed process logs.
If it is an extremely critical process add Auditing.
Re: Observability vs. monitoring debate: An irreverent view
#5I see OpenTelemetry as an application of the same idea pushed by Google via the k8s revolution. Create a great vendor-agnostic open source tech. Get everyone riled up about the dangers of vendor-locking solutions. Use the new tech to carve yourself a piece of the market from the current incumbent. It is pretty great and all, but sometimes it is easier to build your app with a simple vendor-locked tech than a super ge…
I agree with this.
It’s kinda important to understand who all this is meant for. If you’re a lean startup just use the best/cheapest/quickest tool regardless of vendor lock in. It’s when you get to a certain scale that vendor agnosticism becomes a real concern, but by then you probably have enough resources to hire folks that will rebuild your stack.
Re: Observability vs. monitoring debate: An irreverent view
#6Both concepts are related but separate. I'd argue that monitoring is the act of alerting or taking action when some metric is out of bounds with normal values. Those values are based on absolute thresholds, or some changing thresholds based on historical values. Observability is the ability to see what's happening across and between multiple systems so that any issues raised by monitoring can be diagnosed quickly. "I…
Not to be rude,
Monitoring is observing problems and then responding to the alarm in realtime.
You cannot compare the two. Yet we do in certain circumstances and that is a loss in understanding, which I am sad about.
Re: Observability vs. monitoring debate: An irreverent view
#7There’s certainly elements of hype to the term since it’s new and a lot of startups and projects are trying to get the biggest mindshare.
Monitoring to me is exclusively about metrics and alerts. Metrics are really useful but they often don’t give you the whole context, and might sometimes be misleading. Eg you see a spike in cpu usage for a service; you probably just autoscaler and call it a day, and that’s the end of it. Having metrics is SO much better than not having metrics though, it delivered insights that were just not possible before.
Observability to me is the next iteration of this process of understanding system behavior. Metrics are limiting, so maybe you look at logs. Well, they suffer from some of the same issues, so you try profiling, you try tracing. Ultimately the goal is to explore tools that allow developers to quickly get a truthful understanding of how their systems really work, and use that knowledge to improve their systems.
Re: Observability vs. monitoring debate: An irreverent view
#8"Observability" existed 20 years ago and it consisted in application metrics, OS metrics, log analysis and correlation, SIEM.
It was called monitoring.
Re: Observability vs. monitoring debate: An irreverent view
#9"Observability" existed 20 years ago and it consisted in application metrics, OS metrics, log analysis and correlation, SIEM. It was called monitoring.
which i think is the point of the article as well. :)
Re: Observability vs. monitoring debate: An irreverent view
#10I see it as a tiered approach - Detailed Process Logs saved to a db, Audits, Regular logs streamed to your favorite log dump, Monitoring, Health Checks, Metrics, and Usage Statistics are all part of Observability. If it is a critical process, use detailed process logs. If it is an extremely critical process add Auditing.
Yep, pretty much. There is plenty different types of telemetry one can use, and which ones are important for one application depends both on the nature of that application, and who operates them.