blob: 60fa156d55ab8d7fac0382ebc14553bb747accbf (
plain) (
tree)
|
|
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"
# Arbitraty key-value pairs that further identify the environment where this service instance is running. Typically
# these tags will be used by the reporting modules as additional tags for all metrics or spans. Take a look at each
# reporter module's configuration to ensure these tags are supported and included in the reported data. Example:
#
# kamon.environment.tags {
# env = "staging"
# region = "us-east-1"
# }
tags {
}
}
# 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
# Declarative definition of broadcast context keys with type Option[String]. The setting key represents the actual
# key name and the value is the HTTP header name to be used to encode/decode the context key. The key name will
# be used when coding for binary transport. The most common use case for string keys is effortless propagation of
# correlation keys or request related data (locale, user ID, etc). E.g. if wanting to propagate a "X-Request-ID"
# header this config should suffice:
#
# kamon.context.codecs.string-keys {
# request-id = "X-Request-ID"
# }
#
# If the application must read this context key they can define key with a matching name and read the value from
# the context:
# val requestIDKey = Key.broadcastString("request-id") // Do this only once, keep a reference.
# val requestID = Kamon.currentContext().get(requestIDKey)
#
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 {
}
}
}
|