I have a serve where I install some beats (e.g. packetbeat) but I don't enable the systemd service. I only use packetbeat setup --index-management on this server so that the packetbeat index template and the ILM policy get inserted into elasticsearch. This works fine, I can see the index template and ILM policy in Kibana. These are the settings I use:
setup:
ilm:
check_exists: false
enabled: true
overwrite: true
pattern: '{now/d}-000001'
rollover_alias: packetbeat-%{[agent.version]}
template:
enabled: true
overwrite: true
pattern: '%{[agent.name]}-%{[agent.version]}-*'
type: legacy
On a second server, I install packetbeat with the following settings:
setup:
ilm:
check_exists: false
enabled: true
overwrite: false
pattern: '{now/d}-000001'
rollover_alias: packetbeat-%{[agent.version]}
template:
enabled: false
On the second server I enable the packetbeat service. I can see logs being sent to elasticsearch. But there are some problems and some questions that I have:
- The index packetbeat creates is
packetbeat-7.12.1. This does not match the template pattern that has a dash at the end:packetbeat-7.12.1-and ILM is not enforced neither are the template settings used. - If I enable the ILM policy, then I can't change the
setup.template.patternin the first server. - If I set
setup.template.enabled: trueon the second server, then the index template gets used and ILM is enabled.
However, I cannot understand why I need to set setup.template.enabled: true to the second packetbeat for the whole chain to workk. This setting seems like a setting that is used on beat startup and instructs it whether to push the tempate to elasticsearch or not. At least, this is the case with the setup.ilm.enabled and setup.dashboards.enabled settings. My approach was to disable templating loading on the second server, because the elastic user that packetbeat uses in that installation does not have permissions to manage index templates.
Still, setup.template.enabled seems to affect the name of the index that packetbeat will push to. If this is correct and intended, it should be documented in the packetbeat.reference.yml at least.