[Elastic Agent] Discuss: Use EQL for constraints in Elastic Agent

[ruflin]

The Elastic Agent supports constraints/conditions in its configuration to apply certain configs only in certain environments. Details of the discussion can be found here: #16409

The config currently looks as following (examples):

constraints:
  - %{[hello.var]} == 'hello'
  - "validate_version(%{[agent.version]}, '1.0.0 - 7.0.0')"

Elasticsearch is currently in the process of adding support for EQL (https://www.elastic.co/guide/en/elasticsearch/reference/master//eql.html). Looking at the basic syntax of EQL it looks very similar to what we have today: https://eql.readthedocs.io/en/latest/query-guide/basic-syntax.html#conditions

Our users should have to learn as few query languages as possible, that is why I'm proposing we switch to the same syntax as EQL in our constraints.

Currently on our end we use %{[hello.var]} for variables which in EQL would just become hello.var. I'm wonder if this is possible? If not, could we switch to something like moustache as at least this is used in other parts of the stack for variables, for example in Elasticsearch ingest pipelines so it would become {{hello.var}}.

We would not support all functions and options of EQL but a small subset and potentially add a few of our own functions like validate_version. If we name some of the functions the same, behaviour should be the same.

[ruflin]

@ph @michalpristas @jpountz Would be great to get your thoughts on this.

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[jpountz]

I don't think it would be a bad idea to make them consistent, but I don't think it's a requirement. My understanding is that people configuring agents and using EQL would typically be different users (admins vs. analysts), plus EQL is one out of many languages that we plan to support.

[ph]

I don't have a strong opinion on variables %{[]} vs {{}}, this was create before EQL exists on our
side.

Currently on our end we use %{[hello.var]} for variables which in EQL would just become hello.var. I'm wonder if this is possible? If not, could we switch to something like moustache as at least this is used in other parts of the stack for variables, for example in Elasticsearch ingest pipelines so it would become {{hello.var}}.

This is possible, without too much effort, I think its even work today (minus the ".", we need to add this to the allowed list of chars.) By default our parser would consider this as a function call that doesn't exist.

it's a 20 lines code changes and regenerate the state machine.

[michalpristas]

from my point of view it would be better to have a single syntax across products it makes look our products more compact and interconnected. as ph said change wont be that difficult parser change + existing configuration (there's not much of it)

[blakerouse]

Closing this because of #20784