documentationRelease Notes November 17, 2023¶
Instance Settings¶
Workspace Settings provides options for managing users and access to your Observe Instance.
Figure 1 - New Workspace Settings Options
Run query methods¶
The Run query methods can be set to Defaults to “Manual” or Defaults to “Auto-run”. You can also set it to Don’t allow “Auto-run”.
Support Login¶
Previously, when an Observe Support Engineer detected a problem in a customer instance, they would escalate the issue to the account management team, and the account team would manage the resolution with Observe’s Support & Engineering teams. This can introduce delays and potentially slow the resolution of a customer issue. With the addition of the Support Login setting in Workspace settings, administrators for all customers can proactively approve credentialed and audited access for a Support Engineer. Once this account has been initiated, there is an audit trail of every action tied to your Observe account and the stored data. The account also expires unconditionally and must be renewed after 8 hours.
New User Group¶
Select the default New User Group to add new users when you create them. Add users to one of the following groups by default:
reader
writer
admin
For more information about permissions for each User Group, see Members.
Enable AI OpenAI¶
Enable AI for features that use AI as part of the implementation. Select from the following options:
true
false
Enable AI Observe¶
Enable AI services powered by Observe. Select from the following options:
true
false
OPAL Language Updates¶
filter_last¶
Type of operation: Filter
Description¶
Exclude rows from the input dataset that do not match the given predicate expression.
filter_last behaves identically to the verb filter except when the input is a Resource dataset. See the documentation for filter for more details.
When the input is a Resource dataset, cell values may change over time for a given row. In this case, filter_last filters the rows based on their last value. When the input consists of a Resource dataset and the filter predicate refers to a column which is time-mutable, then filter_last is not accelerable. See verb set_col_immutable
for more information on time-mutable and time-immutable columns. To make filter_last accelerable on a Resource dataset,
consider instead using ever with a frame or first using set_col_immutable. Consider also first converting the Resource
to an Event or Interval dataset using make_event or make_interval, upon which filter_last is accelerable.
Usage¶
filter_last predicate
Argument |
Type |
Required |
Multiple |
Constant |
|---|---|---|---|---|
predicate |
bool |
Required |
Only one |
Variable |
Accelerable¶
filter_last is sometimes accelerable, depending on options used. A dataset that only uses accelerable verbs can be accelerated, making queries on the dataset respond faster.
Examples¶
filter_last string(status_code) ~ /^5.*/
Keep only rows where the status_code column, converted to string, starts with “5”.
For more simple examples, see the filter verb.
filter_last status="ON"
Where the input is a Resource dataset with a time-mutable column “status”, select the Resources whose last status during the query window was “ON”. This example is not accelerable.
filter_last server_id>100
Suppose the input is a Resource dataset describing many servers and how their statuses change over time. In this example, the primary key of the
input Resource is the column “server_id”, and this column is time-immutable. This example selects the servers with a server_id greater than 100. This example is accelerable because for a given server, the server_id cannot change over time.