path: root/kamon-core/src/main/resources/reference.conf

kamon {

  environment {

    # Identifier for this service.
    service = "kamon-application"

    # Identifier for the host where this service is running. If set to `auto` Kamon will resolve the hostname using
    # the resolved name for localhost.
    host = "auto"

    # Identifier for a particular instance of this service. If set to `auto` Kamon will use the pattern service@host.
    instance = "auto"
  }

  # FQCN of the reporter instances that should be loaded when calling `Kamon.reporters.loadReportersFromConfig()`. All
  # reporter classes must have a default constructor. No metric filtering is applied to metric reporters started this way.

  # Example: `reporters = ["kamon.prometheus.PrometheusReporter", "kamon.zipkin.ZipkinReporter"]`.
  reporters = [ ]

  # Pool size for the executor service that will run sampling on RangeSampler instruments. This scheduler is accesible
  # through Kamon.scheduler()
  scheduler-pool-size = 2


  metric {

    # Interval at which metric snapshots will be collected and sent to all metric reporters.
    tick-interval = 60 seconds

    # When optimistic tick alignment is enabled the metrics ticker will try to schedule the ticks to happen as close as
    # possible to round tick-interval units. E.g. if the tick-interval is set to 60 seconds then Kamon will try to
    # schedule the ticks at the beginning of each minute; if the tick-interval is set to 20 seconds then Kamon will try
    # to schedule the ticks at 0, 20, and 40 seconds of each minute. The alignment is not meant to be perfect, just to
    # improve the ability to correlate the timestamp reported in ticks with logs.
    optimistic-tick-alignment = yes

    # Thread pool size used by the metrics refresh scheduler. This pool is only used to periodically sampling
    # range-sampler values.
    refresh-scheduler-pool-size = 2

    instrument-factory {

      # Default instrument settings for histograms and min max counters. The actual settings to be used when creating
      # instruments is determined by merging the default settings, code settings and custom-settings using the following
      # priorities (top wins):
      #
      #   - any setting in the `custom-settings` section for the given category/instrument.
      #   - code settings provided when creating the instrument.
      #   - `default-settings` bellow.
      #
      default-settings {
        histogram {
          lowest-discernible-value = 1
          highest-trackable-value = 3600000000000
          significant-value-digits = 2
        }

        range-sampler {
          lowest-discernible-value = 1
          highest-trackable-value = 3600000000000
          significant-value-digits = 2
          sample-interval = 200 ms
        }
      }

      # Custom settings for instruments of a given metric. The settings provided in this section override the default
      # and manually provided settings when creating metrics. All settings are optional in this section and default
      # values from the `kamon.metric.instrument-factory.default-settings` will be used in case of any setting being
      # missing.
      #
      # Example:
      # If you wish to change the highest trackable value setting of the `span.elapsed-time` metric, you should include
      # the following configuration in your application.conf file:
      #
      #   kamon.metric.instrument-factory.custom-settings {
      #     "span.elapsed-time" {
      #       highest-trackable-value = 5000
      #     }
      #   }
      #
      custom-settings {

      }
    }
  }


  trace {

    # Interval at which sampled finished spans will be flushed to SpanReporters.
    tick-interval = 10 seconds

    # Size of the internal queue where sampled spans will stay until they get flushed. If the queue becomes full then
    # sampled finished spans will be dropped in order to avoid consuming excessive amounts of memory. Each configured
    # reporter has a separate queue.
    reporter-queue-size = 4096


    # Decide whether a new, locally created Span should have the same Span Identifier as it's remote parent (if any) or
    # get a new local identifier. Certain tracing systems use the same Span Identifier to represent both sides (client
    # and server) of a RPC call, if you are reporting data to such systems then this option should be enabled.
    #
    # If you are using Zipkin, keep this option enabled. If you are using Jaeger, disable it.
    join-remote-parents-with-same-span-id = no

    # Configures a sample that decides which traces should be reported to the trace backends. The possible values are:
    #   - always: report all traces.
    #   - never:  don't report any trace.
    #   - random: randomly decide using the probability defined in the random-sampler.probability setting.
    #
    sampler = "random"

    # The random sampler uses the "chance" setting and a random number to take a decision, if the random number is
    # on the upper (chance * 100) percent of the number spectrum the trace will be sampled. E.g. a chance of 0.01 will
    # hint that 1% of all traces should be reported.
    random-sampler {

      # Probability of a span being sampled. Must be a value between 0 and 1.
      probability = 0.01
    }

    # The IdentityProvider used to generate Trace and Span Identifiers in Kamon. There are two default implementations
    # that ship with Kamon:
    #   - kamon.trace.IdentityProvider$Default: Creates 8-byte identifiers for both Traces and Spans.
    #   - kamon.trace.IdentityProvider$DoubleSizeTraceID: Creates 16-byte identifiers for Traces and 8-byte identifiers
    #     for Spans.
    #
    # Any external implementation can be configured here, as long as it can be instantiated with a parameterless constructor.
    identity-provider = "kamon.trace.IdentityProvider$Default"

    span-metrics {

      # When this option is enabled the metrics collected for Spans will automatically add a tag named "parentOperation"
      # with the name of the operation on the parent Span, if any.
      scope-spans-to-parent = yes
    }
  }


  context {

    # Codecs are used to encode/decode Context keys when a Context must be propagated either through HTTP headers or
    # Binary transports. Only broadcast keys configured bellow will be processed by the context Codec. The FQCN of
    # the appropriate Codecs for each key must be provided, otherwise keys will be ignored.
    #
    codecs {

      # Size of the encoding buffer for the Binary Codec.
      binary-buffer-size = 256

      string-keys = [ ]

      # Codecs to be used when propagating a Context through a HTTP Headers transport.
      http-headers-keys {
        span = "kamon.trace.SpanCodec$B3"
      }

      # Codecs to be used when propagating a Context through a Binary transport.
      binary-keys {
        span = "kamon.trace.SpanCodec$Colfer"
      }
    }
  }


  util {
    filters {

      # Determines whether entities from a category that doesn't have any filtering configuration should be tracked or
      # not. E.g. If there are no filter sections for the "jdbc-datasource" category and `accept-unmatched-categories`
      # is set to true, all entities for that category will be accepted, otherwise all will be rejected.
      #
      # NOTE: Using entity fil`ters is a commodity for modules that might potentially track thousands of unnecessary
      #       entities, but not all modules are required to use filters, check the your module's documentation to
      #       determine whether setting up filters make sense or not.
      accept-unmatched = true

    }
  }
}