Closed ebvjr closed 4 years ago
Thanks for the issue Eduardo, I'll reproduce it and see if I can track down the problem and get you a resolution. I think all that's handled by libbeat, but perhaps I made a change that affected it without realizing.
Did you run the setup
command against your elastic instance before shipping the logs? Thanks again.
@ebvjr could try the below configuration:
setup:
template:
name: "testbeat"
pattern: "testbeat*"
ilm:
enabled: true
rollover_alias: "testbeat"
pattern: "{now/d}-000001"
output.elasticsearch:
hosts: ["http://localhost:9200"]
username: "elastic"
password: "changeme"
index: "testbeat-%{[agent.version]}"
This should give a result like testbeat-1.4.3-2020.01.14-000001
Thanks
@ebvjr - was @opendevl's suggestion able to fix your issue? If so, I'll capture it in the docs. Thanks to both of you!
Yes. thank you!
Glad to hear it, @ebvjr, and thank you again to @opendevl for the suggested fix. I see how o365beat.reference.yml
led you astray, it suggests including agent.version
in setup.name
and setup.pattern
. Unfortunately that's an artifact of the build process which concatenates libbeat/_meta/config.reference.yml.tmpl
with our o365beat reference template, and we don't control those examples.
I'll mention the fix in the docs, but I don't plan to re-write that libbeat reference template during the build ... there may be other bugs in there that we won't catch, and then we'll have signed up to keep it correct forever 😃. Please feel free to file an issue or PR for the upstream reference template!
Thanks again.
Configuration:
Expected result: The name of new index pattern is
testbeat-%{[agent.version]}-%{+yyyy.MM.dd}
Result: It's still using the
o365beat-%{[agent.version]}-%{+yyyy.MM.dd}
index pattern