0.55 Upgrade Guide

Vector breaking changes

1. Observability API migrated from GraphQL to gRPC
2. headers option removed from http and opentelemetry sinks
3. azure_logs_ingestion sink requires explicit azure_credential_kind

Vector upgrade guide

Observability API migrated from GraphQL to gRPC

Vector’s observability API has been rewritten from GraphQL to gRPC. The following HTTP endpoints have been removed:

• /graphql (HTTP POST queries and WebSocket subscriptions)
• /playground (the GraphQL Playground)

The HTTP GET /health endpoint is unchanged and continues to serve Kubernetes HTTP liveness/readiness probes as before.

Vector will now reject configs that contain api.graphql or api.playground.

The gRPC service definition is available at proto/vector/observability.proto. A standard gRPC Health Checking Protocol service (grpc.health.v1.Health) is also exposed for tooling that prefers gRPC probes, such as grpc-health-probe or native Kubernetes gRPC probes.

Note: vector top and vector tap from version 0.55.0 or later are not compatible with Vector instances running earlier versions.

Action needed

1. Please remove the api.graphql and api.playground fields from your Vector configuration.

2. If you invoke vector top or vector tap with an explicit --url, please drop the /graphql suffix:

   # Old
   vector top --url http://localhost:8686/graphql
   
   # New (the gRPC API listens at the root)
   vector top --url http://localhost:8686
   

3. If you interact with the API from external tooling, please migrate to the gRPC service. For example, using grpcurl:

   # Check health (standard gRPC health check)
   grpcurl -plaintext localhost:8686 grpc.health.v1.Health/Check
   
   # List components
   grpcurl -plaintext localhost:8686 vector.observability.v1.ObservabilityService/GetComponents
   
   # Stream events (tap). Note: limit and interval_ms are required and must be >= 1
   grpcurl -plaintext \
     -d '{"outputs_patterns": ["*"], "limit": 100, "interval_ms": 500}' \
     localhost:8686 vector.observability.v1.ObservabilityService/StreamOutputEvents
   

headers option removed from http and opentelemetry sinks

The top-level headers option on the http and opentelemetry sinks has been removed. It was deprecated in v0.33.0 in favor of request.headers.

Action needed

Please move any headers values under request.headers. The exact location differs between the two sinks.

For the http sink, request lives at the sink root:

# Old
sinks:
  my_http:
    type: http
    uri: https://example.com
    headers:
      X-Custom-Header: value

# New
sinks:
  my_http:
    type: http
    uri: https://example.com
    request:
      headers:
        X-Custom-Header: value

For the opentelemetry sink, request lives under the protocol block (because the sink wraps its transport under protocol:):

# Old
sinks:
  my_otel:
    type: opentelemetry
    protocol:
      type: http
      uri: http://localhost:5318/v1/logs
      headers:
        X-Custom-Header: value

# New
sinks:
  my_otel:
    type: opentelemetry
    protocol:
      type: http
      uri: http://localhost:5318/v1/logs
      request:
        headers:
          X-Custom-Header: value

Note: placing request at the opentelemetry sink root will not error, but the headers will be silently ignored. Please place request under protocol.

azure_logs_ingestion sink requires explicit azure_credential_kind

The azure_logs_ingestion sink (introduced in 0.54.0) previously used client_secret_credential as the implicit default when Client Secret credentials were provided. That implicit default has been removed; azure_credential_kind must now be set explicitly.

Action needed

If you are using azure_logs_ingestion with Client Secret credentials, please add azure_credential_kind: client_secret_credential under the sink’s auth block (alongside azure_tenant_id, azure_client_id, and azure_client_secret):

sinks:
  my_azure_logs:
    type: azure_logs_ingestion
    # ... remaining config
    auth:
      azure_credential_kind: client_secret_credential
      azure_tenant_id: "<tenant-id>"
      azure_client_id: "<client-id>"
      azure_client_secret: "<client-secret>"