From 74e0937250ff6d20379d8d7fda09d4becc234f47 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Wed, 15 Apr 2020 05:14:31 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- reference/html/README.html | 187 -------- reference/html/features.html | 193 +-------- reference/html/index.html | 538 +++++++++++------------- reference/html/spring-cloud-sleuth.html | 538 +++++++++++------------- 4 files changed, 509 insertions(+), 947 deletions(-) diff --git a/reference/html/README.html b/reference/html/README.html index 8da47dc71..3998a2f39 100644 --- a/reference/html/README.html +++ b/reference/html/README.html @@ -357,193 +357,6 @@ frontend.log:2020-04-09 17:45:40.574 ERROR [frontend,5e8eeec48b08e26882aba313eb0

Above, you’ll notice the trace ID is 5e8eeec48b08e26882aba313eb08f0a4, for example. This log configuration was automatically setup by Sleuth.

-
-

If you use a log aggregating tool (such as Kibana, Splunk, and others), you can order the events that took place. -An example from Kibana would resemble the following image:

-
-
-
-Log correlation with Kibana -
-
-
-

If you want to use Logstash, the following listing shows the Grok pattern for Logstash:

-
-
-
-
filter {
-  # pattern matching logback pattern
-  grok {
-    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
-  }
-  date {
-    match => ["timestamp", "ISO8601"]
-  }
-  mutate {
-    remove_field => ["timestamp"]
-  }
-}
-
-
-
- - - - - -
- - -If you want to use Grok together with the logs from Cloud Foundry, you have to use the following pattern: -
-
-
-
-
filter {
-  # pattern matching logback pattern
-  grok {
-    match => { "message" => "(?m)OUT\s+%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
-  }
-  date {
-    match => ["timestamp", "ISO8601"]
-  }
-  mutate {
-    remove_field => ["timestamp"]
-  }
-}
-
-
-
-

1.2.1. JSON Logback with Logstash

-
-

Often, you do not want to store your logs in a text file but in a JSON file that Logstash can immediately pick. -To do so, you have to do the following (for readability, we pass the dependencies in the groupId:artifactId:version notation).

-
-
-

Dependencies Setup

-
-
-
    -
  1. -

    Ensure that Logback is on the classpath (ch.qos.logback:logback-core).

    -
  2. -
  3. -

    Add Logstash Logback encode. For example, to use version 4.6, add net.logstash.logback:logstash-logback-encoder:4.6.

    -
  4. -
-
-
-

Logback Setup

-
-
-

Consider the following example of a Logback configuration file (logback-spring.xml).

-
-
-
-
<?xml version="1.0" encoding="UTF-8"?>
-<configuration>
-    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
-    <springProperty scope="context" name="springAppName" source="spring.application.name"/>
-    <!-- Example for logging into the build folder of your project -->
-    <property name="LOG_FILE" value="${BUILD_FOLDER:-build}/${springAppName}"/>
-
-    <!-- You can override this to have a custom pattern -->
-    <property name="CONSOLE_LOG_PATTERN"
-              value="%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>
-
-    <!-- Appender to log to console -->
-    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
-        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
-            <!-- Minimum logging level to be presented in the console logs-->
-            <level>DEBUG</level>
-        </filter>
-        <encoder>
-            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
-            <charset>utf8</charset>
-        </encoder>
-    </appender>
-
-    <!-- Appender to log to file -->
-    <appender name="flatfile" class="ch.qos.logback.core.rolling.RollingFileAppender">
-        <file>${LOG_FILE}</file>
-        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
-            <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.gz</fileNamePattern>
-            <maxHistory>7</maxHistory>
-        </rollingPolicy>
-        <encoder>
-            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
-            <charset>utf8</charset>
-        </encoder>
-    </appender>
-    <!-- Appender to log to file in a JSON format -->
-    <appender name="logstash" class="ch.qos.logback.core.rolling.RollingFileAppender">
-        <file>${LOG_FILE}.json</file>
-        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
-            <fileNamePattern>${LOG_FILE}.json.%d{yyyy-MM-dd}.gz</fileNamePattern>
-            <maxHistory>7</maxHistory>
-        </rollingPolicy>
-        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
-            <providers>
-                <timestamp>
-                    <timeZone>UTC</timeZone>
-                </timestamp>
-                <pattern>
-                    <pattern>
-                        {
-                        "timestamp": "@timestamp",
-                        "severity": "%level",
-                        "service": "${springAppName:-}",
-                        "trace": "%X{traceId:-}",
-                        "span": "%X{spanId:-}",
-                        "pid": "${PID:-}",
-                        "thread": "%thread",
-                        "class": "%logger{40}",
-                        "rest": "%message"
-                        }
-                    </pattern>
-                </pattern>
-            </providers>
-        </encoder>
-    </appender>
-    <root level="INFO">
-        <appender-ref ref="console"/>
-        <!-- uncomment this to have also JSON logs -->
-        <!--<appender-ref ref="logstash"/>-->
-        <!--<appender-ref ref="flatfile"/>-->
-    </root>
-</configuration>
-
-
-
-

That Logback configuration file:

-
-
-
    -
  • -

    Logs information from the application in a JSON format to a build/${spring.application.name}.json file.

    -
  • -
  • -

    Has commented out two additional appenders: console and standard log file.

    -
  • -
  • -

    Has the same logging pattern as the one presented in the previous section.

    -
  • -
-
-
- - - - - -
- - -If you use a custom logback-spring.xml, you must pass the spring.application.name in the bootstrap rather than the application property file. -Otherwise, your custom logback file does not properly read the property. -
-
-

1.3. Service Dependency Graph

diff --git a/reference/html/features.html b/reference/html/features.html index 9699fae15..0485bef0f 100644 --- a/reference/html/features.html +++ b/reference/html/features.html @@ -117,11 +117,7 @@ $(globalSwitch);
  • 1. Features
  • -
    -

    If you use a log aggregating tool (such as Kibana, Splunk, and others), you can order the events that took place. -An example from Kibana would resemble the following image:

    -
    -
    -
    -Log correlation with Kibana -
    -
    -
    -

    If you want to use Logstash, the following listing shows the Grok pattern for Logstash:

    -
    -
    -
    -
    filter {
    -  # pattern matching logback pattern
    -  grok {
    -    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
    -  }
    -  date {
    -    match => ["timestamp", "ISO8601"]
    -  }
    -  mutate {
    -    remove_field => ["timestamp"]
    -  }
    -}
    -
    -
    -
    - - - - - -
    - - -If you want to use Grok together with the logs from Cloud Foundry, you have to use the following pattern: -
    -
    -
    -
    -
    filter {
    -  # pattern matching logback pattern
    -  grok {
    -    match => { "message" => "(?m)OUT\s+%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
    -  }
    -  date {
    -    match => ["timestamp", "ISO8601"]
    -  }
    -  mutate {
    -    remove_field => ["timestamp"]
    -  }
    -}
    -
    -
    -
    -

    1.2.1. JSON Logback with Logstash

    -
    -

    Often, you do not want to store your logs in a text file but in a JSON file that Logstash can immediately pick. -To do so, you have to do the following (for readability, we pass the dependencies in the groupId:artifactId:version notation).

    -
    -
    -

    Dependencies Setup

    -
    -
    -
      -
    1. -

      Ensure that Logback is on the classpath (ch.qos.logback:logback-core).

      -
    2. -
    3. -

      Add Logstash Logback encode. For example, to use version 4.6, add net.logstash.logback:logstash-logback-encoder:4.6.

      -
    4. -
    -
    -
    -

    Logback Setup

    -
    -
    -

    Consider the following example of a Logback configuration file (logback-spring.xml).

    -
    -
    -
    -
    <?xml version="1.0" encoding="UTF-8"?>
    -<configuration>
    -    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
    -    <springProperty scope="context" name="springAppName" source="spring.application.name"/>
    -    <!-- Example for logging into the build folder of your project -->
    -    <property name="LOG_FILE" value="${BUILD_FOLDER:-build}/${springAppName}"/>
    -
    -    <!-- You can override this to have a custom pattern -->
    -    <property name="CONSOLE_LOG_PATTERN"
    -              value="%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>
    -
    -    <!-- Appender to log to console -->
    -    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
    -        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
    -            <!-- Minimum logging level to be presented in the console logs-->
    -            <level>DEBUG</level>
    -        </filter>
    -        <encoder>
    -            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
    -            <charset>utf8</charset>
    -        </encoder>
    -    </appender>
    -
    -    <!-- Appender to log to file -->
    -    <appender name="flatfile" class="ch.qos.logback.core.rolling.RollingFileAppender">
    -        <file>${LOG_FILE}</file>
    -        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    -            <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.gz</fileNamePattern>
    -            <maxHistory>7</maxHistory>
    -        </rollingPolicy>
    -        <encoder>
    -            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
    -            <charset>utf8</charset>
    -        </encoder>
    -    </appender>
    -    <!-- Appender to log to file in a JSON format -->
    -    <appender name="logstash" class="ch.qos.logback.core.rolling.RollingFileAppender">
    -        <file>${LOG_FILE}.json</file>
    -        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    -            <fileNamePattern>${LOG_FILE}.json.%d{yyyy-MM-dd}.gz</fileNamePattern>
    -            <maxHistory>7</maxHistory>
    -        </rollingPolicy>
    -        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
    -            <providers>
    -                <timestamp>
    -                    <timeZone>UTC</timeZone>
    -                </timestamp>
    -                <pattern>
    -                    <pattern>
    -                        {
    -                        "timestamp": "@timestamp",
    -                        "severity": "%level",
    -                        "service": "${springAppName:-}",
    -                        "trace": "%X{traceId:-}",
    -                        "span": "%X{spanId:-}",
    -                        "pid": "${PID:-}",
    -                        "thread": "%thread",
    -                        "class": "%logger{40}",
    -                        "rest": "%message"
    -                        }
    -                    </pattern>
    -                </pattern>
    -            </providers>
    -        </encoder>
    -    </appender>
    -    <root level="INFO">
    -        <appender-ref ref="console"/>
    -        <!-- uncomment this to have also JSON logs -->
    -        <!--<appender-ref ref="logstash"/>-->
    -        <!--<appender-ref ref="flatfile"/>-->
    -    </root>
    -</configuration>
    -
    -
    -
    -

    That Logback configuration file:

    -
    -
    -
      -
    • -

      Logs information from the application in a JSON format to a build/${spring.application.name}.json file.

      -
    • -
    • -

      Has commented out two additional appenders: console and standard log file.

      -
    • -
    • -

      Has the same logging pattern as the one presented in the previous section.

      -
    • -
    -
    -
    - - - - - -
    - - -If you use a custom logback-spring.xml, you must pass the spring.application.name in the bootstrap rather than the application property file. -Otherwise, your custom logback file does not properly read the property. -
    -
    -

    1.3. Service Dependency Graph

    diff --git a/reference/html/index.html b/reference/html/index.html index 7811e984c..21461d8cf 100644 --- a/reference/html/index.html +++ b/reference/html/index.html @@ -181,26 +181,29 @@ $(globalSwitch);
  • 12. Sending Spans to Zipkin
  • -
  • 13. Zipkin Stream Span Consumer
  • -
  • 14. Integrations +
  • 13. Integrations +
  • +
  • 14. Log integration +
  • 15. Configuration properties
  • -
  • 16. Running examples
  • @@ -323,193 +326,6 @@ frontend.log:2020-04-09 17:45:40.574 ERROR [frontend,5e8eeec48b08e26882aba313eb0

    Above, you’ll notice the trace ID is 5e8eeec48b08e26882aba313eb08f0a4, for example. This log configuration was automatically setup by Sleuth.

    -
    -

    If you use a log aggregating tool (such as Kibana, Splunk, and others), you can order the events that took place. -An example from Kibana would resemble the following image:

    -
    -
    -
    -Log correlation with Kibana -
    -
    -
    -

    If you want to use Logstash, the following listing shows the Grok pattern for Logstash:

    -
    -
    -
    -
    filter {
    -  # pattern matching logback pattern
    -  grok {
    -    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
    -  }
    -  date {
    -    match => ["timestamp", "ISO8601"]
    -  }
    -  mutate {
    -    remove_field => ["timestamp"]
    -  }
    -}
    -
    -
    -
    - - - - - -
    - - -If you want to use Grok together with the logs from Cloud Foundry, you have to use the following pattern: -
    -
    -
    -
    -
    filter {
    -  # pattern matching logback pattern
    -  grok {
    -    match => { "message" => "(?m)OUT\s+%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
    -  }
    -  date {
    -    match => ["timestamp", "ISO8601"]
    -  }
    -  mutate {
    -    remove_field => ["timestamp"]
    -  }
    -}
    -
    -
    -
    -

    2.2.1. JSON Logback with Logstash

    -
    -

    Often, you do not want to store your logs in a text file but in a JSON file that Logstash can immediately pick. -To do so, you have to do the following (for readability, we pass the dependencies in the groupId:artifactId:version notation).

    -
    -
    -

    Dependencies Setup

    -
    -
    -
      -
    1. -

      Ensure that Logback is on the classpath (ch.qos.logback:logback-core).

      -
    2. -
    3. -

      Add Logstash Logback encode. For example, to use version 4.6, add net.logstash.logback:logstash-logback-encoder:4.6.

      -
    4. -
    -
    -
    -

    Logback Setup

    -
    -
    -

    Consider the following example of a Logback configuration file (logback-spring.xml).

    -
    -
    -
    -
    <?xml version="1.0" encoding="UTF-8"?>
    -<configuration>
    -    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
    -    <springProperty scope="context" name="springAppName" source="spring.application.name"/>
    -    <!-- Example for logging into the build folder of your project -->
    -    <property name="LOG_FILE" value="${BUILD_FOLDER:-build}/${springAppName}"/>
    -
    -    <!-- You can override this to have a custom pattern -->
    -    <property name="CONSOLE_LOG_PATTERN"
    -              value="%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>
    -
    -    <!-- Appender to log to console -->
    -    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
    -        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
    -            <!-- Minimum logging level to be presented in the console logs-->
    -            <level>DEBUG</level>
    -        </filter>
    -        <encoder>
    -            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
    -            <charset>utf8</charset>
    -        </encoder>
    -    </appender>
    -
    -    <!-- Appender to log to file -->
    -    <appender name="flatfile" class="ch.qos.logback.core.rolling.RollingFileAppender">
    -        <file>${LOG_FILE}</file>
    -        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    -            <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.gz</fileNamePattern>
    -            <maxHistory>7</maxHistory>
    -        </rollingPolicy>
    -        <encoder>
    -            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
    -            <charset>utf8</charset>
    -        </encoder>
    -    </appender>
    -    <!-- Appender to log to file in a JSON format -->
    -    <appender name="logstash" class="ch.qos.logback.core.rolling.RollingFileAppender">
    -        <file>${LOG_FILE}.json</file>
    -        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    -            <fileNamePattern>${LOG_FILE}.json.%d{yyyy-MM-dd}.gz</fileNamePattern>
    -            <maxHistory>7</maxHistory>
    -        </rollingPolicy>
    -        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
    -            <providers>
    -                <timestamp>
    -                    <timeZone>UTC</timeZone>
    -                </timestamp>
    -                <pattern>
    -                    <pattern>
    -                        {
    -                        "timestamp": "@timestamp",
    -                        "severity": "%level",
    -                        "service": "${springAppName:-}",
    -                        "trace": "%X{traceId:-}",
    -                        "span": "%X{spanId:-}",
    -                        "pid": "${PID:-}",
    -                        "thread": "%thread",
    -                        "class": "%logger{40}",
    -                        "rest": "%message"
    -                        }
    -                    </pattern>
    -                </pattern>
    -            </providers>
    -        </encoder>
    -    </appender>
    -    <root level="INFO">
    -        <appender-ref ref="console"/>
    -        <!-- uncomment this to have also JSON logs -->
    -        <!--<appender-ref ref="logstash"/>-->
    -        <!--<appender-ref ref="flatfile"/>-->
    -    </root>
    -</configuration>
    -
    -
    -
    -

    That Logback configuration file:

    -
    -
    -
      -
    • -

      Logs information from the application in a JSON format to a build/${spring.application.name}.json file.

      -
    • -
    • -

      Has commented out two additional appenders: console and standard log file.

      -
    • -
    • -

      Has the same logging pattern as the one presented in the previous section.

      -
    • -
    -
    -
    - - - - - -
    - - -If you use a custom logback-spring.xml, you must pass the spring.application.name in the bootstrap rather than the application property file. -Otherwise, your custom logback file does not properly read the property. -
    -
    -

    2.3. Service Dependency Graph

    @@ -2011,32 +1827,10 @@ object, you will have to create a bean of zipkin2.reporter.Sender t
    -

    13. Zipkin Stream Span Consumer

    -
    -
    - - - - - -
    - - -We recommend using Zipkin’s native support for message-based span sending. -Starting from the Edgware release, the Zipkin Stream server is deprecated. -In the Finchley release, it got removed. -
    -
    -
    -

    If for some reason you need to create the deprecated Stream Zipkin server, see the Dalston Documentation.

    -
    -
    -
    -
    -

    14. Integrations

    +

    13. Integrations

    -

    14.1. OpenTracing

    +

    13.1. OpenTracing

    Spring Cloud Sleuth is compatible with OpenTracing. If you have OpenTracing on the classpath, we automatically register the OpenTracing Tracer bean. @@ -2044,7 +1838,7 @@ If you wish to disable this, set spring.sleuth.opentracing.enabled

    -

    14.2. Runnable and Callable

    +

    13.2. Runnable and Callable

    If you wrap your logic in Runnable or Callable, you can wrap those classes in their Sleuth representative, as shown in the following example for Runnable:

    @@ -2100,13 +1894,13 @@ Callable<String> traceCallableFromTracer = this.tracing.currentTraceContex
    -

    14.3. Spring Cloud CircuitBreaker

    +

    13.3. Spring Cloud CircuitBreaker

    If you have Spring Cloud CircuitBreaker on the classpath, we will wrap the passed command Supplier and the fallback Function in its trace representations. In order to disable this instrumentation set spring.sleuth.circuitbreaker.enabled to false.

    -

    14.4. RxJava

    +

    13.4. RxJava

    We registering a custom RxJavaSchedulersHook that wraps all Action0 instances in their Sleuth representative, which is called TraceAction. The hook either starts or continues a span, depending on whether tracing was already going on before the Action was scheduled. @@ -2131,12 +1925,12 @@ the Reactor support.

    -

    14.5. HTTP integration

    +

    13.5. HTTP integration

    Features from this section can be disabled by setting the spring.sleuth.web.enabled property with value equal to false.

    -

    14.5.1. HTTP Filter

    +

    13.5.1. HTTP Filter

    Through the TracingFilter, all sampled incoming requests result in creation of a Span. That Span’s name is http: + the path to which the request was sent. @@ -2160,7 +1954,7 @@ to true.

    -

    14.5.2. HandlerInterceptor

    +

    13.5.2. HandlerInterceptor

    Since we want the span names to be precise, we use a TraceHandlerInterceptor that either wraps an existing HandlerInterceptor or is added directly to the list of existing HandlerInterceptors. The TraceHandlerInterceptor adds a special request attribute to the given HttpServletRequest. @@ -2170,13 +1964,13 @@ In that case, please file an issue in Spring Cloud Sleuth.

    -

    14.5.3. Async Servlet support

    +

    13.5.3. Async Servlet support

    If your controller returns a Callable or a WebAsyncTask, Spring Cloud Sleuth continues the existing span instead of creating a new one.

    -

    14.5.4. WebFlux support

    +

    13.5.4. WebFlux support

    Through TraceWebFilter, all sampled incoming requests result in creation of a Span. That Span’s name is http: + the path to which the request was sent. @@ -2191,7 +1985,7 @@ If you want to reuse Sleuth’s default skip patterns and append your own, p

    -

    14.5.5. Dubbo RPC support

    +

    13.5.5. Dubbo RPC support

    Via the integration with Brave, Spring Cloud Sleuth supports Dubbo. It’s enough to add the brave-instrumentation-dubbo dependency:

    @@ -2220,9 +2014,9 @@ An example of Spring Cloud Sleuth and Dubbo can be found -

    14.6. HTTP Client Integration

    +

    13.6. HTTP Client Integration

    -

    14.6.1. Synchronous Rest Template

    +

    13.6.1. Synchronous Rest Template

    We inject a RestTemplate interceptor to ensure that all the tracing information is passed to the requests. Each time a call is made, a new Span is created. @@ -2244,7 +2038,7 @@ If you create a RestTemplate instance with a new keywo

    -

    14.6.2. Asynchronous Rest Template

    +

    13.6.2. Asynchronous Rest Template

    @@ -2301,7 +2095,7 @@ static class Config {
    -

    14.6.3. WebClient

    +

    13.6.3. WebClient

    We inject a ExchangeFilterFunction implementation that creates a span and, through on-success and on-error callbacks, takes care of closing client-side spans.

    @@ -2323,7 +2117,7 @@ If you create a WebClient instance with a new keyword,
    -

    14.6.4. Traverson

    +

    13.6.4. Traverson

    If you use the Traverson library, you can inject a RestTemplate as a bean into your Traverson object. Since RestTemplate is already intercepted, you get full support for tracing in your client. The following pseudo code @@ -2340,7 +2134,7 @@ Traverson traverson = new Traverson(URI.create("https://some/address"),

    -

    14.6.5. Apache HttpClientBuilder and HttpAsyncClientBuilder

    +

    13.6.5. Apache HttpClientBuilder and HttpAsyncClientBuilder

    We instrument the HttpClientBuilder and HttpAsyncClientBuilder so that tracing context gets injected to the sent requests.

    @@ -2350,7 +2144,7 @@ tracing context gets injected to the sent requests.

    -

    14.6.6. Netty HttpClient

    +

    13.6.6. Netty HttpClient

    We instrument the Netty’s HttpClient.

    @@ -2372,7 +2166,7 @@ If you create a HttpClient instance with a new keyword
    -

    14.6.7. UserInfoRestTemplateCustomizer

    +

    13.6.7. UserInfoRestTemplateCustomizer

    We instrument the Spring Security’s UserInfoRestTemplateCustomizer.

    @@ -2382,7 +2176,7 @@ If you create a HttpClient instance with a new keyword
    -

    14.7. Feign

    +

    13.7. Feign

    By default, Spring Cloud Sleuth provides integration with Feign through TraceFeignClientAutoConfiguration. You can disable it entirely by setting spring.sleuth.feign.enabled to false. @@ -2396,12 +2190,12 @@ However, all the default instrumentation is still there.

    -

    14.8. gRPC

    +

    13.8. gRPC

    Spring Cloud Sleuth provides instrumentation for gRPC through TraceGrpcAutoConfiguration. You can disable it entirely by setting spring.sleuth.grpc.enabled to false.

    -

    14.8.1. Variant 1

    +

    13.8.1. Variant 1

    Dependencies
    @@ -2470,16 +2264,16 @@ Spring Cloud Sleuth provides a SpringAwareManagedChannelBuilder tha
    -

    14.8.2. Variant 2

    +

    13.8.2. Variant 2

    Grpc Spring Boot Starter automatically detects the presence of Spring Cloud Sleuth and brave’s instrumentation for gRPC and registers the necessary client and/or server tooling.

    -

    14.9. Asynchronous Communication

    +

    13.9. Asynchronous Communication

    -

    14.9.1. @Async Annotated methods

    +

    13.9.1. @Async Annotated methods

    In Spring Cloud Sleuth, we instrument async-related components so that the tracing information is passed between threads. You can disable this behavior by setting the value of spring.sleuth.async.enabled to false.

    @@ -2502,7 +2296,7 @@ You can disable this behavior by setting the value of spring.sleuth.async.
    -

    14.9.2. @Scheduled Annotated Methods

    +

    13.9.2. @Scheduled Annotated Methods

    In Spring Cloud Sleuth, we instrument scheduled method execution so that the tracing information is passed between threads. You can disable this behavior by setting the value of spring.sleuth.scheduled.enabled to false.

    @@ -2525,7 +2319,7 @@ You can disable this behavior by setting the value of spring.sleuth.schedu
    -

    14.9.3. Executor, ExecutorService, and ScheduledExecutorService

    +

    13.9.3. Executor, ExecutorService, and ScheduledExecutorService

    We provide LazyTraceExecutor, TraceableExecutorService, and TraceableScheduledExecutorService. Those implementations create spans each time a new task is submitted, invoked, or scheduled.

    @@ -2612,12 +2406,12 @@ to add the @Role(BeanDefinition.ROLE_INFRASTRUCTURE) on your
    -

    14.10. Messaging

    +

    13.10. Messaging

    Features from this section can be disabled by setting the spring.sleuth.messaging.enabled property with value equal to false.

    -

    14.10.1. Spring Integration and Spring Cloud Stream

    +

    13.10.1. Spring Integration and Spring Cloud Stream

    Spring Cloud Sleuth integrates with Spring Integration. It creates spans for publish and subscribe events. @@ -2656,7 +2450,7 @@ it’s enough for you to register beans of types:

    -

    14.10.2. Spring RabbitMq

    +

    13.10.2. Spring RabbitMq

    We instrument the RabbitTemplate so that tracing headers get injected into the message.

    @@ -2666,7 +2460,7 @@ into the message.

    -

    14.10.3. Spring Kafka

    +

    13.10.3. Spring Kafka

    We instrument the Spring Kafka’s ProducerFactory and ConsumerFactory so that tracing headers get injected into the created Spring Kafka’s @@ -2677,7 +2471,7 @@ so that tracing headers get injected into the created Spring Kafka’s

    -

    14.10.4. Spring Kafka Streams

    +

    13.10.4. Spring Kafka Streams

    We instrument the KafkaStreams KafkaClientSupplier so that tracing headers get injected into the Producer and Consumer`s. A `KafkaStreamsTracing bean @@ -2689,7 +2483,7 @@ allows for further instrumentation through additional TransformerSupplier<

    -

    14.10.5. Spring JMS

    +

    13.10.5. Spring JMS

    We instrument the JmsTemplate so that tracing headers get injected into the message. We also support @JmsListener annotated methods on the consumer side.

    @@ -2711,7 +2505,7 @@ We don’t support baggage propagation for JMS
    -

    14.10.6. Spring Cloud AWS Messaging SQS

    +

    13.10.6. Spring Cloud AWS Messaging SQS

    We instrument @SqsListener which is provided by org.springframework.cloud:spring-cloud-aws-messaging so that tracing headers get extracted from the message and a trace gets put into the context.

    @@ -2722,14 +2516,14 @@ so that tracing headers get extracted from the message and a trace gets put into
    -

    14.11. Redis

    +

    13.11. Redis

    We set tracing property to Lettcue ClientResources instance to enable Brave tracing built in Lettuce . To disable Redis support, set the spring.sleuth.redis.enabled property to false.

    -

    14.12. Quartz

    +

    13.12. Quartz

    We instrument quartz jobs by adding Job/Trigger listeners to the Quartz Scheduler.

    @@ -2738,7 +2532,7 @@ To disable Redis support, set the spring.sleuth.redis.enabled prope
    -

    14.13. Project Reactor

    +

    13.13. Project Reactor

    For projects depending on Project Reactor such as Spring Cloud Gateway, we suggest turning the spring.sleuth.reactor.decorate-on-each option to false. That way an increased performance gain should be observed in comparison to the standard instrumentation mechanism. What this option does is it will wrap decorate onLast operator instead of onEach which will result in creation of far fewer objects. The downside of this is that when Project Reactor will change threads, the trace propagation will continue without issues, however anything relying on the ThreadLocal such as e.g. MDC entries can be buggy.

    @@ -2746,6 +2540,204 @@ To disable Redis support, set the spring.sleuth.redis.enabled prope
    +

    14. Log integration

    +
    +
    +

    Sleuth configures the logging context with variables including the service name +(%{spring.zipkin.service.name}) and the trace ID (%{traceId}). These help +you connect logs with distributed traces and allow you choice in what tools you +use to troubleshoot your services.

    +
    +
    +

    If you use a log aggregating tool (such as Kibana, Splunk, and others), you can order the events that took place. +An example from Kibana would resemble the following image:

    +
    +
    +
    +Log correlation with Kibana +
    +
    +
    +

    If you want to use Logstash, the following listing shows the Grok pattern for Logstash:

    +
    +
    +
    +
    filter {
    +  # pattern matching logback pattern
    +  grok {
    +    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
    +  }
    +  date {
    +    match => ["timestamp", "ISO8601"]
    +  }
    +  mutate {
    +    remove_field => ["timestamp"]
    +  }
    +}
    +
    +
    +
    +
    + + + + +
    + + +If you want to use Grok together with the logs from Cloud Foundry, you have to use the following pattern: +
    +
    +
    +
    +
    filter {
    +  # pattern matching logback pattern
    +  grok {
    +    match => { "message" => "(?m)OUT\s+%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
    +  }
    +  date {
    +    match => ["timestamp", "ISO8601"]
    +  }
    +  mutate {
    +    remove_field => ["timestamp"]
    +  }
    +}
    +
    +
    +
    +

    14.1. JSON Logback with Logstash

    +
    +

    Often, you do not want to store your logs in a text file but in a JSON file that Logstash can immediately pick. +To do so, you have to do the following (for readability, we pass the dependencies in the groupId:artifactId:version notation).

    +
    +
    +

    Dependencies Setup

    +
    +
    +
      +
    1. +

      Ensure that Logback is on the classpath (ch.qos.logback:logback-core).

      +
    2. +
    3. +

      Add Logstash Logback encode. For example, to use version 4.6, add net.logstash.logback:logstash-logback-encoder:4.6.

      +
    4. +
    +
    +
    +

    Logback Setup

    +
    +
    +

    Consider the following example of a Logback configuration file (logback-spring.xml).

    +
    +
    +
    +
    <?xml version="1.0" encoding="UTF-8"?>
    +<configuration>
    +    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
    +    <springProperty scope="context" name="springAppName" source="spring.application.name"/>
    +    <!-- Example for logging into the build folder of your project -->
    +    <property name="LOG_FILE" value="${BUILD_FOLDER:-build}/${springAppName}"/>
    +
    +    <!-- You can override this to have a custom pattern -->
    +    <property name="CONSOLE_LOG_PATTERN"
    +              value="%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>
    +
    +    <!-- Appender to log to console -->
    +    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
    +        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
    +            <!-- Minimum logging level to be presented in the console logs-->
    +            <level>DEBUG</level>
    +        </filter>
    +        <encoder>
    +            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
    +            <charset>utf8</charset>
    +        </encoder>
    +    </appender>
    +
    +    <!-- Appender to log to file -->
    +    <appender name="flatfile" class="ch.qos.logback.core.rolling.RollingFileAppender">
    +        <file>${LOG_FILE}</file>
    +        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    +            <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.gz</fileNamePattern>
    +            <maxHistory>7</maxHistory>
    +        </rollingPolicy>
    +        <encoder>
    +            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
    +            <charset>utf8</charset>
    +        </encoder>
    +    </appender>
    +    <!-- Appender to log to file in a JSON format -->
    +    <appender name="logstash" class="ch.qos.logback.core.rolling.RollingFileAppender">
    +        <file>${LOG_FILE}.json</file>
    +        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    +            <fileNamePattern>${LOG_FILE}.json.%d{yyyy-MM-dd}.gz</fileNamePattern>
    +            <maxHistory>7</maxHistory>
    +        </rollingPolicy>
    +        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
    +            <providers>
    +                <timestamp>
    +                    <timeZone>UTC</timeZone>
    +                </timestamp>
    +                <pattern>
    +                    <pattern>
    +                        {
    +                        "timestamp": "@timestamp",
    +                        "severity": "%level",
    +                        "service": "${springAppName:-}",
    +                        "trace": "%X{traceId:-}",
    +                        "span": "%X{spanId:-}",
    +                        "pid": "${PID:-}",
    +                        "thread": "%thread",
    +                        "class": "%logger{40}",
    +                        "rest": "%message"
    +                        }
    +                    </pattern>
    +                </pattern>
    +            </providers>
    +        </encoder>
    +    </appender>
    +    <root level="INFO">
    +        <appender-ref ref="console"/>
    +        <!-- uncomment this to have also JSON logs -->
    +        <!--<appender-ref ref="logstash"/>-->
    +        <!--<appender-ref ref="flatfile"/>-->
    +    </root>
    +</configuration>
    +
    +
    +
    +

    That Logback configuration file:

    +
    +
    +
      +
    • +

      Logs information from the application in a JSON format to a build/${spring.application.name}.json file.

      +
    • +
    • +

      Has commented out two additional appenders: console and standard log file.

      +
    • +
    • +

      Has the same logging pattern as the one presented in the previous section.

      +
    • +
    +
    +
    + + + + + +
    + + +If you use a custom logback-spring.xml, you must pass the spring.application.name in the bootstrap rather than the application property file. +Otherwise, your custom logback file does not properly read the property. +
    +
    +
    +
    +
    +

    15. Configuration properties

    @@ -2753,28 +2745,6 @@ To disable Redis support, set the spring.sleuth.redis.enabled prope
    -
    -

    16. Running examples

    -
    -
    -

    You can see the running examples deployed in the Pivotal Web Services. -Check them out at the following links:

    -
    -
    - -
    -
    -
    diff --git a/reference/html/spring-cloud-sleuth.html b/reference/html/spring-cloud-sleuth.html index 7811e984c..21461d8cf 100644 --- a/reference/html/spring-cloud-sleuth.html +++ b/reference/html/spring-cloud-sleuth.html @@ -181,26 +181,29 @@ $(globalSwitch);
  • 12. Sending Spans to Zipkin
  • -
  • 13. Zipkin Stream Span Consumer
  • -
  • 14. Integrations +
  • 13. Integrations +
  • +
  • 14. Log integration +
  • 15. Configuration properties
  • -
  • 16. Running examples
  • @@ -323,193 +326,6 @@ frontend.log:2020-04-09 17:45:40.574 ERROR [frontend,5e8eeec48b08e26882aba313eb0

    Above, you’ll notice the trace ID is 5e8eeec48b08e26882aba313eb08f0a4, for example. This log configuration was automatically setup by Sleuth.

    -
    -

    If you use a log aggregating tool (such as Kibana, Splunk, and others), you can order the events that took place. -An example from Kibana would resemble the following image:

    -
    -
    -
    -Log correlation with Kibana -
    -
    -
    -

    If you want to use Logstash, the following listing shows the Grok pattern for Logstash:

    -
    -
    -
    -
    filter {
    -  # pattern matching logback pattern
    -  grok {
    -    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
    -  }
    -  date {
    -    match => ["timestamp", "ISO8601"]
    -  }
    -  mutate {
    -    remove_field => ["timestamp"]
    -  }
    -}
    -
    -
    -
    - - - - - -
    - - -If you want to use Grok together with the logs from Cloud Foundry, you have to use the following pattern: -
    -
    -
    -
    -
    filter {
    -  # pattern matching logback pattern
    -  grok {
    -    match => { "message" => "(?m)OUT\s+%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
    -  }
    -  date {
    -    match => ["timestamp", "ISO8601"]
    -  }
    -  mutate {
    -    remove_field => ["timestamp"]
    -  }
    -}
    -
    -
    -
    -

    2.2.1. JSON Logback with Logstash

    -
    -

    Often, you do not want to store your logs in a text file but in a JSON file that Logstash can immediately pick. -To do so, you have to do the following (for readability, we pass the dependencies in the groupId:artifactId:version notation).

    -
    -
    -

    Dependencies Setup

    -
    -
    -
      -
    1. -

      Ensure that Logback is on the classpath (ch.qos.logback:logback-core).

      -
    2. -
    3. -

      Add Logstash Logback encode. For example, to use version 4.6, add net.logstash.logback:logstash-logback-encoder:4.6.

      -
    4. -
    -
    -
    -

    Logback Setup

    -
    -
    -

    Consider the following example of a Logback configuration file (logback-spring.xml).

    -
    -
    -
    -
    <?xml version="1.0" encoding="UTF-8"?>
    -<configuration>
    -    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
    -    <springProperty scope="context" name="springAppName" source="spring.application.name"/>
    -    <!-- Example for logging into the build folder of your project -->
    -    <property name="LOG_FILE" value="${BUILD_FOLDER:-build}/${springAppName}"/>
    -
    -    <!-- You can override this to have a custom pattern -->
    -    <property name="CONSOLE_LOG_PATTERN"
    -              value="%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>
    -
    -    <!-- Appender to log to console -->
    -    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
    -        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
    -            <!-- Minimum logging level to be presented in the console logs-->
    -            <level>DEBUG</level>
    -        </filter>
    -        <encoder>
    -            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
    -            <charset>utf8</charset>
    -        </encoder>
    -    </appender>
    -
    -    <!-- Appender to log to file -->
    -    <appender name="flatfile" class="ch.qos.logback.core.rolling.RollingFileAppender">
    -        <file>${LOG_FILE}</file>
    -        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    -            <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.gz</fileNamePattern>
    -            <maxHistory>7</maxHistory>
    -        </rollingPolicy>
    -        <encoder>
    -            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
    -            <charset>utf8</charset>
    -        </encoder>
    -    </appender>
    -    <!-- Appender to log to file in a JSON format -->
    -    <appender name="logstash" class="ch.qos.logback.core.rolling.RollingFileAppender">
    -        <file>${LOG_FILE}.json</file>
    -        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    -            <fileNamePattern>${LOG_FILE}.json.%d{yyyy-MM-dd}.gz</fileNamePattern>
    -            <maxHistory>7</maxHistory>
    -        </rollingPolicy>
    -        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
    -            <providers>
    -                <timestamp>
    -                    <timeZone>UTC</timeZone>
    -                </timestamp>
    -                <pattern>
    -                    <pattern>
    -                        {
    -                        "timestamp": "@timestamp",
    -                        "severity": "%level",
    -                        "service": "${springAppName:-}",
    -                        "trace": "%X{traceId:-}",
    -                        "span": "%X{spanId:-}",
    -                        "pid": "${PID:-}",
    -                        "thread": "%thread",
    -                        "class": "%logger{40}",
    -                        "rest": "%message"
    -                        }
    -                    </pattern>
    -                </pattern>
    -            </providers>
    -        </encoder>
    -    </appender>
    -    <root level="INFO">
    -        <appender-ref ref="console"/>
    -        <!-- uncomment this to have also JSON logs -->
    -        <!--<appender-ref ref="logstash"/>-->
    -        <!--<appender-ref ref="flatfile"/>-->
    -    </root>
    -</configuration>
    -
    -
    -
    -

    That Logback configuration file:

    -
    -
    -
      -
    • -

      Logs information from the application in a JSON format to a build/${spring.application.name}.json file.

      -
    • -
    • -

      Has commented out two additional appenders: console and standard log file.

      -
    • -
    • -

      Has the same logging pattern as the one presented in the previous section.

      -
    • -
    -
    -
    - - - - - -
    - - -If you use a custom logback-spring.xml, you must pass the spring.application.name in the bootstrap rather than the application property file. -Otherwise, your custom logback file does not properly read the property. -
    -
    -

    2.3. Service Dependency Graph

    @@ -2011,32 +1827,10 @@ object, you will have to create a bean of zipkin2.reporter.Sender t
    -

    13. Zipkin Stream Span Consumer

    -
    -
    - - - - - -
    - - -We recommend using Zipkin’s native support for message-based span sending. -Starting from the Edgware release, the Zipkin Stream server is deprecated. -In the Finchley release, it got removed. -
    -
    -
    -

    If for some reason you need to create the deprecated Stream Zipkin server, see the Dalston Documentation.

    -
    -
    -
    -
    -

    14. Integrations

    +

    13. Integrations

    -

    14.1. OpenTracing

    +

    13.1. OpenTracing

    Spring Cloud Sleuth is compatible with OpenTracing. If you have OpenTracing on the classpath, we automatically register the OpenTracing Tracer bean. @@ -2044,7 +1838,7 @@ If you wish to disable this, set spring.sleuth.opentracing.enabled

    -

    14.2. Runnable and Callable

    +

    13.2. Runnable and Callable

    If you wrap your logic in Runnable or Callable, you can wrap those classes in their Sleuth representative, as shown in the following example for Runnable:

    @@ -2100,13 +1894,13 @@ Callable<String> traceCallableFromTracer = this.tracing.currentTraceContex
    -

    14.3. Spring Cloud CircuitBreaker

    +

    13.3. Spring Cloud CircuitBreaker

    If you have Spring Cloud CircuitBreaker on the classpath, we will wrap the passed command Supplier and the fallback Function in its trace representations. In order to disable this instrumentation set spring.sleuth.circuitbreaker.enabled to false.

    -

    14.4. RxJava

    +

    13.4. RxJava

    We registering a custom RxJavaSchedulersHook that wraps all Action0 instances in their Sleuth representative, which is called TraceAction. The hook either starts or continues a span, depending on whether tracing was already going on before the Action was scheduled. @@ -2131,12 +1925,12 @@ the Reactor support.

    -

    14.5. HTTP integration

    +

    13.5. HTTP integration

    Features from this section can be disabled by setting the spring.sleuth.web.enabled property with value equal to false.

    -

    14.5.1. HTTP Filter

    +

    13.5.1. HTTP Filter

    Through the TracingFilter, all sampled incoming requests result in creation of a Span. That Span’s name is http: + the path to which the request was sent. @@ -2160,7 +1954,7 @@ to true.

    -

    14.5.2. HandlerInterceptor

    +

    13.5.2. HandlerInterceptor

    Since we want the span names to be precise, we use a TraceHandlerInterceptor that either wraps an existing HandlerInterceptor or is added directly to the list of existing HandlerInterceptors. The TraceHandlerInterceptor adds a special request attribute to the given HttpServletRequest. @@ -2170,13 +1964,13 @@ In that case, please file an issue in Spring Cloud Sleuth.

    -

    14.5.3. Async Servlet support

    +

    13.5.3. Async Servlet support

    If your controller returns a Callable or a WebAsyncTask, Spring Cloud Sleuth continues the existing span instead of creating a new one.

    -

    14.5.4. WebFlux support

    +

    13.5.4. WebFlux support

    Through TraceWebFilter, all sampled incoming requests result in creation of a Span. That Span’s name is http: + the path to which the request was sent. @@ -2191,7 +1985,7 @@ If you want to reuse Sleuth’s default skip patterns and append your own, p

    -

    14.5.5. Dubbo RPC support

    +

    13.5.5. Dubbo RPC support

    Via the integration with Brave, Spring Cloud Sleuth supports Dubbo. It’s enough to add the brave-instrumentation-dubbo dependency:

    @@ -2220,9 +2014,9 @@ An example of Spring Cloud Sleuth and Dubbo can be found -

    14.6. HTTP Client Integration

    +

    13.6. HTTP Client Integration

    -

    14.6.1. Synchronous Rest Template

    +

    13.6.1. Synchronous Rest Template

    We inject a RestTemplate interceptor to ensure that all the tracing information is passed to the requests. Each time a call is made, a new Span is created. @@ -2244,7 +2038,7 @@ If you create a RestTemplate instance with a new keywo

    -

    14.6.2. Asynchronous Rest Template

    +

    13.6.2. Asynchronous Rest Template

    @@ -2301,7 +2095,7 @@ static class Config {
    -

    14.6.3. WebClient

    +

    13.6.3. WebClient

    We inject a ExchangeFilterFunction implementation that creates a span and, through on-success and on-error callbacks, takes care of closing client-side spans.

    @@ -2323,7 +2117,7 @@ If you create a WebClient instance with a new keyword,
    -

    14.6.4. Traverson

    +

    13.6.4. Traverson

    If you use the Traverson library, you can inject a RestTemplate as a bean into your Traverson object. Since RestTemplate is already intercepted, you get full support for tracing in your client. The following pseudo code @@ -2340,7 +2134,7 @@ Traverson traverson = new Traverson(URI.create("https://some/address"),

    -

    14.6.5. Apache HttpClientBuilder and HttpAsyncClientBuilder

    +

    13.6.5. Apache HttpClientBuilder and HttpAsyncClientBuilder

    We instrument the HttpClientBuilder and HttpAsyncClientBuilder so that tracing context gets injected to the sent requests.

    @@ -2350,7 +2144,7 @@ tracing context gets injected to the sent requests.

    -

    14.6.6. Netty HttpClient

    +

    13.6.6. Netty HttpClient

    We instrument the Netty’s HttpClient.

    @@ -2372,7 +2166,7 @@ If you create a HttpClient instance with a new keyword
    -

    14.6.7. UserInfoRestTemplateCustomizer

    +

    13.6.7. UserInfoRestTemplateCustomizer

    We instrument the Spring Security’s UserInfoRestTemplateCustomizer.

    @@ -2382,7 +2176,7 @@ If you create a HttpClient instance with a new keyword
    -

    14.7. Feign

    +

    13.7. Feign

    By default, Spring Cloud Sleuth provides integration with Feign through TraceFeignClientAutoConfiguration. You can disable it entirely by setting spring.sleuth.feign.enabled to false. @@ -2396,12 +2190,12 @@ However, all the default instrumentation is still there.

    -

    14.8. gRPC

    +

    13.8. gRPC

    Spring Cloud Sleuth provides instrumentation for gRPC through TraceGrpcAutoConfiguration. You can disable it entirely by setting spring.sleuth.grpc.enabled to false.

    -

    14.8.1. Variant 1

    +

    13.8.1. Variant 1

    Dependencies
    @@ -2470,16 +2264,16 @@ Spring Cloud Sleuth provides a SpringAwareManagedChannelBuilder tha
    -

    14.8.2. Variant 2

    +

    13.8.2. Variant 2

    Grpc Spring Boot Starter automatically detects the presence of Spring Cloud Sleuth and brave’s instrumentation for gRPC and registers the necessary client and/or server tooling.

    -

    14.9. Asynchronous Communication

    +

    13.9. Asynchronous Communication

    -

    14.9.1. @Async Annotated methods

    +

    13.9.1. @Async Annotated methods

    In Spring Cloud Sleuth, we instrument async-related components so that the tracing information is passed between threads. You can disable this behavior by setting the value of spring.sleuth.async.enabled to false.

    @@ -2502,7 +2296,7 @@ You can disable this behavior by setting the value of spring.sleuth.async.
    -

    14.9.2. @Scheduled Annotated Methods

    +

    13.9.2. @Scheduled Annotated Methods

    In Spring Cloud Sleuth, we instrument scheduled method execution so that the tracing information is passed between threads. You can disable this behavior by setting the value of spring.sleuth.scheduled.enabled to false.

    @@ -2525,7 +2319,7 @@ You can disable this behavior by setting the value of spring.sleuth.schedu
    -

    14.9.3. Executor, ExecutorService, and ScheduledExecutorService

    +

    13.9.3. Executor, ExecutorService, and ScheduledExecutorService

    We provide LazyTraceExecutor, TraceableExecutorService, and TraceableScheduledExecutorService. Those implementations create spans each time a new task is submitted, invoked, or scheduled.

    @@ -2612,12 +2406,12 @@ to add the @Role(BeanDefinition.ROLE_INFRASTRUCTURE) on your
    -

    14.10. Messaging

    +

    13.10. Messaging

    Features from this section can be disabled by setting the spring.sleuth.messaging.enabled property with value equal to false.

    -

    14.10.1. Spring Integration and Spring Cloud Stream

    +

    13.10.1. Spring Integration and Spring Cloud Stream

    Spring Cloud Sleuth integrates with Spring Integration. It creates spans for publish and subscribe events. @@ -2656,7 +2450,7 @@ it’s enough for you to register beans of types:

    -

    14.10.2. Spring RabbitMq

    +

    13.10.2. Spring RabbitMq

    We instrument the RabbitTemplate so that tracing headers get injected into the message.

    @@ -2666,7 +2460,7 @@ into the message.

    -

    14.10.3. Spring Kafka

    +

    13.10.3. Spring Kafka

    We instrument the Spring Kafka’s ProducerFactory and ConsumerFactory so that tracing headers get injected into the created Spring Kafka’s @@ -2677,7 +2471,7 @@ so that tracing headers get injected into the created Spring Kafka’s

    -

    14.10.4. Spring Kafka Streams

    +

    13.10.4. Spring Kafka Streams

    We instrument the KafkaStreams KafkaClientSupplier so that tracing headers get injected into the Producer and Consumer`s. A `KafkaStreamsTracing bean @@ -2689,7 +2483,7 @@ allows for further instrumentation through additional TransformerSupplier<

    -

    14.10.5. Spring JMS

    +

    13.10.5. Spring JMS

    We instrument the JmsTemplate so that tracing headers get injected into the message. We also support @JmsListener annotated methods on the consumer side.

    @@ -2711,7 +2505,7 @@ We don’t support baggage propagation for JMS
    -

    14.10.6. Spring Cloud AWS Messaging SQS

    +

    13.10.6. Spring Cloud AWS Messaging SQS

    We instrument @SqsListener which is provided by org.springframework.cloud:spring-cloud-aws-messaging so that tracing headers get extracted from the message and a trace gets put into the context.

    @@ -2722,14 +2516,14 @@ so that tracing headers get extracted from the message and a trace gets put into
    -

    14.11. Redis

    +

    13.11. Redis

    We set tracing property to Lettcue ClientResources instance to enable Brave tracing built in Lettuce . To disable Redis support, set the spring.sleuth.redis.enabled property to false.

    -

    14.12. Quartz

    +

    13.12. Quartz

    We instrument quartz jobs by adding Job/Trigger listeners to the Quartz Scheduler.

    @@ -2738,7 +2532,7 @@ To disable Redis support, set the spring.sleuth.redis.enabled prope
    -

    14.13. Project Reactor

    +

    13.13. Project Reactor

    For projects depending on Project Reactor such as Spring Cloud Gateway, we suggest turning the spring.sleuth.reactor.decorate-on-each option to false. That way an increased performance gain should be observed in comparison to the standard instrumentation mechanism. What this option does is it will wrap decorate onLast operator instead of onEach which will result in creation of far fewer objects. The downside of this is that when Project Reactor will change threads, the trace propagation will continue without issues, however anything relying on the ThreadLocal such as e.g. MDC entries can be buggy.

    @@ -2746,6 +2540,204 @@ To disable Redis support, set the spring.sleuth.redis.enabled prope
    +

    14. Log integration

    +
    +
    +

    Sleuth configures the logging context with variables including the service name +(%{spring.zipkin.service.name}) and the trace ID (%{traceId}). These help +you connect logs with distributed traces and allow you choice in what tools you +use to troubleshoot your services.

    +
    +
    +

    If you use a log aggregating tool (such as Kibana, Splunk, and others), you can order the events that took place. +An example from Kibana would resemble the following image:

    +
    +
    +
    +Log correlation with Kibana +
    +
    +
    +

    If you want to use Logstash, the following listing shows the Grok pattern for Logstash:

    +
    +
    +
    +
    filter {
    +  # pattern matching logback pattern
    +  grok {
    +    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
    +  }
    +  date {
    +    match => ["timestamp", "ISO8601"]
    +  }
    +  mutate {
    +    remove_field => ["timestamp"]
    +  }
    +}
    +
    +
    +
    +
    + + + + +
    + + +If you want to use Grok together with the logs from Cloud Foundry, you have to use the following pattern: +
    +
    +
    +
    +
    filter {
    +  # pattern matching logback pattern
    +  grok {
    +    match => { "message" => "(?m)OUT\s+%{TIMESTAMP_ISO8601:timestamp}\s+%{LOGLEVEL:severity}\s+\[%{DATA:service},%{DATA:trace},%{DATA:span}\]\s+%{DATA:pid}\s+---\s+\[%{DATA:thread}\]\s+%{DATA:class}\s+:\s+%{GREEDYDATA:rest}" }
    +  }
    +  date {
    +    match => ["timestamp", "ISO8601"]
    +  }
    +  mutate {
    +    remove_field => ["timestamp"]
    +  }
    +}
    +
    +
    +
    +

    14.1. JSON Logback with Logstash

    +
    +

    Often, you do not want to store your logs in a text file but in a JSON file that Logstash can immediately pick. +To do so, you have to do the following (for readability, we pass the dependencies in the groupId:artifactId:version notation).

    +
    +
    +

    Dependencies Setup

    +
    +
    +
      +
    1. +

      Ensure that Logback is on the classpath (ch.qos.logback:logback-core).

      +
    2. +
    3. +

      Add Logstash Logback encode. For example, to use version 4.6, add net.logstash.logback:logstash-logback-encoder:4.6.

      +
    4. +
    +
    +
    +

    Logback Setup

    +
    +
    +

    Consider the following example of a Logback configuration file (logback-spring.xml).

    +
    +
    +
    +
    <?xml version="1.0" encoding="UTF-8"?>
    +<configuration>
    +    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
    +    <springProperty scope="context" name="springAppName" source="spring.application.name"/>
    +    <!-- Example for logging into the build folder of your project -->
    +    <property name="LOG_FILE" value="${BUILD_FOLDER:-build}/${springAppName}"/>
    +
    +    <!-- You can override this to have a custom pattern -->
    +    <property name="CONSOLE_LOG_PATTERN"
    +              value="%clr(%d{yyyy-MM-dd HH:mm:ss.SSS}){faint} %clr(${LOG_LEVEL_PATTERN:-%5p}) %clr(${PID:- }){magenta} %clr(---){faint} %clr([%15.15t]){faint} %clr(%-40.40logger{39}){cyan} %clr(:){faint} %m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}"/>
    +
    +    <!-- Appender to log to console -->
    +    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
    +        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
    +            <!-- Minimum logging level to be presented in the console logs-->
    +            <level>DEBUG</level>
    +        </filter>
    +        <encoder>
    +            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
    +            <charset>utf8</charset>
    +        </encoder>
    +    </appender>
    +
    +    <!-- Appender to log to file -->
    +    <appender name="flatfile" class="ch.qos.logback.core.rolling.RollingFileAppender">
    +        <file>${LOG_FILE}</file>
    +        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    +            <fileNamePattern>${LOG_FILE}.%d{yyyy-MM-dd}.gz</fileNamePattern>
    +            <maxHistory>7</maxHistory>
    +        </rollingPolicy>
    +        <encoder>
    +            <pattern>${CONSOLE_LOG_PATTERN}</pattern>
    +            <charset>utf8</charset>
    +        </encoder>
    +    </appender>
    +    <!-- Appender to log to file in a JSON format -->
    +    <appender name="logstash" class="ch.qos.logback.core.rolling.RollingFileAppender">
    +        <file>${LOG_FILE}.json</file>
    +        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
    +            <fileNamePattern>${LOG_FILE}.json.%d{yyyy-MM-dd}.gz</fileNamePattern>
    +            <maxHistory>7</maxHistory>
    +        </rollingPolicy>
    +        <encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">
    +            <providers>
    +                <timestamp>
    +                    <timeZone>UTC</timeZone>
    +                </timestamp>
    +                <pattern>
    +                    <pattern>
    +                        {
    +                        "timestamp": "@timestamp",
    +                        "severity": "%level",
    +                        "service": "${springAppName:-}",
    +                        "trace": "%X{traceId:-}",
    +                        "span": "%X{spanId:-}",
    +                        "pid": "${PID:-}",
    +                        "thread": "%thread",
    +                        "class": "%logger{40}",
    +                        "rest": "%message"
    +                        }
    +                    </pattern>
    +                </pattern>
    +            </providers>
    +        </encoder>
    +    </appender>
    +    <root level="INFO">
    +        <appender-ref ref="console"/>
    +        <!-- uncomment this to have also JSON logs -->
    +        <!--<appender-ref ref="logstash"/>-->
    +        <!--<appender-ref ref="flatfile"/>-->
    +    </root>
    +</configuration>
    +
    +
    +
    +

    That Logback configuration file:

    +
    +
    +
      +
    • +

      Logs information from the application in a JSON format to a build/${spring.application.name}.json file.

      +
    • +
    • +

      Has commented out two additional appenders: console and standard log file.

      +
    • +
    • +

      Has the same logging pattern as the one presented in the previous section.

      +
    • +
    +
    +
    + + + + + +
    + + +If you use a custom logback-spring.xml, you must pass the spring.application.name in the bootstrap rather than the application property file. +Otherwise, your custom logback file does not properly read the property. +
    +
    +
    +
    +
    +

    15. Configuration properties

    @@ -2753,28 +2745,6 @@ To disable Redis support, set the spring.sleuth.redis.enabled prope
    -
    -

    16. Running examples

    -
    -
    -

    You can see the running examples deployed in the Pivotal Web Services. -Check them out at the following links:

    -
    -
    - -
    -
    -