Notifications
Clear all
Topic starter
18/08/2026 2:23 pm
TL;DR: OpenTelemetry-based collectors can normalize otherwise awkward log sources, trim noisy systemd fields, and route the same records to multiple destinations during platform transitions, according to Bindplane's journald example. For identity and security teams, the key lesson is that ingestion design affects queryability, retention cost, and the reliability of audit data.
NHIMG editorial — based on content published by Bindplane: Part 2 of 2, Additional Sources and Destinations
Questions worth separating out
Q: How should teams design log pipelines for migration between security platforms?
A: Teams should normalise events before they split into destinations, then compare search results and field mappings in parallel.
Q: Why does log field trimming matter for security operations?
A: Field trimming matters because it improves search consistency, reduces indexing waste, and keeps high-value evidence available for detection and investigation.
Q: What breaks when collectors re-ingest historical logs on rollout?
A: Re-ingestion can duplicate large volumes of data, inflate storage costs, and create confusing search timelines that look like real activity.
Practitioner guidance
- Define a canonical security log schema Keep only the fields your SOC, IAM, and audit workflows actually query, and drop source-specific noise before indexing.
- Validate source start settings before rollout Use tailing behaviour for production collectors unless you explicitly need historical backfill, because starting at the beginning can re-ingest large volumes of existing data.
- Test migration parity across both destinations Compare search results, field mappings, and retention behaviour in parallel logging platforms before cutover, so semantic differences surface while both pipelines are still live.
What's in the full article
Bindplane's full post covers the implementation detail this analysis intentionally leaves at the architecture level:
- Exact Journald source settings and rollout steps for live collector deployment
- The transform expression used to rebuild records into a five-field schema
- Side-by-side examples of how the same events appear in Splunk and Google Cloud Logging
- Operational guidance for using the pipeline during a platform migration or dual-write transition
👉 Read Bindplane's walkthrough of Journald collection and dual-destination routing →
Journald routing and field trimming: what IAM teams should notice?
Explore further
18/08/2026 3:14 pm
Log normalisation is now a governance issue, not just an ingestion issue. Once logs feed audit, detection, and identity investigations, field design becomes part of security control quality. If service account activity, privilege changes, or admin actions are embedded in inconsistent schemas, teams cannot trust the evidence chain. The practical conclusion is that telemetry pipelines need governance, not just transport reliability.
A question worth separating out:
Q: How do security teams know a logging migration is actually working?
A: They should test whether the same events produce the same searchable fields, the same retention behaviour, and the same investigation outcomes in both platforms. If analysts need different queries to reach equivalent conclusions, the migration is not complete. Delivery success is not enough; semantic parity is the real control.
👉 Read our full editorial: Bindplane journald routing shows why log pipelines need normalization
