[
https://issues.apache.org/jira/browse/SOLR-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865546#comment-17865546
]
Chris M. Hostetter commented on SOLR-10654:
-------------------------------------------
Ok, but your stated goal...
{quote}The test using solr-prometheus-output.txt, which I asked for, is
intended to ensure we don't accidentally remove an exported metric due to some
internal renaming choice or a change in the type of metric. That's it. It
also serves as an integration test.
{quote}
Is 100% compatible with my suggestion...
{quote}The test needs to parse the "actual" response and make some basic
assertions about the _structure_ it finds, and if there are certain metrics
that should *always* be present, assert they exist with values that are _valid_
(ie: can be parsed as an int, or can be parsed as a float) w/o asserting
exactly what those values are.
{quote}
...if you want to keep that list of "mandatory" expected metrics that should
*always* be present in a txt file because you think that's easier to maintain
then a static {{Arrays.asList(...)}} so be it. But the way it works now:
asserting that the entire actual response, with a confusing regex applied, will
exactly equals the contents of text file is seriously problematic...
# It's Brittle AF, and is going to be tedius to update anytime we add metrics
– or anytime a library we use (like jetty or dropwizard's executor service)
adds metrics. And if the dev process is "update this exepcted txt fle to match
the actual response anytime the test fails" ... then WTF is the point of having
the test?
# As seen in the 100% jenkins failure rate: Unless/until the lifecycle of
Gauges is drastically overhauled in a future version of dropwizard, you can
never prededict the full list of (jetty, maybe other) metrics that will be in
the actual response depending on what other tests ran before this one in the
same JVM.
#2 is really my biggest concern right now – this isn't a question of what to
do *_*IF*_* the test fails in the future – this test has literally *_never
passed!_*
> Expose Metrics in Prometheus format DIRECTLY from Solr
> ------------------------------------------------------
>
> Key: SOLR-10654
> URL: https://issues.apache.org/jira/browse/SOLR-10654
> Project: Solr
> Issue Type: Improvement
> Components: metrics
> Reporter: Keith Laban
> Priority: Major
> Attachments: prometheus_metrics.txt
>
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> Expose metrics via a `wt=prometheus` response type.
> Example scape_config in prometheus.yml:
> {code:java}
> scrape_configs:
> - job_name: 'solr'
> metrics_path: '/solr/admin/metrics'
> params:
> wt: ["prometheus"]
> static_configs:
> - targets: ['localhost:8983']
> {code}
> [Rationale|https://issues.apache.org/jira/browse/SOLR-11795?focusedCommentId=17261423&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17261423]
> for having this despite the "Prometheus Exporter". They have different
> strengths and weaknesses.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
