Part of our Foundational Concepts series:

Figure 1, View from Three Repositories

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 Humio 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 include:

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

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

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


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() Query Function or count() Query Function.

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







Now, if you run the following query:

ip = | groupBy(url)
Figure 2, Query Execution across Multiple Repositories

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

Under the hood two separate searches are executed:


Executed Query


method=GET | ip =


loglevel=INFO | ip =

The groupBy() Query Function (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 ="| B("View") C[Repo: analytics] -->|"loglevel = INFO | ip ="| B B -->|"groupBy(url)"| D{Client}

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:

#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



Nginx Logs



PostgreSQL Logs



iOS App Analytics


#service=app and eventType=analytics

In this example we create three views that all draw their data from a single repository. If you are using a free cloud account, the repository could be your Sandbox.

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:




country = `` |dquo| ``DE


ip.geo =DE

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


Part of our Foundational Concepts series: