Ms. Aydin opens the order list in the Windows program. The call goes to the web API, the API asks the database, and somewhere on that path it takes eight seconds. The Windows program shows a message, the API has a log entry, the database has nothing. Three places, three timestamps, and nobody knows whether they belong to the same operation.
The basics of observation, that is, Application Insights, queries and alerts in Azure, are taught by K3, module 3.4. This lesson shows what is added in dual running: the same trace in two programs, metrics that make old and new comparable, alerts across both worlds, and a budget that says how many errors the project can afford.
What you need to know
Observation in dual running answers five questions, and they do not all need the same signal:
| Question | Signal | Where in the Order Book |
|---|---|---|
| Is it running? How often does the new way fail compared with the old one? | metric (counter with result and way) | the selector (lesson M6.3) |
| Is it not slower? | metric (duration per way) | the selector |
| Where does a single operation get stuck? | trace (calls from program to program) | Windows program, API, database calls |
| Are the results the same? | comparison of data or results | reconciliation (lesson M6.2), comparison tests (lesson M4.3) |
| Who still uses the old way? | metric with way old and sign-ins at the database |
lesson M6.5 |
The row “Are the results the same?” is not telemetry but a check, and it is the reason why observation never consists of dashboards alone.