lhotari commented on code in PR #22490:
URL: https://github.com/apache/pulsar/pull/22490#discussion_r1562306801
##########
pulsar-broker-common/src/main/java/org/apache/pulsar/broker/ServiceConfiguration.java:
##########
@@ -2915,7 +2915,9 @@ The max allowed delay for delayed delivery (in
milliseconds). If the broker rece
private boolean exposeTopicLevelMetricsInPrometheus = true;
@FieldContext(
category = CATEGORY_METRICS,
- doc = "If true, export buffered metrics"
+ doc = "Set to true to enable the broker to cache the metrics
response, default is false. "
+ + "For scraping metrics more than once per scrape period,
the broker generates metrics at the first "
+ + "scrape and returns the same response for the rest of
the scrape period. "
Review Comment:
Add a better definition for scraping period. Currently "scrape period" is
vague. It's better to explicitly define it. There's 2 different concepts that
are involved:
* Internally, there's a caching period for the metrics response. In the
implementation, the caching period is defined with
`managedLedgerStatsPeriodSeconds`.
* In Prometheus, there's a global setting called
["scrape_interval"](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#configuration-file)
and in the Prometheus operator there's [PodMetricsEndpoint
interval](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#monitoring.coreos.com/v1.PodMetricsEndpoint)
for configuring the scraping interval for individual scraping endpoints.
Please revisit the description to resolve the issue with the undefined
concept "scrape period".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
