Searching with Field Aliasing
When doing searches with field aliasing configured, the following behavior is observed.
The aliased fields will exist on an event at search time, whenever the tag conditions are met on the same event.
The aliased fields contain the exact same data as the original field, and they behave identically to other fields when operating on them in the query language.
If an event contains a field with the same name as an alias, then the alias will overshadow the existing field.
GUI option:
If disabled on an alias, only the alias can be searched. The original field is no longer searchable.
If enabled on an alias, the original field will still be searchable. Source and alias are independent copies — modifying one in a query will not affect the other: this means that existing queries that use the original field names will still continue to work. It can, however, come at the cost of some performance.
Searches with Live Queries
Whenever you activate a schema or make changes to an existing active schema, these changes will take effect immediately, meaning any new search will use the new configuration.
For existing running live queries (such as alerts, or an already opened dashboard), these queries need to be restarted in order for the new configuration to take effect.
An exception to this rule is if the query contains a
join(), selfJoin() or
selfJoinFilter() function: these will use the new
configuration on their next refresh. See
Searches with Join Queries
for more details.
Searches with Join Queries
As described in Join Operation and Optimization, queries with join functions simulate liveness by executing in repeated intervals. For queries with join functions where field aliasing is enabled (that is, there is an active schema on the view where the query is executed), the latest configuration of schema and alias mappings are used on each repeated execution.
Unlike live queries without joins (changes in the configuration does not impact an already running query) live queries using joins must be restarted at each schema or alias mappings configuration change.
As Join Query Functions allow specifying the repository for which the subquery should execute, the subquery will use the field alias configuration of the specified repository.
Searches in a Multi-Cluster Setup
Field aliasing can be used with LogScale Multi-Cluster Search. Only the schema active on the local cluster (either organization level or applied on the Multi-Cluster view) will be effective and applied to data from all remote views connected in the multi-cluster view. You can still use field aliasing on the remote clusters, however it will be effective only when searching the remote cluster directly. When running the search from the multi cluster view, schemas active on remote clusters will be ignored.
If you want to apply different mappings for each remote cluster, Multi-Cluster Views allow setting up an additional tag (#clusteridentity which is set to the value Cluster identity tag when configuring a connection) that can be used in the tag conditions of alias mappings.
For more information, see LogScale Multi-Cluster Search documentation.
Searches with Query Prefixes
LogScale has several types of query prefixes that are implicitly added to any query; field aliasing cannot always be used with these query prefixes. This means that those filters will not work with aliased fields, which are disabled for those queries. Query prefixes are:
| Query Prefix | Field Aliasing |
|---|---|
| View Connection filters, explained at Views Filtering | Disabled. Aliased fields cannot be accessed in the view connection filter. |
| Deletion prefixes in Redact Events API | Disabled. Aliased fields are not available in a filter query used with this API (it only operates on the parsed fields). If the same query is run on the page (for example, to check which events to delete before running the API) where field aliasing is set up, the search will produce different results. To avoid such a discrepancy, you may either disable the field aliasing configuration when running the query on search, or ensure you are not using aliased fields in the filter query executed through the API. |
| Role/User query prefix, explained at Assign Roles to Groups | Enabled. You can access aliased fields when you define a query prefix for the role/user filter query. |