Compound metric name as variable


Is it possible to provide a metric name as a variable?

Here is an example of what I’m trying to do:

        "id" : "alertHIHIFunc35",
        "name" : "alertHIHIFunc35",
        "expression" : "TIMEFUNC > identity(HIHI)",
		    "variables" : [{ "name" : "HIHI"},{ "name" : "TIMEFUNC"}],
        "description" : "implements alert for HIHI, value for which is passed as parameter."

The variable HIHI passes into the expression successfully. The metric works when I replace TIMEFUNC with an actual metric name. However, when I try to use a variable for the metric name, the error I get is: java.lang.NoSuchMethodError:;Lc3/love/timeseries/LazyTimeseries;)Lc3/love/timeseries/LazyTimeseries;
	at Source)


As for the error, the metric engine will use the name to look for a metric (I believe first a CompoundMetric then a SimpleMetric) then if it could not find a match it will look for an ExpressionEngieFunction that match the given name. This is why you see a java.lang.NoSuchMethodError as it could not find such an expression function.

So I guess you will first need to define the target metric (i.e. provision) and than try to pass it’s name as value for your variable, though I’m not sure if this is supported.


@paulyip @bachr You cannot and should not pass metric names as variables. Variables are reserved for “data values” and metrics in C3 platform are “metadata”. In order to pass a mix of variables and use custom metrics, you can use evalMetricsWithMetadata and pass the metrics that are not defined / variable as metadata and the bindings can contain entries for variables that are data.

Let me know if that makes sense.


Thank you @rohit.sureka and @bachr for your quick replies.


In this context, I’d rather use “second class objects” for metrics (as they cannot be passed around as the first class objects), even though they are metadata because they contain attributes of (other) data (but the latter would not preclude their passing around).


@AlexBakic In C3 terminology, they’re truly “metadata” and should not be confused as general objects (data)


OK, I was commenting on the variable binding. It might rather be the third-class entity (in the PL terminology): Perhaps there are other kinds of C3 metadata which behave differently wrt being passed around in the code.