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

/metrics endpoint is way too slow under Wildfly 8 #246

Closed
juliohm1978 opened this issue Feb 20, 2018 · 5 comments
Closed

/metrics endpoint is way too slow under Wildfly 8 #246

juliohm1978 opened this issue Feb 20, 2018 · 5 comments

Comments

@juliohm1978
Copy link
Contributor

juliohm1978 commented Feb 20, 2018

This was earlier reported on #175, which was closed by adding a footnote in the documentation.

I'm running Wildfly instances in a few Docker containers and the /metrics entpoint takes way too long. From inside the container:

$ time curl http://localhost:28686/metrics

## clipped output (metrics are returned as filtered)

real	1m28.087s
user	0m0.020s
sys	0m0.024s

We are having better results using Glassfish 3.1.2.2 or Wildfly 10. Any particular reason why this is taking so long under Wildfly 8? Any tips on how to filter metrics to make the endpoint faster?

Otherwise, we'll have to configure Prometheus with a scrape_interval of at least 2 minutes!

@afalko
Copy link
Contributor

afalko commented Feb 20, 2018

Have you tried latest version version currently in master branch? Several perf improvements were made in master that haven't been released yet.

@brian-brazil
Copy link
Contributor

This is something to take up with Wildfly, we don't control how slow JMX endpoints are.

@juliohm1978
Copy link
Contributor Author

Just tried your suggestion and compiled a fresh version of the master branch: jmx_prometheus_javaagent-0.2.1-SNAPSHOT.jar.

The results are better, down to 30 seconds!

$ time curl http://localhost:28686/metrics

## clipped output (metrics are returned as filtered)

real	0m32.259s
user	0m0.012s
sys	0m0.016s

Still not ideal, but it does fall under an acceptable range for my team.

Thanks a lot!

@n3v3rf411
Copy link

I'm having the same same issue as yours where the usual scrape time takes about 43 seconds even with the latest code. In my case, I already the know the object names in advance so I set whitelistObjectNames accordingly like as follows:

---
whitelistObjectNames: ["jboss.as:subsystem=undertow,server=*,http-listener=*"]
lowercaseOutputName: true
lowercaseOutputLabelNames: true
rules:
  - pattern: "^jboss.as<subsystem=undertow, server=(.+), http-listener=(.+)><>(bytes_.+|error_count|processing_time|request_count):"
    attrNameSnakeCase: true
    name: wildfly_undertow_$3
    labels:
      server: $1
      http_listener: $2

This improves scrape time from 43s to only 0.028s.

finkr added a commit to finkr/jmx_exporter that referenced this issue Jun 14, 2018
see prometheus#246 (comment)
With this patch, the scrape time (`jmx_scrape_duration_seconds`) dropped from 15 seconds to 0.9s. (using with jmx_explorer 0.7)

I can therefore avoid increasing  `scrape_timeout` and `scrape_interval`.
finkr added a commit to finkr/jmx_exporter that referenced this issue Jun 14, 2018
see prometheus#246 (comment)
With this patch, the scrape time (`jmx_scrape_duration_seconds`) dropped from 15 seconds to 0.9s. (using with jmx_explorer 0.7)

I can therefore avoid increasing  `scrape_timeout` and `scrape_interval`.

Signed-off-by: Frank Lin Piat <fpiat@klabs.be>
@finkr
Copy link
Contributor

finkr commented Jun 14, 2018

I have submitted a PR to add whitelistObjectNames, see #284

Thanks @n3v3rf411

brian-brazil pushed a commit that referenced this issue Jun 15, 2018
see #246 (comment)
With this patch, the scrape time (`jmx_scrape_duration_seconds`) dropped from 15 seconds to 0.9s. (using with jmx_explorer 0.7)

I can therefore avoid increasing  `scrape_timeout` and `scrape_interval`.

Signed-off-by: Frank Lin Piat <fpiat@klabs.be>
qinghui-xu pushed a commit to qinghui-xu/jmx_exporter that referenced this issue Sep 18, 2020
see prometheus#246 (comment)
With this patch, the scrape time (`jmx_scrape_duration_seconds`) dropped from 15 seconds to 0.9s. (using with jmx_explorer 0.7)

I can therefore avoid increasing  `scrape_timeout` and `scrape_interval`.

Signed-off-by: Frank Lin Piat <fpiat@klabs.be>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants