Falcon LogScale 1.177.0 GA (2025-02-25)
Version? | Type? | Release Date? | Availability? | End of Support | Security Updates | Upgrades From? | Downgrades To? | Config. Changes? |
---|---|---|---|---|---|---|---|---|
1.177.0 | GA | 2025-02-25 | Cloud | 2026-03-31 | No | 1.150.0 | 1.157.0 | No |
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:
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.
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.
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 theRole
type has been marked as deprecated (will be removed in version 1.195).The
storage
task of the GraphQLNodeTaskEnum
is deprecated and scheduled to be removed in version 1.185. This affects the following items:
The
supportedTasks
field of theClusterNode
type.The
assignedTasks
field of theClusterNode
type.The
unassignedTasks
field of theClusterNode
type.The assignTasks() mutation.
The unassignTasks() mutation
The
INITIAL_DISABLED_NODE_TASKS
configuration variable.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 afield
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()
, andeventSize()
after the first aggregate function is deprecated. For example:Invalid Example for Demonstration - DO NOT USElogscale
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 theScheduledSearch
datatype is now deprecated and planned for removal in LogScale version 1.202. The newlastExecuted
andlastTriggered
fields have been added to theScheduledSearch
datatype to replacelastScheduledSearch
.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:
All types of Triggers (Scheduled Searches, Legacy, Filter, and Aggregate Alerts)
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 Alerts
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.There is a new 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.
There is also a new Frequency option 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
andUnsavedScheduledSearch
:searchIntervalSecond
,searchIntervalOffsetSeconds
,maxWaitTimeSeconds
,backfillLimitV2
,queryTimestampType
. The fieldsqueryStart
andqueryEnd
onCreateScheduledSearch
andUpdateScheduledSearch
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 calledupdate-segments-storage-target
. The new endpoint will be invoked with parametersoldStorageTargetId
andnewStorageTargetId
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 theSearch
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 Alerts
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.