Falcon LogScale Collector 1.12.0 GA (2026-10-12)

Version?Type?Release Date?Config.Changes?
1.12.0GA2026-10-12no

Hide file hashes

Show file hashes

Highlights

  • Log Collector 1.12.0 introduces the new file_snapshot source for ingesting static files, along with a regex_redact transform to mask sensitive log data before transmission.

    Configuring file_snapshot or regex_redact through Fleet Management requires LogScale 1.261 or later. Local configuration files support both features immediately.

  • Key reliability updates include remote fleet configuration caching for offline startups, and bug fixes for the database source, among others.

  • Optimizations and security updates.

Improvements, new features and functionality

  • Collecting Data

    • A new metadata field @collect.timezone_offset disambiguates timezone abbreviations such as CST, which could mean any of the following:

      • China Standard Time (UTC+8:00)

      • Central Standard Time, North America (UTC-6:00)

      • Cuba Standard Time (UTC-5:00)

      Use this field in LogScale queries with parseTimestamp() or findTimestamp() through the timezoneField argument.

    • The new file_snapshot source handles files written once, as opposed to log files that grow continuously. The file_snapshot source waits for a file to stop changing, reads it from start to end, ingests the complete file, and marks the file as ingested to avoid duplication. Examples of applicable file types include scheduled exports, database dumps, audit extracts, and SAP audit logs.

      The source supports several parsing modes depending on file type:

      • line

      • csv

      • sap

      The preambleLines option can discard a fixed number of leading lines before parsing begins if required (default 0). Use this for export headers or banner text. The collector applies it before reading the CSV header line.

      Configuring file_snapshot through Fleet Management requires LogScale 1.261 or later. Local configuration files support it immediately.

    • A new regex_redact filter transform redacts sensitive data. The regex_redact transform replaces text matching a configured pattern with a repeated single character. Use this when logs are operationally necessary but must not carry sensitive data off the host. For example, healthcare providers can strip patient identifiers before logs leave the hospital network. Payment processors can keep cardholder data out of their log platform.

      Key behaviors of the regex_redact transform include:

      • The transform masks every match on an event.

      • The event keeps its original length and structure, so existing parsers and dashboards continue to work unchanged.

      • The transform supports submatches. Redact a captured group instead of the whole match.

      • Without a capture group, the transform masks the whole match.

      • Capture groups work as an either/or choice. When pattern contains one or more groups, the transform masks only the groups. The rest of the match remains unchanged.

      • A pattern may contain several capture groups. The transform masks each one.

      Example without a capture group — the transform masks the entire match: 

      transforms:
- type: regex_redact
  pattern: 'mrn=\S+'

before: admit mrn=MR0092831 ward=4B status=stable
after:  admit ************* ward=4B status=stable

      Example with capture groups — the transform masks only the captured text. This keeps field names readable, showing which values the transform redacted: 

      transforms:
- type: regex_redact
  pattern: 'dob=(\S+) mrn=(\S+)'

before: patient dob=1974-03-11 mrn=MR0092831 ward=4B
after:  patient dob=********** mrn=********* ward=4B

      Configuring regex_redact through Fleet Management requires LogScale 1.261 or later. Local configuration files support it immediately.

  • Debugging

    • For the Journald source: when a journal read fails with EBADMSG, the collector logs a warning. The warning includes the text "journal cursor at corrupted entry" and the journal cursor of the corrupt entry. This allows you to locate the affected region using journalctl --after-cursor.

  • Other

    • This release updates the Go version that builds Log Collector to take advantage of the latest optimizations and security updates.

    • This release prepares Log Collector for an updated configuration file format planned for a future release. When the new format arrives, this version will read it, ensuring smooth upgrades and rollbacks between versions. You need take no action at this time.

  • Fleet Management

    • The collector now caches the remote Fleet Management configuration and applies it at startup, until the latest configuration from Fleet Management supersedes it. This allows a collector that cannot reach Fleet Management at start-up to start with its last known configuration.

      When the collector applies the cached configuration, it logs the SHA and byte length.

Bug Fixes

  • Collecting Data

    • Fixed an issue that could cause database sources to accumulate abandoned sessions on the database server after errors or configuration changes. Each database source opens a connection to the database server and holds it for as long as the source runs. In some cases the source did not close this connection when it stopped, leaving the session established on the server. The next start opened a new connection, and unused sessions would accumulate until the collector process itself restarted.

      Two situations could trigger this issue:

      • A source failure, such as an error communicating with the database.

      • A configuration update, reloading a local configuration file or publishing a new configuration through Fleet Management.

      The Oracle source demonstrates this issue. Oracle caps the number of sessions per user server-side, and once that cap was reached the source stopped collecting and Log Collector would log the following error: "ORA-02391: exceeded simultaneous SESSIONS_PER_USER limit".

    • On macOS, creating a disk queue could fail on fragmented volumes. The error was "no space left on device", even when ample free space existed. This occurred because the collector preallocated the storage file as a single contiguous region.

      The collector now falls back to a non-contiguous allocation of the same size, so it can create disk queues on fragmented volumes. Linux and Windows did not encounter this issue.

    • The collector now ships events from the Windows ForwardedEvents channel with human-readable messages. Previously the collector tried to resolve messages using provider metadata on the collector host. This metadata is usually absent for events forwarded from other machines. Those events arrived with missing or unresolved descriptions.

      The collector now uses the rendering information that forwarded events carry from their originating host. When no rendering information exists, the collector formats messages without local provider metadata.

    • A syslog (TCP) or (TLS) source source configured with a receiveBufferSize smaller than or equal to its maxEventSize could stop processing data. Specifically, this can happen on a connection when a single message arrived that was larger than the receive buffer. In this scenario the connection could stall and stop delivering events until you closed and re-established it.

      The following conditions applied to this issue:

      • Only sources that explicitly set receiveBufferSize to a value at or below maxEventSize encountered this issue.

      • Default configurations never encountered this issue.

      • UDP syslog sources did not encounter this issue.

      The collector now caps the effective maxEventSize at receiveBufferSize. When the collector applies the cap, it logs a warning as the source starts: "Clamping maxEventSize to receiveBufferSize to prevent read-loop stall". The collector truncates oversized messages to the effective limit. This matches the collector's existing behavior for messages that exceed maxEventSize. The connection continues processing subsequent messages.

    • When a Windows event contains several EventData entries that share the same Name, the collector now preserves every value. For example, this applies to arrays in the event template. The first entry keeps the plain field name (windows.EventData.<Name>). Each repeat gets an index suffix (windows.EventData.<Name>[1], [2], and so on). Previously all repeats collapsed into one field and only one arbitrary value survived.