Great question! Here's my mental model of observability.
Observability includes, but isn't limited to, logging errors, counting metrics, and data visualization. It encapsulates anything that lets you see how your app is performing around engineering goals. Engineering goals could include uptime, error rate, read/write times, API call times etc.
What's so awesome about observability is the impact it has on an engineering org. You can contribute a small but well thought out metric, and it could help uncover some crazy bug that has been plaguing devs for years!! But before I get too excited, I want to make the distinction between observability for a software dev versus a devops engineer. Because I think that's an important differentiation that would help teach someone new to the space.
Both of these roles have overlaps but they have some key differences. Devops are primarily concerned about infrastructure; will my database be able to handle x number of requests? While software devs are concerned about the application; how long does an API request take for this route?
Observability gives you the pieces of information needed to solve these questions. And by combining multiple metrics, logs, or errors you get a complete understanding of an issue. It can also help you catch issues before your users find them!
I've been rambling - so I'll end on one last thought. Starting with nothing when it comes to observability is rough. That's why tools like New Relic are really great solutions! They give you a lot of metrics out of the box.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great question! Here's my mental model of observability.
Observability includes, but isn't limited to, logging errors, counting metrics, and data visualization. It encapsulates anything that lets you see how your app is performing around engineering goals. Engineering goals could include uptime, error rate, read/write times, API call times etc.
What's so awesome about observability is the impact it has on an engineering org. You can contribute a small but well thought out metric, and it could help uncover some crazy bug that has been plaguing devs for years!! But before I get too excited, I want to make the distinction between observability for a software dev versus a devops engineer. Because I think that's an important differentiation that would help teach someone new to the space.
Both of these roles have overlaps but they have some key differences. Devops are primarily concerned about infrastructure; will my database be able to handle x number of requests? While software devs are concerned about the application; how long does an API request take for this route?
Observability gives you the pieces of information needed to solve these questions. And by combining multiple metrics, logs, or errors you get a complete understanding of an issue. It can also help you catch issues before your users find them!
I've been rambling - so I'll end on one last thought. Starting with nothing when it comes to observability is rough. That's why tools like New Relic are really great solutions! They give you a lot of metrics out of the box.