One way to do this w/ the existing code is by subclassing an existing MeterRegistryFactory

package mypackage;

import io.micrometer.core.instrument.MeterRegistry;
import io.micrometer.core.instrument.config.MeterFilter;
import org.apache.accumulo.core.spi.metrics.LoggingMeterRegistryFactory;

public class FilteringLoggingMRFactory extends LoggingMeterRegistryFactory {
    @Override
    public MeterRegistry create(final InitParameters params) {
       var meterRegistry = super.create(params);
        MeterFilter myFilter = MeterFilter.denyNameStartsWith("accumulo.gc");
        meterRegistry.config().meterFilter(myFilter);
        return meterRegistry;
    }
}

So, that's a fair point. We don't necessarily have to implement something to provide some base functionality. A user can extend one of our existing implementations or create their own to provide this functionality.

We don't necessarily have to implement something to provide some base functionality. A user can extend one of our existing implementations or create their own to provide this functionality.

Wondering if it would be useful to provide some kind of help in the SPI for building micrometer filters related to Accumulo metrics. One possible way to do this would be to have constants related to metrics in the SPI. This could enable writing a MeterRegistryFactory that manipulates Accumulo metrics using those constants. Could have something like the following.

package org.apache.accumulo.core.spi.metrics;

class MetricsConstants {

   static class Tags {
           String INSTANCE_TAG = "instance.name";
  }

  static class Meters {
           String COMPACTIONS_QUEUED = "...";
  }
}

With the above then could have a scenario like the following.

• Custom MeterRegistryFactory is written against 3.1 that drops the instance name tag. Its impl uses the INSTANCE_TAG constant from the SPI.
• Accumulo 4.0 makes a major changes to the instance name tag that user need to consider. This change deletes INSTANCE_TAG constant from the SPI.
• The custom MeterRegistryFactory written against 3.1 no longer compiles against 4.0 forcing an investigation of the change.

Completely unrelated to metrics, but if this approach of putting metrics related constants in the SPI works then it could also potentially work for Accumulo's properties. Could have constants related to those in the SPI maybe.

I can take a look at this