Kibana: Logs UI: Clarify setup documentation

Created on 22 Nov 2018  路  6Comments  路  Source: elastic/kibana

Kibana version: 6.5

https://www.elastic.co/guide/en/kibana/current/xpack-logs.html#_add_data_sources_2 doesn't really tell you what you need to do to connect the Logs UI to your own log indices. It simply links to the Infra Monitoring Install guide. Then from this guide, it talks about how you need the filebeat system module and "other filebeat modules":

https://www.elastic.co/guide/en/infrastructure/guide/6.5/install-infrastructure-monitoring.html#_which_modules_and_configuration_options_do_i_enable

This is confusing and implies that the Logs UI can only be used if filebeat modules are set up.

However, the Logs UI does work with regular filebeat.inputs.type=log setup (not using filebeat modules). Looking at the underlying requests sent by the Logs UI, it only knows to read from filebeat-* indices.

It will be helpful to make this more clear in the documentation:

  • It only knows how to read from filebeat-* indices (i.e., you can't ask it to read from a different index pattern defined in Kibana)
  • It does work with base filebeat setup (i.e. does not require the use of filebeat modules)
  • Since a lot of users don't have a FB -> ES setup, but have a FB -> LS -> ES type of setup, it is important to point out that FB -> LS -> ES type of setup will still work esp. since we only show an Beats -> ES architecture here (https://www.elastic.co/guide/en/infrastructure/guide/6.5/infrastructure-monitoring-overview.html).
Logs UI Metrics UI Docs logs-metrics-ui v6.6.0

Most helpful comment

What currently works is to redefine the index patterns and the following fields in the configuration:

xpack.infra:
  sources:
    default:
      metricAlias: 'metricbeat-*'
      logAlias: 'filebeat-*'
      fields:
        host: 'beat.hostname'
        pod: 'kubernetes.pod.name'
        container: 'docker.container.name'
        timestamp: '@timestamp'
        tiebreaker: '_doc'

The reconstruction of the log message is a more complicated structure that is currently based on a hard-coded heuristic. It looks for some well-known fields from filebeat modules and falls back to the message and @message fields.

We're working on a way to make this more configurable. In the meantime the best option would be to ensure a message or @message field is populated during ingestion.

All 6 comments

Pinging @elastic/infrastructure-ui

On point 1 above, apparently there are undocumented settings for the Logs UI below:

xpack.infra.sources.default.logAlias: 'logstash-*'
xpack.infra.sources.default.fields.timestamp: '@timestamp'
xpack.infra.sources.default.fields.tiebreaker: 'your_tiebreaker_field'

There is also a setting to disable/enable the beta feature:

xpack.infra.enabled: true

A UI and documentation for these settings are in the pipeline. Regarding point 3, it should be noted that it is still necessary to have filebeat write the correct index template to enable the required queries. AFAIK this does not happen automatically in the FB -> LS -> ES setup and I have seen several users stumble over that.

The Logs UI docs also seem to inappropriately refer to the Infrasturcture UI...

"Using the Logs UI
Customize the Infrastructure UI to focus on the data you want to see and control how you see it."

https://www.elastic.co/guide/en/kibana/master/logs-ui.html

Wait - so is there no way to configure the Logs UI to use a different set of indices? Or is it required to mimic the structure of the indices that Filebeat creates?

Reading the PR, this still does not seem clear. Defining these fields in ELK 6.5.3 results in Logs UI saying it is unable to find the message even if it is defined.

What currently works is to redefine the index patterns and the following fields in the configuration:

xpack.infra:
  sources:
    default:
      metricAlias: 'metricbeat-*'
      logAlias: 'filebeat-*'
      fields:
        host: 'beat.hostname'
        pod: 'kubernetes.pod.name'
        container: 'docker.container.name'
        timestamp: '@timestamp'
        tiebreaker: '_doc'

The reconstruction of the log message is a more complicated structure that is currently based on a hard-coded heuristic. It looks for some well-known fields from filebeat modules and falls back to the message and @message fields.

We're working on a way to make this more configurable. In the meantime the best option would be to ensure a message or @message field is populated during ingestion.

Was this page helpful?
0 / 5 - 0 ratings