---
title: "Fly's Prometheus Metrics"
description: "Fly describes the Prometheus-style metrics infrastructure behind its globally distributed micro-VM platform and explains why it favors metrics over traditional monitoring checks. The system collects counters and other measurements through HTTP /metrics endpoints, stores them in a clustered VictoriaMetrics (“Vicky”) deployment, and uses Telegraf, Vector, exporters, and Consul to connect sources and manage discovery. Within Firecracker instances, custom init, the Nomad driver, and a vsock carry node-exporter-type JSON statistics from guests for collection, while applications can expose their own exporters. Deployments can declare an exporter port and /metrics path in fly.toml, after which Fly routes those application metrics into Vicky alongside platform data. The resulting Prometheus API is available for Grafana queries, dashboards, and alerts, with labels such as app, region, host, and instance; the post argues that the same historical data supports anomaly detection, trending, and planning."
---

# Fly's Prometheus Metrics

[Fly.io](https://yomu.fyi/company/fly-io) · May 13, 2021

**Type:** Explainer

## Summary

Fly describes the Prometheus-style metrics infrastructure behind its globally distributed micro-VM platform and explains why it favors metrics over traditional monitoring checks. The system collects counters and other measurements through HTTP /metrics endpoints, stores them in a clustered VictoriaMetrics (“Vicky”) deployment, and uses Telegraf, Vector, exporters, and Consul to connect sources and manage discovery. Within Firecracker instances, custom init, the Nomad driver, and a vsock carry node-exporter-type JSON statistics from guests for collection, while applications can expose their own exporters. Deployments can declare an exporter port and /metrics path in fly.toml, after which Fly routes those application metrics into Vicky alongside platform data. The resulting Prometheus API is available for Grafana queries, dashboards, and alerts, with labels such as app, region, host, and instance; the post argues that the same historical data supports anomaly detection, trending, and planning.

## Context

Fly needs to collect and query measurements from edge nodes, worker nodes, Firecracker VMs, platform services, and user applications. The post also contrasts metrics-based white-box monitoring with script-based checks, emphasizing that historical metrics support alerting, anomaly detection, trending, and planning.

## Approach / What changed

Fly built a Prometheus-style stack using clustered VictoriaMetrics as its metrics database, with Telegraf agents, Vector, Prometheus exporters, and Consul handling collection, forwarding, and discovery. Firecracker guests send node-exporter-type JSON stats over vsock, and applications can declare an exporter port and /metrics path in fly.toml so their metrics are stored and exposed through Fly’s Prometheus API.

## Takeaways

- VictoriaMetrics replaced the initial simple Prometheus setup after scaling it with Thanos created too much operational hassle, according to the excerpt.
- A Fly application can expose a Prometheus exporter by declaring its port and /metrics path in fly.toml; deployment configuration then sends those metrics to the Vicky cluster.
- Metrics-based monitoring uses historical time-series data to define anomaly rules later, unlike checks that require scripts for predefined probes.

**Tags:** [Monitoring](https://yomu.fyi/topic/monitoring), [Observability](https://yomu.fyi/topic/observability), [Prometheus](https://yomu.fyi/topic/prometheus)

- Source: [Fly.io](https://fly.io/blog/measuring-fly)
- Source URL: https://fly.io/blog/measuring-fly
- Ingested by Yomu: 2026-09-03T01:26:27.864Z

[Read original post](https://fly.io/blog/measuring-fly)