Falcon LogScale 1.154.0 GA (2024-09-03)

Version?Type?Release Date?Availability?End of Support

Security

Updates

Upgrades

From?

Config.

Changes?
1.154.0GA2024-09-03

Cloud

Next LTSNo1.112No

Bug fixes and updates.

Deprecation

Items that have been deprecated and may be removed in a future release.

  • The server.tar.gz release artifact has been deprecated. Users should switch to the OS/architecture-specific server-linux_x64.tar.gz or server-alpine_x64.tar.gz, which include bundled JDKs. Users installing a Docker image do not need to make any changes. With this change, LogScale will no longer support bringing your own JDK, we will bundle one with releases instead.

    We are making this change for the following reasons:

    • By bundling a JDK specifically for LogScale, we can customize the JDK to contain only the functionality needed by LogScale. This is a benefit from a security perspective, and also reduces the size of release artifacts.

    • Bundling the JDK ensures that the JDK version in use is one we've tested with, which makes it more likely a customer install will perform similar to our own internal setups.

    • By bundling the JDK, we will only need to support one JDK version. This means we can take advantage of enhanced JDK features sooner, such as specific performance improvements, which benefits everyone.

    The last release where server.tar.gz artifact is included will be 1.154.0.

  • The lastScheduledSearch field from the ScheduledSearch datatype is now deprecated and planned for removal in LogScale version 1.202. The new lastExecuted and lastTriggered fields have been added to the ScheduledSearch datatype to replace lastScheduledSearch.

Behavior Changes

Scripts or environment which make use of these tools should be checked and updated for the new configuration:

  • Functions

    • Prior to LogScale v1.147, the array:length() function accepted a value in the array argument that did not contain brackets [ ] so that array:length("field") would always produce the result 0 (since there was no field named field). The function has now been updated to properly throw an exception if given a non-array field name in the array argument. Therefore, the function now requires the given array name to have [ ] brackets, since it only works on array fields.

New features and improvements

  • UI Changes

  • GraphQL API

    • Introducing the view field on GraphQL FileEntry type, accessible through the entitiesSearch field.

  • Configuration

    • Minisegments auto-tune their max block count, up to their limit from configuration. This allows bigger minis for fast datasources, which reduces the number of minis in the global change stream.

  • Dashboards and Widgets

    • Improved user experience for creating and configuring dashboards parameters, providing immediate feedback when the setup changes and improved error validation.

      • Saving changes in parameters settings does not require an additional step to apply the changes before saving the dashboard, making it consistent with saving all other dashboard configurations.

      • Changes in the Parameters settings side panel now give immediate feedback on the dashboard.

      • Errors in the parameters setup are now validated on dashboard save, informing users about identified issues.

      • In the Query Parameter type, the Query String field has been replaced with LogScale Query editor, providing rich query writing experience as well as syntax validation.

      • In the File Parameter type, additional validation was added to display a warning if the lookup file used as a source of suggestions was deleted.

      • Parameters have now additional states (error, warning, info) informing users about issues with the setup.

    • Added the ability to move dashboards parameters to a parameter panel from the configuration side panel.

  • Queries

    • Added support for using the new experimental LogScale Regular Expression Engine v2 by specifying the F flag, for example:

      logscale
      '/foo/F'

      The new engine is currently under development and while it can be faster in some cases, there may also be cases where it is slower.

      For more information, see LogScale Regular Expression Engine V2.

      • Query warnings are now included in the activity logs for queries

      • When a query is rejected due to a validation exception, an activity log is added

      • Activity logs for queries are now generated for LogScale Self-Hosted

Fixed in this release

  • Ingestion

    • Fixed issues related to searching for ingest timestamp:

      • Issues with the usage of the query state cache when searching by ingest timestamp.

      • Reject queries where query time interval starts before the UNIX epoch. This applies both when searching by ingest timestamp or event timestamp. Previously such a query by ingest timestamp would cause an error, but a query by event timestamp was allowed, but not useful as all events in LogScale have event timestamps after the UNIX epoch.

      • When searching by ingest timestamp, start() and end() functions now report the correct search range.

      • Use event timestamp in place of ingest timestamp if the latter is missing. In old versions of LogScale (prior to 1.15) ingest timestamp was not stored with events. In order to support correct filtering when searching via ingest timestamp also for such old data, LogScale now considers the event timestamp to be also the ingest timestamp.

  • Log Collector

    • Fixed a performance issue when sorting by config name in the Fleet Management overview which could result in 503s from the backend.

  • Queries

    • Fixed stale QuerySessions that could cause invalid queries to be re-used.

    • Query poll would not be re-tried on dashboards if the request timed out.

  • Functions

    • Fixed some cases where writeJson() would output fields as numbers that are not supported by the JSON standard. These fields are now represented by strings in the output to ensure that the resulting JSON is valid.

Known Issues

  • Queries

    • A known issue in the implementation of the match() function when using cidr option in the mode parameter, could cause a reduction in performance for the query, and block other queries from executing.