Add the function f
as a gauge with the given name.
Add the function f
as a gauge with the given name.
The returned gauge value is only weakly referenced by the StatsReceiver, and if garbage collected will eventually cease to be a part of this measurement: thus, it needs to be retained by the caller. Or put another way, the measurement is only guaranteed to exist as long as there exists a strong reference to the returned gauge and typically should be stored in a member variable.
Measurements under the same name are added together.
provideGauge(String*)(=>Float) when there is not a good location to store the returned gauge that can give the desired lifecycle.
Just like addGauge(Verbosity,String*)(=>Float) but optimized for better Java experience.
Just like addGauge(Verbosity,String*)(=>Float) but optimized for better Java experience.
Just like addGauge(String*)(=>Float) but optimized for better Java experience.
Just like addGauge(String*)(=>Float) but optimized for better Java experience.
Add the function f
as a gauge with the given name.
Add the function f
as a gauge with the given name.
The returned gauge value is only weakly referenced by the StatsReceiver, and if garbage collected will eventually cease to be a part of this measurement: thus, it needs to be retained by the caller. Or put another way, the measurement is only guaranteed to exist as long as there exists a strong reference to the returned gauge and typically should be stored in a member variable.
Measurements under the same name are added together.
addGauge(Supplier[Float],Verbosity,String*) for a Java-friendly version.
provideGauge(String*)(=>Float) when there is not a good location to store the returned gauge that can give the desired lifecycle.
Add the function f
as a gauge with the given name.
Add the function f
as a gauge with the given name.
The returned gauge value is only weakly referenced by the StatsReceiver, and if garbage collected will eventually cease to be a part of this measurement: thus, it needs to be retained by the caller. Or put another way, the measurement is only guaranteed to exist as long as there exists a strong reference to the returned gauge and typically should be stored in a member variable.
Measurements under the same name are added together.
addGauge(Supplier[Float],String*) for a Java-friendly version.
provideGauge(String*)(=>Float) when there is not a good location to store the returned gauge that can give the desired lifecycle.
Get a counter with the given schema.
Get a counter with the given schema.
Get a counter with the given name
.
Get a counter with the given name
.
Get a counter with the given name
.
Get a counter with the given name
.
Accurately indicates if this is a NullStatsReceiver.
Accurately indicates if this is a NullStatsReceiver. Because equality is not forwarded via scala.Proxy, this is helpful to check for a NullStatsReceiver.
Get a metricBuilder for this StatsReceiver.
Get a metricBuilder for this StatsReceiver.
Just like provideGauge(String*)(=>Float) but optimized for better Java experience.
Just like provideGauge(String*)(=>Float) but optimized for better Java experience.
Register a function f
as a gauge with the given name that has
a lifecycle with no end.
Register a function f
as a gauge with the given name that has
a lifecycle with no end.
This measurement exists in perpetuity.
Measurements under the same name are added together.
provideGauge(Supplier[Float],String*) for a Java-friendly version.
addGauge(String*)(=>Float) if you can properly control the lifecycle of the returned gauge.
Specifies the representative receiver.
Specifies the representative receiver. This is in order to expose an object we can use for comparison so that global stats are only reported once per receiver.
Prepend namespace
and namespaces
to the names of the returned StatsReceiver.
Prepend namespace
and namespaces
to the names of the returned StatsReceiver.
For example:
statsReceiver.scope("client", "backend", "pool").counter("adds")
will generate a counter named /client/backend/pool/adds
.
Note it's recommended to be mindful with usage of the scope
method as it's almost always
more efficient to pass a full metric name directly to a constructing method.
Put this way, whenever possible prefer
statsReceiver.counter("client", "backend", "pool", "adds")
to
statsReceiver.scope("client", "backend", "pool").counter("adds")
Prepend namespace
to the names of the returned StatsReceiver.
Prepend namespace
to the names of the returned StatsReceiver.
For example:
statsReceiver.scope("client").counter("adds") statsReceiver.scope("client").scope("backend").counter("adds")
will generate counters named /client/adds
and /client/backend/adds
.
Note it's recommended to be mindful with usage of the scope
method as it's almost always
more efficient to pass a full metric name directly to a constructing method.
Put this way, whenever possible prefer
statsReceiver.counter("client", "adds")
to
statsReceiver.scope("client").counter("adds")
Prepend a suffix value to the next scope.
Prepend a suffix value to the next scope.
For example:
statsReceiver.scopeSuffix("toto").scope("client").counter("adds")
will generate a counter named /client/toto/adds
.
Get a stat with the given schema.
Get a stat with the given schema.
Get a stat with the given name.
Get a stat with the given name.
Get a stat with the given name.
Get a stat with the given name.
The underlying StatsReceivers that the class delegates to.
The underlying StatsReceivers that the class delegates to.
Must be nonempty.
Wraps an underlying StatsReceiver to ensure that derived counters and stats will not start exporting metrics until
incr
oradd
is first called on them.This should be used when integrating with tools that create metrics eagerly, but you don't know whether you're going to actually use those metrics or not. One example might be if you're speaking to a remote peer that exposes many endpoints, and you eagerly create metrics for all of those endpoints, but aren't going to use all of the different methods.
We don't apply this very widely automatically--it can mess with caching, and adds an extra allocation when you construct a new counter or stat, so please be judicious when using it.
does not change the way gauges are used, since there isn't a way of modeling whether a gauge is "used" or not.