BusDK Update

Usage-events siirtyy omaksi Bus API -provideriksi

bus-api-provider-usage ottaa omistukseensa AI Platformin sisäisen usage-events-keräilypinnan. Provider palvelee luotettuja backend-keräilijöitä, ei loppukäyttäjän bus usage -komentoa.

Samalla Bus API -rajat täsmentyvät: käyttödata pysyy sisäisenä providerina, VM/container/LLM-providerit ovat cloud-neutral-palvelupintoja, ja UpCloud-kohtainen työ kuuluu event-pohjaiselle integraatiotyöntekijälle.

26.4.2026bus-api-provider-usageUsage eventsInternal API

Tiiviisti

TL;DR

bus-api-provider-usage omistaa nyt sisäiset /api/internal/usage-events-polut.
Listaus vaatii usage:read-scopen ja poisto usage:delete-scopen; oletusyleisö on ai.hg.fi/internal.
PostgreSQL-tausta luo pienen keräilyskaavansa itse ja toimii väliaikaisena syötteenä downstream-laskutukselle.
/readyz kertoo storage-valmiuden ilman Bus Eventsejä ja redaktoi ilmeiset salaisuudet storage-virheistä.

Providerin HTTP-pinta on tarkoituksella kapea:

GET    /api/internal/usage-events
DELETE /api/internal/usage-events
GET    /readyz

Puuttuva bearer-token palauttaa yhteisen Bus API -virhekuoren:

{
  "error": {
    "type": "invalid_auth",
    "message": "missing bearer token"
  }
}

Onnistunut listaus palauttaa sivutetun JSON-vastauksen, jossa usage-rivit ovat items-taulukossa. GET /api/internal/usage-events?page_size=1 näyttää esimerkiksi tämän olennaisen rakenteen:

{
  "items": [
    {
      "event_type": "llm.tokens"
    }
  ],
  "page": 1,
  "page_size": 1,
  "has_more": true
}

Keräilijä voi poistaa onnistuneesti käsitellyn syötteen samalla suodatusmallilla. DELETE /api/internal/usage-events?page_size=1 palauttaa poistettujen rivien määrän:

{
  "deleted": 1
}

Paikallisessa kehityksessä provider käynnistyy ei-salaisilla arvoilla, ja PostgreSQL-osoite annetaan eksplisiittisesti ympäristöstä:

$ BUS_USAGE_JWT_SECRET=dev-secret \
  BUS_USAGE_DATABASE_URL='postgres://bus:bus@127.0.0.1:5432/bus_usage?sslmode=disable' \
  bus-api-provider-usage --addr 127.0.0.1:8080

Jos tietokantaa ei ole määritetty, /readyz kertoo deterministisesti, että usage storage ei ole käytettävissä. Readiness-vastaus on tarkoitettu operaattorin terveysprobeille, joten storage-virheen obvious credential -osat, kuten password=, token=, secret= ja bearer-arvot, redaktoidaan ennen JSON-vastausta. Se pitää readiness-diagnostiikan hyödyllisenä ilman, että virhepolku vuotaa salaisuuksia lokiin tai health-checkin lukijalle.

Raja on tärkeä ero varsinaiseen laskutuksen pysyvään kirjanpitoon: tämä provider tarjoaa keräilysyötteen, ja pitkän aikavälin laskutusrekisteri kuuluu downstream-järjestelmälle.

Providerin nykyinen pinta löytyy bus-api-provider-usagen dokumentaatiosta. Event-pohjaisen pilvi-integraation rajaa voi verrata bus-eventsin ja bus-integration-upcloudin dokumentaatioon.