Part of our Foundational Concepts series:
Figure 304. 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 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 included:
Figure 305. Searching Multiple Repositories
When searching, all events include a build-in
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.
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.
Here is an example view having two connections with a filter applied to each:
Now, if you run the following query:
ip = 22.214.171.124 | groupBy(url)
Figure 306. Filtering Views
This would select all events with the value
126.96.36.199 in the field
then group the joined result for each repository by the field
Under the hood two separate searches are executed:
groupBy() (the aggregation) only happens after
results of individual searches are joined. Here is a flow diagram of the
Figure 307. Filtering Views
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
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:
|iOS App 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 The Sandbox 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:
In this example, we're dealing with two repositories.