Vector v0.58.0 release notes

The azure_blob sink now supports a tags option, which sets blob index tags (x-ms-tags) on every created blob (parity with the tags option on the aws_s3 sink).

The azure_blob sink now supports a metadata option, which sets custom blob metadata (x-ms-meta-*) on every created blob (parity with the metadata option on the gcp_cloud_storage sink).

Added an optional tls_handshake_timeout_secs setting to the socket (TCP mode), syslog (TCP mode), logstash, fluent, and statsd (TCP mode) sources. When set, a TLS-enabled connection that does not complete its TLS handshake within the configured number of seconds is closed.

Previously, TLS handshakes on these sources had no timeout: a client that opened a TCP connection and never completed (or never started) the TLS handshake would hold its slot against connection_limit indefinitely, since neither TCP keepalive nor max_connection_duration_secs are evaluated until after the handshake succeeds. This could let misbehaving or unresponsive clients gradually exhaust the connection limit and block legitimate traffic. The new setting is unset by default, preserving prior behavior.

The kubernetes_logs source now supports truncating oversized merged log lines instead of dropping them. A new max_merged_line_action configuration option allows choosing between drop (default, existing behavior) and truncate. When truncation is enabled, lines exceeding max_merged_line_bytes are truncated to the limit with a ..TRUNCATED suffix appended.

In drop mode, max_line_bytes is capped to max_merged_line_bytes to avoid wasted I/O. In truncate mode, individual lines up to max_line_bytes are allowed through so the merger can truncate the combined result. Note that max_line_bytes still applies at the file level and always drops individual lines exceeding it; file-level truncation is not yet supported.

Fixed a deadlock in metric sinks that use a disk buffer where the sink would permanently stall after 10-15 minutes of operation. Affected sinks include prometheus_remote_write, datadog_metrics, influxdb_metrics, aws_cloudwatch_metrics, gcp_stackdriver_metrics, appsignal, sematext, statsd, and greptimedb.

Additionally fixed a panic when expire_metrics_secs: 0 was set.

Fixed the OTLP decoder adding an extra timestamp field to trace events when log_namespace was set to legacy. Trace events don’t have a timestamp field in their schema, so this field showed up unexpectedly:

// Before
{
  "trace_id": "...",
  "span_id": "...",
  "name": "test_span",
  "timestamp": "2026-08-06T12:00:00Z"
}

// After
{
  "trace_id": "...",
  "span_id": "...",
  "name": "test_span"
}

vector validate --no-environment now catches sink confinement issues that previously only surfaced when Vector booted.

For example, a Kafka sink with an unconfined topic template:

sinks:
  kafka_out:
    type: kafka
    inputs: [logs]
    bootstrap_servers: "localhost:9092"
    topic: "{{ topic }}"
    encoding:
      codec: json

previously passed vector validate --no-environment and only failed with a full vector validate or when running the config. It now fails validation with a confinement error due to topic having no confinement base.

sinks:
  kafka_out:
    type: kafka
    inputs: [logs]
    bootstrap_servers: "localhost:9092"
    topic: "events-{{ topic }}"
    encoding:
      codec: json

Improve configuration error messages by including the affected field path. For example, this invalid configuration:

sources:
  broken:
    type: demo_logs
    interval: not-a-number

now reports sources.broken: invalid type: string "not-a-number", expected f64.

The kubernetes_logs source now falls back to extracting pod metadata from the log file path when the pod is not found in the Kubernetes API store. Previously, if the pod was deleted before Vector could look it up, the event was sent downstream with no kubernetes metadata at all, causing errors in downstream transforms that expect fields like pod_namespace to be present.

On this fallback path, Vector still populates pod_name, pod_namespace, and container_name. The path segment that is usually a Pod UID is exposed as pod_log_directory_id (not pod_uid), because for static pods it can be a config hash instead of the API Pod UID. Users who want UID semantics can remap the field.