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
