Traditional software has a reassuring property: it either works or it doesn't. A server crashes, an API returns a 500 error, a query times out. The failure is visible, measurable, and usually immediate. Your monitoring dashboard turns red and someone gets paged. This is not how AI systems fail.
An LLM-powered application can degrade in ways that leave every infrastructure metric untouched. Response times are normal. Error rates are zero. The API is returning 200s. And the model is quietly producing outputs that are less accurate, less helpful, or subtly wrong in ways that accumulate into a real problem over time. A green dashboard is not a guarantee that your AI is working. It is only a guarantee that your servers are running.
This is why LLM Observability is a distinct practice from general Observability. The infrastructure layer still matters — you need API Monitoring to catch latency spikes and error rates — but it is not sufficient. You also need visibility into the outputs themselves: what the model is actually saying, whether it is staying on topic, whether its answers are consistent with what users expect.
LLM Monitoring and Model Monitoring sit on top of general Monitoring infrastructure and add the AI-specific signals. LLM Logging and Audit Logging capture the full record of what was sent to the model and what it returned. LLM Tracing and Model Tracing let you follow a single request through the entire system, from the user's input through retrieval and context assembly to the model's final response.
Together, these tools give teams the visibility they need to catch problems that traditional monitoring would never surface. The articles in this section cover each layer, from the infrastructure signals that tell you the system is running to the output signals that tell you it is running well.
