[Windows] Add custom conditions support for Perfmon

[mholttech]

Proposed commit message

Enable using conditionals to apply custom perfmon queries to specific systems.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

Related issues

• Closes [Windows]: Enable custom conditionals for Perfmon #12829

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[elasticmachine]

Pinging @elastic/sec-windows-platform (Team:Security-Windows Platform)

[belimawr]

@mholttech you missed updating the version on manifest.yml

[belimawr]

The only problem with this approach is that condtition is a space character ( ), {{#if condition }} will evaluate to true, rendering

condition: ${host.platform} == 'windows' and

Which will make the Elastic-Agent fail to start the input with the following error:

PS C:\elastic-agent-8.17.2-windows-x86_64> & 'C:\Program Files\Elastic\Agent\elastic-agent.exe' status
+- fleet
¦  +- status: (HEALTHY) Connected
+- elastic-agent
   +- status: (FAILED) Invalid component model: rendering inputs failed: invalid condition "${host.platform} == 'windows' and": condition line 1 column 33: mismatched input '<EOF>' expecting {TRUE, FALSE, FLOAT, NUMBER, NOT, NAME, STEXT, DTEXT, '(', '[', '{', '$${', '${'}
PS C:\elastic-agent-8.17.2-windows-x86_64>

The way it shows in Fleet UI is not the most clear either:

If I recall correctly I tried something similar in the past, the solution was to have the whole condition in the field, so ${host.platform} == 'windows' would be the default value allowing users to freely modify it.

[belimawr]

The system integration has a similar situation: a default for condition but we also want to allow the users to add/overwrite it. We ended up using a default and documenting this default, so users always have an easy way to revert to the default behaviour.

Here is the example:

integrations/packages/system/manifest.yml

Lines 53 to 66 in 01ffd84

	- name: condition
	title: Condition
	description: |
	Condition to filter when to apply this input. Refer to
	[Host provider](https://www.elastic.co/guide/en/fleet/current/host-provider.html)
	to find the available keys and to
	[Conditions](https://www.elastic.co/guide/en/fleet/current/dynamic-input-configuration.html#conditions)
	on how to use the available keys in conditions. It defaults to
	'${host.os_version} == "12 (bookworm)" or (${host.os_platform} == "amzn" and ${host.os_version} == "2023")'
	type: text
	multi: false
	required: false
	show_user: true
	default: ${host.os_version} == "12 (bookworm)" or (${host.os_platform} == "amzn" and ${host.os_version} == "2023")

[mholttech]

That's odd. I'll go ahead and make the change and update the manifest version but it seems like there might be some inconsitencies on how the agent handles this in various situations.

I grabbed this particular pattern from a k8s datastream that i'm familiar with

integrations/packages/kubernetes/data_stream/scheduler/agent/stream/stream.yml.hbs

Lines 13 to 17 in 01ffd84

	{{#if condition }}
	condition: ${kubernetes.labels.{{~scheduler_label_key~}} } == '{{scheduler_label_value}}' and {{ condition }}
	{{ else }}
	condition: ${kubernetes.labels.{{~scheduler_label_key~}} } == '{{scheduler_label_value}}'
	{{/if}}

[belimawr]

(...) it seems like there might be some inconsitencies on how the agent handles this in various situations.

Integrations are owned by different teams and we have a huge number of integrations, sometimes different teams have different approaches to solve the same problem.

[strawgate]

Won't this hide it from the integration configuration?

[mholttech]

show_user: false puts this under "Advanced Options" instead of making it always appear. I figured that would be a good default for this one because it only needs to be modified in specific use cases, especially since it looks like we need to change the implementation slightly per @belimawr's comments

https://github.com/elastic/package-spec/blob/964c4a69e024cc464c4808720ba0db9f001a82a7/spec/integration/data_stream/manifest.spec.yml#L119-L123

[belimawr]

I like keeping it under the "Advanced options"