feat(log-input): add HTTP ingest endpoint - #2466
Merged
Merged
Conversation
Adds POST /v1/ingest as an HTTP transport for log ingestion alongside the existing gRPC endpoint, sharing the same auth logic and NATS publisher through a small middleware refactor.
🛑 AI review — Sensitive area, extra care recommendedThis PR touches critical paths or introduces changes the model cannot judge with sufficient confidence. Review carefully before merging. ✅
|
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
1 participant
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.
A detailed explanation.
Adds
POST /v1/ingestas an HTTP transport for log ingestion on port:50052, alongside the existing gRPC endpoint. Both transports now share the same authentication logic and NATS publisher.Body accepts a single log or a batch (
{"logs": [...]}, up to 1000 entries, max 10 MB). Response is200 {accepted, failed}on success,401on missing/invalid credentials,413on oversized body, and503when NATS is unavailable. Tenant is always derived from the credential, never from the request body.Authentication headers accepted:
Utm-Api-Key(Enterprise API keys, priority)X-Connector-Key+X-Connector-Id+X-Connector-Type(existing agent/collector credentials)The gRPC middleware was refactored to share a transport-agnostic
resolveAuthfunction with the HTTP handler, so authentication logic lives in one place.The reasoning behind these changes.
Customers who want to push events from external systems (webhooks, custom apps, third-party integrations.) currently need to write a gRPC client to talk to log-input. Adding an HTTP endpoint removes that integration barrier without changing anything about how agents, collectors, or forwarders work today.
A reference to the issue that this pull request addresses.
N/A