Prometheus set datastream name

[gizas]

• Enhancement

What does this PR do?

This PR adds the data_stream.dataset textbox for the Prometheus Integration package in UI, in order users to be able to change the dataset name for all the supported Prometheus configurations (Collector, PromQL, Remote_write)
Tested with latest 8.6.2 version of ES

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.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

How to test this PR locally

1. Clone this PR locally
2. Change to Prometheus package folder cd /elastic/integrations/packages/prometheus
3. Run elastic-package build
4. Create Elastic Stack: elastic-package stack up -d -vvv --version=8.6.2
5. Provide different configurations for Prometheus by following guide: https://github.com/elastic/observability-dev/blob/main/docs/infraobs/cloudnative-monitoring/testing/prometheus-integration-on-k8s.md

Related issues

• Closes Adding support for dataset configuration for Prometheus Integration #5285 Adding support for dataset configuration for Prometheus Integration #5285

Screenshots

Default Collector config:

Collector Configuration changed:

Collector with new dataset name:

PromQL Default:

Changed Promql dataset name:

Remote Write default:

Changing Default Configuration for remote_write:

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-02-24T12:07:10.655+0000

• Duration: 16 min 35 sec

Test stats 🧪

Test	Results
Failed	0
Passed	9
Skipped	0
Total	9

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (0/0)	💚
Files	100.0% (0/0)	💚
Classes	100.0% (0/0)	💚
Methods	88.889% (8/9)	👎 -7.013
Lines	100.0% (0/0)	💚 11.181
Conditionals	100.0% (0/0)	💚

[tetianakravchenko]

I think we do not need this if, in case of providing a default value

the same for other data_streams

[gizas]

Indeed, removed with fb2f0ef

[ChrsMark]

@gizas could you provide more details on why we need this addition?
I would expect that this information should be added automatically by Agent, isn't that the case?

[gizas]

@ChrsMark the agent indeed provides a default value of dataset per datastream. This PR adds the flexibility to the user to direct certain metrics to certain datastream (via the dataset naming).

Especially for collector scenario, imagine that user can scrape two diffrent exporters and separate metrics would had been saved in the same prometheus.collector in the past. Now it can create two policies and save them to different ones

[ChrsMark]

Thanks @gizas ! That make sense as an advanced option.
What is concerning to me here is that the specific change implies that the Prometheus package stands as an "input" package too, right? This distinction is not clear yet for this package and it feels like we mix 2 different things here. Are there any plans or discussions regarding if there will be a generic Prometheus input package?
This specific change in this PR would fit to an input package but not to a Prometheus specific one (a package that collects Prometheus server metrics).

[gizas]

I would not say that Prometheus Package stands as an "input." solely. In our team we still promote remote_write and we underline that this Integration aims for the Prometheus Server scraping.

But correctly this change is towards the input. We integrated here a "feature" of the input. FYI we tried to support an ask from the SREs of the MKI project to be able to change the dataset name.

Additionally we have in our backlog the Prometheus Input story and we have made some discussions on what differences this should have comparing to this integration. But until the Prometheus Inout package is out there, we added this change here

[tetianakravchenko]

@gizas is it intentional to make this setting not a advanced option?

[gizas]

Yes. What do you think?
I had changed my mind and thought it can be better like that. Dont have a strong opinion

[tetianakravchenko]

I was thinking about this setting more as an "advanced option" to not overwhelm the configuration view, but it is not a strong opinion as well

[elasticmachine]

Package prometheus - 1.3.0 containing this change is available at https://epr.elastic.co/search?package=prometheus