Referencing Resources

Repository and View resources (saved searches, files) can be referenced using a macro, where the macro starts with $ and is used to identify a LogScale asset that is to be used as part of the query. For the macro, where the portion of the macro before the :// is used to identify the type of the resource. The prefix is case sensitive, and if no prefix is supplied then LogScale assumes the macro is a saved query.

  • Parser

    To reference a parser, use the prefix $parser://, for example, $parser://myParser(). To refer to a specific parser within a given package, use $parser://package/scope:myParser().

    Referencing the parser in this way only references the parser query language; not additional settings within the parser outside of the query content.

    Using the macro in this way enables inclusion of the parser processing within another parser.

  • Saved Search

    To reference a saved search, use the prefix $query://, for example, $query://myQuery().

For example, to reference a parser in another view:

logscale
$parser://paneview/custom-syslog

This references the locally defined parser custom-syslog within the paneview respository.

To reference resources in another package, the scope is tha vendor and package name. For example:

logscale
$parser://paneview/apache/http-access/apache_error

This references the >apache_error parser from the apache/http-access in the paneview view.

For more information on package scopes, see Understanding Package Scopes.

Tip

The Origin or Package column in resource views (for example Parsers Interface) will show the package name (and therefore scope) of a resource. A Local resource does not require the scope.

When using the macro:

  • Prefix is case sensitive.

  • If no prefix is supplied, then the reference is assumed to be a saved search.

  • If the resource type is not supported, then the reference is treated as an invalid reference, and an error will be produced noting that the resource cannot be resolved.

  • Circular references are not allowed.

  • Parameters can be added to saved searches and parser macros using the User Parameters/Variables notation.

During name resolution, the following options are available:

Resolving Resources to a Different Named View or Repository

Security Requirements and Controls

  • Data Read Access permission

Available: Resolving Resources in Other Repositories or Views v1.236

Repositories and views can be configured to look in a different repository or view to resolve file or saved search lookups.

Saved queries, files, and parsers can be accessed using cross-view referencing, enabling the use of this resource from another view or repository, providing the user has permissions to access.

To use this referencing requires a modified forrm of the asset reference:

logscale Syntax
file://VIEWNAME:FILENAME
$query://VIEWNAME:QUERY()
$parser://VIEWNAME:PARSERNAME()

Package scoped resources can also be referenced:

logscale Syntax
file://VIEWNAME/SCOPE/PACKAGE:FILENAME
$query://VIEWNAME/SCOPE/PACKAGE:QUERYNAME()
$parser://VIEWNAME/SCOPE/PACKAGE:PARSERNAME()

To quote the name, for example when using special characters or spaces, enclose the entire reference in quotes:

logscale Syntax
$"PARSER://VIEWNAME/SCOPE/PACKAGE:PARSERNAME"()

Where:

  • VIEWNAME is the name of the other repository or view where the resource is located.

  • SCOPE is the scope of the package name (typically the vendor name). For example, humio.

  • PACKAGE is the package name within the scope. For example, insights. This works with SCOPE, for example humio/insights.

  • FILENAME is the name of the file to be accessed.

  • QUERY is the name of the saved query to be accessed.

For example, to access a saved query:

logscale
$query://anotherView:saved()

If the saved query contains characters that need to be quoted, quote the entire reference:

logscale
$"query://anotherView:saved query name"()

To reference a query in another view from a package, include the scope:

logscale
$"query://paneview/crowdstrike/falcon-devices/CrowdStrike Falcon Devices: Policies not Assigned"()

Which references the CrowdStrike Falcon Devices: Policies not Assigned in the crowdstrike/falcon-devices package installed in the paneview repository.

To reference a file:

logscale
match("file://anotherView:awesomefile.csv", field=field1, column=column1, nrows=2)

In another package:

logscale
readFile("file://datareporting/veeam/veeamdataplatform/action_results_lookup.csv")

Tip

The Origin or Package column in resource views (for example Parsers Interface) will show the package name (and therefore scope) of a resource. A Local resource does not require the scope.

This feature requires ReadAccess permission on both the source view (where the query/parser runs) and the target view (where the asset is located). The feature works in:

  • Queries, including join/defineTable(), subqueries and Triggers (alerts, scheduled searches).

  • Parsers can reference cross-view saved queries and files during data ingestion

For parsers the feature will only work for view level tokens that are setup to include the set of views referenced in the parser or organization and system level tokens as they can operate across views.

Important

Cross-view references are actively blocked for parsers and saved queries used by:

  • Event forwarding rules

  • Ingest tokens

  • Ingest listeners

  • Ingest feeds

  • FDR feeds

Validation is enforced both at assignment time (when associating a parser with one of these features) and when updating a parser or saved query that is already part of such a chain. This includes transitive references through parser and saved query chains.

References that use alternate lookups (see Resolving Resources Using an Explicit Alternate View or Repository) will work for implicit (non-prefixed) references, while explicit cross-view references (with query:// or file:// prefix) override the redirect setting.

Resolving Resources Using an Explicit Alternate View or Repository

Security Requirements and Controls

Views can be configured to resolve saved queries, lookup files and field aliases from a different view or repository. This allows the creation of these resources to be used in related repositories and views without copying or duplicating the information.

Referencing views and resources in this way enables a single view or repository to be configured with common resources that can then be used from other views and repositories. This reduces the requirement to copy saved queries, files and field aliases between repositories and simplifies management of these resources.

To configure, use the GraphQL mutation redirectQueryAssetLookupTo to configure an alternative view or repository to use when resolving assets. Once configured, any saved query, lookup file or field alias used in queries executed against that view will be resolved from the alternative view or repository instead. For example, if ViewA is configured to lookup resources from ViewB then calling::

logscale
RepositoryViewA
$commonFilter()

Will instead be resolved from ViewB.

Important

To configure this feature, you need the ManageViewConnections organization level permission. The alternative view or repository must be accessible within your organization. When queries execute, permission checks apply to the view where the query runs, not the asset source view or repository. This means any user that can query in a view that is set up to use assets in the alternative view or repository, will be able to use those assets without having access to the alternative asset view or repository. This is similar to how a view connection works today; a user can query in a view that is connected to a number of repositories, without having read access in those individual repositories.