justinrsweeney opened a new pull request, #948:
URL: https://github.com/apache/solr/pull/948

   This is more effective for metrics when there are a large number of cores 
per node, especially since some metrics like histograms cannot be aggregated 
after the fact.
   
   https://issues.apache.org/jira/browse/SOLR-15007
   
   <!--
   _(If you are a project committer then you may remove some/all of the 
following template.)_
   
   Before creating a pull request, please file an issue in the ASF Jira system 
for Solr:
   
   * https://issues.apache.org/jira/projects/SOLR
   
   For something minor (i.e. that wouldn't be worth putting in release notes), 
you can skip JIRA. 
   To create a Jira issue, you will need to create an account there first.
   
   The title of the PR should reference the Jira issue number in the form:
   
   * SOLR-####: <short description of problem or changes>
   
   SOLR must be fully capitalized. A short description helps people scanning 
pull requests for items they can work on.
   
   Properly referencing the issue in the title ensures that Jira is correctly 
updated with code review comments and commits. -->
   
   
   # Description
   
   Currently request handlers provide metrics (request count, times, rate) at 
the core level so each core gets distinct metrics for each handler. For use 
cases where there are a large number of cores per node this creates a large 
number of metrics which can make the `/admin/metrics` endpoint unwieldy and 
provide a lot of metrics that aren't easy to use for comparisons.
   
   As an example, at FullStory we were more interested in per node performance 
for `/select` and `/update` than per core performance. Due to the challenge of 
many cores per node and difficulty in aggregating Meter or Histogram metrics 
after the fact, this was essentially impossible using core level metrics. By 
introducing this change, we are able to view metrics for those request handlers 
on a per node basis by just getting the metrics for the `solr.node` group. This 
means less metrics data to process and the ability to compare across nodes.
   
   # Solution
   
   This solution implements a new type of each metric (Counter, Timer, Meter, 
Histogram) allowing for both a primary and delegate metric to be updated. If 
`aggregateNodeLevelMetricsEnabled` is true for a given request handler then a 
delegate type of metric will be created instead of a normal Counter, Timer, 
Meter or Histogram. This will update both primary and delegate when called.
   
   In this case, the primary metric is still the core level metric as part of 
the core level registry and the delegate is a node level metric as part of the 
node level registry.
   
   This ensure that core level metrics are still provided as is, but we can 
additionally provide node level metrics for specific request handlers if 
configured.
   
   As an example of configuration, this can be configured for the select 
handler via:
   ```
   <requestHandler name="/select" class="solr.SearchHandler">
       <!-- default values for query parameters can be specified, these
            will be overridden by parameters in the request
         -->
       <lst name="defaults">
           <str name="echoParams">explicit</str>
           <int name="rows">10</int>
       </lst>
   
       <bool name="aggregateNodeLevelMetricsEnabled">true</bool>
   </requestHandler>
   ```
   
   # Tests
   
   The main test developed is the RequestHandlerMetricsTests which tests that 
the proper metrics are provided based on configuration of request handlers.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [X ] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [X ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [X ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [X ] I have developed this patch against the `main` branch.
   - [ ] I have run `./gradlew check`.
   - [X ] I have added tests for my changes.
   - [ ] I have added documentation for the [Reference 
Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide)
   


-- 
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]

Reply via email to