I am good with making changes for most of these recommendations and have a few
thoughts on some of them.
The solr_executor_ has an executor name attribute inside of it that should let
you know it was associated with a core.
For solr_searcher_cache_size vs solr_field_cache_size_bytes we could change the
suffix for number of entries to solr_searcher_cache_entries to differentiate
them better on the suffix.
On "aggregateNodeLevelMetricsEnabled" I think I made a suggestion somewhere to
just remove those base core attributes off the metric then the user could just
assume that the metric is an aggregation like so:
solr_core_requests_total{handler="/select",core="foo"} 5
solr_core_requests_total{handler="/select",core="bar"} 5
solr_core_requests_total{handler="/select"} 10 <- Node level aggregate
From: [email protected] At: 10/27/25 10:13:21 UTC-4:00To: [email protected]
Cc: Matthew Biscocho (BLOOMBERG/ 919 3RD A )
Subject: Some metric renames for Solr 10
I've been looking at metrics since the OTEL migration merge. I have some
recommendations for metric renames that I've gathered:
solr_field_cache_... -> solr_core_field_cache_... since the underlying
data is tied to cores, even though the metric info is aggregated. This
could be debatable if we want a strictness in registry prefix usage.
solr_executor_… -> solr_core_executor, at least for those associated to a
core.
solr_replication_… -> solr_core_replication
solr_searcher -> solr_core_indexsearcher_… use “index” word as we have an
indexwriter as well. BTW there is solr_core_searcher_new_total but other
searcher stuff doesn’t have “core” in there.
solr_indexwriter_… -> solr_core_indexwriter_…
solr_searcher_timer -> solr_indexsearcher_open or opentimer or opentime
since the word “timer” alone is rather meaningless as to what is being
timed.
solr_searcher_cache_ram_used_bytes ->
solr_indexsearcher_cache_size_bytes. Note
“solr_field_cache_size_bytes” is similar; plus there’s …index_bytes. However,
I recognize there’s a solr_searcher_cache_size that is the number of
entries. Still; the suffix differentiates.
It’d be more practical/friendly if our various “disk_space” metrics were
measured in OtelUnit.GIGABYTES not BYTES. Likewise if
solr_replication_index_size was measured in megabytes or maybe gigabytes. Same
for solr_core_index_size, solr_searcher_index_commit_size
Core to node aggregations (e.g. handler via
aggregateNodeLevelMetricsEnabled): Even though it's aggregated, perhaps it
should still be reported using a solr_core prefix since the information
still pertains to solr cores.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
