RFE: Possible to invoke operations to get metrics?

[seanliu-oss]

Hi there,

If I am reading current code correctly, it's just reading attributes from MBeans.
Some times, the server gives out metrics by calling operations, here's an example from SpringBoot:

$>bean org.springframework.boot:name=Metrics,type=Endpoint
> 
#bean is set to org.springframework.boot:name=Metrics,type=Endpoint
$>info
#mbean = org.springframework.boot:name=Metrics,type=Endpoint
#class name = org.springframework.boot.actuate.endpoint.jmx.EndpointMBean
#there is no attribute
# operations
  %0   - java.util.Map listNames()
  %1   - java.util.Map metric(java.lang.String requiredMetricName,java.util.List tag)
#there's no notifications
$>run listNames
#calling operation listNames of mbean org.springframework.boot:name=Metrics,type=Endpoint with params []
#operation returns: 
{ 
  names = ( application.ready.time, application.started.time, disk.free, disk.total, executor.active, executor.completed, executor.pool.core, executor.pool.max, executor.pool.size, executor.queue.remaining, executor.queued, hikaricp.connections, hikaricp.connections.acquire, hikaricp.connections.active, hikaricp.connections.creation, hikaricp.connections.idle, hikaricp.connections.max, hikaricp.connections.min, hikaricp.connections.pending, hikaricp.connections.timeout, hikaricp.connections.usage, jdbc.connections.max, jdbc.connections.min, jvm.buffer.count, jvm.buffer.memory.used, jvm.buffer.total.capacity, jvm.classes.loaded, jvm.classes.unloaded, jvm.gc.live.data.size, jvm.gc.max.data.size, jvm.gc.memory.allocated, jvm.gc.memory.promoted, jvm.gc.overhead, jvm.gc.pause, jvm.memory.committed, jvm.memory.max, jvm.memory.usage.after.gc, jvm.memory.used, jvm.threads.daemon, jvm.threads.live, jvm.threads.peak, jvm.threads.states, logback.events, mongodb.driver.pool.checkedout, mongodb.driver.pool.size, mongodb.driver.pool.waitqueuesize, process.cpu.usage, process.files.max, process.files.open, process.start.time, process.uptime, rabbitmq.acknowledged, rabbitmq.acknowledged_published, rabbitmq.channels, rabbitmq.connections, rabbitmq.consumed, rabbitmq.failed_to_publish, rabbitmq.not_acknowledged_published, rabbitmq.published, rabbitmq.rejected, rabbitmq.unrouted_published, system.cpu.count, system.cpu.usage, system.load.average.1m, tomcat.sessions.active.current, tomcat.sessions.active.max, tomcat.sessions.alive.max, tomcat.sessions.created, tomcat.sessions.expired, tomcat.sessions.rejected );
 }

$>run metric rabbitmq.published null
#calling operation metric of mbean org.springframework.boot:name=Metrics,type=Endpoint with params [rabbitmq.published, null]
#operation returns: 
{ 
  name = rabbitmq.published;
  description = null;
  baseUnit = null;
  measurements = ( { 
    statistic = COUNT;
    value = 0.0;
   } );
  availableTags = ( { 
    tag = name;
    values = ( rabbitMQProducer, rabbitMQConsumer );
   } );
 }

Can we added to the exporter the ability to invole the operations in this case, possibly definable by the yml file?
I understand I can use spring boot actuator prometheus endpoint to export the metrics, but the metric names are slightly different and may mess up existing grafana dashboards.

Thanks,
Sean

[dhoard]

@seanliu-oss This is an interesting concept, and I can see where it would be valuable. My concern is that MBean operations may not return single native values (int, long, etc.), but may return Objects required for other MBean calls.

Example:

public class Cache {

    public String getName();

    public long getTTL();

    public long getSize();
}

public interface CacheMBean { 
 
    public List<String> getIds();
   
    public Cache getCache(String id);
} 

In this example, an end-user wants to get the Cache name, TTL, and size. (The cache name should be a label.)

Programmatic flow (pseudo code)...

• lookup the MBean
• call cacheMBean.getIds()
• for each id, call cacheMBean.getCache(id)
  • for each Cache Object
    • call cache.getName()
    • call cache.getTTL()
    • call cache.getSize()

Defining such logic via YAML is difficult. The JMX Exporter would have to implement a reflection-based pseudo language.

[alexandrev-tibco]

I also like to have this approach, at least to support "basic data" returned operations or TabularData that could be easily transformed into metrics data