diff options
Diffstat (limited to 'kamon-core/src/main/resources/reference.conf')
| -rw-r--r-- | kamon-core/src/main/resources/reference.conf | 227 |
1 files changed, 196 insertions, 31 deletions
diff --git a/kamon-core/src/main/resources/reference.conf b/kamon-core/src/main/resources/reference.conf index 60fa156d..a35225d4 100644 --- a/kamon-core/src/main/resources/reference.conf +++ b/kamon-core/src/main/resources/reference.conf @@ -150,45 +150,210 @@ kamon { } } + propagation { - context { + http { - # 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: + # Default HTTP propagation. Unless specified otherwise, all instrumentation will use the configuration on + # this section for HTTP context propagation. # - # 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 { + default { + + # Configures how context tags will be propagated over HTTP headers. + # + tags { + + # Header name used to encode context tags. + header-name = "context-tags" + + + # Provide explicit mappins between context tags and the HTTP headers that will carry them. When there is + # an explicit mapping for a tag, it will not be included in the default context header. For example, if + # you wanted to use the an HTTP header called `X-Correlation-ID` for a context tag with key `correlationID` + # you would need to include a the following configuration: + # + # mappings { + # correlationID = "X-Correlation-ID" + # } + # + # The correlationID tag would always be read and written from the `X-Correlation-ID` header. The context + # tag name is represented as the configuration key and the desired header name is represented by the + # cofiguration value. + # + mappings { + + } + } + # Configure which entries should be read from incoming HTTP requests and writen to outgoing HTTP requests. + # + entries { + + # Specify mappings between Context keys and the Propagation.EntryReader[HeaderReader] implementation in charge + # of reading them from the incoming HTTP request into the Context. + incoming { + span = "kamon.trace.SpanPropagation$B3" + } + + # Specify mappings betwen Context keys and the Propagation.EntryWriter[HeaderWriter] implementation in charge + # of writing them to outgoing HTTP requests. + outgoing { + span = "kamon.trace.SpanPropagation$B3" + } + } } + } + + binary { - # Codecs to be used when propagating a Context through a HTTP Headers transport. - http-headers-keys { - span = "kamon.trace.SpanCodec$B3" + # Default HTTP propagation. Unless specified otherwise, all instrumentation will use the configuration on + # this section for HTTP context propagation. + # + default { + + # Maximum outgoing Context size for binary transports. Contexts that surpass this limit will not be written to + # the outgoing medium. + max-outgoing-size = 2048 + + # Configure which entries should be read from incoming messages and writen to outgoing messages. + # + entries { + + # Specify mappings between Context keys and the Propagation.EntryReader[ByteStreamReader] implementation in + # charge of reading them from the incoming messages into the Context. + incoming { + span = "kamon.trace.SpanPropagation$Colfer" + } + + # Specify mappings betwen Context keys and the Propagation.EntryWriter[ByteStreamWriter] implementation in + # charge of writing them on the outgoing messages. + outgoing { + span = "kamon.trace.SpanPropagation$Colfer" + } + } } + } + } + + instrumentation { + http-server { + default { + + # + # Configuration for HTTP context propagation. + # + propagation { + + # Enables or disables HTTP context propagation on this HTTP server instrumentation. Please note that if + # propagation is disabled then some distributed tracing features will not be work as expected (e.g. Spans can + # be created and reported but will not be linked across boundaries nor take trace identifiers from tags). + enabled = yes + + # HTTP propagation channel to b used by this instrumentation. Take a look at the kamon.propagation.http.default + # configuration for more details on how to configure the detault HTTP context propagation. + channel = "default" + } - # Codecs to be used when propagating a Context through a Binary transport. - binary-keys { - span = "kamon.trace.SpanCodec$Colfer" + + # + # Configuration for HTTP server metrics collection. + # + metrics { + + # Enables collection of HTTP server metrics. When enabled the following metrics will be collected, assuming + # that the instrumentation is fully compliant: + # + # - http.server.requets + # - http.server.request.active + # - http.server.request.size + # - http.server.response.size + # - http.server.connection.lifetime + # - http.server.connection.usage + # - http.server.connection.open + # + # All metrics have at least three tags: component, interface and port. Additionally, the http.server.requests + # metric will also have a status_code tag with the status code group (1xx, 2xx and so on). + # + enabled = yes + } + + + # + # Configuration for HTTP request tracing. + # + tracing { + + # Enables HTTP request tracing. When enabled the instrumentation will create Spans for incoming requests + # and finish them when the response is sent back to the clients. + enabled = yes + + # Select a context tag that provides a preferred trace identifier. The preferred trace identifier will be used + # only if all these conditions are met: + # - the context tag is present. + # - there is no parent Span on the incoming context (i.e. this is the first service on the trace). + # - the identifier is valid in accordance to the identity provider. + preferred-trace-id-tag = "none" + + # Enables collection of span metrics using the `span.processing-time` metric. + span-metrics = on + + # Select which tags should be included as span and span metric tags. The possible options are: + # - span: the tag is added as a Span tag (i.e. using span.tag(...)) + # - metric: the tag is added a a Span metric tag (i.e. using span.tagMetric(...)) + # - off: the tag is not used. + # + tags { + + # Use the http.url tag. + url = span + + # Use the http.method tag. + method = metric + + # Use the http.status_code tag. + status-code = metric + + # Copy tags from the context into the Spans with the specified purpouse. For example, to copy a customer_type + # tag from the context into the HTTP Server Span created by the instrumentation, the following configuration + # should be added: + # + # from-context { + # customer_type = span + # } + # + from-context { + + } + } + + # Custom mappings between routes and operation names. + operations { + + # Operation name for Spans created on requests that could not be handled by any route in the current + # application. + unhandled = "unhandled" + + # Provides custom mappings from HTTP paths into operation names. Meant to be used in cases where the bytecode + # instrumentation is not able to provide a sensible operation name that is free of high cardinality values. + # For example, with the following configuration: + # mappings { + # "/organization/*/user/*/profile" = "/organization/:orgID/user/:userID/profile" + # "/events/*/rsvps" = "EventRSVPs" + # } + # + # Requests to "/organization/3651/user/39652/profile" and "/organization/22234/user/54543/profile" will have + # the same operation name "/organization/:orgID/user/:userID/profile". + # + # Similarly, requests to "/events/aaa-bb-ccc/rsvps" and "/events/1234/rsvps" will have the same operation + # name "EventRSVPs". + # + # The patterns are expressed as globs and the operation names are free form. + # + mappings { + + } + } + } } } } |