traversal-processor-charts Helm chart is versioned independently from the Traversal Processor container image (see Container image).
Feature
Startup configuration logging. Each pod logs its effective configuration at startup,
including ports, size-preset tuning, endpoints, TLS and mTLS credential sources, and
configuration source. Credentials are not logged. See
Startup logging.Overridden settings. A startup line lists each setting that differs from its default. See
Overridden settings.Throughput logging improvements. Throughput lines now report rates over the interval since
the previous line, show whether the processor is rejecting data or failing to send it to
Traversal, and are followed by the systems the processor is receiving the most data from. See
Throughput logging.Log level setting. The
traversalProcessor.logLevel value sets the processor’s log level.
The default is info. See Log verbosity.This chart requires processor image 0.8.0 and defaults to it.Feature
Splunk HEC endpoint. The processor accepts Splunk HTTP Event Collector (HEC) requests at
/services/collector on the main ingest port, using Splunk’s batch formats, authentication
forms, and response codes. No values file changes are required. See
Splunk HEC.Compressed OTLP requests. The OTLP gRPC and HTTP endpoints accept gzip-compressed requests,
which the OpenTelemetry Collector and SDKs send by default.Throughput logging. When traversalProcessor.logThroughput is true, each pod logs its
uptime and ingest totals about once a minute. Throughput logging is disabled by default. See
Throughput logging.This chart requires processor image 0.7.2 and defaults to it. With an older image.tag, the
HEC endpoint and OTLP compression are unavailable.Enhancement
The processor receives its configuration more efficiently. No values file changes are required.This chart defaults to processor image
0.7.1.BreakingFeature
Redaction rules move to the processor configuration. This chart removes
traversalProcessor.redaction, including rulesContent and existingConfigMap, and the
ConfigMap the chart rendered from it. Redaction rules are now part of the configuration that
Traversal publishes to the processor, alongside field extraction settings. Rule changes take
effect on the next configuration refresh, without a restart or redeploy.Values files that do not set traversalProcessor.redaction are unaffected.This chart requires processor image 0.7.0 and defaults to it. Earlier images do not read rules
from the processor configuration, so redaction is disabled if you pin an older image.tag. See
Redaction.Feature
Single base domain for Traversal endpoints. The new
baseDomain value sets the domain of all
Traversal endpoints, and the chart derives the ingest, configuration, and telemetry URLs from it.
Explicitly set endpoints override the derived values, so existing values files are unaffected. See
Endpoints.Telemetry follows baseDomain. Ingest and telemetry endpoints are resolved independently, so
setting only the ingest URL leaves telemetry on Traversal’s hosted endpoints. Setting baseDomain
moves all endpoints together.Resolved endpoints in install output. The install output lists the endpoints that the release
resolved. It can also include advisory notes about the values file: missing field configuration, a
missing client certificate, an account ID that is not a UUID, or unrecognized keys, such as typos
or settings from an older values layout.These notes do not cause an install to fail. They describe only the values file: extraEnv and
extraEnvFrom can override what the chart writes, so a deployment configured through those values
can be correct even when a note appears. A values file that does not resolve an ingest endpoint
still fails the install.This chart defaults to processor image 0.6.0.Feature
PEM certificate fields. The new
mtls.certPEM and mtls.keyPEM values accept PEM content
directly, and the chart base64-encodes it. Use them with --set-file to pass certificate files
from disk. The ingest TLS block adds the equivalent tls.certPEM and tls.keyPEM values. See
Client certificate.Install-time validation of certificate encoding. If a base64 field contains PEM content, the
install fails with an error that names the correct field. Previously, the chart rendered without
errors, and the value was later rejected by the Kubernetes API server or caused the processor to
crash on an unreadable certificate.mTLS private key removed from the pod environment. Inline credentials are read from the
mounted Secret, as existingSecret credentials already were. The key is no longer visible to
anyone who can read the pod definition.Operational counters. The processor reports operational counters to Traversal with each
configuration fetch, including ingest volume, request and drop counts, and how recently its
configuration was updated. Reports contain only counters and identifiers, not log content,
keyword values, or configuration values.Existing values files require no changes. certBase64/keyBase64 and certB64/keyB64 are
still supported, and pre-encoded values are used as before. The upgrade restarts the processor
once to apply the new certificate configuration.This chart defaults to processor image 0.6.0.Feature
The processor can now ingest logs from an Amazon SQS queue. This functionality does not require a separate forwarder service. It is off by default — existing deployments are unaffected until you enable it. See Log ingestion from Amazon SQS for configuration details.Memory usage is more predictable if output latency spikes. A slow or briefly unavailable output endpoint now applies backpressure instead of growing the processor’s memory. No values file changes are required.This chart defaults to processor image
0.5.0.Enhancement
More ways to supply mTLS material. In addition to inline base64, you can now point the processor at an existing Kubernetes Secret with
mtls.existingSecret, or at PEM file paths already mounted in the container. Use whichever fits how your cluster manages certificates.Self-reported metrics can egress through a forward proxy. If outbound traffic from your cluster must pass through a proxy, the processor’s own operational metrics can now be routed via that path.Memory stability increased. Internal ingest memory budgets are now effectively adjusted based on the size preset to make memory usage more predictable.Breaking
The chart’s values layout was reorganized. Kubernetes deployment settings (replica count, image, resources, service, probes, scheduling, pod disruption budget) now sit at the top level of the values file, while processor-specific settings stay under the
traversalProcessor key. A few settings were also renamed, consolidated, or removed in the cleanup — for example, log ingestion is now configured through a single traversalProcessor.traversalIngestion.endpoint.Traversal builds and pre-populates your values file, so most deployments need no action. If you maintain your own overrides, re-check them against the updated values.yaml (helm pull … --untar) or the setup guide — some field names and locations have moved.Security
Client certificate material is now mounted from a Kubernetes Secret as a read-only file instead of being injected as a literal pod environment variable. No values file changes are required to pick up this fix. The same
mtls.certBase64/keyBase64 fields you already set are now delivered more securely under the hood.All customers should migrate to processorIngestion.endpoint going forward. It authenticates with the same mtls certificate as everything else.Metrics reporting is now on by default. The processor reports its own operational metrics to Traversal automatically; no configuration is required.