Controlla i costi negli ambienti cloud: tariffazione in OpenStack con CloudKitty

Il tuo cloud privato sembra un buffet aperto a tutti? Sai che offre valore, ma quando arriva il conto è quasi impossibile capire chi consuma cosa.

Negli ambienti cloud dinamici di oggi, è sempre più importante poter attribuire correttamente i costi agli utenti interni, soprattutto per le aziende che gestiscono la propria infrastruttura cloud. Devi definire le responsabilità per distribuire equamente i costi tra i reparti o incoraggiare i team a ridimensionare i carichi di lavoro, e ottenere visibilità è il primo passo.

Con la feature release 5 (FR5) di Red Hat OpenStack Services on OpenShift 18, offriamo un tassello fondamentale per risolvere questo enigma: la possibilità di effettuare la tariffazione in base all'utilizzo misurato dei tuoi tenant.

CloudKitty è il nuovo servizio di tariffazione nativo di OpenStack generalmente disponibile in FR5. Questo servizio colma il divario tra le tue metriche tecniche generiche e le tue operazioni finanziarie.

Perché CloudKitty è importante?

CloudKitty fornisce si occupa di tradurre i dati sull'utilizzo del server in informazioni in grado di orientare i budget dei reparti. Pensa a CloudKitty come al lettore del tuo contatore: si colloca tra le tue metriche raccolte e la tua soluzione FinOps o di fatturazione. Acquisisce i dati tecnici grezzi, ad esempio le ore di funzionamento di una macchina virtuale (VM) o lo storage consumato, e applica le tue regole di tariffazione specifiche per generare un report. In questo modo puoi raggiungere due obiettivi principali.

• Recupero trasparente dei costi: ora puoi vedere una suddivisione chiara e dettagliata dell'utilizzo delle risorse per tenant. In questo modo puoi recuperare le spese operative in modo accurato, senza sorprendere i clienti interni con addebiti poco trasparenti.
• Fiducia e ottimizzazione: potendo vedere in che modo il proprio consumo (suddiviso per progetto, profilo e metrica) influisce sui costi, i tenant possono prendere decisioni informate, per esempio sull’archiviazione dei dati obsoleti o sull'utilizzo delle VM.

Tieni presente che CloudKitty funge esclusivamente da motore per la visibilità e la tariffazione; non applica attivamente i budget né blocca la creazione di risorse (come le istanze Nova) se un tenant supera una determinata soglia di costo.

Come funziona CloudKitty?

Pur non essendo una soluzione di fatturazione completa, CloudKitty connette utilizzo e costi. Il flusso di lavoro, in parole povere, è il seguente:

Imposta regole di tariffazione → Raccogli metriche → Genera report di tariffazione

Imposta le regole

Presentiamo un tenant fittizio dal nostro elenco di esempi: il Ministero dei Dati. Storicamente, il Ministero ha avviato VM di grandi dimensioni per i propri carichi di lavoro di analisi, lasciandole in esecuzione per molto tempo dopo il completamento dei calcoli.

Per un recupero trasparente dei costi, dobbiamo tracciare l’impronta computazionale. Per farlo, tracciamo la metrica ceilometer_cpu. Questa specifica metrica ci consente di fornire un uptime basato sul profilo. Ciò significa che, per ogni periodo in cui un'istanza VM è in esecuzione, CloudKitty può calcolare una tariffa diversa in base alle sue dimensioni.

Passo 1: Crea il servizio

Innanzitutto, dobbiamo creare un container di primo livello per la nostra metrica. Il nome del servizio deve corrispondere esattamente al nome della metrica o all'alt_name definito in metrics.yaml. (Analizzeremo questo file in dettaglio più avanti.)

openstack rating hashmap service create ceilometer_cpu
+----------+--------------------------------------+
| Name | Service ID |
+----------+--------------------------------------+
| ceilometer_cpu | <uuid> |
+----------+--------------------------------------+

Salva quell'ID servizio (UUID): ti servirà per i comandi successivi.

Creando un servizio denominato ceilometer_cpu, contribuimo a garantire che ogni singolo punto dati della CPU proveniente dal collector venga indirizzato direttamente a questa nuova regola di tariffazione.

Passaggio 2: Creazione di un gruppo (facoltativo)

Non vogliamo che i costi di calcolo del Ministero si mescolino con quelli relativi a storage o rete. I gruppi ci aiutano a organizzare le mappature correlate e a isolare i calcoli tra loro.

openstack rating hashmap group create cpu_rating

Raggruppando queste mappature, separiamo i diversi scenari di fatturazione. Se più mappature nello stesso gruppo corrispondono, CloudKitty applicherà solo quella più costosa.

Passaggio 3: Crea una mappatura

Le mappature sono le regole di costo. Innanzitutto, stabiliamo una base di riferimento per il Ministero dei Dati addebitando un costo fisso per elemento. Sostituendo <service_id> e <group_id> con gli UUID restituiti nei passaggi precedenti, puoi collegare questa nuova regola direttamente al tuo servizio ceilometer_cpu e al gruppo cpu_rating.

openstack rating hashmap mapping create 0.02 \
    -s <service_id> \
    -g <group_id> \
    -t flat

In questo scenario, 0,02 indica 0,02 unità per periodo di raccolta (ogni ora per impostazione predefinita). Ogni istanza CPU comporta un costo fisso di 0,02 unità, indipendentemente dall'utilizzo.

Passaggio 4: Valutazione basata sui campi (l'arma segreta)

Il Ministero dei Dati gestisce piccoli server web insieme a enormi nodi di database che richiedono molte risorse. Applicare una tariffa fissa per tutto non sarebbe equo. Vogliamo addebitare loro prezzi diversi per ciascuno dei profili specifici di macchine virtuali (VM) che utilizzano.

Innanzitutto, creiamo un campo che fa riferimento alla chiave dei metadati:

openstack rating hashmap field create <service_id> flavor_id

Quindi, creiamo una mappatura specifica per quel valore di profili:

openstack rating hashmap mapping create 0.05 \
    --field-id <field_id> \
    --value <flavor_uuid> \
    -t flat

Ripeteremo la creazione di questa mappatura per ogni profilo disponibile nel nostro ambiente. Per ogni profilo, crea una nuova regola in modo che il servizio di valutazione sappia quale tariffa calcolare quando quella specifica dimensione di VM è in esecuzione.

Il risultato: Come funziona il tutto

Quando arriva la fine del mese e il Ministero dei Dati chiede di visualizzare l’utilizzo, ecco come CloudKitty elabora le regole create in precedenza:

ceilometer_cpu (metric)
    └─> Service: ceilometer_cpu
           └─> Field: flavor_id (optional)
                  └─> Mapping: m1.tiny = 0.01, m1.large = 0.05
           └─> Mapping (direct): 0.02 flat

Se puoi misurarlo, puoi valutarlo

Abbiamo utilizzato l'utilizzo della CPU del Ministero dei Dati (ceilometer_cpu) as esempio principale, ma le risorse di calcolo sono solo un tassello del puzzle. Il vero punto di forza di CloudKitty in Red Hat OpenStack Services on OpenShift è la sua integrazione con Prometheus.

Ricorda che puoi utilizzare qualsiasi metrica già raccolta per la valutazione. Questo significa che puoi creare facilmente regole di valutazione per il resto del footprint del tuo tenant, seguendo gli stessi identici passaggi descritti sopra. Ad esempio, puoi creare mappature dei costi per i seguenti scopi.

• Archiviazione a blocchi: monitorare la capacità in GB-mese tramite ceilometer_disk_device_capacity
• Reti: addebito per gli indirizzi pubblici allocati tramite ceilometer_ip_floating
• Larghezza di banda in uscita: tariffazione del traffico totale in uscita dalle VM tramite ceilometer_network_outgoing_bytes

Una volta che CloudKitty recupera questi dati da Prometheus, il processore applica le tue regole di valutazione personalizzate e invia le metriche finali valutate direttamente a un backend di storage. Funge da ponte automatizzato tra la telemetria tecnica grezza e la tua reportistica FinOps.

Genera report di tariffazione: il momento della verità

Dopo aver creato le tue regole e raccolto le metriche da Prometheus, l'ultimo passaggio consiste nell'estrarre i dati tariffati.

È importante notare che CloudKitty non è un sistema di fatturazione. Non tenta di generare un'elegante fattura PDF. Al contrario, è progettato per fungere da solido motore di dati che fornisce dati JSON puliti e analizzabili tramite la sua API REST o il client OpenStack. In questo modo potrai integrare più facilmente i dati tariffati direttamente nel middleware di FinOps, showback o fatturazione esistente della tua azienda.

La prospettiva del tenant: il Ministero controlla i propri costi

CloudKitty dispone di un controllo degli accessi tenant-aware integrato. Quando il Ministero dei Dati vuole vedere il proprio utilizzo attuale, può accedere solo all'impronta del proprio progetto. L'API blocca o ignora automaticamente qualsiasi tentativo di visualizzare i dati di altri tenant.

Per ottenere il riepilogo mensile, il Ministero può utilizzare il client OpenStack:

# Get summary for a specific month
openstack rating summary get --begin 2026-02-01 --end 2026-03-01

La prospettiva dell'amministratore: una visione d'insieme

Mentre il Ministero dei Dati può visualizzare solo il proprio utilizzo, gli amministratori cloud hanno bisogno di una visione olistica dell'intero ambiente per gestire la capacità e facilitare il chargeback globale.

Utilizzando un token amministratore, gli operatori hanno una visibilità completa. Possono basarsi su questo comando per isolare un tenant specifico usando --tenant-id <project_uuid>.

openstack rating summary get \
--begin 2026-02-01 \
--end 2026-03-01 \
--tenant-id <project_uuid>

In alternativa, se il team FinOps ha bisogno del quadro completo da esportare nel proprio sistema di fatturazione, l'amministratore può estrarre contemporaneamente i dati tariffati per l'intero cloud utilizzando il flag --all-tenants.

Connettiti direttamente alla tua soluzione FinOps

Se il tuo middleware FinOps estrae questi dati in modo programmatico, può utilizzare l'API REST per richiedere una suddivisione dettagliata raggruppata per i tipi di servizio specifici configurati in precedenza (come ceilometer_cpu):

curl -X GET \
-H "X-Auth-Token: $TENANT_TOKEN" \
"http://localhost:8888/v1/report/summary?begin=2026-02-01T00:00:00&end=2026-03-01T00:00:00&groupby=res_type"

L'output JSON risultante presenta chiaramente il tipo di risorsa, il periodo di tempo e le unità totali calcolate

{
  "summary": [
    {
      "tenant_id": "MoD-project-uuid",
      "res_type": "ceilometer_cpu",
      "begin": "2026-02-01T00:00:00",
      "end": "2026-03-01T00:00:00",
      "rate": 125.50
    }
  ]
}

Incanalando questi dati JSON strutturati e aggregati direttamente nel software finanziario della tua azienda, chiudi con successo il cerchio tra il consumo grezzo dell'infrastruttura e la responsabilità dei costi.

Uno sguardo agli ingranaggi

Ora che abbiamo visto CloudKitty in azione dal punto di vista dell'operatore, vediamo come è fatto. Comprendere l'architettura ti aiuterà a valutare la scalabilità, a risolvere i problemi e a capire perché sono state prese determinate decisioni di progettazione.

Panoramica dell'architettura

CloudKitty opera come due processi indipendenti, ciascuno con una responsabilità distinta:

Figura 1. L'architettura di CloudKitty. cloudkitty-processor recupera gli ambiti da Keystone e le metriche da Prometheus, calcola le tariffe dei dati e li archivia in Loki. cloudkitty-api fornisce i dati tariffati da Loki agli utenti e agli strumenti FinOps tramite REST.

cloudkitty-processor è un motore di valutazione. Durante ogni periodo di raccolta (un'ora per impostazione predefinita), esegue una pipeline a quattro fasi.

1. Recupero: richiede a Keystone l'elenco dei progetti OpenStack (ambiti) da valutare.
2. Raccolta: per ogni ambito, interroga Prometheus per ottenere i valori grezzi delle metriche definiti in metrics.yaml.
3. Valutazione: applica le regole hashmap (i servizi, i campi e i mapping configurati in precedenza) per convertire i consumi non elaborati in dati valutati.
4. Archiviazione: invia i dataframe valutati risultanti a Loki per la persistenza.

cloudkitty-api è il frontend REST. Gestisce tutte le query in arrivo da tenant, amministratori e strumenti FinOps esterni. Quando un utente richiede un riepilogo della valutazione, interroga Loki e restituisce i risultati. Questo processo è stateless ed è possibile sfruttare la scalabilità orizzontale per gestire più richieste simultanee.

Poiché i due processi sono disaccoppiati, puoi ridimensionarli in modo indipendente: aggiungi più repliche API per gestire il carico delle query oppure ottimizza il parallelismo del processore per valutare più ambiti contemporaneamente.

Perché Loki?

L'utilizzo di Grafana Loki como backend di storage per i dati valutati può sembrare una scelta non convenzionale, poiché Loki è noto principalmente come sistema di aggregazione dei log, ma in realtà si adatta molto bene.

• È nativo per serie temporali: i dati valutati sono intrinsecamente temporali (costo per ambito per periodo di raccolta). Loki è progettato appositamente per eseguire query efficienti su intervalli di tempo su flussi strutturati.
• È già nello stack: i deployment di OpenStack Services su OpenShift includono già un LokiStack per la gestione dei log. CloudKitty riutilizza la stessa infrastruttura gestita dall'operatore, quindi non occorre eseguire il deployment o la manutenzione di database aggiuntivi.
• È basato su object storage: Loki salva i dati su uno storage a oggetti compatibile con S3, riducendo l'ingombro operativo — senza dover gestire PVC o cluster di database aggiuntivi.
• Metadati strutturati: in futuro, CloudKitty memorizzerà i metadati indicizzati (tenant, tipo di metrica, profilo) direttamente in ogni voce di log. Questo consentirà di eseguire query filtrate rapide senza un'analisi JSON completa, migliorando notevolmente le prestazioni delle query su larga scala.

La configurazione delle metriche

Al centro della fase di raccolta si trova metrics.yaml. Questo file indica a CloudKitty quali metriche Prometheus raccogliere e come gestirle. Ecco un estratto rappresentativo della configurazione fornita.

metrics:
  ceilometer_cpu:
    unit: instance
    alt_name: instance
    groupby:
      - resource
      - user
      - project
      - flavor_name
      - flavor_id
    mutate: NUMBOOL
    extra_args:
      aggregation_method: max
  ceilometer_image_size:
    unit: MiB
    factor: 1/1048576
    groupby:
      - resource
      - project
    metadata:
      - container_format
      - disk_format
    extra_args:
      aggregation_method: max

Ogni voce controlla il modo in cui CloudKitty raccoglie e interpreta una specifica metrica di Prometheus.

• unit: Unità di fatturazione che compare nei report di valutazione (ad esempio, instance, GiB, B, ip).
• alt_name: Nome alternativo per la metrica. Quando crei servizi hashmap, puoi utilizzare il nome della metrica Prometheus (ceilometer_cpu) o l'attributo alt_name (instance).
• groupby: etichette Prometheus utilizzate per disaggregare la metrica. Per ceilometer_cpu, il raggruppamento per flavor_name e flavor_id abilita le regole di valutazione basate sui profili configurate in precedenza.
• mutate: trasformazione applicata al valore non elaborato. NUMBOOL converte qualsiasi valore diverso da zero in 1, il che è ideale per la semantica "la risorsa è attiva?": non interessa il contatore CPU non elaborato, ma solo che l'istanza sia in esecuzione.
• factor: fattore di moltiplicazione per la conversione delle unità. Ad esempio, ceilometer_image_size utilizza 1/1048576 per convertire i byte non elaborati in MiB.
• metadata: etichette Prometheus aggiuntive da includere nei dati valutati a scopo informativo (ad esempio, container_format, disk_format per le immagini).
• extra_args: argomenti specifici del back-end. aggregation_method: max indica al raccoglitore Prometheus di utilizzare il valore massimo all'interno di ciascun periodo di raccolta.

Poiché il raccoglitore di CloudKitty comunica direttamente con Prometheus, la valutazione di qualsiasi metrica disponibile è semplice: aggiungi una nuova voce a metrics.yaml con le etichette e l'unità appropriate e CloudKitty inizierà a raccoglierla e a valutarla nel ciclo di elaborazione successivo.

Ispeziona i dati non elaborati

Anche se il comando openstack rating summary get fornisce i totali aggregati, a volte devi andare più a fondo. Che tu stia verificando che le regole di valutazione vengano applicate correttamente, eseguendo il debug di una metrica mancante o cercando di capire che cosa archivia CloudKitty, il comando openstack rating dataframes get ti consente di ispezionare i singoli punti dati valutati presenti in Loki.

Pensa ai riepiloghi come all'estratto conto mensile e ai dataframe come alle singole voci della ricevuta.

Per recuperare i dataframe valutati non elaborati per un intervallo di tempo specifico:

openstack rating dataframes get --begin 2026-03-01T00:00:00Z --end 2026-03-01T01:00:00Z

Ogni riga dell'output rappresenta un singolo punto dati valutato per un periodo di raccolta: