Update allow_older_versions when running under Elastic Agent#34964
Update allow_older_versions when running under Elastic Agent#34964rdner merged 8 commits intoelastic:mainfrom
allow_older_versions when running under Elastic Agent#34964Conversation
When Beats are running under Elastic Agent their initial output configuration is empty. Only a few moments later the output configuration arrives as an update via the control protocol. On startup Beats register a global Elasticsearch connection callback to validate the Elasticsearch version. Unfortunately, this callback didn't account for the later `allow_older_versions` update via the control protocol and the updated value was not used. This fixes that broken behaviour and makes an update to the entire in-memory output configuration on each control protocol update. The flag is extracted in a separate struct field for quicker access without a need to parse the configuration again.
|
The linter failure is a false-positive. |
|
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
|
@rdner As I'm trying to test this PR I'm seeing the following errors in As such, none of the component Beats are starting up. I am very familiar with these errors 😅; they were fixed very recently via #34946. If you rebase this PR on I'm working around this error locally but just mentioning the fix here for anyone else who might run into it while testing this PR. |
|
@ycombinator hmm, I've tested with Beats on this branch, your agent must be newer, so the behaviour is different. I don't feel like merging |
The error will only happen if your hostname is set to something that cannot be resolved via DNS. Mine is deliberately set that way 🙂. So it's likely no one else is going to run into this issue. Just wanted to mention it in case someone else does.
Yup, understandable! I'm working around it locally and testing. |
|
Code LGTM (and thanks for the tests). I'm having some issues testing this locally but that might just be due to my local setup. Working through it... |
There was a problem hiding this comment.
LGTM.
Tested with instructions in PR and I can get the Beats under Agent (8.8.0-SNAPSHOT) to connect to an older ES (8.6.1):
{"log.level":"info","@timestamp":"2023-03-30T10:25:58.007-0700","message":"Attempting to connect to Elasticsearch version 8.6.1","component":{"binary":"metricbeat","dataset":"elastic_agent.metricbeat","id":"http/metrics-monitoring","type":"http/metrics"},"log":{"source":"http/metrics-monitoring"},"log.logger":"esclientleg","log.origin":{"file.line":291,"file.name":"eslegclient/connection.go"},"service.name":"metricbeat","ecs.version":"1.6.0","ecs.version":"1.6.0"}
{"log.level":"info","@timestamp":"2023-03-30T10:25:58.080-0700","message":"Attempting to connect to Elasticsearch version 8.6.1","component":{"binary":"metricbeat","dataset":"elastic_agent.metricbeat","id":"beat/metrics-monitoring","type":"beat/metrics"},"log":{"source":"beat/metrics-monitoring"},"log.origin":{"file.line":291,"file.name":"eslegclient/connection.go"},"service.name":"metricbeat","ecs.version":"1.6.0","log.logger":"esclientleg","ecs.version":"1.6.0"}
{"log.level":"info","@timestamp":"2023-03-30T10:25:58.196-0700","message":"Connection to backoff(elasticsearch(https://test-older-versions.es.us-central1.gcp.qa.cld.elstc.co:9243)) established","component":{"binary":"metricbeat","dataset":"elastic_agent.metricbeat","id":"http/metrics-monitoring","type":"http/metrics"},"log":{"source":"http/metrics-monitoring"},"service.name":"metricbeat","ecs.version":"1.6.0","log.logger":"publisher_pipeline_output","log.origin":{"file.line":147,"file.name":"pipeline/client_worker.go"},"ecs.version":"1.6.0"}
{"log.level":"info","@timestamp":"2023-03-30T10:25:58.267-0700","message":"Connection to backoff(elasticsearch(https://test-older-versions.es.us-central1.gcp.qa.cld.elstc.co:9243)) established","component":{"binary":"metricbeat","dataset":"elastic_agent.metricbeat","id":"beat/metrics-monitoring","type":"beat/metrics"},"log":{"source":"beat/metrics-monitoring"},"log.logger":"publisher_pipeline_output","log.origin":{"file.line":147,"file.name":"pipeline/client_worker.go"},"service.name":"metricbeat","ecs.version":"1.6.0","ecs.version":"1.6.0"}
Also tested with allow_older_versions line removed from config and the connection to ES fails, as expected:
{"log.level":"error","@timestamp":"2023-03-30T10:30:19.289-0700","message":"Failed to connect to backoff(elasticsearch(https://test-older-versions.es.us-central1.gcp.qa.cld.elstc.co:9243)): Connection marked as failed because the onConnect callback failed: Elasticsearch is too old. Please upgrade the instance. If you would like to connect to older instances set output.elasticsearch.allow_older_versions to true. ES=8.6.1, Beat=8.8.0","component":{"binary":"metricbeat","dataset":"elastic_agent.metricbeat","id":"system/metrics-default","type":"system/metrics"},"log":{"source":"system/metrics-default"},"log.logger":"publisher_pipeline_output","log.origin":{"file.line":150,"file.name":"pipeline/client_worker.go"},"service.name":"metricbeat","ecs.version":"1.6.0","ecs.version":"1.6.0"}
When Beats are running under Elastic Agent their initial output configuration is empty. Only a few moments later the output configuration arrives as an update via the control protocol. On startup Beats register a global Elasticsearch connection callback to validate the Elasticsearch version. Unfortunately, this callback didn't account for the later `allow_older_versions` update via the control protocol and the updated value was not used. This fixes that broken behaviour and makes an update to the entire in-memory output configuration on each control protocol update. (cherry picked from commit 1a9d627)
…er Elastic Agent (#34979) * Update `allow_older_versions` when running under Elastic Agent (#34964) When Beats are running under Elastic Agent their initial output configuration is empty. Only a few moments later the output configuration arrives as an update via the control protocol. On startup Beats register a global Elasticsearch connection callback to validate the Elasticsearch version. Unfortunately, this callback didn't account for the later `allow_older_versions` update via the control protocol and the updated value was not used. This fixes that broken behaviour and makes an update to the entire in-memory output configuration on each control protocol update. (cherry picked from commit 1a9d627) --------- Co-authored-by: Denis <denis.rechkunov@elastic.co>
When Beats are running under Elastic Agent their initial output configuration is empty. Only a few moments later the output configuration arrives as an update via the control protocol. On startup Beats register a global Elasticsearch connection callback to validate the Elasticsearch version. Unfortunately, this callback didn't account for the later `allow_older_versions` update via the control protocol and the updated value was not used. This fixes that broken behaviour and makes an update to the entire in-memory output configuration on each control protocol update. (cherry picked from commit 1a9d627) # Conflicts: # libbeat/cmd/instance/beat_test.go
…er Elastic Agent (#35574) * Update `allow_older_versions` when running under Elastic Agent (#34964) When Beats are running under Elastic Agent their initial output configuration is empty. Only a few moments later the output configuration arrives as an update via the control protocol. On startup Beats register a global Elasticsearch connection callback to validate the Elasticsearch version. Unfortunately, this callback didn't account for the later `allow_older_versions` update via the control protocol and the updated value was not used. This fixes that broken behaviour and makes an update to the entire in-memory output configuration on each control protocol update. (cherry picked from commit 1a9d627) # Conflicts: # libbeat/cmd/instance/beat_test.go * Remove duplicate changelog entry * Fix conflict in beat_test.go. --------- Co-authored-by: Denis <denis.rechkunov@elastic.co> Co-authored-by: Craig MacKenzie <craig.mackenzie@elastic.co>
When Beats are running under Elastic Agent their initial output configuration is empty. Only a few moments later the output configuration arrives as an update via the control protocol. On startup Beats register a global Elasticsearch connection callback to validate the Elasticsearch version. Unfortunately, this callback didn't account for the later `allow_older_versions` update via the control protocol and the updated value was not used. This fixes that broken behaviour and makes an update to the entire in-memory output configuration on each control protocol update.
What does this PR do?
When Beats are running under Elastic Agent their initial output configuration is empty. Only a few moments later the output configuration arrives as an update via the control protocol.
On startup Beats register a global Elasticsearch connection callback to validate the Elasticsearch version. Unfortunately, this callback didn't account for the later
allow_older_versionsupdate via the control protocol and the updated value was not used.This fixes that broken behaviour and makes an update to the entire in-memory output configuration on each control protocol update.
The flag is extracted in a separate struct field for quicker access without a need to parse the configuration again.
Why is it important?
Our customers are not able to use Elastic Agent with a previous minor version of Elasticsearch, although they might be absolutely compatible.
Checklist
- [ ] I have made corresponding changes to the documentation- [ ] I have made corresponding change to the default configuration filesCHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.How to test this PR locally
elastic-package stack up- this ran elasticsearch@8.6.1 for meDEV=true SNAPSHOT=true PLATFORMS="<your platform>" mage -v packagepolicy.yml:sudo -- ./elastic-agent -e run -c ./policy.yml 2> output-agent.ndjsonoutput-agent.ndjsondespite theallow_older_versions: truein the policy:{ "log.level": "error", "@timestamp": "2023-03-29T18:41:07.937+0200", "message": "Failed to connect to backoff(elasticsearch(https://127.0.0.1:9200)): Connection marked as failed because the onConnect callback failed: Elasticsearch is too old. Please upgrade the instance. If you would like to connect to older instances set output.elasticsearch.allow_older_versions to true. ES=8.6.1, Beat=8.8.0", "component": { "binary": "filebeat", "dataset": "elastic_agent.filebeat", "id": "filestream-monitoring", "type": "filestream" }, "log": { "source": "filestream-monitoring" }, "log.logger": "publisher_pipeline_output", "log.origin": { "file.line": 150, "file.name": "pipeline/client_worker.go" }, "service.name": "filebeat", "ecs.version": "1.6.0" }After the fix, there are no more errors and you can see events coming in Kibana Discover.
I also removed
allow_older_versions: truefrom the policy and ran the agent to verify that I still see the expected version validation errors when the flag is not set.I tried to run Filebeat in a standalone mode in this configuration:
(don't forget to change the paths and write some lines to the matching log files).
And I can still see the expected error message when
allow_older_versions: false:{ "log.level": "error", "@timestamp": "2023-03-29T21:21:13.492+0200", "log.logger": "publisher_pipeline_output", "log.origin": { "file.name": "pipeline/client_worker.go", "file.line": 150 }, "message": "Failed to connect to backoff(elasticsearch(https://127.0.0.1:9200)): Connection marked as failed because the onConnect callback failed: Elasticsearch is too old. Please upgrade the instance. If you would like to connect to older instances set output.elasticsearch.allow_older_versions to true. ES=8.6.1, Beat=8.8.0", "service.name": "filebeat", "ecs.version": "1.6.0" }And no error message when
allow_older_versions: true. Also, I see data coming in Kibana Discover on thefilebeat-*index pattern.Related issues