Falcon LogScale 1.177.0 GA (2025-02-25)

Version?Type?Release Date?Availability?End of SupportSecurity UpdatesUpgrades From?Downgrades To?Config. Changes?
1.177.0GA2025-02-25

Cloud

2026-03-31No1.150.01.157.0No

Hide file download links

Show file download links

Bug fixes and updates.

Breaking Changes

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

  • Automation and Triggers

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

New features and improvements

  • Security

    • The introduction of granular asset permissions in LogScale allows for more control over access to supported assets. With this release, administrators can assign edit and delete permissions to groups or individual users for specific assets.

      Key features are:

      • Assign granular permissions directly or through groups

      • Edit and delete permissions can be granted on individual assets

      • Redesigned UI flow for assigning permissions, providing a more guided experience for asset administrators and clear communication of the consequences of changes applied

      • Read-only views for all assets

      The following assets support granular permissions:

  • Installation and Deployment

    • During an update, nodes with the new version will keep serving static assets with the old version. This should prevent crashes in the UI during upgrades.

  • Administration and Management

    • Changed user or system classifications of certain errors to help make better decisions in clients. System errors where end users need information in the UI will return a status code of 515 with the error message.

  • Automation and Triggers

    • Alerts and Scheduled Searches are now consolidated under one page called Triggers. This provides an overview of all triggers in one spot, making them easier to manage and configure. Additionally, the term "trigger" now refers to both alerts and scheduled searches.

      Triggers Overview

      There is a new Trigger option to save a query as trigger from the Search page, streamlining the process of creating triggers. This option opens a side panel where you can select a query type, live or scheduled search, and configure other trigger properties.

      For scheduled searches, the Delay run option allows you to offset the scheduled search to make sure the search doesn't miss late arriving events. For information about this setting, see Scheduled Search Properties.

      The new Frequency option is also available to run scheduled searches on a daily, weekly, or monthly schedule.

      The Time window for scheduled searches must now be in whole seconds.

      This release also adds two corresponding GraphQL mutations: createScheduledSearchV2() and updateScheduledSearchV2(). And there are new GraphQL fields on type ScheduledSearch and UnsavedScheduledSearch: searchIntervalSecond, searchIntervalOffsetSeconds, maxWaitTimeSeconds, backfillLimitV2, queryTimestampType. The fields queryStart and queryEnd on CreateScheduledSearch and UpdateScheduledSearch no longer accept values that are not in whole seconds.

      For more information, see Automation, Types.

  • Storage

    • To improve security, authorization for S3 archiving has been changed substantially to allow and, in some situations, require assuming an IAM AWS role for new S3 archiving configurations.

      For Falcon LogScale Cloud and multi-organization self-install clusters, new configurations of S3 archiving will now require an AWS IAM role to be specified. This policy for assuming this role must have a condition on the external ID matching what is shown in the LogScale S3 archiving UI. S3 archiving will then assume this role, and then write to the bucket afterwards.

      If you are operating a self-install cluster, the user configured with S3 archiving must have the sts:AssumeRole AWS permission. In addition:

      • If you are operating a multi-organization self-install cluster and are certain this requirement is not relevant to you, this requirement can be disabled via the S3_ARCHIVING_REQUIRE_ROLE environment variable.

      • If you are operating a single-organization self-install cluster, you will continue to be able to create new configurations of S3 archiving without using a role.

      Existing non-role-based S3 archiving configurations will continue to function.

      Consult the documentation on S3 archiving for more information.

      For more information, see S3 Archiving.

  • API

    • Added a new subpath to the bucket-storage-target API endpoint called update-segments-storage-target. The new endpoint will be invoked with parameters oldStorageTargetId and newStorageTargetId to change the bucket entity references in all relevant segment entities. The primary use case for this endpoint is for swapping between bucket providers in a controlled manner.

  • Dashboards and Widgets

    • LogScale introduces data mapping in the Bar Chart configuration. It is now possible to overwrite the default mapping from fields in the query result to visualization properties such as Category (x-axis) and Series values (y-axis).

      LogScale also introduces the Line overlay property for the Bar Chart widget. It is now possible to add a line overlay by enabling it in the widget configuration. Bar Chart also supports an optional, independent right axis for the line overlay that can be configured via the Right axis checkbox.

      For more information, see Bar Chart Widget.

    • The Legend property section in the Scatter Chart has been updated to match the rest of the widgets.

    • When selecting rows in a Table widget on the Search page while a query is running, a message is displayed; the wording of the message has been updated to avoid ambiguity.

  • Queries

    • Improved the fairness of multi-cluster searches.

    • For live queries, LogScale first runs a historic/static query and then LogScale runs the live query which reacts to events coming through the ingest/digest pipeline.

      LogScale now deletes historic warnings from live queries once they are no longer part of the search interval. As an example, say a live query has a search interval of 1 hour. Then LogScale runs a static query for a 1 hour interval. After 1 hour everything related to the initial hour is outside of the search interval. Therefore LogScale can remove the warnings related to the static query from the initial hour at this point in time.

Fixed in this release

  • Administration and Management

    • Fixed an issue where a compiler warning for unknown escape sequences could stop query submission.

  • User Interface

    • Fixed an issue where scrolling to get more events would lead the Event List to become empty.

  • Automation and Triggers

    • Fixed an issue introduced in 1.176 that could prevent all aggregate and filter alerts from running.

  • Configuration

    • Fixed an issue that could cause several nodes to attempt to upload to bucket storage at the same time. This can still occur occasionally, but the issue causing it to occur more often than expected has been fixed.

  • Queries

    • Fixed an issue where the restriction on the placement of the window() function was only enforced at runtime and not in the query editor and GraphQL queries. The query editor and GraphQL queries that analyze LogScale query strings now properly respond with errors when this restriction is violated.

    • Fixed an issue where workers that had completed processing a query would continue to be polled for new data.

Recent Package Updates

The following LogScale packages have been updated within the last month.