feat(collector): implement customer upsert functionality in OpenMeter collector#39
Open
eliteprox wants to merge 1 commit into
Open
feat(collector): implement customer upsert functionality in OpenMeter collector#39eliteprox wants to merge 1 commit into
eliteprox wants to merge 1 commit into
Conversation
…llector Added a local Go provision sidecar to handle idempotent customer upsert requests. Updated Dockerfile and entrypoint script to support the new provision server. Enhanced the collector's configuration to include the OPENMETER_DEFAULT_PLAN_KEY environment variable and updated the collector's pipeline to ensure customer creation before event ingestion.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The collector previously assumed customers already existed in Konnect/OpenMeter before events arrived. If a
create_signed_ticketevent reached the collector before the customer was provisioned (e.g. identity webhook race, cold start, or new deployment), ingest would fail silently with a "no customer found for event subject" error. There was also a gap wherebillable_usd_microswas never emitted to the billing meters.Solution
Add a lightweight Go provision sidecar that runs co-located with the Benthos collector inside the same container. Before each event is ingested, the sidecar idempotently ensures the corresponding Konnect customer and subscription exist. If ingest still fails, the collector self-heals by ensuring again and retrying once.
Presumptions
Changes
New:
deploy/openmeter-collector/provision/— Go provision sidecarPOST /ensure(andGET /health) on127.0.0.1:8091client_id+external_user_id(orauth_idinclientID:externalUserIDcolon-split form) from flexible key aliases in both top-level fields and a nesteddatamapsubjectKeyfor usage attribution) and subscribes it toOPENMETER_DEFAULT_PLAN_KEY— resolves the latest active plan version automaticallysdk-konnect-gowith the samekpat_…PAT already required by the collector; the identity webhook no longer needs OpenMeter credentialsUpdated:
Dockerfile— multi-stage buildCGO_ENABLED=0, trimpath, stripped)alpine:3.21with the benthos binary, sidecar, and config copied inHEALTHCHECKagainst127.0.0.1:8091/healthNew:
entrypoint.shtrap-based cleanup on exit/signal/healthup to 30 × 0.2 s before launching Benthos, ensuring the sidecar is ready before any events are processedUpdated:
collector.yamlbillable_usd_microsto the CloudEvent mapping (initially equal tonetwork_fee_usd_micros)branchprocessor before ingest that calls/ensurewith the event's identity fields (CloudEvent body is preserved viaresult_map: "")http_clientoutput with afallback: primary ingest attempt → on failure, ensure again + retry onceUpdated:
docker-compose.yml/deploy/README.mdOPENMETER_DEFAULT_PLAN_KEYthrough compose (default:clearinghouse_default_ppu)Architecture note
The collector holds the only OpenMeter admin credentials (
kpat_…). The identity webhook, clearinghouse API, and any future caller talk to OpenMeter through the collector's sidecar (or, eventually, a dedicated billing-gateway). This keeps credential scope narrow and makes the event pipeline self-healing without adding a hard boot-time dependency on external provisioning state.