dsmiley commented on code in PR #3713:
URL: https://github.com/apache/solr/pull/3713#discussion_r2404679251
##########
solr/solrj-zookeeper/src/java/org/apache/solr/client/solrj/impl/NodeValueFetcher.java:
##########
@@ -197,10 +173,12 @@ private void getRemoteMetricsFromTags(
SimpleSolrResponse rsp =
ctx.cloudSolrClient.getHttpClient().requestWithBaseUrl(baseUrl,
req::process);
- for (Metrics t : requestedMetricNames) {
- Object value = t.extractResult(rsp.getResponse());
- if (value != null) {
- ctx.tags.put(t.tagName, value);
+ try (InputStream prometheusStream = (InputStream)
rsp.getResponse().get(STREAM_KEY)) {
+ for (Metrics t : requestedMetricNames) {
+ Object value = t.extractFromPrometheus(prometheusStream);
Review Comment:
> That shouldn't be what the /admin/metrics endpoint is intended for. We
should probably do something like implement our own MetricReader otel instance
(SolrMetricReader) and expose those "well known metrics" in a structured format
that is easier to read for this NodeValueFetchers or for internal callers.
Might be too late now but just my thoughts....
I disagree and would rather not see a bespoke internal endpoint for certain
metrics just because it's not super simple to parse Prometheus. Instead, I
propose we have dedicated Prometheus parsing utilities that makes doing what we
need here easy. I imagine some tests might make use of such utilities too.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
