Analytics Consultancy

Metrics that can be collected properly, analysed properly, and explained honestly.

I build analytics and observability systems for organisations that need more than a dashboard. The work covers collection, federation, consolidation, storage, visualisation, deep analysis, and reporting, with a focus on technical accuracy rather than narrative spin.

That includes helping teams find the hidden value in data that appears mundane at first glance, and shaping how it is collected and stored so later analysis stays useful, defensible, and close to the truth.

Storage
VictoriaMetrics and Prometheus-compatible pipelines
Visualisation
Grafana dashboards and custom visualisations
Analysis
Deep metric analysis, explanation, and reporting

What this is for

Useful insight for engineering teams.

This work is aimed at businesses that already collect useful data, but need better systems for turning it into something trustworthy, actionable, and technically meaningful.

Working style

I approach data from a developer perspective: sound instrumentation, careful interpretation, and tools that stand up under real operational use.

Approach

Good analytics starts with the shape of the data, not the shape of the dashboard.

Many teams have metrics scattered across databases, logs, queues, scripts, and third-party services, but no coherent way to gather them, align them, or explain what they actually mean. That is where I tend to work best.

I help design and build systems that collect from the right places, normalise and federate data sensibly, store it efficiently, surface it clearly in Grafana, and support deeper analysis when simple charts are not enough. The goal is not prettier reporting. The goal is more reliable understanding.

A large part of that work is helping clients identify the hidden value in data that might otherwise be dismissed as too mundane, too noisy, or too operational to matter. In practice, apparently ordinary signals often become highly useful once they are collected consistently, stored properly, and interpreted in context.

Core Stack

VictoriaMetrics, Grafana, and custom engineering around the gaps.

VictoriaMetrics

Fast, efficient time-series storage

I use VictoriaMetrics where teams need a serious TSDB with strong ingestion performance, efficient storage, practical querying, and a simpler operational profile than heavier alternatives. It is a good fit for high-volume metrics, long retention, and environments where cost and performance both matter.

That includes schema thinking, metric design, ingestion strategy, retention planning, and helping teams avoid the kinds of cardinality and interpretation problems that quietly make observability systems less useful over time.

Grafana

Dashboards, exploration, and custom visualisations

Grafana is where teams usually meet their data, so clarity matters. I build dashboards that are meant to be read by engineers, not admired in a sales deck. The work ranges from panel design and query structure to alerting, drill-down workflows, and visual explanation.

I also write custom Grafana visualisations when the built-in components are not enough, which makes it possible to present more specialised operational patterns without forcing them into the wrong chart type.

Custom Tooling

Purpose-built systems for collection, federation, analysis, and explanation.

Alongside the standard observability stack, I have developed my own tooling to deal with the practical problems that off-the-shelf products often leave unresolved: pulling metrics out of awkward sources, consolidating them into Prometheus-compatible form, monitoring the collection layer itself, and producing reports that explain what changed and why it matters.

Collection & Federation

Flexible high-performance metrics collection

The core collection system is designed to query a wide range of data sources, transform the results into Prometheus-compatible metrics, and push them onward to Prometheus endpoints. It is built for environments where the interesting data lives in many places and arrives with different levels of structure and reliability.

  • Collects from MySQL, PostgreSQL, MSSQL, MongoDB, Elasticsearch, Kafka, CSV files, external processes, and AWS Athena.
  • Supports hot-reloading configuration, so new jobs and changes can be applied without restart.
  • Pushes directly to Prometheus-compatible endpoints, making it easy to integrate with existing monitoring pipelines.
  • Uses concurrent worker pools for throughput, with automatic retries and exponential backoff for failed jobs.
  • Can isolate retries into dedicated datasource pools, so failed work does not interfere with the normal collection path.
  • Supports timestamp templating plus label and metric filtering for more controlled collection and cleaner downstream series.
Operational UX

Terminal-first monitoring

The collector includes a terminal UI for real-time monitoring of worker state, pools, scheduling, retries, logs, and system statistics, plus remote TUI access so distributed instances can be observed with a consistent view.

Reliability

Designed for long-running collection

A built-in watchdog monitors resources and can restart the service if thresholds are breached, while the plugin architecture allows new datasource types to be added without reworking the whole system.

DeepThought

LLM-backed explanation over defined time windows

DeepThought is the analysis layer: an LLM-backed system that examines a chosen timeframe and produces a readable report on what happened in the data. It is designed to help teams move from raw metrics to coherent explanation without losing the technical substance.

  • Works with local models through Ollama and llama.cpp as well as hosted models such as ChatGPT.
  • Supports detailed exploratory analysis when a simple graph is not enough to explain shifts, anomalies, or operational trends.
  • Helps translate dense metric output into reports that are easier to discuss, while still grounding the explanation in the underlying data.

Case Study

A private multi-source metrics environment used as a real-world analytics testbed.

Challenge

Mixed operational data in a location where resilience matters

One of the most useful proving grounds for this work is my own home environment, where I monitor incoming mains power, indoor and outdoor temperature and humidity, chicken coop conditions, UPS behaviour, and Starlink equipment metrics.

It is a useful test case because the operational constraints are real. The property is in a rural location where mains voltage can behave unpredictably, there is effectively no meaningful cellular signal, and copper land-line connectivity is poor enough to be an unreliable fallback. In practice, Starlink is the only viable communications path, so 24x7 monitoring of uptime and behaviour is not optional.

Architecture

Collection, federation, storage, and visualisation

Clamp-meter power readings and Zigbee environmental sensors feed into two Zigbee networks, which are consolidated through Home Assistant. Bespoke collectors gather data from UPS units and local Starlink equipment, then federate everything into a single Prometheus-compatible metrics pipeline.

All of the resulting metrics are stored in VictoriaMetrics and explored through Grafana. The current environment includes minutely statistics across roughly 35 power, temperature, and humidity metrics, 36 UPS metrics across multiple units, and an additional stream of Starlink telemetry.

Analysis

Correlating power quality, environment, and connectivity

A core analytical question in this environment has been whether unusual mains voltage drops correlate with environmental conditions and what knock-on risk they create for connected equipment. In a rural setting, line quality can behave differently from what many people expect, so simply looking at a voltage graph in isolation is not enough.

  • Voltage trends are examined alongside temperature and humidity over time.
  • The aim is to distinguish routine variation from more meaningful drops, instability, and brownout risk.
  • Starlink telemetry is monitored continuously because connectivity availability is operationally critical in the absence of viable fallback links.
  • The same environment also supports welfare-oriented monitoring, particularly around conditions inside the chicken coop.
Short Term

Immediate operational value

The collected metrics have helped justify the use of UPS units and power-conditioning measures for sensitive equipment, while also providing useful visibility into poultry welfare through environmental monitoring rather than guesswork.

DeepThought

Analysis with explanation

DeepThought has been used against this dataset to detect abnormal voltage behaviour, account for rural operating context and weather-linked conditions, and produce readable explanations of possible causes, brownout risk, and sensible mitigation options.

Medium Term

Trend-led resilience planning

Over a longer window, the same dataset helps identify recurring patterns in power quality, connectivity stability, and environmental conditions, making it easier to decide where resilience improvements will have the most practical value.

Long Term

Better decisions from accumulated evidence

The long-term goal is not just observation but planning: using retained trend data to shape future investment in resilience, protection, monitoring coverage, and infrastructure choices based on measured behaviour rather than assumption.

Engagements

The work can be strategic, practical, or somewhere in between.

Typical consultancy work

  • Designing or improving observability and analytics pipelines.
  • Federating metrics from awkward or distributed data sources.
  • Building Grafana dashboards and custom visual components for engineers.
  • Improving metric quality, naming, retention, and statistical interpretation.
  • Producing deeper analysis systems that explain changes over a chosen timeframe.

What clients tend to need

  • More trust in the numbers they already collect.
  • Help identifying the hidden value in existing data, even when it appears mundane at first glance.
  • Better ways to consolidate metrics from many systems into one operational view.
  • Guidance on how to collect and store data so later analysis is more reliable and more useful.
  • Clearer dashboards for engineering and leadership without oversimplifying the truth.
  • Technical help from someone who understands both the software and the statistics, and who takes an unbiased view of the data rather than forcing a preferred narrative.

Contact

If you need better insight from operational data, I can help build the system around it.

I am particularly interested in consultancy work around VictoriaMetrics, Grafana, Prometheus-compatible metric pipelines, custom collection and federation systems, and deeper analytical tooling that turns raw metrics into useful explanation.

That also includes helping teams improve how they gather and store data in the first place, so future analysis is based on stronger foundations and a more faithful view of what the numbers are actually saying.