Cos'è OpenMeter
OpenMeter è un motore di usage metering open-source, rilasciato con licenza Apache 2.0 e sviluppato in Go. In italiano potremmo tradurlo come "misuratore d'uso": il suo compito è raccogliere gli eventi generati da un software (chiamate API, token LLM consumati, minuti di elaborazione, gigabyte trasferiti, utenti attivi) e aggregarli in tempo reale per cliente, per periodo e per tipologia, rendendoli interrogabili via API.
Il problema che risolve è più comune di quanto sembri. Quasi ogni prodotto software moderno, prima o poi, deve rispondere a domande come: quanto ha consumato questo cliente questo mese? Ha superato la soglia del suo piano? Quanto ci costa servirlo? Rispondere con una query SQL su un database transazionale funziona all'inizio, ma scala malissimo: milioni di eventi al giorno, finestre temporali mobili, aggregazioni per migliaia di clienti contemporaneamente. OpenMeter nasce esattamente per questo collo di bottiglia, ed è diventato particolarmente rilevante con l'esplosione dell'AI generativa, dove ogni interazione ha un costo variabile misurabile in token.
Il progetto è attivo su GitHub sotto l'organizzazione openmeterio, offre SDK ufficiali per Node.js/TypeScript, Python e Go, e può essere usato self-hosted oppure tramite la versione cloud gestita dagli stessi autori.
A cosa serve: i casi d'uso concreti
Il metering non è solo fatturazione. I casi d'uso tipici di OpenMeter sono almeno quattro:
1. Usage-based billing. È il caso più noto: modelli di prezzo in cui il cliente paga in base al consumo reale (per chiamata, per token, per minuto di compute). OpenMeter produce i numeri aggregati che poi alimentano il sistema di invoicing, per esempio tramite l'integrazione con Stripe.
2. Limiti d'uso e entitlement. Un piano "Base" con 10.000 chiamate API al mese ha bisogno di un contatore affidabile e veloce per decidere, a ogni richiesta, se il cliente può procedere o va bloccato/avvisato. OpenMeter espone query in tempo reale pensate proprio per questo controllo.
3. Cost intelligence sull'AI. Chi integra modelli linguistici in un prodotto deve sapere quanto spende per cliente, per feature, per ambiente. Tracciare i token in ingresso e in uscita come eventi permette di calcolare margini reali e individuare clienti o flussi anomali prima che diventino un problema di bilancio.
4. Analytics di prodotto. Il consumo è anche un segnale di comportamento: quali feature vengono usate, da chi, con quale intensità. Gli stessi eventi che alimentano il billing possono alimentare dashboard di product analytics.
Per una PMI o un'agenzia che costruisce servizi digitali, il punto chiave è questo: il metering è infrastruttura, non differenziazione. Costruirsela in casa significa mesi di lavoro su code, aggregazioni e riconciliazione dei dati; OpenMeter la offre pronta e ispezionabile.
Come funziona: l'architettura tecnica
Ingestion basata su CloudEvents
Il primo elemento distintivo è la scelta del formato: OpenMeter accetta eventi nel formato CloudEvents, la specifica aperta incubata dalla CNCF (Cloud Native Computing Foundation) per descrivere eventi in modo standardizzato. Un evento tipico contiene un tipo (type, per esempio api-calls o tokens), un soggetto (subject, di solito l'identificativo del cliente), un timestamp e un payload data in JSON libero con i valori da misurare (durata, quantità di token, percorso chiamato).
Questa scelta ha due vantaggi pratici: gli eventi sono interoperabili con l'ecosistema cloud-native esistente, e il payload flessibile permette di misurare qualsiasi cosa senza cambiare schema.
Pipeline ad alto throughput
Dietro l'API di ingestion, l'architettura di riferimento self-hosted si appoggia a componenti consolidati: Kafka (o compatibili come Redpanda) come dorsale di trasporto degli eventi e ClickHouse, il database colonnare open-source, come motore di aggregazione. È lo stesso pattern usato dalle grandi piattaforme di analytics: gli eventi vengono scritti una sola volta, in append, e le aggregazioni vengono calcolate su finestre temporali con query colonnari molto veloci. Il risultato è la capacità di gestire milioni di eventi in tempo reale senza che il sistema diventi il collo di bottiglia dell'applicazione.
Meter e aggregazioni
Il concetto centrale è il meter: una configurazione che dice ad OpenMeter quali eventi contare, raggruppati per quale soggetto, con quale tipo di aggregazione. Le aggregazioni supportate coprono i casi reali: somma (totale token consumati), conteggio (numero di chiamate), media, minimo, massimo e conteggio di valori univoci (per esempio utenti attivi distinti). I meter si definiscono via API o file di configurazione e producono serie temporali interrogabili per cliente, con granularità oraria, giornaliera o mensile.
Query in tempo reale
Il punto di forza rispetto a un semplice data warehouse è la latenza: le query sui consumi sono pensate per rispondere in millisecondi, perché devono poter stare nel percorso critico dell'applicazione — per esempio nel middleware che decide se un cliente ha ancora credito disponibile prima di eseguire una chiamata al modello AI.
Dal metering alla fatturazione
OpenMeter si colloca a monte del billing: misura, non emette fatture. Il collegamento con i sistemi di pagamento avviene tramite integrazioni e API: il caso più comune è Stripe, dove i consumi aggregati alimentano la fatturazione a consumo. Nel tempo il progetto ha aggiunto componenti che vanno oltre il puro metering — gestione di piani, entitlement e notifiche al raggiungimento di soglie — avvicinandosi a una piattaforma di monetizzazione completa, pur restando il metering il cuore tecnico.
Per un team italiano questo significa poter adottare un pricing a consumo (o ibrido: abbonamento più eccedenze) senza dover costruire da zero contatori, soglie e riconciliazioni, e senza vincolarsi a un vendor chiuso.
Self-hosting e deployment
L'installazione di prova è semplice: il repository fornisce setup basati su Docker per avviare lo stack completo in locale. Per la produzione si passa tipicamente a Kubernetes, con Kafka e ClickHouse come dipendenze infrastrutturali. È una complessità non banale — non è un singolo container come un blog — ma è coerente con il carico che il sistema è progettato a reggere. Chi non vuole gestire l'infrastruttura può valutare il cloud gestito, mantenendo comunque la possibilità di migrare al self-hosted dato che il codice è identico e aperto.
Sul piano della conformità, il self-hosting ha un vantaggio concreto per il mercato europeo: i dati di consumo dei clienti restano nella propria infrastruttura, un argomento rilevante in ottica GDPR quando i soggetti misurati sono persone o aziende identificabili.
Alternative e confronto
Il panorama delle alternative è sostanzialmente triplo. Le soluzioni proprietarie di billing (Stripe Billing con metered pricing, o piattaforme specializzate come Metronome e Lago — quest'ultimo parzialmente open-source) offrono metering come parte di un pacchetto più ampio, ma con lock-in maggiore e meno controllo sull'infrastruttura dati. Le soluzioni fai-da-te (tabelle di eventi più query periodiche) sono semplici all'inizio e fragili dopo. OpenMeter si posiziona nel mezzo: infrastruttura dedicata, standard aperti (CloudEvents, componenti CNCF), codice ispezionabile, nessun costo di licenza.
Per chi ha senso (e per chi no)
OpenMeter ha senso per chi costruisce SaaS, API o prodotti AI con pricing a consumo, piani con limiti d'uso o semplicemente l'esigenza di sapere quanto costa servire ogni cliente. È meno indicato per progetti piccoli con un solo piano flat: in quel caso l'infrastruttura Kafka + ClickHouse è sovradimensionata e basta il metering integrato del provider di pagamento. Il punto di svolta tipico è quando il consumo diventa variabile, misurabile e parte del valore venduto — esattamente la direzione in cui sta andando il software nell'era dei modelli linguistici.
Dove trovarlo
- Repository:
github.com/openmeterio/openmeter(licenza Apache 2.0) - Documentazione e quickstart:
openmeter.io - SDK ufficiali: Node.js/TypeScript, Python, Go
- Deployment: Docker per il test locale, Kubernetes per la produzione, cloud gestito opzionale