Falcon LogScale Collector 1.11.0 GA (2026-01-27)

Version?Type?Release Date?Config.Changes?
1.11.0GA2026-01-27no

Hide file hashes

Show file hashes

Bug fixes and updates

Improvements, new features and functionality

  • Summary

    • The Log Collector now supports databases as source for ingest.

      FIPS support has been improved.

  • Collecting Data

    • The file source has support for joining consecutive lines together to create multiline events by using a regular expression. Previously it was possible to configure a pattern to look for the beginning (multiLineBeginsWith) or the continuation (multiLineContinuesWith) of multiline events. Starting with the 1.11.0 release, it is possible to configure a pattern for the end of a multiline event (multiLineEndsWith). This addresses a use-case in Kubernetes where events are prefixed with a P (partial) or F (full).

      For example: 

      <timestamp> stdout P the first part of the message
<timestamp> stdout P the second part of the message
<timestamp> stdout F the remainder of the message

    • A new database source type has been added, enabling data ingestion into NG-SIEM/LogScale directly from a database. The source schedules SQL queries, generates events from the results, buffers, and ingests these events. Using a mandatory ID column, ingested events are checkpointed. Users can configure columns from the result set to populate the rawstring and optional fields.

      The following database types are supported:

      • MySQL

      • PostgreSQL

      • Oracle

      • MS SQL Server

    • The Windows event log source allows for filtering by individual eventsIDs using the excludeEventIDs or onlyEventIDs parameters. When previously using the xmlOnly output format, the Windows event log source supported a maximum of approximately 20 individual event IDs per channel (inclusion via onlyEventIDs or exclusion via excludeEventIDs). The xmlOnly format now supports an unlimited number of individual event IDs for inclusion or exclusion, aligning with the other available output formats (renderFieldsOnly, renderFieldsWithXML, and xmlWithMessage).

  • Other

    • Various improvements have been implemented to improve stability and harden the security posture.

      • HTTP redirects have been disabled, this prevents automatic redirect following - The HTTP client will NOT automatically follow any 3xx redirect responses. Instead of following redirects, the client returns the redirect response itself (with status codes like 301, 302, 307, etc.).

      • Additional HTTP client timeouts have been implemented.

      • Better recovery from a corrupt internal checkpoint database.

      • Additional validation checks of internal IDs.

      • Added padding when sending compressed requests to follow best practices for protecting against side-channel attacks.

      • The flags for allowing insecure communication (insecure HTTP and disable certificate checks) now result in warnings when activated.

    • Starting with this release the FIPS variants of the Log Collector adhere to FIPS 140-3. Furthermore the FIPS variant can now be used on non-fips operating systems. Previously if using the FIPS compliant release, it was required to run the OS in FIPS compliant mode. As an example in a Windows FIPS environment the registry key: HKLM\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled had to be set to 1. This is no longer necessary.

    • It is now possible to specify multiple certificates. The parameters caCert and caFile now accept arrays as alternatives to single values.

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

  • Debugging

    • Internal logging of issues with the update service has been improved with improved formatting and verbosity.

    • This release introduces a new CLI command ping which can be used locally on the host where the Log Collector is installed to help troubleshoot connectivity issues between the Log Collector and the Fleet Management server.

      Purpose: Tests network connectivity and authentication to the Fleet Management server.

      Key functionality:

      • Reads configuration file to get Fleet Management settings

      • Resolves DNS for the Fleet Management server

      • Tests TLS certificate verification

      • Validates access token authentication

      • Tests connection through proxy if configured

      • Displays detailed connection diagnostics, including certificate chains and TLS info

      Usage: logscale-collector ping --cfg <path/to/config.yaml>.

      Requirements: The command requires LogScale version 1.220 or newer, otherwise the command will respond with an API error: Received HTTP status 404 Not Found.

  • Fleet Management

    • Fleet Management communication has been improved, and metrics are now compressed before transmission to Fleet Management.

Bug Fixes

  • Fleet Management

    • Fixed Windows 10 vs Windows 11 naming issue:

      On Windows platforms, the system string displayed in Fleet management is formatted as <ProductName> (<DisplayVersion>) (<Architecture>), for example, Windows 10 Enterprise (21H2) (amd64). However, the displayed ProductName relies on the internal product name reported by Windows. Unfortunately, some Windows 11 versions incorrectly report the internal product name as "Windows 10."

      Starting with the 1.11.0 release, the Log Collector will automatically translate the reported ProductName from "Windows 10" to "Windows 11" if the build number indicates that this translation is necessary. This aligns with the translation performed by the sensor when communicating with Host management.

      NOTE:

      The system string can be used to create automatic groups within Fleet management. Consequently, if a host group in Fleet management currently relies on the string "Windows 10," collectors might no longer be part of that group after upgrading to version 1.11 or newer.

      The reason this is important is that if a collector "leaves" a group due the above it will "lose" configurations assigned through group membership, and thus potentially cause ingestion to stop. Therefore, before updating to this version, it is very important to verify whether a group depends on the "Windows 10" part of the system string.

      For example, a group filter such as: system="Windows 10 Enterprise*" should be updated to include the Windows 11 equivalent, such as: system="Windows 10 Enterprise*" or system="Windows 11 Enterprise*".

  • Installation and Deployment

    • The Windows PowerShell installation scripts now properly handle cases where the LogScale Collector Update service is already running. Previously, the script would fail when attempting to overwrite the running installation.

Known Issues

  • Other

    • A regression was introduced in the database initialization code where the collector could panic when the database file is locked by another process, instead of returning the expected error message "Could not lock the checkpoint database. Maybe another process is using the same data directory". This has no impact on the running instance.