Business transaction monitoring
Follow one order across every system it touches
OpTier watches a single business operation — an order, a claim, a booking — from the moment it arrives to the moment it is finished, and reports where its time went. It is monitoring software for the team that runs the systems. It does not run them, and it does not stand between you and your own users.
The three questions it exists to answer
- Where did this particular transaction spend its time, hop by hop?
- Is that different from how the same kind of transaction usually behaves on this system, at this hour?
- Which hop changed — and did it change for everyone, or only for the transactions that took one branch?
The unit of measurement
One transaction, hop by hop
Most monitoring is organised around machines: this server, that queue, this container. A business transaction is organised the other way round. It is one named operation with a start and an end, and it is counted as one thing even though it crosses six systems on the way.
Gateway
Where the request first becomes yours. The identifier is minted here, or accepted from whoever called you.
Authentication
The check that decides whether this transaction is allowed to continue at all, and on whose behalf.
Application
Your own code: the business rules, the orchestration, the branch that only runs for certain orders.
Database
Reads and writes — and the time spent waiting for a free connection rather than waiting for the query.
External call
Anything you do not run. Timed from your side of the boundary, because that is the only side you have.
Rendering
Assembling the answer and getting the last byte of it out of the door.
The six hops above are the vocabulary used throughout this site, and the same six appear in the latency budget allocator. Your own system will have more of them, or fewer, or two that only appear on Fridays.
Why the headline number fails
An average response time hides everything worth knowing
An average is a single number standing in for a whole distribution, and it only describes that distribution honestly when the distribution has one hump and short tails. Response times almost never look like that. They are lumpy: a fast path, a slow path, a rare path that hits a cold cache or a retry, and a long thin tail where the genuinely broken transactions live.
Take two figures purely to show the arithmetic, since the formula is the point and not the numbers. If half of your transactions finish in a tenth of a second and the other half take three seconds, the mean sits at about one and a half seconds. Not one transaction in that set took one and a half seconds. The average has invented an experience nobody had, and it has done it by cancelling out exactly the two behaviours you needed to see.
Worse, an average is stable in the wrong way. A slow tail can double in size while the mean barely moves, because the mean is dominated by the many fast transactions underneath it. By the time an average moves enough to be noticed, a lot of people have already had a bad afternoon.
The useful replacement is not a cleverer single number. It is the distribution itself, read as percentiles, plus the ability to open one slow transaction and see which hop it lost its time in. That second half is the part most tools skip.
Definitions
What “one business transaction” means as a unit
It is named by the business
“Place an order”, “submit a claim”, “confirm a booking”. Not “POST to that endpoint”. If a person in the business cannot recognise the name, it is not a business transaction, it is a technical detail wearing a badge.
It has one start and one end
The clock starts at a defined event and stops at a defined event, and both are written down. Half of all arguments about whether something got slower are really arguments about where the two of you started counting.
It carries an identifier
The same value travels with the work through every hop, so the pieces can be reassembled afterwards. Nothing else about the design matters if this identifier is dropped at a boundary.
It survives fan-out
One transaction may become nine parallel pieces of work and then become one again. It is still one transaction. Its duration is not the sum of its parts, and treating it as a sum is one of the commonest ways to produce a confident wrong answer.
It is counted, not sampled, at the top
How many started, how many finished, how many are still open. Those three counts are cheap, and they are what tells you a queue is filling before anybody's average moves.
It has a version
The transaction that ran this morning and the one that runs tonight are only comparable if the code behind them is the same. A measurement without a version attached quietly compares two different products.
Who it is for
Built for the organisation that runs the systems
OpTier is installed by the organisation that owns the software, and it reports to the people who operate it: the engineers on the rota, the person who has to answer “is it us?” in a meeting, and the manager deciding whether the next quarter goes on features or on the database.
It is a product, not a service. We do not log into your systems, we do not sit between your users and your application, and there is nobody here waiting to take over an incident. Every screen it draws is drawn from data your own installation collected, on your own hardware.
That framing also sets the limits. A monitoring tool can describe a system precisely and still be useless if nobody has the authority to change what it describes. If the honest answer to “who can act on this?” is nobody, better instrumentation will not help you.
Honest limits
What this does not do
Everything below is a real limitation of the approach, not a feature waiting on the roadmap. If one of them is fatal for you, better to find out on this page.
It will not tell you why a third party is slow
When a hop is somebody else's service, the only thing your instrumentation can honestly report is the time between your request leaving and their answer arriving, measured on your machine. That number includes the network in both directions, their queueing, their work, and any retry your own client library performed without telling you.
It does not include a cause. We cannot see inside their system, and neither can you. What the measurement is genuinely good for is settling whether the slowness is on your side of the boundary or theirs — which is usually the argument that actually needs settling.
It will not fix anything
There is no automatic remediation here, no restart button, no traffic shifting. This is deliberate. A tool that both diagnoses and acts has to be trusted twice, and the second kind of trust is much harder to earn than the first.
It also means the value of the product is capped by what your organisation does with what it learns. A perfectly instrumented system where nobody is allowed to change the database schema will produce beautiful evidence of the same problem every month.
It adds its own overhead
Every measurement costs something. Creating an identifier, attaching context, timing a span, serialising it and shipping it off the machine all consume processor time, memory and network capacity that would otherwise have gone to your own work. Anyone who tells you their monitoring is free is measuring their monitoring badly.
The overhead is small per transaction and it is not zero, and it grows with how finely you instrument. The right response is to measure the cost on your own hardware with your own workload, decide what you are willing to spend, and then instrument to that budget rather than instrumenting everything because you can.
It cannot see work that nobody instrumented
A trace is made of the spans your code chose to emit. Time spent in a library that emits nothing, in a thread pool queue nobody timed, or in a scheduler waiting for a processor, shows up only as an unexplained gap between two spans that you can see.
Those gaps are informative once you learn to read them, but they are inference, not observation, and we mark them as such rather than filling them in with a confident label.
It is not a replacement for logs or for reading the code
Tracing tells you where the time went. Logs tell you what the program thought it was doing, and the code tells you why. Investigations that end well usually use all three, and a team that deletes its logging because it now has traces will regret it during the first genuinely strange incident.
It will not make an under-resourced team faster
Instrumentation converts a vague problem into a specific one. That is worth a great deal, but it is not the same as capacity. If the specific problem is that one component needs rewriting and nobody has the time, the monitoring will simply describe the situation more precisely each week.
See it against one of your own transactions
A demo is more useful when it follows an operation you recognise. Tell us which one, and roughly how many systems it passes through.