Skip to content
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

Link profiles to indexers #611

Merged
merged 14 commits into from
Apr 19, 2024
Merged

Conversation

rsevilla87
Copy link
Member

@rsevilla87 rsevilla87 commented Mar 18, 2024

Type of change

  • Refactor
  • New feature
  • Bug fix
  • Optimization
  • Documentation Update

Description

Multiple changes with the goal to adopt the updated version the metricsEndpoints API in the configuration file and link metrics, alerts (supporting multiple files now) and measurements to indexers:

With this change the configuration file now looks like:

metricsEndpoints:
- prometheusURL: http://localhost:9090
  token: blablabla
  indexer: 
    type: opensearch
    esServers: ["https://es-instance.com:9200"]
    defaultIndex: kube-burner
  metrics: [metrics-profile.yaml]
  alerts: [alert-profile.yaml]
- prometheusURL: http://localhost:9090
  token: blablabla
  indexer: 
    type: local
  metrics: [metrics-profile.yaml]
  alerts: [alert-profile.yaml]

Another important feature is that now It's possible to "split" the measurement metrics and send them to different indexers thanks to the new fields timeseriesIndexer and quantilesIndexer. i.e:

metricsEndpoints:
- indexer:
    type: local
    alias: local-indexer
- indexer:
    type: opensearch
    defaultIndex: kube-burner
    esServers: ["https://opensearch.domain:9200"]
    alias: opensearch-indexer
global:
  measurements:
  - name: podLatency
    timeseriesIndexer: local-indexer
    quantilesIndexer: opensearch-indexer

With the snippet above, the measurement podLatency would use the local indexer for timeseries metrics and opensearch for the quantile metrics. cc: @afcollins

Related Tickets & Documents

  • Related Issue #
  • Closes #

@rsevilla87 rsevilla87 added documentation Improvements or additions to documentation enhancement New feature or request labels Mar 19, 2024
@rsevilla87 rsevilla87 marked this pull request as ready for review March 19, 2024 11:48
@afcollins
Copy link
Contributor

So timeseriesIndexer: 1 is the index ordinal of the indexers defined under endpoints starting with 1 (not 0) ?

I like being able to specify different metrics profiles for each indexer, so that then we can push report mode to elastic and capture the timeseries locally, for metrics profile metrics.

@rsevilla87
Copy link
Member Author

So timeseriesIndexer: 1 is the index ordinal of the indexers defined under endpoints starting with 1 (not 0) ?

I like being able to specify different metrics profiles for each indexer, so that then we can push report mode to elastic and capture the timeseries locally, for metrics profile metrics.

Yeah, that number points to the indexer to be used. The reason not to use 0 was that 0 is the "null" value of an integer variable, so in case of not specifying timeseriesIndexer 0 would be assumed. Open to other ideas though; Im not super-fan of this either.

@vishnuchalla
Copy link
Collaborator

Except for the build and test failures, overall idea looks good to me.

@vishnuchalla
Copy link
Collaborator

So timeseriesIndexer: 1 is the index ordinal of the indexers defined under endpoints starting with 1 (not 0) ?
I like being able to specify different metrics profiles for each indexer, so that then we can push report mode to elastic and capture the timeseries locally, for metrics profile metrics.

Yeah, that number points to the indexer to be used. The reason not to use 0 was that 0 is the "null" value of an integer variable, so in case of not specifying timeseriesIndexer 0 would be assumed. Open to other ideas though; Im not super-fan of this either.

Instead of numbering here, can we have a name filed in each metricsEndpoint that can be used to reference as an alias for indexer? that way I feel it will be more intuitive for an end user.

@vishnuchalla
Copy link
Collaborator

vishnuchalla commented Mar 27, 2024

So timeseriesIndexer: 1 is the index ordinal of the indexers defined under endpoints starting with 1 (not 0) ?
I like being able to specify different metrics profiles for each indexer, so that then we can push report mode to elastic and capture the timeseries locally, for metrics profile metrics.

Yeah, that number points to the indexer to be used. The reason not to use 0 was that 0 is the "null" value of an integer variable, so in case of not specifying timeseriesIndexer 0 would be assumed. Open to other ideas though; Im not super-fan of this either.

Instead of numbering here, can we have a name filed in each metricsEndpoint that can be used to reference as an alias for indexer? that way I feel it will be more intuitive for an end user.

Few more thoughts to add on top of it.

  • Currently Prometheus metrics are being indexed to all the indexers. Can we have an option to restrict it to one specific indexer?
  • As an extension of above point I think it is good to have 3 fields for indexing, timeSeriesIndexer (for prom metrics), latenciesIndexer (for pod latencies etc) and quantilesIndexer (for pod latency quantiles) at global level (i.e outside measurements config) and at each job level. Meaning indexers at job level will override the ones at global level if a user wants to.
  • Default values of global indexers should be all until unless user explicitly specifies index aliases.

@rsevilla87
Copy link
Member Author

So timeseriesIndexer: 1 is the index ordinal of the indexers defined under endpoints starting with 1 (not 0) ?
I like being able to specify different metrics profiles for each indexer, so that then we can push report mode to elastic and capture the timeseries locally, for metrics profile metrics.

Yeah, that number points to the indexer to be used. The reason not to use 0 was that 0 is the "null" value of an integer variable, so in case of not specifying timeseriesIndexer 0 would be assumed. Open to other ideas though; Im not super-fan of this either.

Instead of numbering here, can we have a name filed in each metricsEndpoint that can be used to reference as an alias for indexer? that way I feel it will be more intuitive for an end user.

Few more thoughts to add on top of it.

* Currently Prometheus metrics are being indexed to all the indexers. Can we have an option to restrict it to one specific indexer?

They are not, the idea of this PR is to link metricsProfiles to indexers so we can restrict what we send to each indexer, if not working like this there must be a bug

@rsevilla87
Copy link
Member Author

So timeseriesIndexer: 1 is the index ordinal of the indexers defined under endpoints starting with 1 (not 0) ?
I like being able to specify different metrics profiles for each indexer, so that then we can push report mode to elastic and capture the timeseries locally, for metrics profile metrics.

Yeah, that number points to the indexer to be used. The reason not to use 0 was that 0 is the "null" value of an integer variable, so in case of not specifying timeseriesIndexer 0 would be assumed. Open to other ideas though; Im not super-fan of this either.

Update, I've updated the code to use indexer aliases rather than integers pointing to an indexer

@rsevilla87 rsevilla87 force-pushed the indexers-profiles branch 2 times, most recently from c33c96d to e4cd82f Compare April 1, 2024 10:58
if scraperConfig.MetricsEndpoint != "" {
scraperConfig.ConfigSpec.MetricsEndpoints = DecodeMetricsEndpoint(scraperConfig.MetricsEndpoint)
}
for pos, metricsEndpoint := range scraperConfig.ConfigSpec.MetricsEndpoints {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this loop indexing metrics.yaml in all the given list of indexers?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't follow you... what do you mean?

globalCfg = configSpec.GlobalConfig
factory = measurementFactory{
createFuncs: make(map[string]measurement),
metadata: metadata,
}
for _, measurement := range globalCfg.Measurements {
indexerFound = false
if measurement.QuantilesIndexer != "" {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you refactor this if-block? Looks like common logic being used for both the indexers.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated and optimized this logic, PTAL

@rsevilla87 rsevilla87 force-pushed the indexers-profiles branch 2 times, most recently from dfe0d8c to 0810041 Compare April 15, 2024 10:02
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
…y are not necessary

Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Copy link
Collaborator

@vishnuchalla vishnuchalla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@rsevilla87 rsevilla87 merged commit d0c1563 into kube-burner:main Apr 19, 2024
6 checks passed
@rsevilla87 rsevilla87 mentioned this pull request Apr 22, 2024
5 tasks
rsevilla87 pushed a commit that referenced this pull request Apr 22, 2024
## Type of change

- [ ] Refactor
- [ ] New feature
- [x] Bug fix
- [ ] Optimization
- [ ] Documentation Update

## Description

#611 added
`metricsEndpoints`. Update examples to fix the error.
```
level=fatal msg="Config error: error decoding configuration file: yaml: unmarshal errors:\n  line 2: field indexers not found in type config.Spec" file="kube-burner.go:97"
```

## Related Tickets & Documents

- Related Issue #
- Closes #

Signed-off-by: Shuaiyi Zhang <zhang_syi@qq.com>
vishnuchalla pushed a commit that referenced this pull request Apr 24, 2024
## Type of change

- [ ] Refactor
- [ ] New feature
- [x] Bug fix
- [ ] Optimization
- [ ] Documentation Update

## Description

My mistake, kube-burner-ocp doesn't work well with the latest changes
pushed in #611

## Related Tickets & Documents

- Related Issue #
- Closes #

Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants