Skip to main content

Agent 0.5.58 (Oct 2026)

New Features​

Destinations​

Azure Blob Storage destination​

A new Azure Blob Storage destination archives logs, metrics, and traces to an Azure Storage container as OTLP JSON or protobuf files, optionally gzip- or zstd-compressed.

  • Authentication is configured once in a reusable Azure Blob Storage credential, so the destination itself holds no secrets. Five methods are supported: connection string (account key or SAS), service principal, system-assigned managed identity, user-assigned managed identity, and workload identity.
  • Microsoft Entra ID methods need the Storage Blob Data Contributor role on the container or storage account.
  • The container must already exist — the destination does not create it.
  • Files are written under time-partitioned folders (year=/month=/day=/hour=/minute=) and each batch becomes its own blob.
  • Requires Praxis Collector v0.5.42 or later.

See Azure Blob Storage destination for setup steps and the output layout.

Azure Monitor destination​

A new Azure Monitor destination sends logs, metrics, and traces to Azure Monitor Application Insights, where they can be queried in the standard Application Insights tables.

  • Authentication: the Application Insights connection string, stored in a Connection String credential. Copy the full string from the resource's Overview page, including IngestionEndpoint.
  • Where data lands: logs → traces (or exceptions / customEvents when those options are enabled), spans → requests and dependencies, metrics → customMetrics.
  • Microsoft Entra ID authentication is not supported, so Application Insights resources with local authentication disabled will reject the data.
  • A disk-backed queue is enabled by default so data buffered during an outage survives a collector restart.
  • Requires Praxis Collector v0.5.50 or later.

See Azure Monitor for setup steps and example KQL queries.

Processors​

Translate log bodies with a self-hosted LibreTranslate​

A new translate processor translates string log bodies through a self-hosted LibreTranslate instance, so non-English log streams arrive in your SIEM and detection content already readable.

Translation is a network round trip per line, so the processor is built around caching. Before hashing a body it masks out the parts that change between otherwise-identical lines and restores them verbatim afterwards. Two lines that differ only in their timestamp therefore share one cache entry and one upstream call, and each still keeps its own timestamp.

The built-in mask rules are deliberately few — slash-separated dates, RFC3164 syslog dates, UUIDs and email addresses. Those are the spans a translation model was measured to actually damage. Spans it copies through intact (ISO8601 timestamps, IPs, 0x identifiers, bare clocks, epoch integers) are left alone: a rule that never saves anything still costs a placeholder, and an unanchored one costs correctness.

Minimal configuration:

processors:
  translate:
    endpoint: http://libretranslate:5000
    source_lang: de
    target_lang: en

The processor never drops a record and never fails a batch. If LibreTranslate is slow, unreachable or returns something unusable, the affected records keep their original body and the failure is counted. The original text is preserved on the translate.original attribute by default, and only on records that were actually translated.

Tunables include cache_size, max_batch_size, max_text_bytes, max_concurrent_requests, timeout, and a masking block for adding your own volatile-span patterns (IPv6, MAC addresses, internal hostnames, or any built-in you want back) or disabling built-in ones. Logs only; source_lang must be an explicit language, not auto.

Sources​

Azure Blob Storage source​

A new Azure Blob Storage source reads logs from blobs in an Azure Storage container, including Azure diagnostic-log archives and files written by the Azure Blob Storage destination.

  • Discovery: the source polls the container every 60 seconds by default. Attach an optional Event Hub connection string (it must include EntityPath) to switch to Azure Event Grid BlobCreated notifications instead.
  • Authentication: an Azure Blob Storage credential — connection string, service principal, system-assigned or user-assigned managed identity, or workload identity. Microsoft Entra ID methods need the Storage Blob Data Reader role, or Storage Blob Data Contributor if you enable deleting blobs after reading.
  • Formats: OTLP JSON (default), OTLP protobuf, JSON records (use this for Azure diagnostic PT1H.json archives), JSON array, and plain text, with gzip and zstd blobs decompressed automatically.
  • Blobs stay in place by default. The read position is saved on disk so a restart resumes where it stopped; delivery is at-least-once, so some blobs can be read again after a restart.
  • On large containers, set a Blob Prefix — every poll lists all blobs under the prefix. For diagnostic archives that are still being appended to, set Settle For so a blob is read only after it stops changing.
  • Logs only.

See Azure Blob Storage source for setup steps.

Azure Event Hub source​

A new Azure Event Hub source ingests logs from an Azure event hub into your pipelines — Azure Monitor diagnostic logs streamed to the hub are parsed into individual log records, and any other payload can be passed through as-is.

  • Authentication: an Event Hub connection string from a shared access policy with the Listen claim (it must include EntityPath), or an Azure Auth credential (service principal, managed identity, workload identity) with the Azure Event Hubs Data Receiver role on the event hub.
  • Formats: azure unpacks Azure Monitor diagnostic-log envelopes into one log record per entry; raw keeps each event body unchanged.
  • Resume after restart: the read position is saved per partition. On its very first start the source reads only new events, not the hub's retained backlog.
  • Consumer groups: use a consumer group dedicated to Praxis, and run each pipeline on a single collector — every collector reading the same hub receives every event.
  • Logs only. Requires Praxis Collector v0.5.49 or later.

See Azure Event Hub for setup steps.

Enhancements​

Destinations​

Microsoft Sentinel destination uses Azure Auth credentials​

The Microsoft Sentinel destination now authenticates through a reusable Azure Auth credential instead of authentication fields on the destination, so the same Microsoft Entra ID identity can be shared across Azure integrations and no secret is stored on the node.

  • Supported methods: service principal (client secret), system-assigned managed identity, user-assigned managed identity, workload identity, and the default Azure credential chain.
  • The identity needs the Monitoring Metrics Publisher role on the Data Collection Rule. Role assignments can take up to 30 minutes to take effect.
  • Existing Sentinel destinations keep working without changes. Editing one now requires selecting an Azure Auth credential.
  • Requires Praxis Collector v0.5.46 or later.

See Microsoft Sentinel for setup steps.

Packaging & Deployment​

Upstream OpenTelemetry Collector updated to v0.162.0​

The collector now builds on OpenTelemetry Collector core and contrib v0.162.0, which resolves HTTP keepalive settings through the keepalive block by default, makes exporter queue batch partitioning configurable, and changes several component defaults.

  • Core collector modules move from v0.161.0 to v0.162.0 (stable modules v1.67.0 to v1.68.0), and all contrib components move from v0.161.0 to v0.162.0.
  • The keepalive block is now the form HTTP keepalive settings resolve through, rather than the deprecated flat keys: idle_conn_timeout, max_idle_conns, max_idle_conns_per_host and disable_keep_alives on clients, idle_timeout and keep_alives_enabled on servers. Existing configurations using the flat keys keep working and keep their effective values, but now log a deprecation warning; mixing the two forms in one block is still rejected at startup. Upstream governs this with the new pkg.confighttp.PrioritizeNewKeepalive feature gate, enabled by default and not togglable here.
  • How long an empty exporter queue batch partition is kept before removal is now an explicit setting, sending_queue::batch::partition::idle_timeout, defaulting to 90s. It was previously derived as ten flush-timeout cycles, which came to 2s at the default 200ms flush_timeout, so idle partitions are now retained substantially longer. This only affects exporters using partition::metadata_keys, where it shows up as higher steady-state memory.
  • The cap on active partition batchers is now configurable as sending_queue::batch::partition::cache_size and must be positive. The default of 10000 matches the previous fixed limit. Current size and capacity are reported as otelcol_exporter_queue_batch_partition_cache_size and otelcol_exporter_queue_batch_partition_cache_capacity.
  • When a batch is split and a single item exceeds the maximum size, only that item is dropped instead of every item queued behind it. Applies to logs for now.
  • The memory limiter extension reports refused network requests as otelcol_memorylimiter_refused_requests.
  • The OTLP receiver preserves the HTTP status code when a request carries a Content-Type it cannot encode a status into, so client errors such as 401 from a server auth extension are no longer reported as 500.
  • The signaltometrics connector now defaults to an ignore error mode instead of propagate, so a failure building one metric no longer drops the whole payload. Set error_mode: propagate to keep the old behaviour.
  • The elasticsearch exporter drops the removed flush and num_workers settings; a configuration still setting either now fails to load with has invalid keys: ... use sending_queue instead. Migrate num_workers to sending_queue::num_consumers, flush::interval to sending_queue::batch::flush_timeout, and flush::bytes to sending_queue::batch::max_size with sending_queue::batch::sizer set to bytes. In otel mapping mode it also writes profiling signals to OTel-native datastreams that require Elasticsearch 9.6.0 or later; on older clusters restrict the exporter with mapping.allowed_modes: [ecs] to avoid index_not_found_exception and data loss.
  • Prometheus label sanitization is now permissive: a label starting with a single underscore, such as _foo, is no longer prefixed with key_. This affects the Prometheus receivers and the Prometheus remote write exporter. Upstream gates this behaviour behind a feature gate, but the collector does not expose a way to set feature gates, so the new naming applies unconditionally. Dashboards or alerts matching the old key__foo form need updating.
  • The Prometheus receiver no longer reads scope attributes from otel_scope_info, which is now converted like any other metric; scope attributes come from otel_scope_-prefixed labels instead. This is no longer optional, and the setting that controlled it is removed upstream in v0.164.0.
  • The kafkametrics receiver now honours metadata::retry::max, whose default moves from 3 to 20 to match the value the receiver has effectively been using. Only configurations that set it explicitly change behaviour. Its metadata::full setting is deprecated and has no effect.
  • The kubeletstats receiver deprecates the k8s.pod.cpu.node.utilization, k8s.pod.memory.node.utilization, k8s.container.cpu.node.utilization and k8s.container.memory.node.utilization metrics, following the Kubernetes semantic conventions SIG. They will be removed in a future release.
  • Upstream removed several feature gates that had reached stable (processor.transform.defaultErrorModeIgnore, ottl.PanicDuplicateName, ottl.contexts.enableOTelColContext) and promoted others to stable. The collector accepts no --feature-gates option, so none of these were settable and their removal changes nothing here; the behaviour each one guarded is now the only behaviour.
  • No configuration changes are required unless a setting listed above is set explicitly.