Falcon LogScale 1.176.0 GA (2025-02-18)
Version? | Type? | Release Date? | Availability? | End of Support | Security Updates | Upgrades From? | Downgrades To? | Config. Changes? |
---|---|---|---|---|---|---|---|---|
1.176.0 | GA | 2025-02-18 | 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 removeLimit() GraphQL mutation is being deprecated and replaced by the new mutation removeLimitWithId().
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
Administration and Management
The
Usage
page now uses the ingestAfterFieldRemovalSize metric for visualizing Average ingest per day. It's still possible to query the humio-usage repository for the legacy segmentWriteBytes metric as well asingestAfterFieldRemovalSize
.
Automation and Alerts
Alerts and Scheduled searches now show additional warning types in the UI. Before, these warnings only appeared in the humio-activity logs.
Configuration
The
enable.idempotence
feature for Kafka producers, which is configurable through theEXTRA_KAFKA_CONFIGS_FILE
variable, has been set tofalse
by default due to stability issues reported in certain environments.
Dashboards and Widgets
Row selection is now available in the
Table
widget, on theSearch
page only: you can now select rows from a table and copy them to the clipboard.A new option to format the numerical values for the
Pie Chart
andHeat Map
widgets is now available.A new option to select value formatting for
Time Chart
is now available. The resizing behavior of the chart has also been adjusted.New settings for formatting numerical values in the
Scatter Chart
are now available.
Queries
Execution time is now included in the activity logs for the queries' execution information.
Main queries now support retry polling subqueries that are for example being restarted or otherwise temporarily unavailable (as for
defineTable()
subqueries). This change is meant to address the Subquery not found on poll warning issue occurring when subqueries are being restarted.
Functions
The new query function
base64Encode()
is now available. The function allows the user to base64-encode a field, and output the results in another field. For instance, the stringhello, world
will encode asaGVsbG8sIHdvcmxk
.Usage example:
base64Encode(fieldName)
will produce events with a field named _base64Encode, containing the encoded value of the fieldName field.
Fixed in this release
User Interface
Fixed an issue that only the first error for a field would be returned from the API and shown in the UI.
Ingestion
When ingesting events with additional tags, such as when using humio structured endpoint, tags that were specified in the parser for removal were discounted from ingest accounting, but not removed from the event. This issue has now been fixed.
Dashboards and Widgets
Renaming the Id of a parameter inside a panel on the dashboard would make it jump to the top panel. This issue has now been fixed.
A Query Editor error in one of the widgets on a dashboard could result in an error on the Query Editor of a parameter. This issue has now been fixed.
Queries
The query-millis metric wrongly counted the time spent waiting for CPU. This has been fixed so that the metric now measures the CPU time used by the query only.
A query might be started on an incorrect node in case of a mixed version cluster. This would lead to failure in polling the query. This issue has now been fixed.
Functions
Matching on multiple rows in
mode=cidr
missed some matching rows. This happened in cases where there are rows with different subnets that match on the same event.Example of the bug, using a file
example.csv
.column1 column2 1.2.3.4/25 one 1.2.3.4/24 two 1.2.3.4/24 three For the query:
logscalematch(example.csv, field=column1, mode=cidr, nrows=3)
an event with the field column1=1.2.3.10 would only match on the last two rows. This change fixes this issue so that all three rows will match on the event.
Improvement
Storage
The load on Global Database could be slightly reduced by removing some unnecessary messages that were being sent by mistake.
Queries
Error recovery messages have been improved in the Query Editor. LogScale now informs about any missing or excessive arguments in queries when using for example
worldMap()
andrename()
functions.