Falcon LogScale 1.166.0 GA (2024-11-26)
Version? | Type? | Release Date? | Availability? | End of Support | Security Updates | Upgrades From? | Config. Changes? |
---|---|---|---|---|---|---|---|
1.166.0 | GA | 2024-11-26 | Cloud | Next LTS | No | 1.136 | No |
Available for download two days after release.
Bug fixes and updates.
Deprecation
Items that have been deprecated and may be removed in a future release.
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 theScheduledSearch
datatype to replace lastScheduledSearch.
Upgrades
Changes that may occur or be required during an upgrade.
Installation and Deployment
The minimum supported version that LogScale can be upgraded from has increased from 1.112 to 1.136. This change allows for removal of some obsolete data from LogScale database.
The Kafka client has been upgraded to 3.9.0.
New features and improvements
Security
Users granted with the
ReadAccess
permission on the repository can now read files in read-only mode.
Automation and Alerts
Updated the wording on a number of error and warning messages shown in the UI for alerts and scheduled searches.
Dashboards and Widgets
Sections in the Styling panel for all widgets are now collapsible.
Functions
When the @timestamp field is used in
collect()
, a warning has been added because collecting @timestamp will usually not return any results unless there's only one unique timestamp or thelimit
parameter has been given an argument of1
. A work-around is to rename or create a new field with the value of timestamp and collect that field instead, for example:logscaletimestamp := @timestamp | collect(timestamp)
Other
Added
organization
to logs from building parsers.When logging organizations, the name is now logged with key
organizationName
instead ofname
.
Fixed in this release
UI Changes
The layout of the
Table
widget has been fixed due to a a vertical scroll bar that was appearing inside the table even when rows took up minimum space. This would lead to users having to scroll in the table to see the last row.
Queries
The
Query stats
panel on the Organization Query Monitor was reporting misleading information about total number of running queries, total number of live queries etc. when there were more than 1,000 queries that matched the searched term. This has been fixed by changing the global part of the result of the runningQueries graphql query, although the list of specific queries used to populate the table on the page is still capped at 1,000.
Functions
Matching on multiple rows in
glob
mode missed some matching rows. This happened in cases where there were rows with differentglob
patterns matching on the same event. For example, using a fileexample.csv
:csvcolumn1, column2 ab*, one a*, two a*, three
And the query:
logscalematch(example.csv, field=column1, mode=glob, nrows=3)
An event with the field column1=abc would only match on the last two rows. This issue has been fixed so that all three rows will match on the event.
objectArray:eval()
has been fixed as it did not work on array names containing an array index, for exampleobjectArray:eval(array="myArray[0].foo[]", ...)
.The
defineTable()
function in Ad-hoc tables has been fixed as it did not use the ingest timestamp for time range specification provided by the primary query, using the event timestamp instead. This issue only affected queries where the primary query used ingest timestamps.The
defineTable()
function in Ad-hoc tables has been fixed as it incorrectly used UTC time zone for query start and end timestamps, regardless of the primary query's time zone. This issue only affected queries where the primary query used a non-UTC time zone, and either of the following:the primary query's time interval used calendar-based presets (like
calendar:2d
, ornow@week
), or:the sub-query used any query function that uses the timezone, for example
timeChart()
,bucket()
, and anytime:*
function.
Improvement
UI Changes
The Search Link dashboard interaction now allows you to specify the target view/repository as . This setting allows for exporting and importing the dashboard in another view, while allowing the Search Link interaction to execute in the same view as the dashboard was imported to. is now the first suggested option in the drop-down list in Dashboard Link or Search Link interaction types.
Queries
In cases where a streaming query is unable to start — for example, if it refers to a file that does not exist — an error message is now returned instead of an empty string.