This is the first of four posts on Live Optics. Not because it is a bad tool, but because it is a widely used one that produces a confident-looking report, and confident-looking reports get treated as measurements when they are partly inference.

The shape of the data

Live Optics runs a collector against hosts, hypervisors or a file system and samples performance over a window. What comes back, broadly:

Per-server and per-VM CPU and memory utilisation. Storage IOPS split by read and write. Throughput in MB/s. Average block size. Latency. A capacity picture of what is provisioned versus what is written. Depending on the collector, a file scan giving file counts and size distribution.

That is a genuinely useful set. It is far more than an inventory export gives you, because it has a time dimension, and the time dimension is where sizing arguments are won.

What it does not tell you

Why. The tool sees a workload spike at 02:00 every night. It does not know that this is a batch job that has been scheduled badly since 2017 and could move. Sizing to accommodate a spike you could eliminate is an expensive way to preserve a mistake.

Application context. The report is organised by host and VM. Your business is organised by application. The mapping between the two exists only in somebody’s head, and you need it before the numbers mean anything.

Working set. You get capacity and you get IOPS. What you do not directly get is how much of the data is actually hot. For any tiering or cache sizing decision, that is the number that matters, and it has to be inferred.

Anything outside the window. This is the big one and it gets its own post.

The queue. Latency tells you what the storage delivered. It does not tell you what the application wanted and did not get. A workload that has already been throttled by slow storage reports as a modest workload. Size from that and you rebuild the constraint.

The collector choice matters more than people think

There are different collectors for different sources, and they do not see the same things. A hypervisor-level collection gives you VM-level detail. A host-level agent sees the operating system’s view. A storage array collection sees the array’s view.

These disagree. Not because any of them is wrong, but because they measure at different points in the stack, and everything between those points — caching, coalescing, queueing, the hypervisor’s own scheduling — changes the numbers.

If you collect at the array and size for the array, you are consistent. If you collect at the array and size a host-based solution, you are not, and the gap will not be small. Decide which layer you are sizing for, and collect at that layer.

The practical checklist

Before you accept a collection as the basis for anything:

  • Which collector, at which layer?
  • Which window, and does it include the busy period?
  • Were all hosts in scope, or did some fail to collect?
  • Are powered-off systems included in capacity but absent from performance?
  • Does anyone recognise the top ten workloads by name?

That last question is the most valuable one in the list, and it takes five minutes. Show the top consumers to the people who run the applications. They will immediately tell you which ones are real, which ones are runaway logging, and which ones are scheduled and movable. No tool can give you that, and it routinely changes the design.

Where this leaves the tool

Live Optics is a good data collector attached to a report that is built to lead somewhere. The data is worth having. The report’s conclusions are worth reading the way you would read any document produced by someone with something to sell, including when that someone is your own vendor.

Next in this series: why a twenty-four hour collection is not a workload profile.