Falcon LogScale Collector 1.9.1 GA (2025-05-20)

Version?Type?Release Date?Config.Changes?
1.9.1GA2025-05-20no

Hide file hashes

Show file hashes

Highlights Various bug fixes and improvements

Improvements, new features and functionality

  • Collecting Data

    • Various performance and reliability improvements have been implemented in disk queue handling. Although not yet encountered, earlier analysis suggested that corrupt data in disk queues could stop queue processing and data ingest.

      A new recovery mechanism has been proactively added to ensure continuous queue processing in scenarios where corrupt data is encountered. Corrupt entries are now archived to compressed dead-letter files with timestamp-based naming (deadletter-YYYYMMDDTHHMMSSZ-XXXX.gz). Warning notifications are logged every five minutes while dead-letter files are present.

    • Performance when draining queues by sending batches to Falcon LogScale Collector/NG-SIEM has been improved. The batch bundling efficiency has been improved while maintaining configured limits. This improves throughput and reduces overhead in high-volume event scenarios with disk queues.

  • Debugging

    • Improved internal logging for better traceability. For example disk queue, and Windows event source actions.

  • Other

    • To take advantage of the latest optimisations and security updates the Go version has been updated.

Bug Fixes

  • Collecting Data

    • A scenario has been identified in which customers collecting Windows Events from Forwarded Events on pre-Windows Server 2016 systems might experience Log Collector crashes when processing these events. The issue has been seen in environments with mixed Windows versions where older systems forward events to newer collectors.

      The core issue involves compatibility problems when parsing forwarded events due to version mismatches between event templates.

      While Windows Server 2016 and later versions resolve this through the RenderingInfo XML element (which includes pre-formatted messages), earlier versions relied on FormatMessage() calls, that have proven to be potentially unsafe and might cause crashes.

      If this issue is encountered, it is possible to use a new configuration option (disableFormatMessage: true) in the channel configuration. When enabled, this option prevents the use of FormatMessage() for rendering event messages, ensuring system stability but at the cost of not displaying complete message details for events from legacy systems.

  • Debugging

    • The internal metric sink time to send was not calculated correctly. This has been fixed.

    • On Windows, the interactive monitor had a visual issue where debug messages would flood the screen when the mouse cursor was moved over the terminal. This has been fixed.

  • Other

    • The syslog TCP source potentially did not honour configured limits for maxBatchSize. This could cause a scenario in which a queue could stop sending events to the configured sink, effectively stopping ingestion for all sources configured to use this sink. This has been fixed.

    • Fixed an issue with a potential counter overflow in disk queue storage. The specific scenario which could cause this issue would only occur when there were more than four billion events.

  • Fleet Management

    • Fixed OS Version for Windows Server 2016/2019.

      A System string describing the operating system on the host is displayed in Fleet Overview. For Windows systems the string consists of <ProductName> (<DisplayVersion>) (<Architecture>) . For example, Windows 10 Enterprise (21H2) (amd64).

      On older Windows versions, the Falcon LogScale Collector failed to fetch the DisplayVersion and reported the fallback string Windows (amd64). This is now corrected and the string will consist of ProductName and architecture. For example, Windows Server 2016 (amd64).

      Note that the displayed ProductName relies on the internal productname reported by Windows. Some Windows 11 versions identify with ProductName Windows 10.

      Important

      If the groups functionality has been used to define a group based on the system string, and this group relies on the old incorrect string, for example: filter: system= windows* the filter must be updated to system= windows* or system=Windows* in order to match the new corrected system string.

      If not, the machines affected (Windows Server 2016 and 2019) will fall out of their group, leaving them without a config. These machines will then stop ingesting data.

  • Installation and Deployment

    • Fixed an issue where non-default umask settings during installation could cause the configuration file to be unreadable by the service user. This would prevent the Log Collector from starting.

      In this scenario, the following would be logged on the host:

      systemd[1]: The configuration file could not be read. Trying to read file /etc/logscale-collector/config.yaml.

      systemd[1]: The underlying problem was: open/etc/logscale-collector/config.yaml: permission denied.

    • Corrected permission bit handling for systemd service files in Linux installation scripts.

      Previously, installing Falcon LogScale Collector on Linux could cause warnings to be reported on the host. For example:

      systemd[1]: Configuration file /usr/lib/systemd/system/logscale-collector.service is marked executable. Please remove executable permission parts. Proceeding anyway.

Known Issues

  • Collecting Data

    • When using the onlyEventIDs parameter with the xmlOnly option, a maximum of ~20 event IDs can be specified. This is because, when xmlOnly is used, Log Collector requires the channel subscription to be purely XML-based, and XML queries have a limit of 32 statements. This issue is resolved in Falcon LogScale Collector version 1.11.0.