Falcon LogScale 1.129.0 GA (2024-03-12)

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

Security

Updates

Upgrades

From?

Config.

Changes?
1.129.0GA2024-03-12

Cloud

2025-04-30No1.106No

Bug fixes and updates.

Advance 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 split by AWS record setting within ingest feeds will now accept numbers with leading zeros.

    • The default IP filter for IdP and RDNS operations is now more restrictive: 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.

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.