Since module 3.7, every change to the Kladde goes through the pipeline to dev and, after an approval, to prod. It then runs on computers
you can't look at. When a customer calls and says the booking “took forever” or “is just gone,” you need
answers to questions like: Which request was that? Where did the time go? Does it happen often, or was it once? You get these answers
only if the Kladde has told you beforehand what it is doing. That is called observability, and it is what the whole of module 3.4 is about.
In this lesson you learn the three ways an application tells its story, and the tools .NET has built in for them. At the end you see a booking of the Kladde in the Aspire dashboard as a trace from the request to the database. Everything runs on your computer; Azure comes only in the next lesson.
Three signals
An application can tell its story in three ways. They are called signals:
| Signal | What it is | Which question it answers | Example from the Kladde |
|---|---|---|---|
| Log | a single event with time, level and text | What exactly happened at this moment? | “Booking 1042 created,” “TED answered with 503” |
| Metric | a number that is counted or measured over time | How much, how often, how fast, overall? | bookings per minute, response time at the 95th percentile |
| Trace | the path of a request through all the parts involved, broken into sections with durations | Where did the time go, and where did it go wrong? | request → check for overlap → SQL command → mail into the outbox |
The three complement each other. A metric shows you that the response time has been rising since ten o'clock. A trace shows you in a single example where the time is lost, in a SQL command, say. The log lines of the same request tell you what happened along the way, such as which exception was thrown.
They also differ in cost. A metric is cheap: whether there were ten or ten thousand bookings, one number per minute is stored. Logs and traces cost storage per event, and in the cloud that is billed by volume. That is why traces are later sampled in Application Insights, meaning only partly kept, and metrics never are (lesson 3.4.2).
A few words you will meet everywhere from now on:
- A trace consists of spans. Each span is a piece of work with a name, a start and a duration. Spans hang off one another like branches: The request's span is the root, the SQL command's span hangs below it.
- All spans of a trace carry the same trace ID. Each span also has an ID of its own and knows the ID of its parent span.
- Attributes (also tags) are pairs of name and value on a span, a measurement or a log line, such as
http.response.status_code = 200.