Falcon LogScale 1.179.0 GA (2025-03-11)

Version?Type?Release Date?Availability?End of SupportSecurity UpdatesUpgrades From?Downgrades To?Config. Changes?
1.179.0GA2025-03-11

Cloud

Next LTSNo1.150.01.157.0No

Available for download two days after release.

Bug fixes and updates.

Breaking Changes

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

  • Automation and Alerts

    • Important Notice: Downgrade Considerations

      Enhancements to Aggregate alerts in version 1.176 include additional state tracking for errors and warnings. While this is an improvement, it does require attention if you need to downgrade to an earlier version.

      Potential Impact:

      If you downgrade from 1.176 or above to 1.175 or below, you may encounter errors related to Aggregate Alerts, causing Aggregate Alerts to not run to completion.

      Resolution Steps:

      After downgrading, if you encounter errors containing Error message and error in phase must either both be set or not set, do the following:

      1. Identify affected Aggregate Alerts by executing the following GraphQL query:

        graphql
        query q1 {
          searchDomains {
            name    
            aggregateAlerts {id, lastError, lastWarnings}
          }
        }

        Document the IDs of any affected alerts having warnings and no errors set.

      2. Apply the resolution – for each identified alert with warnings (optionally and/or errors), apply this GraphQL mutation, replacing INSERT with your actual view name and alert ID:

        graphql
        mutation m1 {
          clearErrorOnAggregateAlert(input:{viewName:"INSERT",id:"INSERT"}) {id}
        }

        Keep track of modified alert IDs for future reference.

      3. Verify the resolution – confirm that the system returns to normal operation, and monitor for any additional error messages using a LogScale query and/or alert, such as:

        logscale
        #kind=logs
        class="c.h.c.Context"
        "Error message and error in phase must either both be set or not set"

      These steps will reset the Aggregate Alerts and restore the system to normal operation.

Deprecation

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

  • The color field on the Role type has been marked as deprecated (will be removed in version 1.195).

  • The storage task of the GraphQL NodeTaskEnum is deprecated and scheduled to be removed in version 1.185. This affects the following items:

  • LogScale is deprecating free-text searches that occur after the first aggregate function in a query. These searches likely did not and will not work as expected. Starting with version 1.189.0, this functionality will no longer be available. A free-text search after the first aggregate function refers to any text filter that is not specific to a field and appears after the query's first aggregate function. For example, this syntax is deprecated:

    logscale Syntax
    "Lorem ipsum dolor" 
    | tail(200)         
    | "sit amet, consectetur"

    Some uses of the wildcard() function, particularly those that do not specify a field argument are also free-text-searches and therefore are deprecated as well. Regex literals that are not particular to a field, for example /(abra|kadabra)/ are also free-text-searches and are thus also deprecated after the first aggregate function.

    To work around this issue, you can:

    • Move the free-text search in front of the first aggregate function.

    • Search specifically in the @rawstring field.

    If you know the field that contains the value you're searching for, it's best to search that particular field. The field may have been added by either the log shipper or the parser, and the information might not appear in the @rawstring field.

    Free-text searches before the first aggregate function continue to work as expected since they are not deprecated. Field-specific text searches work as expected as well: for example, myField=/(abra|kadabra)/ continue to work also after the first aggregate function.

  • The use of the event functions eventInternals(), eventFieldCount(), and eventSize() after the first aggregate function is deprecated. For example:

    Invalid Example for Demonstration - DO NOT USE
    logscale
    eventSize() | tail(200) | eventInternals()

    Usage of these functions after the first aggregate function is deprecated because they work on the original events, which are not available after the first aggregate function.

    Using these functions after the first aggregate function will be made unavailable in version 1.189.0 and onwards.

    These functions will continue to work before the first aggregate function, for example:

    logscale
    eventSize() | tail(200)
  • 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.

  • The EXTRA_KAFKA_CONFIGS_FILE configuration variable has been deprecated and planned to be removed no earlier than version 1.225.0. For more information, see RN Issue.

Behavior Changes

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

  • Configuration

    • The semantics of S3_STORAGE_PREFERRED_COPY_SOURCE variable has been adjusted so that LogScale now attempts to fetch from local nodes first, and if that fails, it will try bucket storage. Previously, LogScale would try fetching from both local nodes and bucket storage in parallel. The new behavior should reduce the number of fetches from bucket storage on clusters configured this way.

New features and improvements

  • Administration and Management

    • The new losable-node-count-before-storage-over-capacity metric of type Gauge is now available, labelled by zone. For each zone, this metric indicates the number of nodes that a zone can lose before going over capacity in terms of primary disk storage, taking into account the value of the PRIMARY_STORAGE_MAX_FILL_PERCENTAGE environment variable.

  • GraphQL API

    • The maximum amount of errors returned in the errors field for a GraphQL error is now capped at 100. For example:

      JSON
      {
        "errors": [
          {
            "message": "Unexpected token 'T', \"The reques\"... is not valid JSON",
            "stack": "SyntaxError: Unexpected token 'T', \"The reques\"... is not valid JSON"
          }
        ]
      }

      Any queries that result in a larger amount of errors than allowed will return 400 Bad Request with a single error stating that the maximum error limit was exceeded.

  • Configuration

  • Queries

    • Multi-Cluster Search can now estimate and report coordinator memory usage. This feature ensures that multi-cluster searches block queries that exceed system memory thresholds.

Fixed in this release

  • UI Changes

    • When configuring field aliasing and importing a field alias schema from a YAML file, the Original field name and Alias to fields were being swapped. The example below of a YAML file would cause myOriginalField to become the alias, and myAliasField to become the original field:

      yaml
      $schema: https://schemas.humio.com/dataschema/v0.1.0
      aliasMapping:
       - aliases: myOriginalField: myAliasField    
                                           
        fieldsToKeep: []
        name: someAliasMappingName
        tags:
          '#someTag': someTagValue
          fields: []
          name: mySchema

      • Intended setup: myOriginalField → myAliasField

      • Bug result: myAliasField → myOriginalField

      For those who used the import feature:

      1. Review current alias mappings in your schema

      2. Check if fields are reversed from your intended configuration

      3. If reversed, manually swap the fields back to correct order.

  • Automation and Alerts

    • Aggregate alerts have been fixed for an issue where they could fail and restart while starting the alert query.

  • Storage

    • Digest would fail to start in rare cases until the node was manually rebooted.

  • Dashboards and Widgets

    • The Bar Chart widget has been fixed as bars would not always react to hover and click events.

  • Queries

    • In case of network failures, even transient failures, occurring during polling or other operations in Multi-Cluster Search, the message could not be correctly serialized, thus leading to query failure. This fixes some cases where a multi-cluster query (using for example defineTable()) might now work and return results with a warning, where it previously failed.

    • Events could be missed if a live query was run based on @ingesttimestamp but @timestamp was outside the time window of the query. This would affect all Filter alerts as well as Aggregate alerts running on @ingesttimestamp.

Improvement

  • Storage

    • Jobs and metrics which were specific to S3 Archiving have been renamed to generic archiving to make them more provider agnostic. For example,S3ArchivingSchema is now ArchivingSchema.