About analytics views

This document describes analytics views and when you might want to create them. It also describes the differences between analytics views and saved queries.

Overview

An analytics view is a resource you can query. That is, after you define an analytics view, you can write queries where you specify your analytics view in the FROM clause.

The primary benefit of using analytics views is that you aren't constrained to querying the data in the format an API or system defines. An analytics view lets you define a schema, which lets you simplify your queries or reduce the time you spend writing queries. The query in an analytics view can do things like retain only specific fields, rename fields, move nested fields to a top-level column, and perform grouping and aggregation.

Analytics views aren't materialized views. An analytics view isn't a precomputed view that periodically caches query results. Therefore, querying an analytics view is equivalent to querying the views that are listed in the analytics view's query.

Analytics views are more powerful than saved queries, which are queries that you run on the Log Analytics page and then save. You can rerun a saved query, but you can't query the results of a saved query.

Types of analytics views

There are two types of analytics views: user-defined and system-defined:

User-defined analytics views are any analytics views that you create. You can query, edit, and delete user-defined analytics views.
System-defined analytics views are analytics views created by Google Cloud services. You can query system-defined analytics views. However, you can't edit or delete them.

For information about listing the analytics views in your Google Cloud project, see List analytics views.

Location of analytics views

The location of an analytics view is determined by the location of the resources it queries. For example, if an analytics view queries a observability view that is in the global location, then the location of the analytics view must also be global. When you use the Google Cloud console to create an analytics view, the location is set automatically.

Example use cases

The primary benefit of an analytics view is that you aren't constrained to querying the data in the format the system defines. An analytics view lets you define a schema, which lets you simplify your queries or reduce the time you spend writing queries.

Extract trace service name

Suppose that you want to write queries that analyze your trace data, and you either want to display or group by a synthesized service name. The query for your analytics view determines the service name for a span by using the COALESCE function, which evaluates a list of expressions, in order, and returns the value for the first expression that doesn't evaluate to NULL:

SELECT
  start_time,
  -- Set the value of service name based on the first non-null value in the list.
  COALESCE(
    JSON_VALUE(resource.attributes, '$."service.name"'),
    JSON_VALUE(attributes, '$."service.name"'),
    JSON_VALUE(attributes, '$."g.co/gae/app/module"')) AS service_name,
  name AS span_name,
  duration_nano,
  status.code AS status,
  trace_id,
  span_id
FROM
  `PROJECT_ID.us._Trace.Spans._AllSpans`
LIMIT 10

Before you use the query, replace PROJECT_ID with the ID of your Google Cloud project.

Limitations

The following limitations apply to analytics views:

An analytics view can only query observability views.
The parent resource of an analytics view must be a Google Cloud project.
You can only query an analytics view by using the Log Analytics page, and only when you use the Log Analytics (default) query engine.
All views that an analytics view queries must be in the same location.
You must use the Google Cloud console to create or manage your analytics views.
You can create at most 100 analytics views per Google Cloud project.
You can create a most 50 analytics views per region.
Per Google Cloud project, at most 10 regions can contain an analytics view.