Views

Part of our Foundational Concepts series:

Simple View

Figure 447. Simple View


A view is a special kind of repository. In most respects a view is like an ordinary repository. They can be searched, they have their own dashboards, users, and queries. But unlike Repositories, a view contains no data of its own. Instead views read data from one or more other repositories. In that sense LogScale views are very much like the views you might know from SQL databases.

A view is defined as a set of connections to repositories and associated queries that filter or modify the data as it is read.

There are many use-cases for views and you can see a list of examples later on this page.

Searching Multiple Repositories

The main function of a view is joining data from other repositories and allowing you to search across their data.

When creating a new view you connect repositories and write a filter query specifying the subset of the data that should be included:

graph LR; B[Repo 1] --> A("View 1") C[Repo 2] --> A D[Repo 3] --> A

Figure 448. Searching Multiple Repositories


When searching, all events include a build-in #repo tag with the name of the repository they were read from.

You can use #repo in conjunction with a case statement to modify events based on which repository they come from.

Filtering

By default views contain all data from their connected repositories. This is not always what you want and that is why you can apply a filter to each connection.

A filter will reduce or transform the data before it produces the final search result.

A filter is a normal query expression and you can use the same functions that you use when writing queries. The only thing you can't do is use aggregate functions like groupBy() or count().

Here is an example view having two connections with a filter applied to each:

Repository Filter
accesslogs method=GET
analytics loglevel=INFO

Now, if you run the following query:

logscale
ip = 158.191.19.12 | groupBy(url)
Filtering Views

Figure 449. Filtering Views


This would select all events with the value 158.191.19.12 in the field ip and then group the joined result for each repository by the field url.

Under the hood two separate searches are executed:

Repository Executed Query
accesslogs method=GET | ip = 158.191.19.12
analytics loglevel=INFO | ip = 158.191.19.12

The groupBy() (the aggregation) only happens after results of individual searches are joined. Here is a flow diagram of the process:

graph LR; A[Repo: accesslogs] -->|"method = GET | ip = 158.191.19.12"| B("View") C[Repo: analytics] -->|"loglevel = INFO | ip = 158.191.19.12"| B B -->|"groupBy(url)"| D{Client}

Figure 450. Filtering Views


Example Use-Cases

Views are a powerful tool and you can achieve many things, like:

  • Restrict access to a subset of data based on the user

  • Fine-grained retention strategies

  • Consolidating different log formats

Here are some examples of how you can use views to give you an idea of their power.

One repository per Service

Say you have a micro-service setup and you store all logs from all applications in a single repository, let's call it acme-project. It can become cumbersome to examine logs from each individual service, and their log formats may be very diverse.

First you would have to filter your results down to only include logs from your target service and write something like:

logscale
#service=login-service | ...

And you would have to do it at the beginning of every single query. Instead you can create a specialized view for each service:

Log Type Repository Filter
Nginx Logs acme-project #service=nginx
PostgreSQL Logs acme-project #service=postgres
iOS App Analytics acme-project #service=app and eventType=analytics

In this example we create three views that all draw their data from a single repository.

Restricting Access to Repository Subsets

Say your system produces logs in several regions, but some of the people who have search access should only be able to see logs for their respective region.

It is easy to select a subset of the logs by filtering the results before they reach the user, in this case limiting access to logs Germany:

Repository Filter
website country = " DE "
db ip.geo = " DE "

In this example, we're dealing with two repositories.

Part of our Foundational Concepts series: