What is observability, in plain words

Observability is a property of a system that lets you understand what is happening inside it from its external signals — without writing new code for every new question. It rests on three data types: metrics, logs and traces.

How it differs from monitoring

Classic monitoring answers pre-defined questions: "is CPU above 90%?", "is the host alive?". Observability helps answer questions you did not ask in advance: "why did latency rise for these specific users in this region after the release?".

The three pillars

• Metrics — numeric time series (error rate, p99 latency, memory usage). Cheap to store, great for alerts and trends.
• Logs — discrete events with context. They answer "what exactly happened at this second".
• Traces — the path of a single request through services. They show where the time actually went.

Why it matters

Without observability an incident turns into guesswork: you see that "something is slow" but not where. Linking metric → log → trace by shared labels and time window shortens the path from symptom to cause.

Where it lives in Unimoni

The agent collects metrics over mTLS; logs and traces (via OTLP) land next to them with shared labels — you switch between them in one cabinet, without a separate system per signal.