-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inputs with incomplete variable substitutions will be silently ignored #2261
Comments
@blakerouse any ideas what would be causing this? |
It can be quite easy to overlook an input is not running especially in very complex policies. It might become more complex to handle when using autodiscovery, but the example in this issue should be manageable to report. |
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
+1 |
discarded-input.yml.txt
The attached agent policy (with .txt extension so GitHub would let me upload it) should start two instances of the httpjson input, but only ends up starting the input with ID
httpjson-ti_abusech-5c2d6965-8136-4237-8c08-20a54da01a13
.Looking the diagnostics the second input with ID
httpjson-ti_misp-911740ef-8690-424f-8e0c-e7a540a178d6
is present in thepre-config.yaml
but removed in thecomputed-config.yaml
suggesting that the agent has decided it does not need to run it without explaining why.Looking closer at the agent policy reveals the use of
${MISP_API_KEY}
as a variable that does not resolve to anything. The agent determines that the input configuration is incomplete and decides not to run it without any error messages in the logs or the agent status output.We can continue not running the input at all, but a much better user experience would be for the removed input to appear in the
elastic-agent status
input with an error indicating that the input could not be started because of an error during variable substitution.We could consider a simple log statement, but including the incomplete input in the agent runtime model allows its status to be reported back to Fleet in a much more obvious way.
The text was updated successfully, but these errors were encountered: