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

http_client_requests_seconds Prometheus metrics missing with retry enabled #1294

Open
gianvitom opened this issue Jun 22, 2022 · 10 comments
Open
Labels

Comments

@gianvitom
Copy link

Looks like when retry is enabled for the Prometheus does not return the http_client_requests_seconds metric for the configured client

Description

The stack we are using is SpringBoot 2.6.8, Riptide 3.2.2 and Kotlin/target Java 17 (eclipse-temurin), GET operation on the client.
With this configuration:

factoring-service:
      base-url: https://xxx.zalan.do/
      tracing:
        tags:
          peer.service: factoring-service
      retry:
        enabled: true
        fixed-delay: 10 milliseconds
        max-retries: 1

The prometheus actuator doesn't return the http_client_requests_seconds metric (for other clients without retry everything is fine).
While disabling it, so with just:

factoring-service:
      base-url: https://xxx.zalan.do/
      tracing:
        tags:
          peer.service: factoring-service

Everything is fine.

Expected Behavior

http_client_requests_seconds is returned in any case, when the client operation is called.

Actual Behavior

http_client_requests_seconds is missing for the client configured with retry enabled, while it is returned for all the other clients

Steps to Reproduce

  • Configure a project with the previous stack (defined at the beginning of the description)
  • Configure 2 clients, one with retry and another without
  • Verify, after calling the client operations, that only for one of them the metric http_client_requests_seconds is available.

Context

Upgrade SpringBoot/Riptide/JDK in the project

@gianvitom gianvitom added the Bug label Jun 22, 2022
@gianvitom
Copy link
Author

From an additional investigation, looks like with retry enabled there is an additional tag called retry_number that doesn't exist in the metrics for the clients without retry.

So, if you have multiple Riptide clients defined, some with retry.enabled=true and others without, depending on which one pushes the metric first, the ones that pushes after will not be visible.

@whiskeysierra
Copy link
Collaborator

whiskeysierra commented Jun 23, 2022 via email

@gianvitom
Copy link
Author

Do you mean by setting:

  • metric tag retry_number = 0
  • metric tag retry = false
    if the metrics do not contain those already?

In a MeterFilter, like this?

@Configuration
class RiptideMetricsConfiguration {
    @Bean
    fun meterFilter(): MeterFilter {
        return object : MeterFilter {
            override fun map(id: Meter.Id): Meter.Id {
                return if (id.name.startsWith("http.client") && id.tags.none { it.key.equals("retry_number") })
                    id.withTags(Tags.concat(Tags.of("retry_number", "0", "retry", "false"), id.tagsAsIterable))
                else
                    id
            }
        }
    }
}

@whiskeysierra
Copy link
Collaborator

That might work. Alternatively, you can use the application.yaml:

riptide:
  defaults:
    metrics:
      tags:
        retry: "false"
        retry_number: "0"
  clients:
    factoring-service:
      base-url: https://xxx.zalan.do/
      tracing:
        tags:
          peer.service: factoring-service
      retry:
        enabled: true
        fixed-delay: 10 milliseconds
        max-retries: 1

@gianvitom
Copy link
Author

Nice, would that override only the ones without or also the one that already have it for example retry_number=1 and retry=true?

@whiskeysierra
Copy link
Collaborator

I believe it should.

@gianvitom
Copy link
Author

Ok, you mean the ones with already the tags will not re-default to false/0?

@whiskeysierra
Copy link
Collaborator

Sorry, it should default it for every client, but the ones with retry enabled should then override it with proper values.

@gianvitom
Copy link
Author

Ok, thank you. I will try to use your suggestion 👍

@whiskeysierra
Copy link
Collaborator

For reference, this is the issue for micrometer: micrometer-metrics/micrometer#877

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants