1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
|
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
# 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 {
# 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
}
}
}
|
