Humio comes with a very powerful, but general, set of core capabilities. Packages allow you to install assets created by others, so you don’t have to start from zero every time.
A package provides a collection of templates, and other assets that extend Humio’s functionality.
For instance, if you are using nginx you would probably benefit from installing the
humio/nginx package. It will provide you with a bunch of parsers, queries, and alert template that help you get started working with nginx logs.
There are two types of packages:
Only parsers, queries, dashboards and alerts may be included in a package, currently.
A package library is a collection of asset templates and extensions like for example dashboards, saved queries, alerts, or parsers. After installing a library these templates will be available when you create a new item (e.g., create a new parser).
Libraries don’t do anything by themselves, they provide a reference and starting point for customizing Humio to fit your needs, without having to start from scratch.
You can use libraries to share common functionality across several repositories. For instance your company could maintain a custom package that provides useful queries and templates to all your repositories. The example represented by Figure 1 here shows a library package with templates and files.
Libraries are still a very new concept in Humio, and under development. We plan on extending the number of different things they can contain. Adding things like new visualizations, charts, custom widgets, actions, and more.
Applications (or simply apps) are bundles of components that are made to work together - usually made for a specific technology or service.
Applications provide a degree of plug-and-play functionality for a technology stack, or at least a solid starting point that you can customize to fit your needs.
They are the best way to get started using Humio because you don’t need to know how to e.g. write a parser to get started ingesting data for a standard technology.
Installing an app will add a bunch of new dashboards, parsers, queries, etc to your repository. Unlike a template library an application actually creates and maintains dashboards, alerts etc. and these are visible alongside your own items in e.g. the Dashboard List or under Alerts where they are displayed separate from other assets categorized by the package they come from.
Put plainly an app is a bundle of dashboards, parsers, queries and so on that can be installed into your repository all at once. In Figure 2 here, you can see an application package that installs saved queries, two dashboards, parsers, and an alert that triggers on error conditions.
There are three ways to install a package:
Once you have installed a package it will appear under the Packages → Installed section of the Settings tab.
If you installed a library, you will now be able to navigate to dashboards, saved queries, alerts and parsers and from there create a new asset based on a template from that library.
If you installed an application you will also be able to create new assets based on assets from the application like you can from installing a library, but more importantly you will also have an installed managed asset for each template in the application. When you navigate to dashboards etc. you will find a grouping in the lists of assets with the name of the application and under that you will find these managed assets. Application assets are freely customizable and you can even delete parts you are not interested in. Doing this will however have a consequence when updating the package.
When a package update is available in the Marketplace it will be shown next to the installed package in the list of available packages, as well as on the individual installed package view.
To update simply click on Update, this will take you through the update wizard. The wizard will show you what assets have been added, changed, and removed alongside the assets that remain unchanged.
In the case of libraries only the asset templates are updated, and so any assets created based on a template remains unchanged by this process.
On the other hand when it comes to applications, where asset templates are materialized during installation and afterwards managed by Humio, you may encounter conflicts from one version to another when Humio tries to update the installed assets. Conflicts arise when you make local changes to an application asset prior to updating it. For example, if you installed an application with a dashboard and you’ve changed one of its widgets, this will result in a conflict when you update that application — unless the new version is identical to your local changes. In order to resolve conflicts while updating an application, Humio supports a basic Use Ours/Theirs merging view that lets you choose what to do with each conflicting asset. That is to say, you can either keep your modified version or replace it completely with the new version.
If you’re using the Humio CLI, you’re able to overwrite the installed package entirely without handling update conflicts.
You can also create custom packages either based on assets created in Humio, or by writing them manually. You can use these to maintain your Humio assets in source control or to share your work with others.
Custom packages can be published to the central Marketplace, or you can share them in whatever way you find best without having to publish them to everyone else.
You can find out more about creating and maintaining your own packages in the creating a package documentation.
In order to publish your package you just have to make it available as a Zip file, and publish the URL. A good place to tell people about your package is Humio’s Slack community.
You can make an open source Github repository on and people can install it using Humio’s CLI or by downloading the zipball archive of your repository.