Interface ActivityInstrumentation

All Known Implementing Classes:
ComponentActivityInstrumentation
public interface ActivityInstrumentation
All the accessors of the metrics that will be used for each activity instance. Implementors of this interface should ensure that the methods are synchronized to avoid race conditions during lazy init from callers.

  • Method Details

    • getOrCreateErrorsTotal

      NBMetricGauge getOrCreateErrorsTotal()

    • getOrCreateErrorRate1m

      NBMetricGauge getOrCreateErrorRate1m()

    • getOrCreateErrorRate5m

      NBMetricGauge getOrCreateErrorRate5m()

    • getOrCreateErrorRate15m

      NBMetricGauge getOrCreateErrorRate15m()

    • getOrCreateErrorRateTotal

      NBMetricGauge getOrCreateErrorRateTotal()

    • getOrCreateInputTimer

      com.codahale.metrics.Timer getOrCreateInputTimer()
      The input timer measures how long it takes to get the cycle value to be used for an operation.
      Returns:
      a new or existing Timer

    • getOrCreateStridesServiceTimer

      com.codahale.metrics.Timer getOrCreateStridesServiceTimer()
      The strides service timer measures how long it takes to complete a stride of work.
      Returns:
      a new or existing Timer

    • getStridesResponseTimerOrNull

      com.codahale.metrics.Timer getStridesResponseTimerOrNull()
      The strides response timer measures the total response time from the scheduled time a stride should start to when it completed. Stride scheduling is only defined when it is implied by a stride rate limiter, so this method should return null if there is no strides rate limiter.
      Returns:
      a new or existing Timer if appropriate, else null

    • getOrCreateCyclesServiceTimer

      com.codahale.metrics.Timer getOrCreateCyclesServiceTimer()
      The cycles service timer measures how long it takes to complete a cycle of work.
      Returns:
      a new or existing Timer

    • getCyclesResponseTimerOrNull

      com.codahale.metrics.Timer getCyclesResponseTimerOrNull()
      The cycles response timer measures the total response time from the scheduled time an operation should start to when it is completed. Cycle scheduling is only defined when it is implied by a cycle rate limiter, so this method should return null if there is no cycles rate limiter.
      Returns:
      a new or existing Timer if appropriate, else null

    • getOrCreatePendingOpCounter

      com.codahale.metrics.Counter getOrCreatePendingOpCounter()
      The pending ops counter keeps track of how many ops are submitted or in-flight, but which haven't been completed yet.
      Returns:
      a new or existing Counter

    • getOrCreateBindTimer

      com.codahale.metrics.Timer getOrCreateBindTimer()
      The bind timer keeps track of how long it takes for NoSQLBench to create an instance of an executable operation, given the cycle. This is usually done by using an OpSequence in conjunction with an OpDispenser. This is named for "binding a cycle to an operation".
      Returns:
      a new or existing Timer

    • getOrCreateExecuteTimer

      com.codahale.metrics.Timer getOrCreateExecuteTimer()
      The execute timer keeps track of how long it takes to submit an operation to be executed to an underlying native driver. For asynchronous APIs, such as those which return a Future, this is simply the amount of time it takes to acquire the future. When possible, APIs should be used via their async methods, even if you are implementing a SyncAction. This allows the execute timer to measure the hand-off to the underlying API, and the result timer to measure the blocking calls to aquire the result.
      Returns:
      a new or existing Timer

    • getOrCreateResultTimer

      com.codahale.metrics.Timer getOrCreateResultTimer()
      The result timer keeps track of how long it takes a native driver to service a request once submitted. This timer, in contrast to the result-success timer (getOrCreateResultSuccessTimer()), is used to track all operations. That is, no matter whether the operation succeeds or not, it should be tracked with this timer. The scope of this timer should cover each attempt at an operation through a native driver. Retries are not to be combined in this measurement.
      Returns:
      a new or existing Timer

    • getOrCreateResultSuccessTimer

      com.codahale.metrics.Timer getOrCreateResultSuccessTimer()
      The result-success timer keeps track of operations which had no exception. The measurements for this timer should be exactly the same values as used for the result timer (getOrCreateResultTimer(), except that attempts to complete an operation which yield an exception should be excluded from the results. These two metrics together provide a very high level sanity check against the error-specific metrics which can be reported by the error handler logic.
      Returns:
      a new or existing Timer

    • getOrCreateTriesHistogram

      com.codahale.metrics.Histogram getOrCreateTriesHistogram()
      The tries histogram tracks how many tries it takes to complete an operation successfully, or not. This histogram does not encode whether operations were successful or not. Ideally, if every attempt to complete an operation succeeds on its first try, the data in this histogram should all be 1. In practice, systems which are running near their capacity will see a few retried operations, and systems that are substantially over-driven will see many retried operations. As the retries value increases the further down the percentile scale you go, you can detect system loading patterns which are in excess of the real-time capability of the target system. This metric should be measured around every retry loop for a native operation.
      Returns:
      a new or existing Histogram

    • getOrCreateVerifierTimer

      com.codahale.metrics.Timer getOrCreateVerifierTimer()