MAIE6000C Chap.10 Observability and Debugging
Observability and Debugging
Signals exist so that you can reason
The more joined-up a system becomes, the harder a failure is to pin down unless something is reporting on it. The module's aim is a workable floor of observability, so that a team can think about how the system behaves, spot breakage sooner, and debug from evidence instead of assumption.
Its stated actions for the week are deliberately singular: close one gap in what you can observe, exercise one route through failure, and write down one operational weakness without dressing it up.
Three signals, three questions, three blind spots
Logs are the narrative: what happened, in what order, with what detail, and they are blind to anything nobody thought to log.
Health checks are the present tense: is this process alive and can it serve, and they are blind to anything intermittent. Metrics are the aggregate: how much, how often, how long, and they are blind to why any single case behaved as it did.
A team with excellent logs and no health check can explain last night's failure and cannot say whether the system is working now.
Structured events rather than sentences
The starter emits log lines as named fields: a timestamp, a level, the service, the logger name, an event name, and then event-specific detail such as method, path, status and duration. The event name is what makes a log searchable.
A line whose message is a sentence can only be found by remembering the sentence; a line whose message is a stable event name can be counted, filtered and compared across a week.
The starter's own sequence for one item is five such names, from the case being created to the job completing.
Two probes, two opposite lies
A liveness probe that queries the database reports unhealthy during a database outage, causing a restart for a fault the process did not have and cannot fix. A readiness probe that returns success regardless of dependencies reports ready while every request fails.
Both look correct in normal operation, and both are only exposed by deliberately breaking a dependency, which is precisely the failure path the module asks you to test.
Stopping a container and starting it again is two commands.
Localising rather than inspecting
A four-service system has more places to look than an afternoon allows, so the productive move is a sequence of questions each of which halves the search. Does a fresh submission work, which separates an outage from one stuck item.
Does a job row exist for the affected item, and what state is it in, which separates a transaction-boundary failure from a claim query problem from a dead worker.
None of that requires reading code, which is what the module means by debugging with evidence.
Observability is largely a schema decision
Whether a failure has a state, whether a job records the stage it reached, whether the proposal and the decision are separate facts: each is the difference between a question you can answer with one query and a question you cannot answer at all.
That is why the module asks you to identify likely failure points in your architecture rather than to instrument everything. The instrumentation worth adding is the instrumentation that closes a gap you can name.
What this chapter covers
- 01
Logs, health checks and metrics by the question each answers
- 02
The blind spot each signal kind structurally leaves
- 03
Structured fields and why the event name is the useful part
- 04
The five event names the starter emits for one item
- 05
Container prefixes as the cheapest localisation available
- 06
The two ways a health check can lie, and how to expose them
- 07
Narrowing a four-service failure with three questions
- 08
Why most of observability was decided when the schema was
One stuck item, four candidate faults, three questions
- 3Say what the two observations jointly rule out.
- 4Give the question to ask the store, and the branches it produces.
- 2Say what the reasoning did not require.
Key terms
- Structured Log
- A log line emitted as named fields rather than prose, so that it can be filtered, counted and compared rather than only read.
- Event Name
- The stable identifier of what happened, which is what makes a log searchable across a week instead of findable only by remembering a sentence.
- Container Prefix
- The label the multi-container tool prepends to each log line naming which service produced it, answering the first question of almost every diagnosis.
- Failure Path Test
- A deliberate break of a dependency to observe what the system does, which is the only way a health check's honesty can be confirmed.
- Observability Gap
- A question about the system's behaviour that the current signals cannot answer, which is what the module asks you to close one of.
- Operational Weakness
- A known shortcoming recorded honestly while it is fresh, which supplies the limitation the final demonstration and brief both ask for.
- Postmortem
- A written account of a failure with the signal that revealed it and the change that followed, written from a record rather than from memory.
Observability and Debugging FAQ
How are logs, health checks and metrics different?
They answer different questions and each is blind to what the others catch. Logs tell you what happened, in what order and with what detail, but only about things somebody chose to log. Health checks tell you whether a process is alive and able to serve right now, and cannot see anything intermittent.
Metrics tell you how much, how often and how long across many runs, and cannot explain why one particular case behaved as it did. That is why a team with all three still queries the store to answer a question about one item, and why the module makes distinguishing them a learning goal.
How do I debug a failure across four services?
By narrowing rather than inspecting. Start with a question that separates an outage from a single stuck item, such as whether a fresh submission works. Then ask the store whether a job record exists for the affected item and what state it is in, which splits the remaining possibilities into a transaction-boundary failure, a claim query problem and a dead worker. Each branch points at one place to look.
The container prefix on every log line answers where a failure surfaced, and it costs nothing because the tooling supplies it.
What counts as enough observability for a semester project?
Four questions answered is a complete baseline at this scale: is the system up, is anything stuck, did this item fail and why, and how long does the slow step take. Those are answered by a readiness probe, a queue-depth query with the age of the oldest waiting job, a stored failure reason on the job record, and one duration measurement.
A team with those four can defend the absence of anything else as a deliberate scope decision. The module asks for one improved gap rather than a monitoring stack, and the narrow version produces evidence the final brief can cite.
Assessment move
Once a week from Week 10, try to answer one real question using only the signals you have: how many items failed this week, or how long the background step usually takes. If answering requires reading code or inventing a new query, you have found the gap the module asks you to close, and you have found it in ten minutes rather than during a demonstration.
Working through Observability and Debugging in MAIE6000C? Sia is AskSia’s AI Computer Science tutor — ask any MAIE6000C Observability and Debugging question and get a clear, step-by-step explanation grounded in how MAIE6000C is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
