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":
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:
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."
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.
Most helpful comment
What currently works is to redefine the index patterns and the following fields in the configuration:
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
messageand@messagefields.We're working on a way to make this more configurable. In the meantime the best option would be to ensure a
messageor@messagefield is populated during ingestion.