Knowing how your service is doing,
not how your servers are doing.
We measure per business process whether the service is doing its job and where it falters, with network and certificates as modules alongside. Monitoring tells you a component fell over; this tells you whether your customer could finish their order. Four teams reporting green is still not a working chain.
Knowing how your service is doing, not how your servers are doing.
Monitoring tells you that a component fell over. Observability lets you ask a question afterwards that you had not thought of in advance: why did this order, for this customer, at a quarter past three, take eleven seconds? That difference is not about more screens. It is about data tied together at transaction level.
End-to-end service monitoring.
We monitor the service the way a user experiences it: from the click in the browser, through your applications and middleware, down to the database and the interface with an external party. One timeline per transaction, across team and supplier boundaries.
That makes ‘is it us or is it you’ an answerable question. Not with an opinion, but with a timeline everyone is looking at.
- Service availability per business process, not per server
- From click to query, including third parties and chain partners
- Agreed targets per process, that you either meet or you do not
- Shorter recovery time, because searching gets shorter
- One timeline that development, operations and suppliers share
MELT: metrics, events, logs and traces.
Observability rests on four kinds of signal. They only become useful when they are tied together: separately they give you four dashboards and no answers.
How are things going.
Numbers over time: response time, throughput, error rate, queues. Cheap to store and suitable to hang a target on. They tell you that something is changing.
What happened.
A release, a change, a scaling action, a failover. Half of all outages start with something someone did, put that alongside your graph and the explanation is right there.
What the system says itself.
The detail and the error messages. Essential for the last step of an investigation, but only usable if they are normalised and you know which ones you need.
Where the time went.
One transaction followed through every hop, with the duration of each step. This is the layer that settles the question of where the delay sits.
Our work is in the tying together: the same timestamp, the same transaction id, the same naming of services. After that an outage is a reading exercise rather than a puzzle.
One process drops below target, and the cause sits outside your own walls. That is exactly the conversation you want to have with your supplier, with numbers attached.
Reporting on what the customer notices.
Availability of 99.9% per server says little if the chain around it was broken. So we measure per business process: could the customer take out the policy, report the claim, make the payment?
- A target, a measurement and an owner for every process
- Chain partners measured too, so an outage outside your walls is visible
- Figures you can put on the table with a supplier without arguing about the measurement
- The same source for the engineers and for the board report
Is it us or is it you?.
That question costs the most time during an outage. With one timeline it is answered in two minutes.