Full Release Notes Index

This section contains a single page with all release notes on the same page.

If you are using this to look for specific release note entries or changes, please use Search Release Notes page instead, which provides a much richer set of functionality.

Falcon LogScale 1.147.0 Preview (2024-07-16)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.147.0Preview2024-07-16

Cloud

Next StableYes1.11221-22No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • 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 HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • 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.

New features and improvements

  • UI Changes

    • A new timestamp column has been added in the Event list displaying the alert timestamp selected (@ingesttimestamp or @timestamp). This will show as the new default column along with the usual @rawstring field column.

      For more information, see Alert Properties.

    • The Time Interval panel now displays the @ingesttimestamp/@timestamp options selected when querying events for Aggregate Alerts.

      For more information, see Changing Time Interval.

  • Automation and Alerts

    • A new Disabled actions status is added and can be visible from the Alerts overview table. This status will be displayed when there is an alert (or scheduled search) with only disabled actions attached.

      For more information, see Alerts Overview.

    • Standard Alerts have been renamed to Legacy Alerts. It is recommended using Filter Alerts or Aggregate Alerts alerts instead of legacy alerts.

      For more information, see Alerts.

    • A new aggregate alert type is introduced. The aggregate alert is now the recommended alert type for any queries containing aggregate functions. Like filter alerts, aggregate alerts use ingest timestamps and run back-to-back searches, guaranteeing at least once delivery to the actions for more robust results, even in case of ingest delays of up to 24 hours.

      For more information, see Aggregate Alerts.

    • The following UI changes are introduced for alerts:

      • The Alerts overview page now presents a table with search and filtering options.

      • An alert-specific version of the Search page is now available for creating and refining your query before saving it as an alert.

      • The alert's properties are opened in a side panel when creating or editing an alert.

      • In the side panel, the recommended alert type to choose is suggested based on the query.

      • For aggregate alerts, the side panel allows you to select the timestamp (@ingesttimestamp or @timestamp).

      For more information, see Creating Alerts, Alert Properties.

  • Log Collector

    • RemoteUpdate version dialog has been improved, with the ability to cancel pending and scheduled updates.

Fixed in this release

  • Ingestion

    • When shutting down a node, the process that load files used by a parser would be stopped before the parser itself. This could lead to ingested events not being parsed. This issue has now been fixed.

  • Functions

    • parseXml() would sometimes only partially extract text elements when the text contained newline characters. This issue has now been fixed.

    • Live queries using Field Aliasing on a repository with Tag Groupings enabled could fail. This issue has now been fixed.

    • Long running queries using window() could end up never completing. This issue has now been fixed.

Falcon LogScale 1.146.0 Preview (2024-07-09)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.146.0Preview2024-07-09

Cloud

Next StableYes1.11221-22No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • 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 HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • 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.

New features and improvements

  • Automation and Alerts

    • A maximum limit of 1 week has been added on the throttle period for Filter Alerts and Standard Alerts. Any existing alert with a higher throttle time will continue to run, but when edited, lowering the throttle time to 1 week at most will be required.

  • GraphQL API

    • The getFileContent() and newFile() GraphQL endpoint responses will change for empty files. The return type is still UploadedFileSnapshot!, but the lines field will be changed to return [] when the file is empty. Previously, the return value was a list containing an empty list [[]]. This change applies both for empty files, and when the provided filter string doesn't match any rows in the file.

  • Storage

    • An alternative S3 client is now available and enabled by default. It handles file uploads more efficiently, by setting the Content-MD5 header during upload thus allowing S3 to perform file validation instead of having LogScale do it via post-upload validation steps. This form of validation should work for all uploads, including when server-side encryption is enabled. The new S3 client only supports this validation mode, so setting the following variables will have no effect:

      In case of issues, the S3 client can be disabled by setting USE_AWS_SDK=false, which will set LogScale back to the previous default client. Should you need to do this, please reach out to Support to have the issue addressed, because the previous client will be deprecated and removed eventually.

  • API

Fixed in this release

  • UI Changes

    • The event histogram would not adhere to the timezone selected for the query.

  • GraphQL API

    • The getFileContent() GraphQL endpoint will now return an UploadedFileSnapshot! datatype with the field totalLinesCount: 0 when a file has no matches for a given filter string. Previously it would return the total number of lines in the file.

  • API

  • Functions

    • Parsing the empty string as a number could lead to errors causing the query to fail (in formatTime() function, for example). This issue has now been fixed.

Falcon LogScale 1.145.0 Preview (2024-07-02)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.145.0Preview2024-07-02

Cloud

Next StableYes1.11221-22No

Bug fixes and updates.

Breaking Changes

The following items create a breaking change in the behavior, response or operation of this release.

  • Functions

    • Calling the match() function with multiple columns now finds the last matching row in the file. This now aligns with the behavior of calling the same function with a single column.

      For more information, see match().

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • 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 HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • 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.

New features and improvements

  • UI Changes

    • When a file is referenced in a query, the Search page now shows a new tab next to the Results and Events tabs, bearing the name of the uploaded file. Activating the file tab will fetch the contents of the file and will show them as a Table widget. Alternatively, if the file cannot be queried, a download link will be presented instead.

      For more information, see Creating a File.

    • When exporting data to CSV, the Export to File dialog now offers the ability to select field names that are suggested based on the query results, or to select all fields in one click.

      For more information, see Exporting Data.

  • Automation and Alerts

  • GraphQL API

    • The new startFromDateTime argument has been added to s3ConfigureArchiving GraphQL mutation. When set, S3Archiving does not consider segment files that have a start time that is before this point in time. This in particular allows enabling S3 archiving only from a point in time and going forward, without archiving all the older files too.

  • Configuration

    • A new dynamic configuration variable GraphQlDirectivesAmountLimit has been added to restrict how many GraphQL directives can be in a query. Valid values are integers from 5 to 1,000. The default value is 25.

  • Functions

    • The new query function text:contains() is introduced. The function tests if a specific substring is present within a given string. It takes two arguments: string and substring, both of which can be provided as plain text, field values, or results of an expression.

      For more information, see text:contains().

    • The new query function array:append() is introduced, used to append one or more values to an existing array, or to create a new array.

      For more information, see array:append().

Fixed in this release

  • UI Changes

    • A long list of large queries would break the queries' list appearing under the Recent tab by not being updatable. The limit to recent queries has now been set to 30.

      For more information, see Recalling Queries.

    • It was not possible to sort by columns other than ID in the Cluster nodes table under the Operations UI menu. This issue has now been fixed.

    • The dialog to quickly switch to another repository would open when pressing the undo hotkey on Windows machines. This wrong behavior has now been fixed.

  • Automation and Alerts

    • The read-only alert page would wrongly report that actions were being throttled when a filter alert had disabled throttling. This issue has now been fixed.

    • Actions would show up as scheduled searches and vice versa when viewing the contents of a package. This issue has now been fixed.

  • GraphQL API

    • The background processing underlying the redactEvents() mutation would fail if the filter included tags. This error has now been fixed.

  • Storage

    • Notifying to Global Database about file changes could be slow. This issue has now been fixed.

  • Ingestion

    • A wrong order of the output events for parsers have been fixed — the output now returns the correct event order.

  • Dashboards and Widgets

    • Arguments for parameters no longer used in a deleted query could be submitted anyway when invoking a saved query that uses the same arguments, thus generating an error. This issue has now been fixed.

Improvement

  • Storage

    • The global topic throughput has been improved for particular updates to segments in datasources with many segments.

      For more information, see Global Database.

    • Let segment merge span vary by +/- 10% of the configured value to avoid all segment targets switching to a new merge targets at the same point in time.

Falcon LogScale 1.144.0 Preview (2024-06-25)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.144.0Preview2024-06-25

Cloud

Next StableYes1.11221-22No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • 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 HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • 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:

  • Installation and Deployment

    • The default cleanup.policy for the transientChatter-events topic has been switched from compact to delete,compact. This change will not apply to existing clusters. Changing this setting to delete,compact via Kafka's command line tools is particularly recommended if transientChatter is taking up excessive space on disk, whereas it is less relevant in production environments where Kafka's disks tend to be large.

  • Configuration

    • When global publish to Kafka times out from digester threads, the system would initiate a failure shutdown. Instead, from this 1.144 version the system retries the publish to Global Database indefinitely for those specific global transactions that originate in a digester thread. If retries occur, these get logged with an error executeTransactionRetryingOnTimeout: unable to execute transaction for global, retrying.

New features and improvements

  • Automation and Alerts

    • Two new GraphQL fields have been added in the ScheduledSearch datatype:

      • lastExecuted will hold the timestamp of the end of the search interval on the last scheduled search run.

      • lastTriggered will hold the timestamp of the end of the search interval on the last scheduled search run that found results and triggered actions.

      These two new fields are now displayed in the Scheduled Searches user interface.

  • GraphQL API

    • The log line containing Executed GraphQL query in the humio repository, that is logged for every GraphQL call, now contains the name of the mutations and queries that are executed.

  • Storage

    • Support for bucket storage upload validation has changed. LogScale now supports the following three validation modes:

      • Checking the ETag HTTP response header on the upload response. This mode is the default, and can be opted out of via the BUCKET_STORAGE_IGNORE_ETAG_UPLOAD configuration parameter.

      • Checking the ETag HTTP response header on a HEAD request done for the uploaded file. This is the second preferred mode, and can be opted out of via the BUCKET_STORAGE_IGNORE_ETAG_AFTER_UPLOAD configuration parameter.

      • Downloading the file that was uploaded, in order to validate the checksum file. This mode is enabled if neither of the other modes are enabled.

      Previous validation modes that did not compare checksums have been removed, as they were not reliable indicators of the uploaded file integrity.

Fixed in this release

Falcon LogScale 1.143.0 Preview (2024-06-18)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.143.0Preview2024-06-18

Cloud

Next StableYes1.11221-22No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Removed

Items that have been removed as of this release.

Other

  • Unnecessary digest-coordinator-changes and desired-digest-coordinator-changes metrics have been removed. Instead, the logging in the IngestPartitionCoordinator class has been improved, to allow monitoring of when reassignment of desired and current digesters happens — by searching for Wrote changes to desired digest partitions / Wrote changes to current digest partitions.

Deprecation

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

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • 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 HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

Upgrades

Changes that may occur or be required during an upgrade.

  • Installation and Deployment

    • The minimum version of Java compatible with LogScale is now 21. Docker users, and users installing the release artifacts that bundle the JDK, are not affected.

      It is recommended to switch to the release artifacts that bundle a JDK, because LogScale no longer supports bringing your own JDK as of release 1.138, see Falcon LogScale 1.138.0 Preview (2024-05-14)

New features and improvements

  • Security

    • When extending Retention span or size, any segments that were marked for deletion — but where the files remain in the system — are automatically resurrected. How much data you reclaim via this depends on the backupAfterMillis configuration on the repository.

      For more information, see Audit Logging.

  • GraphQL API

    • The new concatenateQueries() GraphQL API has been introduced for programmatically concatenating multiple queries into one. This is intended to eliminate errors that might occur if queries are combined naively.

    • The new environmentVariableUsage() GraphQL API has been introduced for listing non-secret environment variables used by a node. This is intended as an aid to help do configuration discovery when managing a large number of LogScale clusters.

    • The preview tag has been removed from the following GraphQL mutations:

      • createAwsS3SqsIngestFeed

      • DeleteIngestFeed

      • resetQuota

      • testAwsS3SqsIngestFeed

      • triggerPollIngestFeed

      • updateAwsS3SqsIngestFeed

  • Functions

    • The match() function now supports matching on multiple pairs of fields and columns.

      For more information, see match().

Fixed in this release

  • UI Changes

    • In the Export to File dialog, when using the keyboard to switch between options, a different item than the one selected was highlighted. This issue has now been fixed.

  • Storage

    • Digest threads could fail to start digesting if global is very large, and if writing to global is slow. This issue has now been fixed.

Falcon LogScale 1.142.1 Stable (2024-07-03)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.142.1Stable2024-07-03

Cloud

On-Prem

2025-07-31Yes1.11217-22No
TAR ChecksumValue
MD51a5dd967685b998da46afaed3c0fe18c
SHA14b87496f773a8ac0c51e5b27f35de15475fc34fd
SHA256b2fc87e706d02f48694caaf422f2700f9d178f56afe06e35a006ae1b8524a844
SHA51262ed51ae91d7e4c2c9276a1473ae26303ba89f36dece7f7ffbbb09d169c52b219ef7f79a3886c60cb9163823c8564feda3b58bfec23cc25b9abf107fbc7308a5
Docker ImageIncluded JDKSHA256 Checksum
humio2204af3a13ac01a9278105b223bc61639b20c735439fc9a131d49ec240cd50bc26
humio-core22a3868201a659cccb6bf44e0aedc18de6789938ac1e500b49aebc9362ec106759
kafka2230bff675f267171b99046d68419429f3b78e0e258282feade9bae1d726100b92
zookeeper22cc49c209a4de0de071e0be5bba530c6f39b012b0183f444daf2b73ea56cae646

Download

Bug fixes and updates.

Breaking Changes

The following items create a breaking change in the behavior, response or operation of this release.

  • Functions

    • The limit parameter has been added to the rdns() function. It is controlled by dynamic configurations RdnsMaxLimit and RdnsDefaultLimit. This is a breaking change addition due to incidents caused by the large implicit limit used before.

      For more information, see rdns().

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • 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 HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

Behavior Changes

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

  • API

    • It is no longer possible to revive a query by polling it after it has been stopped.

      For more information, see Submitting Query Jobs.

  • Other

    • LogScale deletes humiotmp directories when gracefully shut down, but this can cause tmp directories to leak if LogScale crashes. LogScale now also deletes these directories on startup.

Upgrades

Changes that may occur or be required during an upgrade.

  • Installation and Deployment

    • The Kafka client has been upgraded to 3.7.0. The Kafka server version in the deprecated humio/kafka Docker image is also upgraded to 3.7.0.

  • Other

    • Bundled JDK upgraded to 22.0.1.

New features and improvements

  • Installation and Deployment

    • Changing the NODE_ROLES of a host is now forbidden. A host will now crash if the role it is configured to have doesn't match what is listed in global for that host. People wishing to change the role of a host in a cluster should instead remove that host from the cluster by unregistering it, wipe the data directory of the host, and boot the node back into the cluster as if it were a completely new node. The node will be assigned a new vhost identifier when doing this.

    • Unused modules have been removed from the JDK bundled with LogScale releases, thus reducing the size of release artifacts.

  • UI Changes

    • Time zone data has been updated to IANA 2024a and has been trimmed to +/- 5 years from the release date of IANA 2024a.

    • Layout changes have been made in the Connections UI page.

      For more information, see Connections.

    • The maximum limit for saved query names has been set to 200 characters.

    • A new Field list column type has been added in the Event List. It formats all fields in the event in key-value pairs by grouping a field list by prefix.

      For more information, see Column Properties.

    • The warnings for numbers out of the browser's safe number range have been slightly modified.

      For more information, see Troubleshooting: UI Warning: The actual value is different from what is displayed.

  • Automation and Alerts

    • Scheduled Reports can now be created. Scheduled Reports generate reports directly from dashboards and send them to the selected email addresses on a regular schedule.

      For more information, see Scheduled PDF Reports.

  • GraphQL API

    • A new unsetDynamicConfig GraphQL mutation is introduced to unset dynamic configurations.

    • Added a new GraphQL API generateParserFromTemplate() for decoding a parser YAML template without installing it.

  • API

    • Upgrade to the latest Jakarta Mail API to prevent a warning message from being logged about a missing mail configuration file.

    • Information about files used in a query is now added to the query result returned by the API.

  • Configuration

    • The EXACT_MATCH_LIMIT configuration has been removed. It is no longer needed, since files are limited by size instead of rows.

    • When UNSAFE_RELAX_MULTI_CLUSTER_PROTOCOL_VERSION_CHECK is set to ensure Multi-Cluster Compatibility Across Versions, attempting to search in clusters older than version 1.131.2 is not allowed and a UI message will now be displayed.

    • A new QueryBacktrackingLimit dynamic configuration is available through GraphQL as experimental. It allows to limit a query iterating over individual events too many times (which may happen with an excessive use of copyEvent(), join() and split() functions, or regex() with repeat-flags). The default for this limit is 3,000 and can be modified with the dynamic configuration. At present, the feature flag sets this limit off by default.

  • Ingestion

    • Self-hosted only: derived tags (like #repo) are now included when executing Event Forwarding Rules. These fields will be included in the forwarded events unless filtered by select() or drop(#repo) in the rule.

    • Audit logs related to Event Forwarders no longer include the properties of the event forwarder.

      Event forwarder disablement is now audit logged with type disable instead of enable.

    • The parser assertions can now be written and loaded to YAML files, using the V3 parser format.

  • Dashboards and Widgets

    • A parameter panel widget type has been added to allow users to drag parameters from the top panel and into these panels. Also, a parameter's width is now adjustable in the settings.

      For more information, see Parameter Panel Widget.

  • Log Collector

    • Fleet Management now supports ephemeral hosts. If a collector is enrolled with the parameter --ephemeralTimeout, after being offline for the specified duration in hours it will disappear from the Fleet Overview interface and be unenrolled. The feature requires LogScale Collector version 1.7.0 or above.

    • Live and Historic options for Fleet Overview are introduced. When Live, the overview will show online collectors and continuously be updated with e.g. new CPU metrics or status changes. The Historic view will display all records of collectors for the last 30 days. In this case the overview will not be updated with new information.

      For more information, see Switching between Live and Historic overview.

  • Functions

    • The onlyTrue parameter has been added to the bitfield:extractFlags() query function, it allows to output only flags whose value is true.

      For more information, see bitfield:extractFlags().

    • Multi-valued arguments can now be passed to a saved query.

      For more information, see User Functions (Saved Searches).

    • array:filter has been fixed as performing a filter test on an array field outputted from this function would sometimes lead to no results.

    • The query editor now gives warnings about certain regex constructs that are valid but suboptimal. Specifically, quantified wildcards in the beginning or end of an (unanchored) regex.

  • Other

    • A new metric max_ingest_delay is introduced to keep track of the current maximum ingest delay across all Kafka partitions.

    • Two new metrics are introduced:

      • internal-throttled-poll-rate keeps track of the number of times polling workers during query execution was throttled due to rate limiting.

      • internal-throttled-poll-wait-time keeps track of maximum delays per poll round due to rate limiting.

Fixed in this release

  • Storage

    • Taking nodes offline in a cluster that does not use bucket storage could prevent cleanup of minisegments associated with merge targets owned by the offline nodes, causing global to grow. To solve this, the cluster now moves merge targets that have not yet achieved full replication to follow digest nodes.

    • The Did not query segment error spuriously appearing when the cluster performs digest reassignment has now been fixed.

    • The file synchronization job would stop if upload to bucket storage fails. This issue has been fixed.

  • Dashboards and Widgets

    • Dragging a parameter to an empty Parameter Panel Widget would sometimes not move the parameter. This issue has been fixed.

    • The execution of dashboard parameter queries has been changed to only run as live when the dashboard itself is live.

  • Functions

    • The time:xxx() functions have been fixed as they did not correctly use the query's timezone as default. The offset was applied in an opposite manner, such that for example GMT+2 was applied as GMT-2. This has now been fixed.

    • The query editor has been fixed as field auto-completions would sometimes not be suggested.

    • The query editor would mark the entire query as erroneous when count() was given with distinct=true parameter but missing an argument for the field parameter. This issue has been fixed.

  • Other

    • A regression introduced in version 1.132 has been fixed, where a file name starting with shared/ would be recognized as a shared file instead of a regular file. However, a shared file should be referred to using exactly /shared/ as a prefix.

    • Fixing a very rare edge case that could cause creation of malformed entities in global when a nested entity — such as a datasource — was deleted.

Improvement

  • UI Changes

    • When a saved query is used, the query editor will display the query string when hovering over it.

  • Storage

    • Logging improvements have been made around bucket uploads to assist with troubleshooting slow uploads, which are only seen in clusters with very large data sets.

  • Packages

    • Validate that there are no duplicate names used for each package template type during package installations (for example you cannot use the same name for multiple parsers that are part of the same package).

Falcon LogScale 1.142.0 Preview (2024-06-11)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.142.0Preview2024-06-11

Cloud

On-Prem

2025-07-31Yes1.11217-22No

Bug fixes and updates.

Breaking Changes

The following items create a breaking change in the behavior, response or operation of this release.

  • Functions

    • The any argument in sort() has been removed. Queries where any is explicitly set will be rejected. Please change the argument to either number, hex or string, depending on which option is the best fit for the data your query operates on.

    • The following changes have been made to sort():

      • It will no longer try to guess the type of the field values and instead default to number.

      • The number and hex options have been redefined to be total orders: values of the given type are sorted according to their natural order and those that could not be understood as the given type are sorted lexicographically. For instance, sorting the values 10, 100, 20, bcd, cde, abc in an ascending order with number will be rendered as: 10, 20, 100, abc, bcd, cde

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • 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 HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

Behavior Changes

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

  • Storage

    • When a digest leader exceeds the PRIMARY_STORAGE_MAX_FILL_PERCENTAGE, instead of pausing by releasing leadership of all partitions, it'll pause while holding on to leadership.

New features and improvements

  • Security

    • The new ManageViewConnections Organization Administration permission has been added. It grants access to:

      • List all views and repositories

      • Create views linked to any repository

      • Update Connections of any existing view.

  • Installation and Deployment

    • NUMA support for the Docker images is now enabled:

      • The launcher script has been updated to set -XX:+UseNUMA in the default HUMIO_JVM_PERFORMANCE_OPTS.

      • The Docker images have been updated to include libnuma.so.1, which allows the JDK to optimize for NUMA hardware.

  • Dashboards and Widgets

    • Widget-level time selection can now be adjusted when a dashboard is used in view mode. This change adds flexibility in working with time on the dashboard and allows for easy comparative analysis on the fly.

Fixed in this release

  • Storage

    • Pending merges of segments would contend with the verification of segments being transferred between nodes/bucket. This resulted in spuriously long transfer times, due to queueing of the verification step for the segment file. This issue has now been fixed.

  • Other

    • A fix has been made to reduce contention in file reading for queries, thus resulting in performance improvement.

Improvement

  • Storage

    • The amount of work required for the local segment verifier at boot of nodes has been reduced.

Falcon LogScale 1.141.0 Preview (2024-06-04)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.141.0Preview2024-06-04

Cloud

On-Prem

2025-07-31Yes1.11217-22No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • 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 HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

Upgrades

Changes that may occur or be required during an upgrade.

  • Other

    • Bundled JDK upgraded to 22.0.1.

New features and improvements

Fixed in this release

  • Storage

    • The Did not query segment error spuriously appearing when the cluster performs digest reassignment has now been fixed.

  • Dashboards and Widgets

    • Dragging a parameter to an empty Parameter Panel Widget would sometimes not move the parameter. This issue has been fixed.

  • Functions

    • The time:xxx() functions have been fixed as they did not correctly use the query's timezone as default. The offset was applied in an opposite manner, such that for example GMT+2 was applied as GMT-2. This has now been fixed.

  • Other

    • A regression introduced in version 1.132 has been fixed, where a file name starting with shared/ would be recognized as a shared file instead of a regular file. However, a shared file should be referred to using exactly /shared/ as a prefix.

Improvement

  • Packages

    • Validate that there are no duplicate names used for each package template type during package installations (for example you cannot use the same name for multiple parsers that are part of the same package).

Falcon LogScale 1.140.0 Preview (2024-05-28)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.140.0Preview2024-05-28

Cloud

On-Prem

2025-07-31Yes1.11217-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • 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 HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

New features and improvements

  • UI Changes

    • A new Field list column type has been added in the Event List. It formats all fields in the event in key-value pairs by grouping a field list by prefix.

      For more information, see Column Properties.

  • GraphQL API

    • Added a new GraphQL API generateParserFromTemplate() for decoding a parser YAML template without installing it.

  • API

    • Information about files used in a query is now added to the query result returned by the API.

  • Configuration

    • The EXACT_MATCH_LIMIT configuration has been removed. It is no longer needed, since files are limited by size instead of rows.

  • Functions

Falcon LogScale 1.139.0 Preview (2024-05-21)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.139.0Preview2024-05-21

Cloud

On-Prem

2025-07-31Yes1.11217-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • 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 HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

Behavior Changes

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

  • API

    • It is no longer possible to revive a query by polling it after it has been stopped.

      For more information, see Submitting Query Jobs.

  • Other

    • LogScale deletes humiotmp directories when gracefully shut down, but this can cause tmp directories to leak if LogScale crashes. LogScale now also deletes these directories on startup.

New features and improvements

  • UI Changes

  • Configuration

    • A new QueryBacktrackingLimit dynamic configuration is available through GraphQL as experimental. It allows to limit a query iterating over individual events too many times (which may happen with an excessive use of copyEvent(), join() and split() functions, or regex() with repeat-flags). The default for this limit is 3,000 and can be modified with the dynamic configuration. At present, the feature flag sets this limit off by default.

  • Ingestion

    • Audit logs related to Event Forwarders no longer include the properties of the event forwarder.

      Event forwarder disablement is now audit logged with type disable instead of enable.

    • The parser assertions can now be written and loaded to YAML files, using the V3 parser format.

  • Functions

    • The onlyTrue parameter has been added to the bitfield:extractFlags() query function, it allows to output only flags whose value is true.

      For more information, see bitfield:extractFlags().

    • The query editor now gives warnings about certain regex constructs that are valid but suboptimal. Specifically, quantified wildcards in the beginning or end of an (unanchored) regex.

  • Other

    • Two new metrics are introduced:

      • internal-throttled-poll-rate keeps track of the number of times polling workers during query execution was throttled due to rate limiting.

      • internal-throttled-poll-wait-time keeps track of maximum delays per poll round due to rate limiting.

Improvement

  • UI Changes

    • When a saved query is used, the query editor will display the query string when hovering over it.

Falcon LogScale 1.138.0 Preview (2024-05-14)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.138.0Preview2024-05-14

Cloud

On-Prem

2025-07-31Yes1.11217-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • 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 HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

Upgrades

Changes that may occur or be required during an upgrade.

  • Installation and Deployment

    • The Kafka client has been upgraded to 3.7.0. The Kafka server version in the deprecated humio/kafka Docker image is also upgraded to 3.7.0.

New features and improvements

  • Installation and Deployment

    • Changing the NODE_ROLES of a host is now forbidden. A host will now crash if the role it is configured to have doesn't match what is listed in global for that host. People wishing to change the role of a host in a cluster should instead remove that host from the cluster by unregistering it, wipe the data directory of the host, and boot the node back into the cluster as if it were a completely new node. The node will be assigned a new vhost identifier when doing this.

    • Unused modules have been removed from the JDK bundled with LogScale releases, thus reducing the size of release artifacts.

  • UI Changes

    • Layout changes have been made in the Connections UI page.

      For more information, see Connections.

  • GraphQL API

    • A new unsetDynamicConfig GraphQL mutation is introduced to unset dynamic configurations.

  • Ingestion

    • Self-hosted only: derived tags (like #repo) are now included when executing Event Forwarding Rules. These fields will be included in the forwarded events unless filtered by select() or drop(#repo) in the rule.

  • Functions

    • array:filter has been fixed as performing a filter test on an array field outputted from this function would sometimes lead to no results.

  • Other

    • A new metric max_ingest_delay is introduced to keep track of the current maximum ingest delay across all Kafka partitions.

Fixed in this release

  • Storage

    • Taking nodes offline in a cluster that does not use bucket storage could prevent cleanup of minisegments associated with merge targets owned by the offline nodes, causing global to grow. To solve this, the cluster now moves merge targets that have not yet achieved full replication to follow digest nodes.

    • The file synchronization job would stop if upload to bucket storage fails. This issue has been fixed.

  • Dashboards and Widgets

    • The execution of dashboard parameter queries has been changed to only run as live when the dashboard itself is live.

  • Other

    • Fixing a very rare edge case that could cause creation of malformed entities in global when a nested entity — such as a datasource — was deleted.

Improvement

  • Storage

    • Logging improvements have been made around bucket uploads to assist with troubleshooting slow uploads, which are only seen in clusters with very large data sets.

Falcon LogScale 1.137.0 Preview (2024-05-07)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.137.0Preview2024-05-07

Cloud

On-Prem

2025-07-31Yes1.11217-21No

Bug fixes and updates.

Breaking Changes

The following items create a breaking change in the behavior, response or operation of this release.

  • Functions

    • The limit parameter has been added to the rdns() function. It is controlled by dynamic configurations RdnsMaxLimit and RdnsDefaultLimit. This is a breaking change addition due to incidents caused by the large implicit limit used before.

      For more information, see rdns().

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • The HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

New features and improvements

  • UI Changes

    • Time zone data has been updated to IANA 2024a and has been trimmed to +/- 5 years from the release date of IANA 2024a.

  • Automation and Alerts

    • Scheduled Reports can now be created. Scheduled Reports generate reports directly from dashboards and send them to the selected email addresses on a regular schedule.

      For more information, see Scheduled PDF Reports.

  • Dashboards and Widgets

    • A parameter panel widget type has been added to allow users to drag parameters from the top panel and into these panels. Also, a parameter's width is now adjustable in the settings.

      For more information, see Parameter Panel Widget.

  • Log Collector

    • Fleet Management now supports ephemeral hosts. If a collector is enrolled with the parameter --ephemeralTimeout, after being offline for the specified duration in hours it will disappear from the Fleet Overview interface and be unenrolled. The feature requires LogScale Collector version 1.7.0 or above.

    • Live and Historic options for Fleet Overview are introduced. When Live, the overview will show online collectors and continuously be updated with e.g. new CPU metrics or status changes. The Historic view will display all records of collectors for the last 30 days. In this case the overview will not be updated with new information.

      For more information, see Switching between Live and Historic overview.

Fixed in this release

  • Functions

    • The query editor has been fixed as field auto-completions would sometimes not be suggested.

    • The query editor would mark the entire query as erroneous when count() was given with distinct=true parameter but missing an argument for the field parameter. This issue has been fixed.

Falcon LogScale 1.136.2 Stable (2024-06-12)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.136.2Stable2024-06-12

Cloud

On-Prem

2025-05-31Yes1.11217-21No
TAR ChecksumValue
MD5e9ff17d2c3f763bbe282fc4055aa3ea4
SHA16d215f73a3f0794f5d25293dab541bb2172d525c
SHA2566682216a929202b826c7a3b2bbf504cee03c1c2c0ead20e87324b92c7f3e84cf
SHA512e0a5092cce05067186ef90bb001092b880107a3e53bace59cb83f0f56bd919381f5bfb7cc4794a382e4756faa34777996b477dc58074dbc61ee0a4e2d2b8b9d5
Docker ImageIncluded JDKSHA256 Checksum
humio212d23d1ac912f2521ea2f6df58d1eb71809a37aab906e4af1833ad6515d71aa39
humio-core213045f568bf56c831aa2d068de4e21921ab1a58730a17f6b72d0f20fc34467315
kafka215e7bcafde7f97247d39436debf051eed74d392d3c8108814deba44c1e5201532
zookeeper2141f009aaf13990b57fefbc7c53718251d66e805412e9cb7afb970c55bb189304

Download: https://repo.humio.com/repository/maven-releases/com/humio/server/1.136.2/server-1.136.2.tar.gz

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • The HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

Fixed in this release

  • Storage

    • Pending merges of segments would contend with the verification of segments being transferred between nodes/bucket. This resulted in spuriously long transfer times, due to queueing of the verification step for the segment file. This issue has now been fixed.

  • Other

    • A regression introduced in version 1.132 has been fixed, where a file name starting with shared/ would be recognized as a shared file instead of a regular file. However, a shared file should be referred to using exactly /shared/ as a prefix.

Falcon LogScale 1.136.1 Stable (2024-05-29)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.136.1Stable2024-05-29

Cloud

On-Prem

2025-05-31Yes1.11217-21No
TAR ChecksumValue
MD55d85313bbb4ca534e2dbdad64cb93cf4
SHA122258d1028543b021397b016ab8ec46ca1ba157a
SHA256d7bba11fa29c730476fefe1a90176dd5c38ed7f5da0569beab0f0f60e6f2b1fa
SHA5120dd5b99de53bdc3c48dc3977b2a86793d440f1aab6941715f0ec9d46b640e3bb20d9c11930d6db05e538e83f50edb336eefae590f2428e718bd3aee517806e4a
Docker ImageIncluded JDKSHA256 Checksum
humio211274cc9fbdcee71a206ea9d3c874a331387359e0df8797874360b4b28abb6e28
humio-core21c29cef0886b22d41c346624dd1109b977e8efe7873f1f68a306f5135d7f55a6c
kafka211c9f0ce03d3877e78893061b2ef67cb2e7cb0b534a858d01e9616be88a5cbd40
zookeeper21fe64ed2195c1df1fa3a668a4d010973e8a602b9a37862bf41de06fc698db7226

Download: https://repo.humio.com/repository/maven-releases/com/humio/server/1.136.1/server-1.136.1.tar.gz

Bug fixes and updates.

Breaking Changes

The following items create a breaking change in the behavior, response or operation of this release.

  • Functions

    • The limit parameter has been added to the rdns() function. It is controlled by dynamic configurations RdnsMaxLimit and RdnsDefaultLimit. This is a breaking change addition due to incidents caused by the large implicit limit used before.

      For more information, see rdns().

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Removed

Items that have been removed as of this release.

Storage

  • The full JDK has been removed from the Docker images, leaving only the bundled JDK that is part of LogScale release tarballs.

Deprecation

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

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • The HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

Behavior Changes

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

  • Other

    • Hitting the query count quota no longer cancels existing queries, but only disallows starting new ones.

      For more information, see Query Count.

Upgrades

Changes that may occur or be required during an upgrade.

  • Storage

    • Docker images have been upgraded to Java 22.

    • Added new deployment artifacts. The published tarballs (e.g. server.tar.gz) are now available with a bundled JDK. The platforms currently supported are linux_x64 for 64-bit Linux, and alpine_x64 for 64-bit Alpine Linux and other musl-based Linuxes. The Docker images have been updated to use this bundled JDK internally. We encourage users to migrate to using the tarballs with bundled JDKs.

New features and improvements

  • Installation and Deployment

    • The LogScale Launcher Script now sets -XX:+UseTransparentHugePages as part of the mandatory flags. THP is already enabled for all processes on many Linux distributions by default. This flag enables THP on systems where processes must opt into THP via madvise. We strongly recommend enabling THP for LogScale.

  • UI Changes

    • Time zone data has been updated to IANA 2024a and has been trimmed to +/- 5 years from the release date of IANA 2024a.

    • The query editor now shows completions for known field values that have previously been observed in results. For instance, #repo = m may show completions for repositories starting with m seen in previous results.

    • Sign up to LogScale Community Edition is no longer available for new users. Links, pages and UI flows to access it have been removed.

    • The number of events in the current window has been added to Metric Types as window_count.

  • Automation and Alerts

  • GraphQL API

  • Storage

    • We reverted a change introduced in 1.131.0 intended to cause fewer minisegments to move in the cluster when digest reassignment occurs. The change could cause minisegments to not be balanced across cluster nodes in the expected way.

    • The bucket transfer prioritization has been adjusted. When behind on both uploads and downloads, 75% of the S3_STORAGE_CONCURRENCY capacity is reserved for uploads, and 25% for downloads, rather than using all slots for downloads.

  • Configuration

    • The amount of global meta data required for retention spans of over 30 days has been reduced. The amount of global meta data required in clusters with high number of active datasources has also been reduced, as well as the global size of mini segments, by combining them into larger mini segments.

      Pre-merging mini segments now reduces the number of segment files on disk (and in bucket) and reduces the amount of meta data for segment targets in progress. This allows getting larger target segment files and reduces the amount of "undersized" merging of "completed" segments. It also allows a smaller flush interval for mini segments without incurring in a larger number of mini segments.

      This feature is only supported from v1.112.0. To safely enable it by default, we are now raising to v1.112.0 the minimum version to upgrade from, to disallow rollback to versions older than this version.

      The feature is on by default. It can be disabled using the feature flag PreMergeMiniSegments. Disabling the feature stops future merges of mini segments into larger mini segment files, but does not alter the defaults below, nor modify how already merged minisegments behave.

      For more information, see Global Database, Ingestion: Digest Phase.

    • The following configuration parameters have been introduced:

    • The default values for the following configuration parameters have changed:

      • FLUSH_BLOCK_SECONDS = 900 (was 1,800)

      • MAX_HOURS_SEGMENT_OPEN = 720 (was 24, maximum is now 24,000)

  • Ingestion

    • Ingest feed scheduling has been changed to be more gradual in ramping up concurrency and will also reduce concurrency in response to failures. This will make high-pressure failing ingest feeds fall back to periodic retries instead of constantly retrying.

      For more information, see Ingesting Data from AWS S3.

    • Parser test cases can now include assertions. This allows you to specify that you expect certain fields to have certain values in a test case after parsing, or that you expect certain fields to not be present at all. Note that the assertions are not exported as part of the YAML template yet.

      For more information, see Writing a Parser.

  • Dashboards and Widgets

    • Dashboard parameters have gotten the following updates:

      • The name of the parameter is on top of the input field, so more space is available for both parts.

      • A Clear all button has been added to multi-value parameters so that all values can be removed in one click.

      • The parameter's configuration form has been moved to the side panel.

      • Multiple values can be added at once to a multi-value parameter by inputting a comma separated list of values, which can be used as individual values.

      For more information, see Multi-value Parameters.

    • The automatic rendering of URLs as links has been disabled for the Table widget. Only URLs appearing in queries with the markdown style e.g. [CrowdStrike](https://crowdstrike.com) will be automatically rendered as links in the Table widget columns. Content, including plain URLs e.g. https://crowdstrike.com, can still be rendered as links, but this should now be explicitly configured using the Show asLink widget property.

      For more information, see Table Widget Properties.

  • Log Collector

  • Functions

    • The optional limit parameter has been added to the readFile() function to limit the number of rows of the file returned.

    • The geography:distance() function is now generally available. The default value for the as parameter has been changed to _distance.

      For more information, see geography:distance().

    • onDuplicate parameter has been added to kvParse() to specify how to handle duplicate fields.

    • For Cloud customers: the maximum value of the limit parameter for tail() and head() functions has been increased to 20,000.

    • For Self-Hosted solutions: the maximum value of the limit parameter for tail() and head() functions has been aligned with the StateRowLimit dynamic configuration. This means that the upper value of limit is now adjustable for these two functions.

    • The readFile() function will show a warning when the results are truncated due to reaching global result row limit. This behaviour was previously silent.

  • Other

    • New metrics ingest-queue-write-offset and ingest-queue-read-offset have been added, reporting the Kafka offsets of the most recently written and read events on the ingest queue.

    • Queries are now allowed to be queued for start by the query coordinator for a maximum of 10 minutes.

      For more information, see Query Coordination.

    • The ConfigLoggerJob now also logs digestReplicationFactor, segmentReplicationFactor, minHostAlivePercentageToEnableClusterRebalancing, allowUpdateDesiredDigesters and allowRebalanceExistingSegments.

    • New metric events-parsed has been added, serving as an indicator for how many input events a parser has been applied to.

Fixed in this release

  • Security

    • Various OIDC caching issues have been fixed including ensuring refresh of the JWKS cache once per hour by default.

  • UI Changes

    • The formatting of @timestamp has been improved to make time-based visualizations fully compatible with time zones when selecting time zones other than the browser default.

    • The error Failed to fetch data for aliased fields would sometimes appear on the Search page of the sandbox repository. This issue has been fixed.

    • Data statistics in the Organizations overview page could not be populated in some cases.

    • Fixed an issue that prevented users from copying the query string from the flyout in the Recent / Saved queries panel.

    • Still existing Humio occurrences have been replaced with LogScale in a lot of places, primarily in GraphQL documentation and error messages.

  • Storage

    • redactEvents segment rewriting has been fixed for several issues that could cause either failure to complete the rewrite, or events to be missed in rare cases. Users should be aware that redaction jobs that were submitted prior to upgrading to a fixed version may fail to complete correctly, or may miss events. Therefore, you are encouraged to resubmit redactions you have recently submitted, to ensure the events are actually gone.

  • Dashboards and Widgets

    • A visualization issue has been fixed as the dropdown menu for saving a dashboard widget was showing a wrong title in dashboards not belonging to a package.

    • Parameters appearing between a string containing \\ and any other string would not be correctly detected. This issue has been fixed.

    • Other options than exporting to CSV file were not possible on the Dashboard page for a widget and on the Search page for a query result. This issue is now fixed.

  • Functions

    • The error message when providing a non-existing query function in an anonymous query e.g. bucket(function=[{_noFunction()}]) has been fixed.

    • The table() function has been fixed as it would wrongly accept a limit of 0, causing serialisation to break between cluster nodes.

  • Other

    • Multiple clients might trigger concurrent computation of the result step for a shared query. This issue has been fixed: now only one pending computation is allowed at a time.

    • DNS lookup was blocked by heavy disk IO when using a HTTP proxy, causing timeouts. This issue has been fixed.

  • Packages

    • Uploading a package zip would fail on Windows devices. This issue has been fixed.

Improvement

  • Installation and Deployment

    • An error log is displayed if the latency on global-events exceeds 150 seconds, to prevent nodes from crashing.

  • Storage

    • Removed some work from the thread scheduling bucket transfers that could be slightly expensive in cases where the cluster had fallen behind on uploads.

  • Configuration

    • Whenever a SAML or OIDC IdP is created or updated, any leading or trailing whitespace will be trimmed from its fields. This is to avoid configuration errors.

Falcon LogScale 1.136.0 Preview (2024-04-30)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.136.0Preview2024-04-30

Cloud

On-Prem

2025-05-31No1.11217-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Removed

Items that have been removed as of this release.

Storage

  • The full JDK has been removed from the Docker images, leaving only the bundled JDK that is part of LogScale release tarballs.

Deprecation

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

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • The HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

New features and improvements

  • GraphQL API

  • Ingestion

    • Parser test cases can now include assertions. This allows you to specify that you expect certain fields to have certain values in a test case after parsing, or that you expect certain fields to not be present at all. Note that the assertions are not exported as part of the YAML template yet.

      For more information, see Writing a Parser.

  • Log Collector

Fixed in this release

  • UI Changes

    • Still existing Humio occurrences have been replaced with LogScale in a lot of places, primarily in GraphQL documentation and error messages.

  • Functions

    • The table() function has been fixed as it would wrongly accept a limit of 0, causing serialisation to break between cluster nodes.

  • Other

    • DNS lookup was blocked by heavy disk IO when using a HTTP proxy, causing timeouts. This issue has been fixed.

Falcon LogScale 1.135.0 Preview (2024-04-23)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.135.0Preview2024-04-23

Cloud

On-Prem

2025-05-31No1.11217-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

Upgrades

Changes that may occur or be required during an upgrade.

  • Storage

    • Docker images have been upgraded to Java 22.

    • Added new deployment artifacts. The published tarballs (e.g. server.tar.gz) are now available with a bundled JDK. The platforms currently supported are linux_x64 for 64-bit Linux, and alpine_x64 for 64-bit Alpine Linux and other musl-based Linuxes. The Docker images have been updated to use this bundled JDK internally. We encourage users to migrate to using the tarballs with bundled JDKs.

New features and improvements

  • UI Changes

    • The query editor now shows completions for known field values that have previously been observed in results. For instance, #repo = m may show completions for repositories starting with m seen in previous results.

  • Automation and Alerts

  • Storage

    • We reverted a change introduced in 1.131.0 intended to cause fewer minisegments to move in the cluster when digest reassignment occurs. The change could cause minisegments to not be balanced across cluster nodes in the expected way.

  • Configuration

    • The amount of global meta data required for retention spans of over 30 days has been reduced. The amount of global meta data required in clusters with high number of active datasources has also been reduced, as well as the global size of mini segments, by combining them into larger mini segments.

      Pre-merging mini segments now reduces the number of segment files on disk (and in bucket) and reduces the amount of meta data for segment targets in progress. This allows getting larger target segment files and reduces the amount of "undersized" merging of "completed" segments. It also allows a smaller flush interval for mini segments without incurring in a larger number of mini segments.

      This feature is only supported from v1.112.0. To safely enable it by default, we are now raising to v1.112.0 the minimum version to upgrade from, to disallow rollback to versions older than this version.

      The feature is on by default. It can be disabled using the feature flag PreMergeMiniSegments. Disabling the feature stops future merges of mini segments into larger mini segment files, but does not alter the defaults below, nor modify how already merged minisegments behave.

      For more information, see Global Database, Ingestion: Digest Phase.

    • The following configuration parameters have been introduced:

    • The default values for the following configuration parameters have changed:

      • FLUSH_BLOCK_SECONDS = 900 (was 1,800)

      • MAX_HOURS_SEGMENT_OPEN = 720 (was 24, maximum is now 24,000)

  • Dashboards and Widgets

    • Dashboard parameters have gotten the following updates:

      • The name of the parameter is on top of the input field, so more space is available for both parts.

      • A Clear all button has been added to multi-value parameters so that all values can be removed in one click.

      • The parameter's configuration form has been moved to the side panel.

      • Multiple values can be added at once to a multi-value parameter by inputting a comma separated list of values, which can be used as individual values.

      For more information, see Multi-value Parameters.

    • The automatic rendering of URLs as links has been disabled for the Table widget. Only URLs appearing in queries with the markdown style e.g. [CrowdStrike](https://crowdstrike.com) will be automatically rendered as links in the Table widget columns. Content, including plain URLs e.g. https://crowdstrike.com, can still be rendered as links, but this should now be explicitly configured using the Show asLink widget property.

      For more information, see Table Widget Properties.

  • Functions

Fixed in this release

  • Dashboards and Widgets

    • Other options than exporting to CSV file were not possible on the Dashboard page for a widget and on the Search page for a query result. This issue is now fixed.

  • Functions

    • The error message when providing a non-existing query function in an anonymous query e.g. bucket(function=[{_noFunction()}]) has been fixed.

Falcon LogScale 1.134.0 Preview (2024-04-16)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.134.0Preview2024-04-16

Cloud

On-Prem

2025-05-31No1.10617-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

Behavior Changes

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

  • Other

    • Hitting the query count quota no longer cancels existing queries, but only disallows starting new ones.

      For more information, see Query Count.

New features and improvements

  • UI Changes

    • Sign up to LogScale Community Edition is no longer available for new users. Links, pages and UI flows to access it have been removed.

    • The number of events in the current window has been added to Metric Types as window_count.

  • Functions

    • The geography:distance() function is now generally available. The default value for the as parameter has been changed to _distance.

      For more information, see geography:distance().

    • The readFile() function will show a warning when the results are truncated due to reaching global result row limit. This behaviour was previously silent.

  • Other

    • The ConfigLoggerJob now also logs digestReplicationFactor, segmentReplicationFactor, minHostAlivePercentageToEnableClusterRebalancing, allowUpdateDesiredDigesters and allowRebalanceExistingSegments.

Fixed in this release

  • UI Changes

    • The formatting of @timestamp has been improved to make time-based visualizations fully compatible with time zones when selecting time zones other than the browser default.

    • Data statistics in the Organizations overview page could not be populated in some cases.

  • Dashboards and Widgets

    • A visualization issue has been fixed as the dropdown menu for saving a dashboard widget was showing a wrong title in dashboards not belonging to a package.

  • Other

    • Multiple clients might trigger concurrent computation of the result step for a shared query. This issue has been fixed: now only one pending computation is allowed at a time.

Falcon LogScale 1.133.0 Preview (2024-04-09)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.133.0Preview2024-04-09

Cloud

On-Prem

2025-05-31No1.10617-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

New features and improvements

  • Installation and Deployment

    • The LogScale Launcher Script now sets -XX:+UseTransparentHugePages as part of the mandatory flags. THP is already enabled for all processes on many Linux distributions by default. This flag enables THP on systems where processes must opt into THP via madvise. We strongly recommend enabling THP for LogScale.

  • Automation and Alerts

  • Storage

    • The bucket transfer prioritization has been adjusted. When behind on both uploads and downloads, 75% of the S3_STORAGE_CONCURRENCY capacity is reserved for uploads, and 25% for downloads, rather than using all slots for downloads.

  • Functions

    • The optional limit parameter has been added to the readFile() function to limit the number of rows of the file returned.

  • Other

    • Queries are now allowed to be queued for start by the query coordinator for a maximum of 10 minutes.

      For more information, see Query Coordination.

Fixed in this release

  • UI Changes

    • The error Failed to fetch data for aliased fields would sometimes appear on the Search page of the sandbox repository. This issue has been fixed.

    • Fixed an issue that prevented users from copying the query string from the flyout in the Recent / Saved queries panel.

  • Storage

    • redactEvents segment rewriting has been fixed for several issues that could cause either failure to complete the rewrite, or events to be missed in rare cases. Users should be aware that redaction jobs that were submitted prior to upgrading to a fixed version may fail to complete correctly, or may miss events. Therefore, you are encouraged to resubmit redactions you have recently submitted, to ensure the events are actually gone.

  • Dashboards and Widgets

    • Parameters appearing between a string containing \\ and any other string would not be correctly detected. This issue has been fixed.

  • Packages

    • Uploading a package zip would fail on Windows devices. This issue has been fixed.

Improvement

  • Storage

    • Removed some work from the thread scheduling bucket transfers that could be slightly expensive in cases where the cluster had fallen behind on uploads.

  • Configuration

    • Whenever a SAML or OIDC IdP is created or updated, any leading or trailing whitespace will be trimmed from its fields. This is to avoid configuration errors.

Falcon LogScale 1.132.0 Preview (2024-04-02)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.132.0Preview2024-04-02

Cloud

On-Prem

2025-05-31No1.10617-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • The LogScale Launcher Script script for starting LogScale will be modified to change the way CPU core usage can be configured. The -XX:ActiveProcessorCount=n command-line option will be ignored if set. Users that need to configure the core count manually should set CORES=n environmant variable instead. This will cause the launcher to configure both LogScale and the JVM properly.

      This change is scheduled for 1.148.0.

      For more information, see Configuring Available CPU Cores.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • The following API endpoints are deprecated and marked for removal in 1.148.0:

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment

    • GET /api/v1/clusterconfig/kafka-queues/partition-assignment

    • POST /api/v1/clusterconfig/kafka-queues/partition-assignment/set-replication-defaults

    The deprecated methods are used for viewing and changing the partition assignment in Kafka for the ingest queue. Administrators should use Kafka's own tools for editing partition assignments instead, such as the bin/kafka-reassign-partitions.sh and bin/kafka-topics.sh scripts that ship with the Kafka install.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The HUMIO_JVM_ARGS environment variable in the LogScale Launcher Script script will be removed in 1.154.0.

    The variable existed for migration from older deployments where the launcher script was not available. The launcher script replaces the need for manually setting parameters in this variable, so the use of this variable is no longer required. Using the launcher script is now the recommended method of launching LogScale. For more details on the launcher script, see LogScale Launcher Script. Clusters that still set this configuration should migrate to the other variables described at Override garbage collection configuration within the launcher script.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

New features and improvements

  • Ingestion

    • Ingest feed scheduling has been changed to be more gradual in ramping up concurrency and will also reduce concurrency in response to failures. This will make high-pressure failing ingest feeds fall back to periodic retries instead of constantly retrying.

      For more information, see Ingesting Data from AWS S3.

  • Functions

    • For Cloud customers: the maximum value of the limit parameter for tail() and head() functions has been increased to 20,000.

    • For Self-Hosted solutions: the maximum value of the limit parameter for tail() and head() functions has been aligned with the StateRowLimit dynamic configuration. This means that the upper value of limit is now adjustable for these two functions.

  • Other

    • New metrics ingest-queue-write-offset and ingest-queue-read-offset have been added, reporting the Kafka offsets of the most recently written and read events on the ingest queue.

    • New metric events-parsed has been added, serving as an indicator for how many input events a parser has been applied to.

Fixed in this release

  • Security

    • Various OIDC caching issues have been fixed including ensuring refresh of the JWKS cache once per hour by default.

Improvement

  • Installation and Deployment

    • An error log is displayed if the latency on global-events exceeds 150 seconds, to prevent nodes from crashing.

Falcon LogScale 1.131.2 Stable (2024-05-14)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.131.2Stable2024-05-14

Cloud

On-Prem

2025-04-30No1.10617-21No
TAR ChecksumValue
MD5e35c49087dcc810d4b2a636f116e3aff
SHA1cb77fc4309aa57d22903eb33647e4b909eb428fe
SHA256f38d06a4ad1a3cffb65af1f935c737d8b9e4568debf8df1624bf86365f5c31ee
SHA51279ff9cf7e16753537e551eb486003c45f88e1a20adf99ee6e977f1dfd534bf889c8be74e9f4ef6f9624733b82f19b7772b123f454668871601756c7aa1c0fe35
Docker ImageIncluded JDKSHA256 Checksum
humio21183d1bb7618a662c06febe4257d320123e8a916f18c0db9806d37317093af540
humio-core21452d98fd6cf99a0404ee7f7d81898a67276afa63312aba9cf2a53f5bea36a383
kafka2187c87d012ec4f461ec64764b4c01e07bb1b17357f74fc8fcdb3839792b421605
zookeeper214ec1a15874dc1b4065cd18359c3f419b337d4796b0718a6b4827af329a72a719

Download: https://repo.humio.com/repository/maven-releases/com/humio/server/1.131.2/server-1.131.2.tar.gz

Bug fixes and updates.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

New features and improvements

  • UI Changes

    • Time zone data has been updated to IANA 2024a and has been trimmed to +/- 5 years from the release date of IANA 2024a.

Fixed in this release

  • Packages

    • Uploading a package zip would fail on Windows devices. This issue has been fixed.

Falcon LogScale 1.131.1 Stable (2024-04-17)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.131.1Stable2024-04-17

Cloud

On-Prem

2025-04-30No1.10617-21No
TAR ChecksumValue
MD54a9223ff7d628a52257783b70b084726
SHA13666c2ac1eea45e07ea9a89f0c16eafffebc1e01
SHA2565eb83a4ee2c9a8792f1ac1ec9ddad9282a5e9e98d523a77556762eded9fd50ad
SHA51286000582f6b4134f85943ae2385b0b17113f241f988864c9113f2df639f4a2f97a6eba69edb305ec57e2e0db53578a79fb7f54aa15b9acd909092d8cc88f1438
Docker ImageIncluded JDKSHA256 Checksum
humio21adcf2fea3d8f9c10b764a73577959eeb5c58cdb2955e69846b26effc5758e0b9
humio-core212985c7ec6bde2f3c8904f71d238e7fdd70547c9d71488aea997acb89cf2d15ec
kafka21262c7e74062a32cecee9119836752ee6310662d570f80926e7dd36dcb785d380
zookeeper21b9b0349704cc996701c65cf713c1584c0b5db7f70cb00d53bf1051c50e0e99ab

Download: https://repo.humio.com/repository/maven-releases/com/humio/server/1.131.1/server-1.131.1.tar.gz

Bug fixes and updates.

Removed

Items that have been removed as of this release.

GraphQL API

  • The enabledFeatures() query has been removed from GraphQL schema. Use featureFlags() query instead.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

Behavior Changes

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

  • Security

    • DNS caches are now invalidated after 60 seconds instead of never. To override this behavior, set the security policy networkaddress.cache.ttl in the security manager of the JRE (see Java Networking Properties).

  • Ingestion

    • It is no longer possible to delete a parser that is being used in an ingest feed. The parser must first be removed from the ingest feed.

      For more information, see Deleting an Ingest Feed.

New features and improvements

  • Upgrades

    • The minimum version required to upgrade from has been raised to 1.106, in order to allow removing some workarounds for compatibility with old versions.

  • Security

    • Added support for authorizing with an external JWT from an IdP setup in our cloud environment.

    • The audience for dynamic OIDC IdPs in our cloud environments are now logscale-$orgId, where $orgId is the ID of your organization.

    • Added support for Oktas federated IdP OIDC extension to identity providers setup in cloud.

  • Automation and Alerts

    • Throttling and field-based throttling are introduced as optional functionalities in Filter Alerts. The minimum throttling period is 1 minute.

    • The customizable trigger limit for Filter Alerts is removed. The trigger limit is now automatically determined based on the associated actions. If one or more email actions are associated, the trigger limit will be 15, otherwise, the trigger limit will be 100. Any existing customizable trigger limit of 1 will be treated as a throttling period of 1 minute, all other custom trigger limits will be ignored. This is a non-backwards compatible change to the GraphQL APIs for Filter Alerts, so any automation for these alerts must be updated.

  • GraphQL API

  • Configuration

    • The new dynamic configuration MaxOpenSegmentsOnWorker is implemented to control hard cap on open segment files for the scheduler. The scheduler should in most cases not reach this limit and it only acts as a backstop. Therefore, we recommend that administrators do not modify this setting unless advised to do so by CrowdStrike Support.

    • Authorization attempted via JWT tokens will now only try to grab user information from the user info endpoint if the scope in the access token contains any of the following: profile, email, openid. If no such scope is located in the token, LogScale will try to extract the username from the token and no other user details will be added. We will extract the scope claim based on the new environment variable OIDC_SCOPE_CLAIM, whose default is scope.

  • Ingestion

  • Functions

    • The parseTimestamp() function is now able to parse timestamps with nanosecond precision.

    • The setField() query function is introduced. It takes two expressions, target and value and sets the field named by the result of the target expression to the result of the value expression. This function can be used to manipulate fields whose names are not statically known, but computed at runtime.

      For more information, see setField().

    • The getField() query function is introduced. It takes an expression, source, and sets the field defined by as to the result of the source expression. This function can be used to manipulate fields whose names are not statically known, but computed at runtime.

      For more information, see getField().

  • Other

    • The default IP filter for IdP and RDNS operations is now more restrictive: the rdns() now defaults to denying lookups of reserved IP ranges and the filter has been updated to deny additional reserved IP ranges, as specified by the IANA. Self hosted administrators can specify their own filters by using the environment variables IP_FILTER_IDP, IP_FILTER_RDNS, and IP_FILTER_RDNS_SERVER respectively.

    • The split by AWS record setting within ingest feeds will now accept numbers with leading zeros.

    • The missing-cluster-nodes metric will now track the nodes that are missing heartbeat data in addition to the nodes that have outdated heartbeat data. The new missing-cluster-nodes-stateful metric will track the registered nodes with outdated/missing heartbeat data that can write to global.

      For more information, see Node-Level Metrics.

    • Queries are now allowed to be queued for start by the query coordinator for a maximum of 10 minutes.

      For more information, see Query Coordination.

Fixed in this release

  • UI Changes

    • Field aliases could not be read on the sandbox repository. This issue is now fixed.

    • CSV files produced by LogScale for sending as attachments from email actions or uploaded through a LogScale Repository action could contain values where part of the text was duplicated. This would only happen for values that needed to be quoted. This issue is now fixed.

  • Automation and Alerts

    • Filter Alerts with field-based throttling could trigger on two events with the same value for the throttle field, if actions were slow. This issue is now fixed.

  • Ingestion

    • Cloning a parser from the UI would not clone the fields to be removed before parsing. This issue is now fixed.

    • Fixed an issue that prevented the creation of Netflow/UDP protocol ingest listeners.

  • Dashboards and Widgets

    • A dashboard with fixed shared time as default would not update correctly when selecting a new relative time. This issue is now fixed.

  • Other

    • An issue with the IOC Configuration causing the local database to update too often has now been fixed.

    • Multiple clients might trigger concurrent computation of the result step for a shared query. This issue has been fixed: now only one pending computation is allowed at a time.

  • Packages

    • Updating a package could fail, if one of the assets from the package had been deleted from the view where the package was installed. This issue has been fixed.

    • When attempting to upload a package disguised as a folder, some browsers would get a generic error messages. To fix this issue, only zip files are accepted now.

Public Preview

Improvement

  • Storage

    • Moved the work of creating a global snapshot for upload to bucket storage from the thread coordinating segment uploads/downloads to a separate thread. This improves the reliability of uploading and download the global snapshot to/from bucket storage.

    • SegmentChangesJobTrigger has been disabled on nodes configured to not be able to store segments, thus saving some CPU time.

  • Configuration

    • The default value for AUTOSHARDING_MAX has changed from 128 to 1,024.

    • The default maximum limit for groupBy() has been increased from 200,000 to 1,000,000, meaning that this function can now be asked to collect up to a million groups. However, due to stability concerns it will not allow groupBy() to return the full million rows as a result when this function is the last aggregator: this is governed by the QueryResultRowCountLimit dynamic configuration, which remains unchanged. Therefore, this new limit is best utilized when groupBy() is used as a computational tool for creating groups that are then later aggressively filtered and/or aggregated down in size. If you experience resource strain or starvation on your cluster, you can reduce the maximum limit via the GroupMaxLimit dynamic configuration.

    • The default value for AUTOSHARDING_TRIGGER_DELAY_MS has changed from 1 hour to 4 hours.

    • The default memory limit for the query coordinator node has been increased from 400 MB to 4 GB. This new limit allows each query to use up to 1 GB of memory and thus produce more results, at the cost of taking up more resources. This in turn indirectly limits the amount of concurrent queries as the query scheduler may choose not to run a given query before existing queries have completed. If you experience resource strain or starvation on your cluster, you can reduce the memory limit by setting the QueryCoordinatorMemoryLimit dynamic configuration to 400,000,000.

  • Functions

    • Live queries now restart and run with the updated version of a saved query when the saved query changes.

      For more information, see User Functions (Saved Searches).

    • Reduction of memory requirements when processing empty arrays in functions that accept them. This helps reduce the memory required to use these functions with empty arrays.

  • Other

    • Improved handling of segments being replaced due to either merging or event redaction, to address rare cases of event duplication when segments are replaced multiple times shortly after each other.

Falcon LogScale 1.131.0 Preview (2024-03-26)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.131.0Preview2024-03-26

Cloud

On-Prem

2025-04-30No1.10617-21No

Bug fixes and updates.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

Behavior Changes

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

  • Storage

    • We've removed a throttling behavior that prevented background merges of minisegments from running when digest load is high. Such throttling can cause global in the LogScale cluster to grow over time if the digest load isn't transient, which is undesirable.

    • Registering local segment files is skipped on nodes that are configured to not have storage via their node role.

    • When booting a node, wait until we've caught up to the top of global before publishing the start message. This should help avoid global publish timeouts on boot when global has a lot of traffic.

    • Moving minisegments to the digest leader in cases where it is not necessary is now avoided. This new behavior reduces global traffic on digest reassignment.

New features and improvements

  • UI Changes

    • The parser test window width can now be resized.

  • Other

    • The metrics endpoint for the scheduled report render node has been updated to output the Prometheus text based format.

Fixed in this release

  • UI Changes

    • Duplicate HTML escape has been removed to prevent recursive field references having double escaped formatting in emails.

  • Storage

    • We've fixed a rarely hit error in the query scheduler causing a ClassCastException for scala.runtime.Nothing..

  • Functions

    • join() function has been fixed as warnings of the sub-query would not propagate to the main-query result.

    • Serialization of very large query states would crash nodes by requesting an array larger than what the JVM can allocate. This issue has been fixed.

Public Preview

Improvement

  • Storage

    • Concurrency for segment merging is improved, thus avoiding some unnecessary and inefficient pauses in execution.

    • We've switched to running the RetentionJob in a separate thread from DataSyncJob. This should enable more consistent merging.

    • The RetentionJob work is now divided among nodes such that there's no overlap. This reduces traffic in global.

    • An internal limit on use of off-heap memory has been adjusted to allow more threads to perform segment merging in parallel.

  • Functions

    • Some performance improvements have been made to the join() function, allowing it to skip blocks that do not contain the specified fields of the main and sub-query.

Falcon LogScale 1.130.0 Preview (2024-03-19)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.130.0Preview2024-03-19

Cloud

On-Prem

2025-04-30No1.10617-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

Behavior Changes

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

  • Security

    • DNS caches are now invalidated after 60 seconds instead of never. To override this behavior, set the security policy networkaddress.cache.ttl in the security manager of the JRE (see Java Networking Properties).

New features and improvements

  • Functions

    • The parseTimestamp() function is now able to parse timestamps with nanosecond precision.

Fixed in this release

  • Automation and Alerts

    • Filter Alerts with field-based throttling could trigger on two events with the same value for the throttle field, if actions were slow. This issue is now fixed.

  • Dashboards and Widgets

    • A dashboard with fixed shared time as default would not update correctly when selecting a new relative time. This issue is now fixed.

Public Preview

Improvement

  • Storage

    • Moved the work of creating a global snapshot for upload to bucket storage from the thread coordinating segment uploads/downloads to a separate thread. This improves the reliability of uploading and download the global snapshot to/from bucket storage.

  • Functions

    • Reduction of memory requirements when processing empty arrays in functions that accept them. This helps reduce the memory required to use these functions with empty arrays.

Falcon LogScale 1.129.0 Preview (2024-03-12)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.129.0Preview2024-03-12

Cloud

On-Prem

2025-04-30No1.10617-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Removed

Items that have been removed as of this release.

GraphQL API

  • The enabledFeatures() query has been removed from GraphQL schema. Use featureFlags() query instead.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

  • The following GraphQL queries and mutations for interacting with parsers are deprecated and scheduled for removal in version 1.142.

    • The deprecated createParser mutation is replaced by createParserV2(). The differences between the old and new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • fieldsToBeRemovedBeforeParsing can now be specified as part of the parser creation.

      • force field is renamed to allowOverwritingExistingParser.

      • sourceCode field is renamed to script.

      • tagFields field is renamed to fieldsToTag.

      • languageVersion is no longer an enum, but a LanguageVersionInputType instead.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    • The deprecated removeParser mutation is replaced by deleteParser. The difference between the old and new mutation is:

      • The mutation returns boolean to represent success or failure, instead of a Parser wrapped in an object.

    • The deprecated testParser mutation is replaced by testParserV2(). The differences between the old and new mutation are:

      • The test cases are now structured types, instead of just being strings. To emulate the old API, take the test string and put it in the ParserTestEventInput inside the ParserTestCaseInput, and they will behave the same as before.

      • The new test cases can contain assertions about the contents of the output.

      • The mutation output is significantly different from before, as it provides more detailed information on how a test case has failed.

      • The mutation now accepts both a language version and list of fields to be removed before parsing.

      • The parserScript field is renamed to script.

      • The tagFields field is renamed to fieldsToTag.

    • The deprecated updateParser mutation is replaced by updateParserV2() where more extensive test cases can be set. Continuing to use the previous API may result in test information on parsers being lost. To ensure information is not unintentionally erased, please migrate away from the deprecated APIs for both reading and updating parser test cases and use updateParserV2() instead. The differences between the previous and the new mutation are:

      • testData input field is replaced by testCases, which can contain more data than the old tests could. This includes adding assertions to the output of a test. These assertions are not displayed in the UI yet. To emulate the old API, you can take the old test string and put it in the `ParserTestEventInput` inside the `ParserTestCaseInput`, and they will behave the same as before.

      • sourceCode field, used to updating the parser script, is changed to the script field, which takes a UpdateParserScriptInput object. This updates the parser script and the language version together.

      • tagFields field is renamed to fieldsToTag.

      • The languageVersion is located inside the UpdateParserScriptInput object, and is no longer an enum, but a LanguageVersionInputType instead.

      • The repositoryName and id fields are now correctly marked as mandatory in the schema. Previously this wasn't the case, even though the mutation would fail without them.

      • The mutation returns a Parser, instead of a Parser wrapped in an object.

      • The old mutation had a bug where it would overwrite the languageVersion with a default value in some cases, which is fixed in the new one.

      • The mutation fails when a parser has more than 2,000 test cases, or the test input in a single test case exceeds 40,000 characters.

    On the Parser type:

    • testData field is deprecated and replaced by testCases.

    • sourceCode field is deprecated and replaced by script.

    • tagFields field is deprecated and replaced by fieldsToTag.

    For more information, see Parser, DeleteParserInput, LanguageVersionInputType, createParserV2(), testParserV2(), updateParserV2().

Behavior Changes

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

  • Ingestion

    • We have reverted the behavior of blocking heavy queries in case of high ingest, and returned to the behavior of only stopping the query, due to issues caused by the blockage. Heavy queries causing ingest delay will be handled differently in a future version release.

New features and improvements

  • Upgrades

    • The minimum version required to upgrade from has been raised to 1.106, in order to allow removing some workarounds for compatibility with old versions.

  • Security

    • Added support for authorizing with an external JWT from an IdP setup in our cloud environment.

    • The audience for dynamic OIDC IdPs in our cloud environments are now logscale-$orgId, where $orgId is the ID of your organization.

    • Added support for Oktas federated IdP OIDC extension to identity providers setup in cloud.

  • Automation and Alerts

    • Throttling and field-based throttling are introduced as optional functionalities in Filter Alerts. The minimum throttling period is 1 minute.

    • The customizable trigger limit for Filter Alerts is removed. The trigger limit is now automatically determined based on the associated actions. If one or more email actions are associated, the trigger limit will be 15, otherwise, the trigger limit will be 100. Any existing customizable trigger limit of 1 will be treated as a throttling period of 1 minute, all other custom trigger limits will be ignored. This is a non-backwards compatible change to the GraphQL APIs for Filter Alerts, so any automation for these alerts must be updated.

  • GraphQL API

  • Configuration

    • Authorization attempted via JWT tokens will now only try to grab user information from the user info endpoint if the scope in the access token contains any of the following: profile, email, openid. If no such scope is located in the token, LogScale will try to extract the username from the token and no other user details will be added. We will extract the scope claim based on the new environment variable OIDC_SCOPE_CLAIM, whose default is scope.

  • Ingestion

  • Other

    • The default IP filter for IdP and RDNS operations is now more restrictive: the rdns() now defaults to denying lookups of reserved IP ranges and the filter has been updated to deny additional reserved IP ranges, as specified by the IANA. Self hosted administrators can specify their own filters by using the environment variables IP_FILTER_IDP, IP_FILTER_RDNS, and IP_FILTER_RDNS_SERVER respectively.

    • The split by AWS record setting within ingest feeds will now accept numbers with leading zeros.

Fixed in this release

  • Ingestion

    • Cloning a parser from the UI would not clone the fields to be removed before parsing. This issue is now fixed.

Improvement

  • Other

    • Improved handling of segments being replaced due to either merging or event redaction, to address rare cases of event duplication when segments are replaced multiple times shortly after each other.

Falcon LogScale 1.128.0 Preview (2024-03-05)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.128.0Preview2024-03-05

Cloud

On-Prem

2025-04-30No1.70.017-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

New features and improvements

  • Configuration

    • The new dynamic configuration MaxOpenSegmentsOnWorker is implemented to control hard cap on open segment files for the scheduler. The scheduler should in most cases not reach this limit and it only acts as a backstop. Therefore, we recommend that administrators do not modify this setting unless advised to do so by CrowdStrike Support.

Fixed in this release

  • UI Changes

    • CSV files produced by LogScale for sending as attachments from email actions or uploaded through a LogScale Repository action could contain values where part of the text was duplicated. This would only happen for values that needed to be quoted. This issue is now fixed.

  • Packages

    • When attempting to upload a package disguised as a folder, some browsers would get a generic error messages. To fix this issue, only zip files are accepted now.

Improvement

Falcon LogScale 1.127.0 Preview (2024-02-27)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.127.0Preview2024-02-27

Cloud

On-Prem

2025-04-30No1.70.017-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

New features and improvements

  • Functions

    • The setField() query function is introduced. It takes two expressions, target and value and sets the field named by the result of the target expression to the result of the value expression. This function can be used to manipulate fields whose names are not statically known, but computed at runtime.

      For more information, see setField().

    • The getField() query function is introduced. It takes an expression, source, and sets the field defined by as to the result of the source expression. This function can be used to manipulate fields whose names are not statically known, but computed at runtime.

      For more information, see getField().

Fixed in this release

Improvement

  • Configuration

    • The default maximum limit for groupBy() has been increased from 200,000 to 1,000,000, meaning that this function can now be asked to collect up to a million groups. However, due to stability concerns it will not allow groupBy() to return the full million rows as a result when this function is the last aggregator: this is governed by the QueryResultRowCountLimit dynamic configuration, which remains unchanged. Therefore, this new limit is best utilized when groupBy() is used as a computational tool for creating groups that are then later aggressively filtered and/or aggregated down in size. If you experience resource strain or starvation on your cluster, you can reduce the maximum limit via the GroupMaxLimit dynamic configuration.

    • The default memory limit for the query coordinator node has been increased from 400 MB to 4 GB. This new limit allows each query to use up to 1 GB of memory and thus produce more results, at the cost of taking up more resources. This in turn indirectly limits the amount of concurrent queries as the query scheduler may choose not to run a given query before existing queries have completed. If you experience resource strain or starvation on your cluster, you can reduce the memory limit by setting the QueryCoordinatorMemoryLimit dynamic configuration to 400,000,000.

  • Functions

    • Live queries now restart and run with the updated version of a saved query when the saved query changes.

      For more information, see User Functions (Saved Searches).

Falcon LogScale 1.126.0 Preview (2024-02-20)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.126.0Preview2024-02-20

Cloud

On-Prem

2025-04-30No1.70.017-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

New features and improvements

  • Configuration

    • Ingest rate monitoring for autosharding improved. For clusters with more than 10 nodes, only a subset of the nodes will be reporting their ingest rate for any given datasource, and the total rate for each datasource estimated based on that. The dynamic configuration TargetMaxRateForDatasource still sets the threshold for sharding; however, once the rate is exceeded, it is no longer needed to be twice the TargetMaxRateForDatasource configuration before shards are added.

  • Ingestion

    • Ingest feeds can read from an AWS SQS queue that has been populated with AWS SNS subscription events.

      For more information, see Ingesting Data from AWS S3.

Fixed in this release

  • UI Changes

    • Field aliases could not be read on the sandbox repository. This issue is now fixed.

  • Other

    • An issue with the IOC Configuration causing the local database to update too often has now been fixed.

  • Packages

    • Updating a package could fail, if one of the assets from the package had been deleted from the view where the package was installed. This issue has been fixed.

Falcon LogScale 1.125.0 Preview (2024-02-13)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.125.0Preview2024-02-13

Cloud

On-Prem

2025-04-30No1.70.017-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The any argument to the type parameter of sort() and table() has been deprecated and will be removed in version 1.142.

    Warnings prompts will be shown in queries that fall into either of these two cases:

    • If you are explicitly supplying an any argument, please either simply remove both the parameter and the argument, for example change sort(..., type=any) to sort(...) or supply the argument for type that corresponds to your data.

    • If you are sorting hexadecimal values by their equivalent numerical values, please change the argument of type parameter to hex e.g. sort(..., type=hex).

    In all other cases, no action is needed.

    The new default value for sort() and table() will be number. Both functions will fall back to lexicographical ordering for values that cannot be understood as the provided argument for type.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

Behavior Changes

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

  • Ingestion

    • It is no longer possible to delete a parser that is being used in an ingest feed. The parser must first be removed from the ingest feed.

      For more information, see Deleting an Ingest Feed.

New features and improvements

  • Other

    • The missing-cluster-nodes metric will now track the nodes that are missing heartbeat data in addition to the nodes that have outdated heartbeat data. The new missing-cluster-nodes-stateful metric will track the registered nodes with outdated/missing heartbeat data that can write to global.

      For more information, see Node-Level Metrics.

Improvement

  • Storage

    • Allowed reassignment of digest that assigns partitions unevenly to hosts. This is to support clusters where hosts are not evenly sized, and so an even partition assignment is not expected.

    • SegmentChangesJobTrigger has been disabled on nodes configured to not be able to store segments, thus saving some CPU time.

Falcon LogScale 1.124.3 Stable (2024-05-14)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.124.3Stable2024-05-14

Cloud

On-Prem

2025-03-01No1.70.017-21No
TAR ChecksumValue
MD5730dd2226aa23d325b7fecc7f7ee4138
SHA13fdde9ee0728eace9808f845504c9f584d0da81f
SHA256fd5d88be54cc487db542d4c3dad3072913edad50540e0fe2e14487ee26525d0b
SHA51222377e496e6cd0abd4aac0c6fba41d35596703246d98d0e2dcd8ddb026127a6fce4a2fa4bad6e46682f0686508b58c5c13ad23db8ad3554356b157aeb6c95e0e
Docker ImageIncluded JDKSHA256 Checksum
humio2184fb05447e3776cace395a8799a17476aca125bc7b4ee50d515a4e3aa89d3282
humio-core2181b999f222d55ca6c36a05fbb1237444a6de91997eef7520cd208d16a7d29618
kafka21b375c5ce0bbfbc3dea1fa2fbaa2be5cc66b2c59dd38710c1b09acdbce176a40f
zookeeper21e054e07d2ba316b0c9e59699b420f37bac2057e39516f5a7263d46c13628dc26

Download: https://repo.humio.com/repository/maven-releases/com/humio/server/1.124.3/server-1.124.3.tar.gz

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

New features and improvements

  • UI Changes

    • Time zone data has been updated to IANA 2024a and has been trimmed to +/- 5 years from the release date of IANA 2024a.

Falcon LogScale 1.124.2 Stable (2024-03-20)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.124.2Stable2024-03-20

Cloud

On-Prem

2025-03-01No1.70.017-21No
TAR ChecksumValue
MD5b66d180a49887e3cbb65b5315e835579
SHA13be945d1557a751eb690f5c0a6dca940095aa1f3
SHA256588f89b0de65413dad67c96653d4debdeb2f9012299a1c237040f64c8c48bf5c
SHA512a5504f59b9d42a6c28d9ad6cc3e98c0ef1db16286412cc15d4f9114f01c0249ba152b92ab5c8c94d3a1155f80209042891a23a1780feaa2928fab9c2a5c14390
Docker ImageIncluded JDKSHA256 Checksum
humio21b75ee983542ee41303143cd18e2b7dab0ac0e9a06a667a027f1eb4cfb3e40c23
humio-core2189a299ad54f71b0dce43e3149362c336739bc3002e5f45decd1512282bcf4ef9
kafka219e170eff22a95031a763af235b1cb11ff560a07167136ceaa2e31bb127bc9779
zookeeper215809022af39312ef3352365ab63aeaa81844f74717411a9338e32516b0be91d7

Download: https://repo.humio.com/repository/maven-releases/com/humio/server/1.124.2/server-1.124.2.tar.gz

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

Behavior Changes

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

  • Ingestion

    • We have reverted the behavior of blocking heavy queries in case of high ingest, and returned to the behavior of only stopping the query, due to issues caused by the blockage. Heavy queries causing ingest delay will be handled differently in a future version release.

Fixed in this release

  • Other

    • Fixed a bug in which the second poll inside the cluster could be delayed by upwards of 10 seconds. This fix ensures that the time between polls will never be later than the start time of the query, this means that early polls will not be delayed too much, enabling faster query responses.

Falcon LogScale 1.124.1 Stable (2024-02-29)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.124.1Stable2024-02-29

Cloud

On-Prem

2025-03-01No1.70.017-21No
TAR ChecksumValue
MD57cb9867805e79bf88d9a8824b94bd717
SHA145e7db8dc5e8371351d8abea91b0d0b8c3560cf0
SHA2564dd76bb4abd36b13350a509d57d7d3867f317cd1910a50e677c52db86e377b79
SHA512bc02e36be4a077b4cd3c210f2fe8eda63674334c9c47847fa1a0df0cdc21d24973daab9ab2078187f35093238a0932fcb19fd06b89aa4238d5a70b88066174b4
Docker ImageIncluded JDKSHA256 Checksum
humio21fef66d15aed2ee6f2b5e48a332b7d08119ed6901450a165a8f78de0f452a9ac6
humio-core21afafad52ac55c06fbd841a025a917b4445fd458b501797ed02886808773d2fa1
kafka219390b66e795e152a6bc70055603e14a41ae2d5064e4942de16c8ec3eb65d9dd4
zookeeper21c7fec5d72136886e971acf69a1faa8bfd81b126c426d77b1e6a992b82fc3b64b

Download: https://repo.humio.com/repository/maven-releases/com/humio/server/1.124.1/server-1.124.1.tar.gz

Bug fixes and updates.

Breaking Changes

The following items create a breaking change in the behavior, response or operation of this release.

  • Functions

    • The default accuracy of the percentile() function has been adjusted. This means that any query that does not explicitly set the accuracy may see a change in reported percentile. Specifically, the percentile() function may now deviate by up to one 100th of the true percentile, meaning that if a given percentile has a true value of 1000, percentile() may report a percentile in the range of [990; 1010].

      On the flip side, percentile() now uses less memory by default, which should allow for additional series or groups when this function is used with either timeChart() or groupBy() and the default accuracy is used.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Removed

Items that have been removed as of this release.

GraphQL API

  • Removed the Asset interface type in GraphQL that Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes implemented. It was not used as a type for any field. All fields from the Asset interface type are still present in the implementing types.

Configuration

  • The DEFAULT_PARTITION_COUNT configuration parameter has been removed, as it was unused by the system due to earlier changes to partition handling.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • The QUERY_COORDINATOR environment variable is deprecated. To control whether a node should be allowed to be a query coordinator, use the query node task instead. Node tasks can be assigned and unassigned at runtime using the assignTasks() and unassignTasks() GraphQL mutations respectively, or controlled using the INITIAL_DISABLED_NODE_TASKS environment variable.

    For more information, see INITIAL_DISABLED_NODE_TASK.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

Behavior Changes

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

  • Storage

    • We have adjusted the code that calculates where to start reading from the ingest queue to be more conservative. It will no longer allow for skipping past segments that are not fully replicated when later segments on the same datasource are fully replicated. This fixes a very rare edge case that could cause data loss on clusters using ephemeral disks. Due to the changed behavior, any segment failing to properly replicate will now cause LogScale to stop deleting data from the affected Kafka partition. Cluster administrators are strongly encouraged to monitor this case, by keeping under observation Kafka's disk usage.

Upgrades

Changes that may occur or be required during an upgrade.

  • Other

    • Kafka client library has been upgraded to 3.6.1. Some minor changes have been made to serializers used by LogScale to reduce memory copying.

New features and improvements

  • UI Changes

    • Time zone data has been updated to IANA 2023d.

    • Deletion of a file that is actively used by live queries will now stop those queries.

      For more information, see Exporting or Deleting a File.

    • Multi-Cluster Search — early adopter release for Self-hosted LogScale.

      • Keep the data close to the source, search from single UI

      • Search across multiple LogScale clusters in a single view

      • Support key functionalities like alerts & dashboards

      The functionality is limited to LogScale self-hosted versions at this point.

      For more information, see LogScale Multi-Cluster Search.

    • When Managing Users, it is now possible to filter users based also on their assigned roles (for example, type admin in the Users search field).

    • The Field Aliasing feature is introduced. Implementing Field Aliasing in your workflow simplifies data correlation from various sources. With this feature, users can give alternative names — aliases — to fields created at parse time, across a view, or the entire organization. It makes data interpretation more intuitive and provides analysts with a smoother search experience.

      For more information, see Field Aliasing.

  • Automation and Alerts

    • The following changes affects the UI for Standard Alerts:

      • A minimum time window of 1 minute is introduced, since anything smaller will not produce reliable results. Any existing standard alert with a time window smaller than 1 minute will not run, instead an error notification will be shown.

      • It is no longer possible to specify the time window and the throttle period in milliseconds. Any existing standard alerts with a time window or throttle period specified in milliseconds will have it rounded to the nearest second.

      • When saving the alert, the query window is automatically changed to the largest unit in the Relative Time Syntax that can represent it. For example 24h is changed to 1d and 60s is changed to 1m.

    • The ChangeTriggersAndActions permission is now replaced by two new permissions:

      • ChangeTriggers permission is needed to edit alerts or scheduled searches.

      • ChangeActions permission is needed to edit actions as well as viewing them. Viewing the name and type of actions when editing triggers is still possible without this permission.

      Any user with the legacy ChangeTriggersAndActions permissions will by default have both. It is possible to remove one of them for more granular access controls.

    • A slow-query logging has been added when an alert is slow to start due to the query not having finished the historical part.

  • GraphQL API

    • Added limits for GraphQL queries on the total number of selected fields and fragments. Defaults are 1000 for authenticated and 150 for unauthenticated users.

      Cluster administrators can adjust these limits with the GraphQLSelectionSizeLimit and UnauthenticatedGraphQLSelectionSizeLimit dynamic configurations.

  • Storage

  • Configuration

    • The meaning of S3_STORAGE_CONCURRENCY and GCP_STORAGE_CONCURRENCY configuration variables has slightly changed. The settings are used for throttling downloads and uploads for bucket storage. Previously, a setting of S3_STORAGE_CONCURRENCY=10 for example, meant that LogScale would allow 10 concurrent uploads, and 10 concurrent downloads. Now, it means that LogScale will allow a total of 10 transfers at a time, disregarding the transfer direction.

    • New dynamic configurations have been added:

    • Ingest rate monitoring for autosharding improved. For clusters with more than 10 nodes, only a subset of the nodes will be reporting their ingest rate for any given datasource, and the total rate for each datasource estimated based on that. The dynamic configuration TargetMaxRateForDatasource still sets the threshold for sharding; however, once the rate is exceeded, it is no longer needed to be twice the TargetMaxRateForDatasource configuration before shards are added.

  • Ingestion

    • Introducing Ingest Feeds, a new pull-based ingest source that ingests logs stored in AWS S3. The files within the AWS S3 bucket can be Gzip compressed and we currently support newline delimited files and the JSON object format in which CloudTrail logs are stored in. Ingest Feeds require some configuration setup on the AWS side to get started.

      This feature is part of a gradual rollout process and may not be available on your cloud instance, but will be available to all customers in the following weeks.

      For more information, see Ingesting Data from AWS S3.

    • The limits on the size of parser test cases when exporting as templates or packages has been increased.

    • The amount of logging produced by DigestLeadershipLoggerJob has been reduced in clusters with many ingest queue partitions.

  • Dashboards and Widgets

    • A series of improvements has been added to the dashboard layout experience:

      • New widgets will be added in the topmost available space

      • When you drag widgets up, all widgets in the same column will move together

      • Improved experience when swapping the order of widgets (horizontally or vertically)

  • Log Collector

    • Groups have been added to Fleet Management for the LogScale Collector. This feature makes it possible to define dynamic groups using a filter based upon a subset of the LogScale Query Language Syntax. New Collectors enrolled into the fleet will automatically be configured based upon the groups filters they match, eliminating the need for manually assigning a configuration to every new LogScale Collector. Groups also allow you to combine multiple reusable configuration snippets.

      Additionally the management of instances has been simplified and merged into this new feature, and therefore the Assigned Instances page has been removed to favor use of the Group functions.

      For more information, see Manage Groups.

  • Functions

    • The new array:length() function has been introduced. It finds the length of an array by counting the number of array entries.

      For more information, see array:length().

  • Other

    • Live query cost metrics corrections:

      • livequeries-rate metric has changed from long to double.

      • livequeries-rate-canceled-due-to-digest-delay metric has changed from long to double.

      For more information, see Node-Level Metrics.

    • The worker-level prioritization of queries has been changed. The new prioritization will attempt to divide time evenly between all users, and divide the time given to each user evenly among that user's queries.

Fixed in this release

  • UI Changes

    • When hovering over a query function in the query editor, the link to the function's documentation now always points to the latest version of the page.

  • Automation and Alerts

    • After updating Scheduled searches where the action was failing, they would constantly fail with a None.get error until they were disabled and enabled again, or the LogScale cluster was restarted. This issue is now fixed.

  • Storage

    • Fixed an issue that could cause repositories undeleted using the mechanism described at Restoring a Repository or View to be only partially restored. Some deleted datasources within the repositories could erroneously be skipped during restoration.

      For more information, see Restoring a Repository or View.

  • Dashboards and Widgets

    • Users were prevented from exporting results of queries containing multi value parameters. This issue is now fixed.

  • Functions

    • selectLast() has been fixed for an issue that could cause this query function to miss events in certain cases.

  • Other

    • Queries in some cases would be killed as if they were blocked even though they did not match the criteria of the block. This issue is now fixed.

    • It was not possible to create a new repository with a time retention greater than 365 days. Now, the UI limit is the one that is set on the customer's organization.

      Input validation on fields when creating new repositories is now also improved.

Improvement

  • Storage

    • Allowed reassignment of digest that assigns partitions unevenly to hosts. This is to support clusters where hosts are not evenly sized, and so an even partition assignment is not expected.

  • Configuration

  • Ingestion

    • The cancelling mechanism for specific costly queries has been improved to solve cases where those queries got restarted anyway: the query with the exact match on the query string is now blocked for 5 minutes. This will free enough CPU for ingest to catch up and avoid blocking queries for too long.

Falcon LogScale 1.124.0 Preview (2024-02-06)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.124.0Preview2024-02-06

Cloud

On-Prem

2025-03-01No1.70.017-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

Behavior Changes

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

  • Storage

    • We have adjusted the code that calculates where to start reading from the ingest queue to be more conservative. It will no longer allow for skipping past segments that are not fully replicated when later segments on the same datasource are fully replicated. This fixes a very rare edge case that could cause data loss on clusters using ephemeral disks. Due to the changed behavior, any segment failing to properly replicate will now cause LogScale to stop deleting data from the affected Kafka partition. Cluster administrators are strongly encouraged to monitor this case, by keeping under observation Kafka's disk usage.

New features and improvements

  • UI Changes

    • Multi-Cluster Search — early adopter release for Self-hosted LogScale.

      • Keep the data close to the source, search from single UI

      • Search across multiple LogScale clusters in a single view

      • Support key functionalities like alerts & dashboards

      The functionality is limited to LogScale self-hosted versions at this point.

      For more information, see LogScale Multi-Cluster Search.

    • The Field Aliasing feature is introduced. Implementing Field Aliasing in your workflow simplifies data correlation from various sources. With this feature, users can give alternative names — aliases — to fields created at parse time, across a view, or the entire organization. It makes data interpretation more intuitive and provides analysts with a smoother search experience.

      For more information, see Field Aliasing.

Fixed in this release

  • Storage

    • Fixed an issue that could cause repositories undeleted using the mechanism described at Restoring a Repository or View to be only partially restored. Some deleted datasources within the repositories could erroneously be skipped during restoration.

      For more information, see Restoring a Repository or View.

Improvement

Falcon LogScale 1.123.0 Preview (2024-01-30)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.123.0Preview2024-01-30

Cloud

On-Prem

2025-03-01No1.70.017-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • We are deprecating the humio/kafka and humio/zookeeper Docker images due to low use. The planned final release for these images will be with LogScale 1.148.0.

    Better alternatives are available going forward. We recommend the following:

    • If your cluster is deployed on Kubernetes: STRIMZI

    • If your cluster is deployed to AWS: MSK

    If you still require humio/kafka or humio/zookeeper for needs that cannot be covered by these alternatives, please contact Support and share your concerns.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

New features and improvements

  • UI Changes

    • When Managing Users, it is now possible to filter users based also on their assigned roles (for example, type admin in the Users search field).

  • Automation and Alerts

    • A slow-query logging has been added when an alert is slow to start due to the query not having finished the historical part.

  • Storage

    • We have changed how LogScale handles being temporarily bottlenecked by bucket storage. Uploads are now prioritized ahead of downloads, which reduces the impact on ingest work.

  • Configuration

    • The meaning of S3_STORAGE_CONCURRENCY and GCP_STORAGE_CONCURRENCY configuration variables has slightly changed. The settings are used for throttling downloads and uploads for bucket storage. Previously, a setting of S3_STORAGE_CONCURRENCY=10 for example, meant that LogScale would allow 10 concurrent uploads, and 10 concurrent downloads. Now, it means that LogScale will allow a total of 10 transfers at a time, disregarding the transfer direction.

  • Log Collector

    • Groups have been added to Fleet Management for the LogScale Collector. This feature makes it possible to define dynamic groups using a filter based upon a subset of the LogScale Query Language Syntax. New Collectors enrolled into the fleet will automatically be configured based upon the groups filters they match, eliminating the need for manually assigning a configuration to every new LogScale Collector. Groups also allow you to combine multiple reusable configuration snippets.

      Additionally the management of instances has been simplified and merged into this new feature, and therefore the Assigned Instances page has been removed to favor use of the Group functions.

      For more information, see Manage Groups.

Fixed in this release

  • Automation and Alerts

    • After updating Scheduled searches where the action was failing, they would constantly fail with a None.get error until they were disabled and enabled again, or the LogScale cluster was restarted. This issue is now fixed.

  • Other

    • Queries in some cases would be killed as if they were blocked even though they did not match the criteria of the block. This issue is now fixed.

    • It was not possible to create a new repository with a time retention greater than 365 days. Now, the UI limit is the one that is set on the customer's organization.

      Input validation on fields when creating new repositories is now also improved.

Improvement

  • Ingestion

    • The cancelling mechanism for specific costly queries has been improved to solve cases where those queries got restarted anyway: the query with the exact match on the query string is now blocked for 5 minutes. This will free enough CPU for ingest to catch up and avoid blocking queries for too long.

Falcon LogScale 1.122.0 Preview (2024-01-23)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.122.0Preview2024-01-23

Cloud

On-Prem

2025-03-01No1.70.017-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • The humio Docker image is deprecated in favor of humio-core. humio is no longer considered suitable for production use, as it runs Kafka and Zookeeper on the same host as LogScale, which our deployment guidelines no longer recommend. The final release of humio Docker image will be in version 1.130.0.

    The new humio-single-node-demo image is an all-in-one container suitable for quick and easy demonstration setups, but which is entirely unsupported for production use.

    For more information, see Installing Using Containers.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

New features and improvements

  • UI Changes

    • Time zone data has been updated to IANA 2023d.

    • Deletion of a file that is actively used by live queries will now stop those queries.

      For more information, see Exporting or Deleting a File.

  • Automation and Alerts

    • The following changes affects the UI for Standard Alerts:

      • A minimum time window of 1 minute is introduced, since anything smaller will not produce reliable results. Any existing standard alert with a time window smaller than 1 minute will not run, instead an error notification will be shown.

      • It is no longer possible to specify the time window and the throttle period in milliseconds. Any existing standard alerts with a time window or throttle period specified in milliseconds will have it rounded to the nearest second.

      • When saving the alert, the query window is automatically changed to the largest unit in the Relative Time Syntax that can represent it. For example 24h is changed to 1d and 60s is changed to 1m.

  • Configuration

  • Dashboards and Widgets

    • A series of improvements has been added to the dashboard layout experience:

      • New widgets will be added in the topmost available space

      • When you drag widgets up, all widgets in the same column will move together

      • Improved experience when swapping the order of widgets (horizontally or vertically)

  • Other

    • Live query cost metrics corrections:

      • livequeries-rate metric has changed from long to double.

      • livequeries-rate-canceled-due-to-digest-delay metric has changed from long to double.

      For more information, see Node-Level Metrics.

Falcon LogScale 1.121.0 Preview (2024-01-16)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.121.0Preview2024-01-16

Cloud

On-Prem

2025-03-01No1.70.017-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Removed

Items that have been removed as of this release.

Configuration

  • The DEFAULT_PARTITION_COUNT configuration parameter has been removed, as it was unused by the system due to earlier changes to partition handling.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

New features and improvements

  • GraphQL API

    • Added limits for GraphQL queries on the total number of selected fields and fragments. Defaults are 1000 for authenticated and 150 for unauthenticated users.

      Cluster administrators can adjust these limits with the GraphQLSelectionSizeLimit and UnauthenticatedGraphQLSelectionSizeLimit dynamic configurations.

  • Ingestion

    • The amount of logging produced by DigestLeadershipLoggerJob has been reduced in clusters with many ingest queue partitions.

  • Functions

    • The new array:length() function has been introduced. It finds the length of an array by counting the number of array entries.

      For more information, see array:length().

Fixed in this release

  • UI Changes

    • When hovering over a query function in the query editor, the link to the function's documentation now always points to the latest version of the page.

Falcon LogScale 1.120.0 Preview (2024-01-09)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.120.0Preview2024-01-09

Cloud

On-Prem

2025-03-01No1.70.017-21No

Bug fixes and updates.

Breaking Changes

The following items create a breaking change in the behavior, response or operation of this release.

  • Functions

    • The default accuracy of the percentile() function has been adjusted. This means that any query that does not explicitly set the accuracy may see a change in reported percentile. Specifically, the percentile() function may now deviate by up to one 100th of the true percentile, meaning that if a given percentile has a true value of 1000, percentile() may report a percentile in the range of [990; 1010].

      On the flip side, percentile() now uses less memory by default, which should allow for additional series or groups when this function is used with either timeChart() or groupBy() and the default accuracy is used.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We aim to stop publishing the jar distribution of LogScale (e.g. server-1.117.jar) as of LogScale version 1.130.0.

      Users deploying via Docker images are not affected. Users deploying on bare metal should ensure they deploy the tar artifact, and not the jar artifact.

      A migration guide for bare metal deployments is available at How-To: Migrating from server.jar to Launcher Startup.

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • In the GraphQL API, the ChangeTriggersAndAction enum value for both the Permission and ViewAction enum is now deprecated and will be removed in version 1.136 of LogScale.

  • In the GraphQL API, the name argument to the parser field on the Repository datatype has been deprecated and will be removed in version 1.136 of LogScale.

Upgrades

Changes that may occur or be required during an upgrade.

  • Other

    • Kafka client library has been upgraded to 3.6.1. Some minor changes have been made to serializers used by LogScale to reduce memory copying.

New features and improvements

  • Automation and Alerts

    • The ChangeTriggersAndActions permission is now replaced by two new permissions:

      • ChangeTriggers permission is needed to edit alerts or scheduled searches.

      • ChangeActions permission is needed to edit actions as well as viewing them. Viewing the name and type of actions when editing triggers is still possible without this permission.

      Any user with the legacy ChangeTriggersAndActions permissions will by default have both. It is possible to remove one of them for more granular access controls.

  • Storage

  • Ingestion

    • Introducing Ingest Feeds, a new pull-based ingest source that ingests logs stored in AWS S3. The files within the AWS S3 bucket can be Gzip compressed and we currently support newline delimited files and the JSON object format in which CloudTrail logs are stored in. Ingest Feeds require some configuration setup on the AWS side to get started.

      This feature is part of a gradual rollout process and may not be available on your cloud instance, but will be available to all customers in the following weeks.

      For more information, see Ingesting Data from AWS S3.

Fixed in this release

  • Dashboards and Widgets

    • Users were prevented from exporting results of queries containing multi value parameters. This issue is now fixed.

  • Functions

    • selectLast() has been fixed for an issue that could cause this query function to miss events in certain cases.

Falcon LogScale 1.119.0 Preview (2023-12-19)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.119.0Preview2023-12-19

Cloud

On-Prem

2025-03-01No1.70.017-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Removed

Items that have been removed as of this release.

GraphQL API

  • Removed the Asset interface type in GraphQL that Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes implemented. It was not used as a type for any field. All fields from the Asset interface type are still present in the implementing types.

Deprecation

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

  • The assetType GraphQL field on Alert, Dashboard, Parser, SavedQuery and ViewInteraction datatypes has been deprecated and will be removed in version 1.136 of LogScale.

  • The QUERY_COORDINATOR environment variable is deprecated. To control whether a node should be allowed to be a query coordinator, use the query node task instead. Node tasks can be assigned and unassigned at runtime using the assignTasks() and unassignTasks() GraphQL mutations respectively, or controlled using the INITIAL_DISABLED_NODE_TASKS environment variable.

    For more information, see INITIAL_DISABLED_NODE_TASK.

New features and improvements

  • Ingestion

    • The limits on the size of parser test cases when exporting as templates or packages has been increased.

  • Other

    • The worker-level prioritization of queries has been changed. The new prioritization will attempt to divide time evenly between all users, and divide the time given to each user evenly among that user's queries.

Falcon LogScale 1.118.4 Stable (2024-02-23)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.118.4Stable2024-02-23

Cloud

On-Prem

2025-01-31No1.70.017-21No
TAR ChecksumValue
MD5c5be7194bc05d24ab75bf25713489193
SHA12897fbe6a80dcc312d7fc554691b7ce66f8f8530
SHA2563a841235ddecd9371e25f5982bc1928c4531f5e1a97c852c0e72236b42c229af
SHA512cf26d6782eae95f177a343f46442408201b5335006227f50f6c1a2224e9036cd12f7fdd6fb6e3bc54c08b829fb90339fe400e1599f9b36fe6ff6a4fdbf93a726
Docker ImageIncluded JDKSHA256 Checksum
humio2133877a390533ca48e8e4e6d116bb2dfb71d60832686ab02eae74b557872f0c1e
humio-core21041e91dd7869fadd60878c5610ad33a8942890f7e7014b4c90230b4661a4d362
kafka2149a9fd9441382170e71f5720a64e2841e69a77abfd7667dfe43e6cac4f38186a
zookeeper21220fe6e43ed70478b737ce98e2738d9065399b4a053771fcab66666f27a4bc13

Download: https://repo.humio.com/repository/maven-releases/com/humio/server/1.118.4/server-1.118.4.tar.gz

Bug fixes and performance improvements.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Improvement

  • Storage

    • Allowed reassignment of digest that assigns partitions unevenly to hosts. This is to support clusters where hosts are not evenly sized, and so an even partition assignment is not expected.

Falcon LogScale 1.118.3 Stable (2024-02-06)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.118.3Stable2024-02-06

Cloud

On-Prem

2025-01-31No1.70.017-21No
TAR ChecksumValue
MD5bd20b91e48cfe6dddc10b7554d6a3ad1
SHA1bba9db6f0ed1dbe63991004479e140fd88162151
SHA25605868147bf56827b465b5acb8a264e8e0ec3db29c58449002b01f2a7cdc483c4
SHA51253961c1fafa99f0075915582d221c41f8281d50050b5bb11193a4e315053c9bc0267d3dd040837245b2309f481a17807a9bacca03ce9ad3e8f5368c7be21191a

Download: https://repo.humio.com/repository/maven-releases/com/humio/server/1.118.3/server-1.118.3.tar.gz

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Removed

Items that have been removed as of this release.

API

  • The deprecated REST endpoints api/v1/dataspaces/(id)/deleteevents and /api/v1/repositories/(id)/deleteevents have been removed. You can use the redactEvents GraphQL mutation and query instead.

    For more information, see redactEvents().

New features and improvements

  • UI Changes

    • We have improved the navigation on the page for Alerts, Scheduled Searches and Actions and the page is now called Automation.

      For more information, see Automation.

  • GraphQL API

    • Added limits for GraphQL queries on the total number of selected fields and fragments. Defaults are 1000 for authenticated and 150 for unauthenticated users.

      Cluster administrators can adjust these limits with the GraphQLSelectionSizeLimit and UnauthenticatedGraphQLSelectionSizeLimit dynamic configurations.

  • Configuration

    • New configuration variables KAFKA_CLIENT_RACK_GLOBAL_TOPIC and KAFKA_CLIENT_RACK_GLOBAL_TOPIC_ENV_VAR are introduced to allow setting specific client.rack for the Kafka consumer for the global-events topic independent of the other consumers in LogScale.

      For more information, see ???, ???.

  • Ingestion

    • The amount of logging produced by DigestLeadershipLoggerJob has been reduced in clusters with many ingest queue partitions.

  • Dashboards and Widgets

    • Small multiples functionality is introduced for the Single Value, Gauge, and Pie Chart widgets. This feature allows you to partition your query result on a single dimension into multiple visuals of the same widget type for easy comparison.

      For more information, see Widgets.

    • We have added the new width option Fit to content for Event List columns. With this option selected, the width of the column depends on the content in the column.

Fixed in this release

  • Storage

    • Fixed an issue that could cause repositories undeleted using the mechanism described at Restoring a Repository or View to be only partially restored. Some deleted datasources within the repositories could erroneously be skipped during restoration.

      For more information, see Restoring a Repository or View.

  • Dashboards and Widgets

    • Users were prevented from exporting results of queries containing multi value parameters. This issue is now fixed.

Falcon LogScale 1.118.2 Stable (2024-01-17)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.118.2Stable2024-01-17

Cloud

On-Prem

2025-01-31No1.70.017-21No
TAR ChecksumValue
MD53017ca48346bd2f8144d5a5d5f2b36e9
SHA1e58c6996a2c689441c40b83ca0ac79e3d145de8b
SHA2562253c36be65768e920270970189c78c8c290e416526cf596bf9f26f057506d74
SHA5127d54033d4d3cbc830b33c94275f4296f0d7d8457042bb6358a91b5770f7a295b96c16bb52b34f75fab4cf0c64f7512a83881298d8411f49aa1ba10002a68c8e9
Docker ImageIncluded JDKSHA256 Checksum
humio21ea03778fc8ac15a2a8f8a457faf6c2172534b2b56d402bda84b0c7b5aa9404f9
humio-core2191bbcdb27c5f21d6e693716a248376efe28938ee670b6906a2552a74c744bf3e

Download: https://repo.humio.com/repository/maven-releases/com/humio/server/1.118.2/server-1.118.2.tar.gz

Bug fixes and updates.

Breaking Changes

The following items create a breaking change in the behavior, response or operation of this release.

  • Functions

    • The new parameter unit is added to formatTime() to specify whether the input field is in seconds or milliseconds, or if it should be auto-detected by the system.

      This is a breaking change: if you want to ensure fully backward-compatible behavior, set unit=milliseconds.

      For more information, see formatTime().

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Removed

Items that have been removed as of this release.

API

  • The deprecated REST endpoints api/v1/dataspaces/(id)/deleteevents and /api/v1/repositories/(id)/deleteevents have been removed. You can use the redactEvents GraphQL mutation and query instead.

    For more information, see redactEvents().

Deprecation

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

  • GraphQL mutation updateOrganizationMutability is deprecated in favor of the new setBlockIngest mutation.

Behavior Changes

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

  • Automation and Alerts

    • We have changed how Scheduled Searches handle query warnings, similar to what was done for Standard Alerts (see Falcon LogScale 1.112.0 Preview (2023-10-24)). Previously, LogScale only triggered Scheduled Searches if there were no query warnings. Now, scheduled searches will trigger despite most query warnings, and the scheduled search status will show a warning instead of an error.

      For query warnings about missing data, either due to ingest delay or some existing data that is currently unavailable, the scheduled search will retry for up to 10 minutes by default. This waiting time is configurable, see SCHEDULED_SEARCH_MAX_WAIT_FOR_MISSING_DATA for more information.

      Up until now, all query warnings were treated as errors: the scheduled search did not trigger even though it produced results, and the scheduled search was shown with an error in LogScale. Most query warnings meant that not all data was queried. The previous behaviour prevented the scheduled search from triggering in cases where it would not have, if all data had been available. For instance, a scheduled search that would trigger if a count of events dropped below a threshold. On the other hand, it made some scheduled searches not trigger, even though they would still have if all data was available. That meant that previously you would almost never have a scheduled search trigger when it should not, but you would sometimes have a scheduled search not trigger, when it should have. We have reverted this behavior.

      With this change, we no longer recommend to set the configuration option SCHEDULED_SEARCH_DESPITE_WARNINGS to true, since it treats all query warnings as non-errors, and there are a few query warnings that should make the scheduled search fail.

Upgrades

Changes that may occur or be required during an upgrade.

  • Configuration

    • We've migrated from Akka dependency component to Apache Pekko. This means that all internal logs referencing Akka will be substituted with the Pekko counterpart. Users will need to update any triggers or dashboards that rely on such logs.

      On Prem only: be aware that the Akka to Pekko migration also affects configuration field names in application.conf. Clusters that are using a custom application.conf will need to update their configuration to use the Pekko configuration names instead of the Akka configuration names.

New features and improvements

  • UI Changes

    • The Files page has a new layout and changes:

      • It has been split into two pages: one containing a list of files and one with details of each file.

      • A view limit of 100 MB has been added and you'll get an error in the UI if you try to view files larger than this size.

      • It displays information on the size limits and the step needed for syncing the imported files.

      For more information, see Files.

    • Parser test cases will automatically expand to the height of their content when loading the parser page now.

    • When selecting a parser test case, there is now a button to scroll to that test case again if you scroll away from it.

    • We have improved the navigation on the page for Alerts, Scheduled Searches and Actions and the page is now called Automation.

      For more information, see Automation.

    • Lookup Files require unique column headers to work as expected, which was previously validated when attempting to use the file. You could still install an invalid file into LogScale however, but now lookup files with duplicate header names are also blocked from being installed.

  • Automation and Alerts

    • LogScale now creates notifications for alerts and scheduled searches with warnings in addition to notifications for errors. The notifications for warnings will have a severity of warning.

    • When Filter Alerts encounter a query warning that could potentially affect the result of the alert, the warning is now saved with the alert, so that it is visible in the alerts overview, same as for Standard Alerts.

    • When clearing errors on alerts or scheduled searches, all notifications about the problem are now automatically deleted right when the error is cleared. Previously, notifications were only updated every 15 minutes. Note, that if the error returns, a new notification will be created.

  • GraphQL API

    • The redactEvents() mutation will no longer be allowed for users who have a limiting query prefix.

    • Added limits for GraphQL queries on the total number of selected fields and fragments. Defaults are 1000 for authenticated and 150 for unauthenticated users.

      Cluster administrators can adjust these limits with the GraphQLSelectionSizeLimit and UnauthenticatedGraphQLSelectionSizeLimit dynamic configurations.

    • The new setBlockIngest GraphQL mutation is introduced to block ingest for the organization and set ingest to paused in the dataspaces owned by the organization.

  • Storage

    • Handling of IOExceptions in part of the segment reading code has been improved. Such exceptions will cause the segment to be excluded from the query, and potentially refetched from bucket storage, and a warning to be shown to the user, rather than cancelling the query.

  • Configuration

    • Added validation for LOCAL_STORAGE_PERCENTAGE configuration against the targetDiskUsagePercentage, that might be set on runtime, to enforce that the LOCAL_STORAGE_PERCENTAGE variable is at least 5 percentage points larger than targetDiskUsagePercentage. Nodes that are violating this constraint will not be able to start. In addition, the setTargetDiskUsagePercentage mutation will not allow violating the constraint.

    • QueryMemoryLimit and LiveQueryMemoryLimit dynamic configurations have been replaced with QueryCoordinatorMemoryLimit, which controls the maximum memory usage of the coordinating node. This memory limit will, in turn, determine the limits of the static query state size and the live query state size. QueryCoordinatorMemoryLimit defaults to 400MB; QueryMemoryLimit and LiveQueryMemoryLimit defaults to 100MB regardless of their previous configuration.

      For more information, see General Limits & Parameters.

    • New configuration variables KAFKA_CLIENT_RACK_GLOBAL_TOPIC and KAFKA_CLIENT_RACK_GLOBAL_TOPIC_ENV_VAR are introduced to allow setting specific client.rack for the Kafka consumer for the global-events topic independent of the other consumers in LogScale.

      For more information, see ???, ???.

    • The new INITIAL_DISABLED_NODE_TASK environment variable is introduced.

      For more information, see INITIAL_DISABLED_NODE_TASK.

  • Ingestion

    • When navigating between parser test cases, the table showing the outputs for the test case will now scroll to the top when you select a new test case.

    • A new mechanism is introduced that delays the response to a HTTP ingest request from nodes that also do digest when the digest node locally experiences digest lag. The following new dynamic configurations control this mechanism:

      • DelayIngestResponseDueToIngestLagMaxFactor limits how much longer than the actual execution it may be, measured as a factor on top of the actual time spent (default is 2).

      • DelayIngestResponseDueToIngestLagThreshold sets the number of milliseconds of digest lag where the feature starts to kick in (default is 20,000).

      • DelayIngestResponseDueToIngestLagScale sets the numer of milliseconds of lag that adds 1 to the factor applied (default is 300,000).

  • Dashboards and Widgets

    • Small multiples functionality is introduced for the Single Value, Gauge, and Pie Chart widgets. This feature allows you to partition your query result on a single dimension into multiple visuals of the same widget type for easy comparison.

      For more information, see Widgets.

    • We have added the new width option Fit to content for Event List columns. With this option selected, the width of the column depends on the content in the column.

    • Show thousands separator has been added as a configuration option of format Number for the Table widget.

  • Functions

    • The new query function duration() is introduced: it can be helpful in computations involving timestamps.

    • Live queries that use files in either match(), cidr(), or lookup() functions are no longer restarted when the file is updated. Instead the files are swapped while the queries are still running.

      For more information, see Lookup Files Operations.

    • The new query function parseUri() is introduced to support parsing of URIs without a scheme.

    • The new query function if() is introduced to compute one of two expressions depending on the outcome of a test.

Fixed in this release

  • UI Changes

    • Turned the dropdown menu in the TablePage upwards and set it to the front to fix a bug where the menu would be hidden.

    • The page for creating repository or view tokens would fail to load if the user didn't have a Change IP filters Organization settings permission.

  • Automation and Alerts

    • If a filter alert, standard alert or scheduled search was assigned to run on another node in the cluster, due to changes to the available cluster nodes, they would be wrongly marked as failing with an error like The alert is broken. Save the alert again to fix it and an error log. This issue is now fixed.

    • If an error occurred where the error message was huge, the error would not be stored on the failing alert or scheduled search. This issue has been fixed.

  • GraphQL API

    • Swapped parameters in GraphQL mutation updateOrganizationMutability have been fixed.

  • Storage

  • Ingestion

    • Parser timeout errors on ingested events that would occur at shutdown have now been fixed.

    • A gap in the statistics of ingest per day experienced by some organizations on the Usage Page and in humio-usage repository, causing the graph to drop to zero, has now been fixed. As a consequence of this fix, the first measurement performed with version 1.114 will result in the graph showing a peak, since it would include statistics from the period where calculations were skipped.

    • A parser that failed to construct would sometimes result in events receiving a null error. This issue has been fixed.

    • A digest coordination issue has been fixed: it could cause minisegments to stay behind on old digest leaders when leadership changes.

  • Dashboards and Widgets

    • The Gauge widget has been fixed as the Styling panel would not display configured thresholds.

    • The options for precision and thousands separators in Table widget have been fixed as they would not be saved correctly when editing other widgets on the Search page.

    • The hovered series in TimeChart widget have been fixed as they would not be highlighted in the tooltip.

    • The legend title in widget charts has been fixed as it would offset the content when positioned to the right.

    • The Styling panel in the Table widget has been fixed as threshold coloring could be assigned unintentionally.

  • Functions

    • cidr() query function would fail to find some events when parameter negate=true was set. This incorrect behavior has now been fixed.

    • The cidr() function would handle a validation error incorrectly. This issue has been fixed.

    • The count() function with distinct parameter would give an incorrect count for utf8 strings. This issue has been fixed.

    • timeChart() and bucket() functions have been fixed as they would give slightly different results depending on whether their limit argument was left out or explicitly set to the default value.

  • Other

    • Occasional error logging from QueryScheduler.reduceAndSetSnapshot has been fixed.

Falcon LogScale 1.118.1 Internal (2023-12-20)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.118.1Internal2023-12-20

Cloud

On-Prem

2025-01-31No1.70.017-21No

Internal only release.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Falcon LogScale 1.118.0 Preview (2023-12-12)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.118.0Preview2023-12-12

Cloud

On-Prem

2025-01-31No1.70.017-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Removed

Items that have been removed as of this release.

API

  • The deprecated REST endpoints api/v1/dataspaces/(id)/deleteevents and /api/v1/repositories/(id)/deleteevents have been removed. You can use the redactEvents GraphQL mutation and query instead.

    For more information, see redactEvents().

New features and improvements

  • UI Changes

    • We have improved the navigation on the page for Alerts, Scheduled Searches and Actions and the page is now called Automation.

      For more information, see Automation.

  • Configuration

    • New configuration variables KAFKA_CLIENT_RACK_GLOBAL_TOPIC and KAFKA_CLIENT_RACK_GLOBAL_TOPIC_ENV_VAR are introduced to allow setting specific client.rack for the Kafka consumer for the global-events topic independent of the other consumers in LogScale.

      For more information, see ???, ???.

  • Dashboards and Widgets

    • Small multiples functionality is introduced for the Single Value, Gauge, and Pie Chart widgets. This feature allows you to partition your query result on a single dimension into multiple visuals of the same widget type for easy comparison.

      For more information, see Widgets.

    • We have added the new width option Fit to content for Event List columns. With this option selected, the width of the column depends on the content in the column.

Falcon LogScale 1.117.0 Preview (2023-12-05)

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

Security

Updates

Upgrades

From?

JDK

Compatibility?

Config.

Changes?
1.117.0Preview2023-12-05

Cloud

On-Prem

2025-01-31No1.70.017-21No

Bug fixes and updates.

Advanced Warning

The following items are due to change in a future release.

  • Installation and Deployment

    • We intend to drop support for Java 17, making Java 21 the minimum. We plan to make this change in March 2024.

Deprecation

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

  • GraphQL mutation updateOrganizationMutability is deprecated in favor of the new setBlockIngest mutation.

New features and improvements

  • GraphQL API

    • The new setBlockIngest GraphQL mutation is introduced to block ingest for the organization and set ingest to paused in the dataspaces owned by the organization.

  • Configuration

  • Functions

    • Live queries that use files in either match(), cidr(), or lookup() functions are no longer restarted when the file is updated. Instead the files are swapped while the queries are still running.

      For more information, see Lookup Files Operations.

Fixed in this release

  • GraphQL API