# Observability

An observable system is one we can understand by asking questions from the outside, without having to ship new code everytime. Is easy to answer a question by shipping some bit of new code. Ideally our instrumentation should be able to answer any question.

There is always a sharing gap, there are people in our team that know how some piece of code works, how some components relate to each other and how they interact, debugging something you are not familiar with can be really hard, and becomes harder day by day given the constant grow of complexity in our system. Having observability helps us define our problems.

It helps us see what is important, how much a resource is used and how long it operations are taking, by having this knowledge we can better prioritize tech debt, bugs, performance issues etc.

We all like the idea of shipping faster and with confidence, but how can we actually do this?. The only way to confidently say that something is working is by testing it in production. We could test our code manually, do some exploratory test on the dev environment, we could even have robust integrations tests, but in the end all this has a limit and it stops at the border of our laptop, and our ci. What we could do instead is whenever we deploy something we could ship it with instrumentation and make it observable. Go to the graphs and say, did whay i expected to happened actually happened? is there anything weird around it? not doing this means start having silent problems, maybe there is something weird that is not big enough to trigger an alert or trigger user errors, but these silent problems always arise and eventually they are going to come up.

We should get into the habit of looking at our system when it is normal, if we dont know what an abnormal actually looks like.

is not only about needing our observability tools when things are wrong, it is important to also understand how things behave in a normal fashion

## Metrics

## Implementation