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: commits-unsubscr...@pulsar.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org