After you’ve created a repository in Humio and started data shippers on your server sending data to that repository, you can then search your data through the Humio User Interface. If you click on the Search tab, you’ll see a screen similar to the one shown in Figure 1 here. We’ve highlight in goldenrod some key bits we want to bring to your attention. We’ll refer to those highlight items throughout this page of the documentation.
First, let’s look at the basic layout of the Search page. At the top left, next to the Humio owl logo, is the name of the repository selected. In the screenshot here, it says, Testeroo. Just below that and below where Automatic (Event List) is highlighted, you’ll see the number 1 and a long white input box. This is where you’ll enter the text and other parameters for which you want to search.
Going further down, you’ll see a fairly wide margin on the left that contains the names of fields sound in the repository and statistics on those fields found. These fields are the result of whatever parser was used to separate the data and identify it’s elements. You can create and edit parsers on the Parsers page, which is covered the Parsers page of this section of the Humio Documentation.
To the right of the fields margin, is the main, large panel. It contains the data. These are segregated into separate log entries or events. You can click on any of these events for a closer look and to reveal more information.
As mentioned above, the left margin shows fields that were found in the data by the parser used for processing the data. Notice where we’ve highlighted the word Columns. Under it are two fields, listed alphabetically:
@timestamp. These correspond to the column headings in the main panel, which are presented in a different order — the
@timestamp column is always first.
There are generally more fields that were found. They’re listed under Known Fields in the left margin (see screenshot where it’s highlighted). We highlighted some of these known fields in the main panel, so you can see the relationship between them. For fields of interest to you click on the empty star (i.e., ). This will change the star to a filled one (i.e., ) and move the field to the top of the list of known fields.
Another method of focusing on fields of interest is to filter them. In Figure 1 we highlighted the text, Filter Fields. You could enter some text there to narrow the list of known fields shown. For instance, you might
error to see fields that contain the word error. You can see how this would look in Figure 2 here.
You can also reduce the number of known fields shown in the margin by clicking on the filter-list icon (i.e., filter_list). This will toggle between showing and not showing metadata fields. The fields that start with an at-sign (i.e., @) as metadata fields.
In the main panel, each entry is rather thick. To reduce what’s shown to one line only, click on the wrap-text icon (i.e., wrap_text), above the main panel, near the top right (see it highlighted in Figure 1).
With less text shown for each event, you might want to add one of the known fields as a column to the main panel. To do this, click on the circled plus sign (i.e., ⊕) icon, which is highlighted in the screenshot in Figure 1. Then type in the column you want to add and hit Enter or click Add Column
You may add multiple fields to view in the main panel. You may also want to reorder them. To move or remove a field, move your mouse to the heading of the column you want to change. A keyboard down-arrow-head (i.e., keyboard_arrow_down) will appear. Click on it and you’ll be given some choices, like you see in Figure 3 here. You can move the column to the left or right, or resize its width. You can also remove it.
There are so many fields from which to choose, to use as a column in the main panel. If you’re not sure which column might be worth adding, you could just add one to see what it does. If you don’t like it, remove it and try another. Perhaps a better method would be to click on the name of a known field in the left margin to see what values you would see. When you do this, a box will appear with a list of values found and the number of occurences of each. The screenshot in Figure 4 here shows the results of clicking on the statuscode field — those are Apache http codes such as 404 for page not found. There aren’t many status codes or occurences. This is because it’s only including the most recent events.
Notice there are some clickable boxes which provide you with some choices. The first pair relate to getting counts. One is Group By in this screenshot. If you were to click on it, the screen would change and show you all of the status codes found in the repository, not just the most recent ones. It would group that information on each status codes, which would be quite a few, and many more occurences of each. Going back to the boxes in Figure 4 above, the next pair of choices are for seeing a Time Chart. If you click on As Series, the screen will show the data on status codes as a chart, similar to the one in Figure 5 here. Notice that text was entered into the query input box at the top left (i.e,
timechart(statuscode)). This is how you can get a time chart showing only the status codes.
The data contained in the main panel, as shown in Figure 1, is a list of events. This corresponds to the choice at the top left of the screen, where it says Automatic (Event List) (see our highlight in Figure 1). If you click on that, you’ll see that there are theoretically other choices, similar to what you see in Figure 6 here.
If the data being viewed were compatible, you’d be able to choose from displaying the data as a table, or some sort of chart. When we looked at the time chart for status codes above, the list of choices changed. You can see in Figure 5, that the automatic choice is different. If you change the search parameter to
groupBy(statuscode), this will result in a table of data being displayed. Then other choices become available (i.e., table, pie chart, and bar chart).
The data available for searching by default has been from the past twenty-four hours. This is indicated by the button near the top right, by the purple Run button (see Figure 1). If you click on the small button to the left of it, the chevron-left icon (i.e., chevron_left), it will show include the data from the past two 24-hour periods. The more you click left, the more days are included. Clicking right reduces the periods included in the search.
Notice that the time-frame button said initially, Last 24h (Static). The word Static indicates that it’s not including any data that comes in after you opened the Search page. It’s not streaming or live data. If you click on the time-frame button, you’ll see (Figure 7) that you have many other choices besides incrementing the time frame, one day at a time. At the top, there is a small check-box for Live Query. Checking this will switch it from static to steaming. It will also drop off anything older that 24 hours as time passes.
There is also a list of preset time frames. Under the heading, Fixed Time Range are static time frames. Under Time Window in the Presets section, are streaming data choices. Below the Presets section is another section, also labeled, Time Window. Clicking on it will allow you to choose whether you want a time frame spanning milliseconds, seconds, minutes, hours, days, or years. You can also enter manually the number of these intervals (e.g., 12 minutes). After this section, there’s yet another section. It’s called, Fixed Time Range. Here you can use two calendars to select the start and end dates for your data searches.
In searching the repository’s data, if you want to save the results of your search or you’ve devised a search query that you might want to use another time, you could save it. To do this, click on the Save as… link at the top right above the main panel (it’s highlighted in Figure 1 above). You will be given a list of save choices (see Figure 8).
The first choice is to save as a Saved Query. Suppose you had entered the query
groupBy(statuscode) used earlier. You could save that as a saved query — saving the query, not the resulting data. When you do, a box will appear asking you if if this query is overwriting a previously saved one (see Figure 9). If it’s a new one, give it a name and then hit Save. Later, you can reload this query from the pull-down menu labeled, Queries at the top left, just above the query input field. You can see it in the background in Figure 9 here. You can make a saved search load automatically when opening the repository (see User Interface - Settings).
In addition to saving the search as a query, you could save it as a Dashboard Widget. This is covered on the User Interface - Dashboards documentation page. If the search were the appropriate type, you could choose to save it as an Alert, which is covered on the User Interface - Alerts documentation page. The last possibility is to choose Export to File. This is the same as click on the file-download icon (i.e., file_download) to its left. This will export the results of the query, what’s shown in the main panel, to a file locally. You can choose between a json, comma-separate values, or plain text format.