From a4cd06f76c3ef95ac68ff65aa4b7e97bcdc29d15 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Thu, 7 Jun 2018 15:59:54 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- multi/multi__http_clients.html | 4 +- .../multi__polyglot_support_with_sidecar.html | 4 +- multi/multi_retrying-failed-requests.html | 10 +- multi/multi_spring-cloud-netflix.html | 2 +- single/spring-cloud-netflix.html | 109 +------- spring-cloud-netflix.xml | 234 ------------------ 6 files changed, 16 insertions(+), 347 deletions(-) diff --git a/multi/multi__http_clients.html b/multi/multi__http_clients.html index 553aac90f..e9822cacd 100644 --- a/multi/multi__http_clients.html +++ b/multi/multi__http_clients.html @@ -1,7 +1,7 @@ - 13. HTTP Clients
13. HTTP Clients
Prev   

13. HTTP Clients

Spring Cloud Netflix automatically creates the HTTP client used by Ribbon, Feign, and Zuul for you. + 11. HTTP Clients

11. HTTP Clients
Prev   

11. HTTP Clients

Spring Cloud Netflix automatically creates the HTTP client used by Ribbon, Feign, and Zuul for you. However, you can also provide your own HTTP clients customized as you need them to be. To do so, you can create a bean of type ClosableHttpClient if you are using the Apache Http Cient or OkHttpClient if you are using OK HTTP.

[Note]Note

When you create your own HTTP client, you are also responsible for implementing the correct connection management strategies for these clients. -Doing so improperly can result in resource management issues.

Prev   
12. Retrying Failed Requests Home 
\ No newline at end of file +Doing so improperly can result in resource management issues.

Prev   
10. Retrying Failed Requests Home 
\ No newline at end of file diff --git a/multi/multi__polyglot_support_with_sidecar.html b/multi/multi__polyglot_support_with_sidecar.html index 05c1a60ad..c9b3d4434 100644 --- a/multi/multi__polyglot_support_with_sidecar.html +++ b/multi/multi__polyglot_support_with_sidecar.html @@ -1,6 +1,6 @@ - 9. Polyglot support with Sidecar
9. Polyglot support with Sidecar
Prev   Next

9. Polyglot support with Sidecar

Do you have non-JVM languages with which you want to take advantage of Eureka, Ribbon, and Config Server? + 9. Polyglot support with Sidecar

9. Polyglot support with Sidecar
Prev   Next

9. Polyglot support with Sidecar

Do you have non-JVM languages with which you want to take advantage of Eureka, Ribbon, and Config Server? The Spring Cloud Netflix Sidecar was inspired by Netflix Prana. It includes an HTTP API to get all of the instances (by host and port) for a given service. You can also proxy service calls through an embedded Zuul proxy that gets its route entries from Eureka. @@ -55,4 +55,4 @@ might result in a YAML document resembling the following:

  password: password
 info:
   description: Spring Cloud Samples
-  url: https://github.com/spring-cloud-samples
Prev   Next
8. Router and Filter: Zuul Home 10. Metrics: Spectator, Servo, and Atlas
\ No newline at end of file + url: https://github.com/spring-cloud-samples
Prev   Next
8. Router and Filter: Zuul Home 10. Retrying Failed Requests
\ No newline at end of file diff --git a/multi/multi_retrying-failed-requests.html b/multi/multi_retrying-failed-requests.html index 58e6d4d5e..bc5ac927d 100644 --- a/multi/multi_retrying-failed-requests.html +++ b/multi/multi_retrying-failed-requests.html @@ -1,11 +1,11 @@ - 12. Retrying Failed Requests
12. Retrying Failed Requests
Prev   Next

12. Retrying Failed Requests

Spring Cloud Netflix offers a variety of ways to make HTTP requests. + 10. Retrying Failed Requests

10. Retrying Failed Requests
Prev   Next

10. Retrying Failed Requests

Spring Cloud Netflix offers a variety of ways to make HTTP requests. You can use a load balanced RestTemplate, Ribbon, or Feign. No matter how you choose to create your HTTP requests, there is always a chance that a request may fail. When a request fails, you may want to have the request be retried automatically. To do so when using Sping Cloud Netflix, you need to include Spring Retry on your application’s classpath. -When Spring Retry is present, load-balanced RestTemplates, Feign, and Zuul automatically retry any failed requests (assuming your configuration allows doing so).

12.1 BackOff Policies

By default, no backoff policy is used when retrying requests. +When Spring Retry is present, load-balanced RestTemplates, Feign, and Zuul automatically retry any failed requests (assuming your configuration allows doing so).

10.1 BackOff Policies

By default, no backoff policy is used when retrying requests. If you would like to configure a backoff policy, you need to create a bean of type LoadBalancedBackOffPolicyFactory, which is used to create a BackOffPolicy for a given service, as shown in the following example:

@Configuration
 public class MyConfiguration {
     @Bean
@@ -17,11 +17,11 @@ If you would like to configure a backoff policy, you need to create a bean of ty
             }
         };
     }
-}

12.2 Configuration

When you use Ribbon with Spring Retry, you can control the retry functionality by configuring certain Ribbon properties. +}

10.2 Configuration

When you use Ribbon with Spring Retry, you can control the retry functionality by configuring certain Ribbon properties. To do so, set the client.ribbon.MaxAutoRetries, client.ribbon.MaxAutoRetriesNextServer, and client.ribbon.OkToRetryOnAllOperations properties. See the Ribbon documentation for a description of what these properties do.

[Warning]Warning

Enabling client.ribbon.OkToRetryOnAllOperations includes retrying POST requests, which can have an impact on the server’s resources, due to the buffering of the request body.

In addition, you may want to retry requests when certain status codes are returned in the response. You can list the response codes you would like the Ribbon client to retry by setting the clientName.ribbon.retryableStatusCodes property, as shown in the following example:

clientName:
   ribbon:
-    retryableStatusCodes: 404,502

You can also create a bean of type LoadBalancedRetryPolicy and implement the retryableStatusCode method to retry a request given the status code.

12.2.1 Zuul

You can turn off Zuul’s retry functionality by setting zuul.retryable to false. -You can also disable retry functionality on a route-by-route basis by setting zuul.routes.routename.retryable to false.

Prev   Next
11. Metrics Backend: Atlas Home 13. HTTP Clients
\ No newline at end of file + retryableStatusCodes: 404,502

You can also create a bean of type LoadBalancedRetryPolicy and implement the retryableStatusCode method to retry a request given the status code.

10.2.1 Zuul

You can turn off Zuul’s retry functionality by setting zuul.retryable to false. +You can also disable retry functionality on a route-by-route basis by setting zuul.routes.routename.retryable to false.

Prev   Next
9. Polyglot support with Sidecar Home 11. HTTP Clients
\ No newline at end of file diff --git a/multi/multi_spring-cloud-netflix.html b/multi/multi_spring-cloud-netflix.html index e9d7a4e10..5dd76ee92 100644 --- a/multi/multi_spring-cloud-netflix.html +++ b/multi/multi_spring-cloud-netflix.html @@ -1,3 +1,3 @@ - Spring Cloud Netflix
Spring Cloud Netflix
   Next

Spring Cloud Netflix

Table of Contents

1. Service Discovery: Eureka Clients
1.1. How to Include Eureka Client
1.2. Registering with Eureka
1.3. Authenticating with the Eureka Server
1.4. Status Page and Health Indicator
1.5. Registering a Secure Application
1.6. Eureka’s Health Checks
1.7. Eureka Metadata for Instances and Clients
1.7.1. Using Eureka on Cloud Foundry
1.7.2. Using Eureka on AWS
1.7.3. Changing the Eureka Instance ID
1.8. Using the EurekaClient
1.8.1. EurekaClient without Jersey
1.9. Alternatives to the Native Netflix EurekaClient
1.10. Why Is It so Slow to Register a Service?
1.11. Zones
2. Service Discovery: Eureka Server
2.1. How to Include Eureka Server
2.2. How to Run a Eureka Server
2.3. High Availability, Zones and Regions
2.4. Standalone Mode
2.5. Peer Awareness
2.6. When to Prefer IP Address
2.7. Securing The Eureka Server
3. Circuit Breaker: Hystrix Clients
3.1. How to Include Hystrix
3.2. Propagating the Security Context or Using Spring Scopes
3.3. Health Indicator
3.4. Hystrix Metrics Stream
4. Circuit Breaker: Hystrix Dashboard
5. Hystrix Timeouts And Ribbon Clients
5.1. How to Include the Hystrix Dashboard
5.2. Turbine
5.2.1. Clusters Endpoint
5.3. Turbine Stream
6. Client Side Load Balancer: Ribbon
6.1. How to Include Ribbon
6.2. Customizing the Ribbon Client
6.3. Customizing the Default for All Ribbon Clients
6.4. Customizing the Ribbon Client by Setting Properties
6.5. Using Ribbon with Eureka
6.6. Example: How to Use Ribbon Without Eureka
6.7. Example: Disable Eureka Use in Ribbon
6.8. Using the Ribbon API Directly
6.9. Caching of Ribbon Configuration
6.10. How to Configure Hystrix Thread Pools
6.11. How to Provide a Key to Ribbon’s IRule
7. External Configuration: Archaius
8. Router and Filter: Zuul
8.1. How to Include Zuul
8.2. Embedded Zuul Reverse Proxy
8.3. Zuul Http Client
8.4. Cookies and Sensitive Headers
8.5. Ignored Headers
8.6. Management Endpoints
8.6.1. Routes Endpoint
8.6.2. Filters Endpoint
8.7. Strangulation Patterns and Local Forwards
8.8. Uploading Files through Zuul
8.9. Query String Encoding
8.10. Plain Embedded Zuul
8.11. Disable Zuul Filters
8.12. Providing Hystrix Fallbacks For Routes
8.13. Zuul Timeouts
8.14. Rewriting the Location header
8.15. Metrics
8.16. Zuul Developer Guide
8.16.1. The Zuul Servlet
8.16.2. Zuul RequestContext
8.16.3. @EnableZuulProxy vs. @EnableZuulServer
8.16.4. @EnableZuulServer Filters
8.16.5. @EnableZuulProxy Filters
8.16.6. Custom Zuul Filter Examples
How to Write a Pre Filter
How to Write a Route Filter
How to Write a Post Filter
8.16.7. How Zuul Errors Work
8.16.8. Zuul Eager Application Context Loading
9. Polyglot support with Sidecar
10. Metrics: Spectator, Servo, and Atlas
10.1. Dimensional Versus Hierarchical Metrics
10.2. Default Metrics Collection
10.3. Metrics Collection: Spectator
10.3.1. Spectator Counter
10.3.2. Spectator Timer
10.3.3. Spectator Gauge
10.3.4. Spectator Distribution Summaries
10.4. Metrics Collection: Servo
10.4.1. Creating Servo Monitors
11. Metrics Backend: Atlas
11.1. Global Tags
11.1.1. Using Atlas
12. Retrying Failed Requests
12.1. BackOff Policies
12.2. Configuration
12.2.1. Zuul
13. HTTP Clients
   Next
   
\ No newline at end of file + Spring Cloud Netflix
Spring Cloud Netflix
   Next

Spring Cloud Netflix

Table of Contents

1. Service Discovery: Eureka Clients
1.1. How to Include Eureka Client
1.2. Registering with Eureka
1.3. Authenticating with the Eureka Server
1.4. Status Page and Health Indicator
1.5. Registering a Secure Application
1.6. Eureka’s Health Checks
1.7. Eureka Metadata for Instances and Clients
1.7.1. Using Eureka on Cloud Foundry
1.7.2. Using Eureka on AWS
1.7.3. Changing the Eureka Instance ID
1.8. Using the EurekaClient
1.8.1. EurekaClient without Jersey
1.9. Alternatives to the Native Netflix EurekaClient
1.10. Why Is It so Slow to Register a Service?
1.11. Zones
2. Service Discovery: Eureka Server
2.1. How to Include Eureka Server
2.2. How to Run a Eureka Server
2.3. High Availability, Zones and Regions
2.4. Standalone Mode
2.5. Peer Awareness
2.6. When to Prefer IP Address
2.7. Securing The Eureka Server
3. Circuit Breaker: Hystrix Clients
3.1. How to Include Hystrix
3.2. Propagating the Security Context or Using Spring Scopes
3.3. Health Indicator
3.4. Hystrix Metrics Stream
4. Circuit Breaker: Hystrix Dashboard
5. Hystrix Timeouts And Ribbon Clients
5.1. How to Include the Hystrix Dashboard
5.2. Turbine
5.2.1. Clusters Endpoint
5.3. Turbine Stream
6. Client Side Load Balancer: Ribbon
6.1. How to Include Ribbon
6.2. Customizing the Ribbon Client
6.3. Customizing the Default for All Ribbon Clients
6.4. Customizing the Ribbon Client by Setting Properties
6.5. Using Ribbon with Eureka
6.6. Example: How to Use Ribbon Without Eureka
6.7. Example: Disable Eureka Use in Ribbon
6.8. Using the Ribbon API Directly
6.9. Caching of Ribbon Configuration
6.10. How to Configure Hystrix Thread Pools
6.11. How to Provide a Key to Ribbon’s IRule
7. External Configuration: Archaius
8. Router and Filter: Zuul
8.1. How to Include Zuul
8.2. Embedded Zuul Reverse Proxy
8.3. Zuul Http Client
8.4. Cookies and Sensitive Headers
8.5. Ignored Headers
8.6. Management Endpoints
8.6.1. Routes Endpoint
8.6.2. Filters Endpoint
8.7. Strangulation Patterns and Local Forwards
8.8. Uploading Files through Zuul
8.9. Query String Encoding
8.10. Plain Embedded Zuul
8.11. Disable Zuul Filters
8.12. Providing Hystrix Fallbacks For Routes
8.13. Zuul Timeouts
8.14. Rewriting the Location header
8.15. Metrics
8.16. Zuul Developer Guide
8.16.1. The Zuul Servlet
8.16.2. Zuul RequestContext
8.16.3. @EnableZuulProxy vs. @EnableZuulServer
8.16.4. @EnableZuulServer Filters
8.16.5. @EnableZuulProxy Filters
8.16.6. Custom Zuul Filter Examples
How to Write a Pre Filter
How to Write a Route Filter
How to Write a Post Filter
8.16.7. How Zuul Errors Work
8.16.8. Zuul Eager Application Context Loading
9. Polyglot support with Sidecar
10. Retrying Failed Requests
10.1. BackOff Policies
10.2. Configuration
10.2.1. Zuul
11. HTTP Clients
   Next
   
\ No newline at end of file diff --git a/single/spring-cloud-netflix.html b/single/spring-cloud-netflix.html index b7af00d1d..4b3d47cf9 100644 --- a/single/spring-cloud-netflix.html +++ b/single/spring-cloud-netflix.html @@ -1,6 +1,6 @@ - Spring Cloud Netflix

Spring Cloud Netflix

Table of Contents

1. Service Discovery: Eureka Clients
1.1. How to Include Eureka Client
1.2. Registering with Eureka
1.3. Authenticating with the Eureka Server
1.4. Status Page and Health Indicator
1.5. Registering a Secure Application
1.6. Eureka’s Health Checks
1.7. Eureka Metadata for Instances and Clients
1.7.1. Using Eureka on Cloud Foundry
1.7.2. Using Eureka on AWS
1.7.3. Changing the Eureka Instance ID
1.8. Using the EurekaClient
1.8.1. EurekaClient without Jersey
1.9. Alternatives to the Native Netflix EurekaClient
1.10. Why Is It so Slow to Register a Service?
1.11. Zones
2. Service Discovery: Eureka Server
2.1. How to Include Eureka Server
2.2. How to Run a Eureka Server
2.3. High Availability, Zones and Regions
2.4. Standalone Mode
2.5. Peer Awareness
2.6. When to Prefer IP Address
2.7. Securing The Eureka Server
3. Circuit Breaker: Hystrix Clients
3.1. How to Include Hystrix
3.2. Propagating the Security Context or Using Spring Scopes
3.3. Health Indicator
3.4. Hystrix Metrics Stream
4. Circuit Breaker: Hystrix Dashboard
5. Hystrix Timeouts And Ribbon Clients
5.1. How to Include the Hystrix Dashboard
5.2. Turbine
5.2.1. Clusters Endpoint
5.3. Turbine Stream
6. Client Side Load Balancer: Ribbon
6.1. How to Include Ribbon
6.2. Customizing the Ribbon Client
6.3. Customizing the Default for All Ribbon Clients
6.4. Customizing the Ribbon Client by Setting Properties
6.5. Using Ribbon with Eureka
6.6. Example: How to Use Ribbon Without Eureka
6.7. Example: Disable Eureka Use in Ribbon
6.8. Using the Ribbon API Directly
6.9. Caching of Ribbon Configuration
6.10. How to Configure Hystrix Thread Pools
6.11. How to Provide a Key to Ribbon’s IRule
7. External Configuration: Archaius
8. Router and Filter: Zuul
8.1. How to Include Zuul
8.2. Embedded Zuul Reverse Proxy
8.3. Zuul Http Client
8.4. Cookies and Sensitive Headers
8.5. Ignored Headers
8.6. Management Endpoints
8.6.1. Routes Endpoint
8.6.2. Filters Endpoint
8.7. Strangulation Patterns and Local Forwards
8.8. Uploading Files through Zuul
8.9. Query String Encoding
8.10. Plain Embedded Zuul
8.11. Disable Zuul Filters
8.12. Providing Hystrix Fallbacks For Routes
8.13. Zuul Timeouts
8.14. Rewriting the Location header
8.15. Metrics
8.16. Zuul Developer Guide
8.16.1. The Zuul Servlet
8.16.2. Zuul RequestContext
8.16.3. @EnableZuulProxy vs. @EnableZuulServer
8.16.4. @EnableZuulServer Filters
8.16.5. @EnableZuulProxy Filters
8.16.6. Custom Zuul Filter Examples
How to Write a Pre Filter
How to Write a Route Filter
How to Write a Post Filter
8.16.7. How Zuul Errors Work
8.16.8. Zuul Eager Application Context Loading
9. Polyglot support with Sidecar
10. Metrics: Spectator, Servo, and Atlas
10.1. Dimensional Versus Hierarchical Metrics
10.2. Default Metrics Collection
10.3. Metrics Collection: Spectator
10.3.1. Spectator Counter
10.3.2. Spectator Timer
10.3.3. Spectator Gauge
10.3.4. Spectator Distribution Summaries
10.4. Metrics Collection: Servo
10.4.1. Creating Servo Monitors
11. Metrics Backend: Atlas
11.1. Global Tags
11.1.1. Using Atlas
12. Retrying Failed Requests
12.1. BackOff Policies
12.2. Configuration
12.2.1. Zuul
13. HTTP Clients

2.0.0.BUILD-SNAPSHOT

This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration + Spring Cloud Netflix

Spring Cloud Netflix

Table of Contents

1. Service Discovery: Eureka Clients
1.1. How to Include Eureka Client
1.2. Registering with Eureka
1.3. Authenticating with the Eureka Server
1.4. Status Page and Health Indicator
1.5. Registering a Secure Application
1.6. Eureka’s Health Checks
1.7. Eureka Metadata for Instances and Clients
1.7.1. Using Eureka on Cloud Foundry
1.7.2. Using Eureka on AWS
1.7.3. Changing the Eureka Instance ID
1.8. Using the EurekaClient
1.8.1. EurekaClient without Jersey
1.9. Alternatives to the Native Netflix EurekaClient
1.10. Why Is It so Slow to Register a Service?
1.11. Zones
2. Service Discovery: Eureka Server
2.1. How to Include Eureka Server
2.2. How to Run a Eureka Server
2.3. High Availability, Zones and Regions
2.4. Standalone Mode
2.5. Peer Awareness
2.6. When to Prefer IP Address
2.7. Securing The Eureka Server
3. Circuit Breaker: Hystrix Clients
3.1. How to Include Hystrix
3.2. Propagating the Security Context or Using Spring Scopes
3.3. Health Indicator
3.4. Hystrix Metrics Stream
4. Circuit Breaker: Hystrix Dashboard
5. Hystrix Timeouts And Ribbon Clients
5.1. How to Include the Hystrix Dashboard
5.2. Turbine
5.2.1. Clusters Endpoint
5.3. Turbine Stream
6. Client Side Load Balancer: Ribbon
6.1. How to Include Ribbon
6.2. Customizing the Ribbon Client
6.3. Customizing the Default for All Ribbon Clients
6.4. Customizing the Ribbon Client by Setting Properties
6.5. Using Ribbon with Eureka
6.6. Example: How to Use Ribbon Without Eureka
6.7. Example: Disable Eureka Use in Ribbon
6.8. Using the Ribbon API Directly
6.9. Caching of Ribbon Configuration
6.10. How to Configure Hystrix Thread Pools
6.11. How to Provide a Key to Ribbon’s IRule
7. External Configuration: Archaius
8. Router and Filter: Zuul
8.1. How to Include Zuul
8.2. Embedded Zuul Reverse Proxy
8.3. Zuul Http Client
8.4. Cookies and Sensitive Headers
8.5. Ignored Headers
8.6. Management Endpoints
8.6.1. Routes Endpoint
8.6.2. Filters Endpoint
8.7. Strangulation Patterns and Local Forwards
8.8. Uploading Files through Zuul
8.9. Query String Encoding
8.10. Plain Embedded Zuul
8.11. Disable Zuul Filters
8.12. Providing Hystrix Fallbacks For Routes
8.13. Zuul Timeouts
8.14. Rewriting the Location header
8.15. Metrics
8.16. Zuul Developer Guide
8.16.1. The Zuul Servlet
8.16.2. Zuul RequestContext
8.16.3. @EnableZuulProxy vs. @EnableZuulServer
8.16.4. @EnableZuulServer Filters
8.16.5. @EnableZuulProxy Filters
8.16.6. Custom Zuul Filter Examples
How to Write a Pre Filter
How to Write a Route Filter
How to Write a Post Filter
8.16.7. How Zuul Errors Work
8.16.8. Zuul Eager Application Context Loading
9. Polyglot support with Sidecar
10. Retrying Failed Requests
10.1. BackOff Policies
10.2. Configuration
10.2.1. Zuul
11. HTTP Clients

2.0.0.BUILD-SNAPSHOT

This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration and binding to the Spring Environment and other Spring programming model idioms. With a few simple annotations you can quickly enable and configure the common patterns inside your application and build large distributed systems with battle-tested Netflix components. The @@ -1005,109 +1005,12 @@ might result in a YAML document resembling the following:

  password: password
 info:
   description: Spring Cloud Samples
-  url: https://github.com/spring-cloud-samples

10. Metrics: Spectator, Servo, and Atlas

When used together, Spectator (or Servo) and Atlas provide a near real-time operational insight platform. -Spectator and Servo are Netflix’s metrics collection libraries. -Atlas is a Netflix metrics backend that manages dimensional time-series data.

Servo served Netflix for several years and is still usable but is gradually being phased out in favor of Spectator, which is designed to work only with Java 8. -Spring Cloud Netflix provides support for both, but Java 8-based applications are encouraged to use Spectator.

10.1 Dimensional Versus Hierarchical Metrics

Spring Boot Actuator metrics are hierarchical, and the metrics are separated only by name. -These names often follow a naming convention that embeds key/value attribute pairs (dimensions) into the name (separated by periods). -Consider the following metrics for two endpoints, root and star-star:

{
-    "counter.status.200.root": 20,
-    "counter.status.400.root": 3,
-    "counter.status.200.star-star": 5,
-}

The first metric gives us a normalized count of successful requests against the root endpoint per unit of time. -But what if the system has 20 endpoints and you want to get a count of successful requests against all the endpoints? -Some hierarchical metrics backends would let you specify a wildcard, such as counter.status.200.*, that would read all 20 metrics and aggregate the results. -Alternatively, you could provide a HandlerInterceptorAdapter that intercepts and records a metric such as counter.status.200.all for all successful requests irrespective of the endpoint, but now you must write 20+1 different metrics. -Similarly, if you want to know the total number of successful requests for all endpoints in the service, you could specify a wildcard such as counter.status.2*.*.

Even in the presence of wildcarding support on a hierarchical metrics backend, naming consistency can be difficult. -Specifically, the position of these tags in the name string can slip with time, breaking queries. -For example, suppose we add an additional dimension to the earlier hierarchical metrics for an HTTP method. -Then counter.status.200.root becomes counter.status.200.method.get.root (or post and so on). -Suddenly, Our counter.status.200.* no longer has the same semantic meaning. -Furthermore, if the new dimension is not applied uniformly across the codebase, certain queries may become impossible. -This can quickly get out of hand.

Netflix metrics are tagged (in other words, they are dimensional). -Each metric has a name, but this single named metric can contain multiple statistics and 'tag' key/value pairs, which allows more querying flexibility. -In fact, the statistics themselves are recorded in a special tag.

When recorded with Netflix Servo or Spectator, a timer for the root endpoint described earlier contains four statistics for each status code, where the count statistic is identical to Spring Boot Actuator’s counter. -When we have encountered an HTTP 200 and 400 with the preceding examples, there are eight available data points, as shown in the following example:

{
-    "root(status=200,stastic=count)": 20,
-    "root(status=200,stastic=max)": 0.7265630630000001,
-    "root(status=200,stastic=totalOfSquares)": 0.04759702862580789,
-    "root(status=200,stastic=totalTime)": 0.2093076914666667,
-    "root(status=400,stastic=count)": 1,
-    "root(status=400,stastic=max)": 0,
-    "root(status=400,stastic=totalOfSquares)": 0,
-    "root(status=400,stastic=totalTime)": 0,
-}

10.2 Default Metrics Collection

Without any additional dependencies or configuration, a Spring Cloud based service autoconfigures a Servo MonitorRegistry and begins collecting metrics on every Spring MVC request. -By default, a Servo timer with a name of rest is recorded for each MVC request, which is tagged with the following information:

  • HTTP method (GET, POST, and so on).
  • HTTP status (200, 400, 500, and so on).
  • URI (or root if the URI is empty), sanitized for Atlas.
  • The exception class name, if the request handler threw an exception.
  • The caller, if a request header with a key matching netflix.metrics.rest.callerHeader is set on the request. -There is no default key for netflix.metrics.rest.callerHeader. -You must add it to your application properties if you wish to collect caller information.

Set the netflix.metrics.rest.metricName property to change the name of the metric from rest to the name you provide.

If Spring AOP is enabled and org.aspectj:aspectjweaver is present on your runtime classpath, Spring Cloud also collects metrics on every client call made with RestTemplate. -A Servo timer with a name of restclient is recorded for each MVC request, which is tagged with the following information:

  • HTTP method ('GET', 'POST', and so on).
  • HTTP status (200, 400, 500, and so on) and possibly CLIENT_ERROR if the response returned null or IO_ERROR if an IOException occurred during the execution of the RestTemplate method.
  • URI, sanitized for Atlas.
  • Client name.
[Warning]Warning

Avoid using hard-coded URL parameters within RestTemplate. -When targeting dynamic endpoints, use URL variables. -Doing so avoids potential “GC Overhead Limit Reached” issues where ServoMonitorCache treats each URL as a unique key. -The following example shows both the recommended and the problematic ways to set URL parameters:

// recommended
-String orderid = "1";
-restTemplate.getForObject("http://testeurekabrixtonclient/orders/{orderid}", String.class, orderid)
-
-// avoid
-restTemplate.getForObject("http://testeurekabrixtonclient/orders/1", String.class)

10.3 Metrics Collection: Spectator

To enable Spectator metrics, include a dependency on spring-boot-starter-spectator, as follows:

    <dependency>
-        <groupId>org.springframework.cloud</groupId>
-        <artifactId>spring-cloud-starter-netflix-spectator</artifactId>
-    </dependency>

In Spectator parlance, a meter is a named, typed, and tagged configuration, while a metric represents the value of a given meter at a point in time. -Spectator meters are created and controlled by a registry, which currently has several different implementations. -Spectator provides four meter types: counter, timer, gauge, and distribution summary.

Spring Cloud Spectator integration configures an injectable com.netflix.spectator.api.Registry instance for you. -Specifically, it configures a ServoRegistry instance in order to unify the collection of REST metrics and the exporting of metrics to the Atlas backend under a single Servo API. -Practically, this means that your code may use a mixture of Servo monitors and Spectator meters. -Spring Boot scoops up both Actuator MetricReader instances and ships them to the Atlas backend.

10.3.1 Spectator Counter

A counter measures the rate at which some event is occurring, as shown in the following example:

// create a counter with a name and a set of tags
-Counter counter = registry.counter("counterName", "tagKey1", "tagValue1", ...);
-counter.increment(); // increment when an event occurs
-counter.increment(10); // increment by a discrete amount

The counter records a single time-normalized statistic.

10.3.2 Spectator Timer

A timer measures how long some event takes. -Spring Cloud automatically records timers for Spring MVC requests and, conditionally, RestTemplate requests, which can later be used to create dashboards for request related metrics like latency, as shown in the following example:

Figure 10.1. Request Latency

RequestLatency

// create a timer with a name and a set of tags
-Timer timer = registry.timer("timerName", "tagKey1", "tagValue1", ...);
-
-// execute an operation and time it at the same time
-T result = timer.record(() -> fooReturnsT());
-
-// alternatively, if you must manually record the time
-Long start = System.nanoTime();
-T result = fooReturnsT();
-timer.record(System.nanoTime() - start, TimeUnit.NANOSECONDS);

The timer simultaneously records four statistics: count, max, totalOfSquares, and totalTime. -The count statistic always matches the single normalized value provided by a counter as though you had called increment() once on the counter for each time you recorded a timing, so it is rarely necessary to count and time separately for a single operation.

For long-running operations, Spectator provides a special LongTaskTimer.

10.3.3 Spectator Gauge

Gauges show some current value, such as the size of a queue or number of threads in a running state. -Since gauges are sampled, they provide no information about how these values fluctuate between samples.

The normal use of a gauge involves registering the gauge once on initialization with an ID, a reference to the object to be sampled, and a function to get or compute a numeric value based on the object. -The reference to the object is passed in separately, and the Spectator registry keeps a weak reference to the object. -If the object is garbage collected, Spectator automatically drops the registration. -See the note in Spectator’s documentation about potential memory leaks if this API is misused. -The following listing shows how to automatically and manually sample a gauge:

// the registry automatically samples this gauge periodically
-registry.gauge("gaugeName", pool, Pool::numberOfRunningThreads);
-
-// manually sample a value in code at periodic intervals -- last resort!
-registry.gauge("gaugeName", Arrays.asList("tagKey1", "tagValue1", ...), 1000);

10.3.4 Spectator Distribution Summaries

A distribution summary tracks the distribution of events. -It is similar to a timer but more general in that the size does not have to be a period of time. -For example, a distribution summary could be used to measure the payload sizes of requests hitting a server. -The following example defines a distribution summary:

// the registry automatically samples this gauge periodically
-DistributionSummary ds = registry.distributionSummary("dsName", "tagKey1", "tagValue1", ...);
-ds.record(request.sizeInBytes());

10.4 Metrics Collection: Servo

[Note]Note

If your code is compiled on Java 8, use Spectator instead of Servo, as Spectator is destined to replace Servo entirely.

In Servo parlance, a monitor is a named, typed, and tagged configuration, and a metric represents the value of a given monitor at a point in time. -Servo monitors are logically equivalent to Spectator meters. -Servo monitors are created and controlled by a MonitorRegistry. -While it is still available, Servo has a wider array of monitor options than Spectator has meters.

Spring Cloud integration configures an injectable com.netflix.servo.MonitorRegistry instance for you. -Once you have created the appropriate Monitor type in Servo, the process of recording data is similar to that of Spectator.

10.4.1 Creating Servo Monitors

If you use the Servo MonitorRegistry instance provided by Spring Cloud (specifically, an instance of DefaultMonitorRegistry), Servo provides convenience classes for retrieving counters and timers. -These convenience classes ensure that only one Monitor is registered for each unique combination of name and tags.

To manually create a Monitor type in Servo, especially for the more exotic monitor types for which convenience methods are not provided, instantiate the appropriate type by providing a MonitorConfig instance, as shown in the following example:

MonitorConfig config = MonitorConfig.builder("timerName").withTag("tagKey1", "tagValue1").build();
-
-// somewhere we should cache this Monitor by MonitorConfig
-Timer timer = new BasicTimer(config);
-monitorRegistry.register(timer);

11. Metrics Backend: Atlas

Atlas was developed by Netflix to manage dimensional time-series data for near real-time operational insight. -Atlas features in-memory data storage, letting it gather and report large numbers of metrics quickly.

Atlas captures operational intelligence. -Whereas business intelligence is data gathered for analyzing trends over time, operational intelligence provides a picture of what is currently happening within a system.

Spring Cloud provides a spring-cloud-starter-netflix-atlas that has all the dependencies you need. -Then you can annotate your Spring Boot application with @EnableAtlas and provide a location for your running Atlas server by setting the netflix.atlas.uri property.

11.1 Global Tags

Spring Cloud lets you add tags to every metric sent to the Atlas backend. -Global tags can be used to separate metrics by application name, environment, region, and so on.

Each bean implementing AtlasTagProvider contributes to the global tag list, as shown in the following example:

@Bean
-AtlasTagProvider atlasCommonTags(
-    @Value("${spring.application.name}") String appName) {
-  return () -> Collections.singletonMap("app", appName);
-}

11.1.1 Using Atlas

To bootstrap an in-memory standalone Atlas instance, use the following commands:

$ curl -LO https://github.com/Netflix/atlas/releases/download/v1.4.2/atlas-1.4.2-standalone.jar
-$ java -jar atlas-1.4.2-standalone.jar
[Tip]Tip

An Atlas standalone node running on an r3.2xlarge (61GB RAM) can handle roughly 2 million metrics per minute for a given six-hour window.

Once the application is running and you have collected a handful of metrics, you can verify that your setup is correct by listing tags on the Atlas server, as shown in the following example:

$ curl http://ATLAS/api/v1/tags
[Tip]Tip

After running several requests against your service, you can gather some basic information on the request latency of every request by pasting the following URL in your browser: http://ATLAS/api/v1/graph?q=name,rest,:eq,:avg

The Atlas wiki contains a compilation of sample queries for various scenarios.

See the alerting philosophy and docs on using double exponential smoothing to generate dynamic alert thresholds.

12. Retrying Failed Requests

Spring Cloud Netflix offers a variety of ways to make HTTP requests. + url: https://github.com/spring-cloud-samples

10. Retrying Failed Requests

Spring Cloud Netflix offers a variety of ways to make HTTP requests. You can use a load balanced RestTemplate, Ribbon, or Feign. No matter how you choose to create your HTTP requests, there is always a chance that a request may fail. When a request fails, you may want to have the request be retried automatically. To do so when using Sping Cloud Netflix, you need to include Spring Retry on your application’s classpath. -When Spring Retry is present, load-balanced RestTemplates, Feign, and Zuul automatically retry any failed requests (assuming your configuration allows doing so).

12.1 BackOff Policies

By default, no backoff policy is used when retrying requests. +When Spring Retry is present, load-balanced RestTemplates, Feign, and Zuul automatically retry any failed requests (assuming your configuration allows doing so).

10.1 BackOff Policies

By default, no backoff policy is used when retrying requests. If you would like to configure a backoff policy, you need to create a bean of type LoadBalancedBackOffPolicyFactory, which is used to create a BackOffPolicy for a given service, as shown in the following example:

@Configuration
 public class MyConfiguration {
     @Bean
@@ -1119,14 +1022,14 @@ If you would like to configure a backoff policy, you need to create a bean of ty
             }
         };
     }
-}

12.2 Configuration

When you use Ribbon with Spring Retry, you can control the retry functionality by configuring certain Ribbon properties. +}

10.2 Configuration

When you use Ribbon with Spring Retry, you can control the retry functionality by configuring certain Ribbon properties. To do so, set the client.ribbon.MaxAutoRetries, client.ribbon.MaxAutoRetriesNextServer, and client.ribbon.OkToRetryOnAllOperations properties. See the Ribbon documentation for a description of what these properties do.

[Warning]Warning

Enabling client.ribbon.OkToRetryOnAllOperations includes retrying POST requests, which can have an impact on the server’s resources, due to the buffering of the request body.

In addition, you may want to retry requests when certain status codes are returned in the response. You can list the response codes you would like the Ribbon client to retry by setting the clientName.ribbon.retryableStatusCodes property, as shown in the following example:

clientName:
   ribbon:
-    retryableStatusCodes: 404,502

You can also create a bean of type LoadBalancedRetryPolicy and implement the retryableStatusCode method to retry a request given the status code.

12.2.1 Zuul

You can turn off Zuul’s retry functionality by setting zuul.retryable to false. -You can also disable retry functionality on a route-by-route basis by setting zuul.routes.routename.retryable to false.

13. HTTP Clients

Spring Cloud Netflix automatically creates the HTTP client used by Ribbon, Feign, and Zuul for you. + retryableStatusCodes: 404,502

You can also create a bean of type LoadBalancedRetryPolicy and implement the retryableStatusCode method to retry a request given the status code.

10.2.1 Zuul

You can turn off Zuul’s retry functionality by setting zuul.retryable to false. +You can also disable retry functionality on a route-by-route basis by setting zuul.routes.routename.retryable to false.

11. HTTP Clients

Spring Cloud Netflix automatically creates the HTTP client used by Ribbon, Feign, and Zuul for you. However, you can also provide your own HTTP clients customized as you need them to be. To do so, you can create a bean of type ClosableHttpClient if you are using the Apache Http Cient or OkHttpClient if you are using OK HTTP.

[Note]Note

When you create your own HTTP client, you are also responsible for implementing the correct connection management strategies for these clients. diff --git a/spring-cloud-netflix.xml b/spring-cloud-netflix.xml index e1165f1d2..4d1ad4538 100644 --- a/spring-cloud-netflix.xml +++ b/spring-cloud-netflix.xml @@ -1945,240 +1945,6 @@ info: description: Spring Cloud Samples url: https://github.com/spring-cloud-samples - -Metrics: Spectator, Servo, and Atlas -When used together, Spectator (or Servo) and Atlas provide a near real-time operational insight platform. -Spectator and Servo are Netflix’s metrics collection libraries. -Atlas is a Netflix metrics backend that manages dimensional time-series data. -Servo served Netflix for several years and is still usable but is gradually being phased out in favor of Spectator, which is designed to work only with Java 8. -Spring Cloud Netflix provides support for both, but Java 8-based applications are encouraged to use Spectator. -

-Dimensional Versus Hierarchical Metrics -Spring Boot Actuator metrics are hierarchical, and the metrics are separated only by name. -These names often follow a naming convention that embeds key/value attribute pairs (dimensions) into the name (separated by periods). -Consider the following metrics for two endpoints, root and star-star: -{ - "counter.status.200.root": 20, - "counter.status.400.root": 3, - "counter.status.200.star-star": 5, -} -The first metric gives us a normalized count of successful requests against the root endpoint per unit of time. -But what if the system has 20 endpoints and you want to get a count of successful requests against all the endpoints? -Some hierarchical metrics backends would let you specify a wildcard, such as counter.status.200.*, that would read all 20 metrics and aggregate the results. -Alternatively, you could provide a HandlerInterceptorAdapter that intercepts and records a metric such as counter.status.200.all for all successful requests irrespective of the endpoint, but now you must write 20+1 different metrics. -Similarly, if you want to know the total number of successful requests for all endpoints in the service, you could specify a wildcard such as counter.status.2*.*. -Even in the presence of wildcarding support on a hierarchical metrics backend, naming consistency can be difficult. -Specifically, the position of these tags in the name string can slip with time, breaking queries. -For example, suppose we add an additional dimension to the earlier hierarchical metrics for an HTTP method. -Then counter.status.200.root becomes counter.status.200.method.get.root (or post and so on). -Suddenly, Our counter.status.200.* no longer has the same semantic meaning. -Furthermore, if the new dimension is not applied uniformly across the codebase, certain queries may become impossible. -This can quickly get out of hand. -Netflix metrics are tagged (in other words, they are dimensional). -Each metric has a name, but this single named metric can contain multiple statistics and 'tag' key/value pairs, which allows more querying flexibility. -In fact, the statistics themselves are recorded in a special tag. -When recorded with Netflix Servo or Spectator, a timer for the root endpoint described earlier contains four statistics for each status code, where the count statistic is identical to Spring Boot Actuator’s counter. -When we have encountered an HTTP 200 and 400 with the preceding examples, there are eight available data points, as shown in the following example: -{ - "root(status=200,stastic=count)": 20, - "root(status=200,stastic=max)": 0.7265630630000001, - "root(status=200,stastic=totalOfSquares)": 0.04759702862580789, - "root(status=200,stastic=totalTime)": 0.2093076914666667, - "root(status=400,stastic=count)": 1, - "root(status=400,stastic=max)": 0, - "root(status=400,stastic=totalOfSquares)": 0, - "root(status=400,stastic=totalTime)": 0, -} -
-
-Default Metrics Collection -Without any additional dependencies or configuration, a Spring Cloud based service autoconfigures a Servo MonitorRegistry and begins collecting metrics on every Spring MVC request. -By default, a Servo timer with a name of rest is recorded for each MVC request, which is tagged with the following information: - - -HTTP method (GET, POST, and so on). - - -HTTP status (200, 400, 500, and so on). - - -URI (or root if the URI is empty), sanitized for Atlas. - - -The exception class name, if the request handler threw an exception. - - -The caller, if a request header with a key matching netflix.metrics.rest.callerHeader is set on the request. -There is no default key for netflix.metrics.rest.callerHeader. -You must add it to your application properties if you wish to collect caller information. - - -Set the netflix.metrics.rest.metricName property to change the name of the metric from rest to the name you provide. -If Spring AOP is enabled and org.aspectj:aspectjweaver is present on your runtime classpath, Spring Cloud also collects metrics on every client call made with RestTemplate. -A Servo timer with a name of restclient is recorded for each MVC request, which is tagged with the following information: - - -HTTP method ('GET', 'POST', and so on). - - -HTTP status (200, 400, 500, and so on) and possibly CLIENT_ERROR if the response returned null or IO_ERROR if an IOException occurred during the execution of the RestTemplate method. - - -URI, sanitized for Atlas. - - -Client name. - - - -Avoid using hard-coded URL parameters within RestTemplate. -When targeting dynamic endpoints, use URL variables. -Doing so avoids potential “GC Overhead Limit Reached” issues where ServoMonitorCache treats each URL as a unique key. -The following example shows both the recommended and the problematic ways to set URL parameters: - -// recommended -String orderid = "1"; -restTemplate.getForObject("http://testeurekabrixtonclient/orders/{orderid}", String.class, orderid) - -// avoid -restTemplate.getForObject("http://testeurekabrixtonclient/orders/1", String.class) -
-
-Metrics Collection: Spectator -To enable Spectator metrics, include a dependency on spring-boot-starter-spectator, as follows: - <dependency> - <groupId>org.springframework.cloud</groupId> - <artifactId>spring-cloud-starter-netflix-spectator</artifactId> - </dependency> -In Spectator parlance, a meter is a named, typed, and tagged configuration, while a metric represents the value of a given meter at a point in time. -Spectator meters are created and controlled by a registry, which currently has several different implementations. -Spectator provides four meter types: counter, timer, gauge, and distribution summary. -Spring Cloud Spectator integration configures an injectable com.netflix.spectator.api.Registry instance for you. -Specifically, it configures a ServoRegistry instance in order to unify the collection of REST metrics and the exporting of metrics to the Atlas backend under a single Servo API. -Practically, this means that your code may use a mixture of Servo monitors and Spectator meters. -Spring Boot scoops up both Actuator MetricReader instances and ships them to the Atlas backend. -
-Spectator Counter -A counter measures the rate at which some event is occurring, as shown in the following example: -// create a counter with a name and a set of tags -Counter counter = registry.counter("counterName", "tagKey1", "tagValue1", ...); -counter.increment(); // increment when an event occurs -counter.increment(10); // increment by a discrete amount -The counter records a single time-normalized statistic. -
-
-Spectator Timer -A timer measures how long some event takes. -Spring Cloud automatically records timers for Spring MVC requests and, conditionally, RestTemplate requests, which can later be used to create dashboards for request related metrics like latency, as shown in the following example: -
-Request Latency - - - - -RequestLatency - -
-// create a timer with a name and a set of tags -Timer timer = registry.timer("timerName", "tagKey1", "tagValue1", ...); - -// execute an operation and time it at the same time -T result = timer.record(() -> fooReturnsT()); - -// alternatively, if you must manually record the time -Long start = System.nanoTime(); -T result = fooReturnsT(); -timer.record(System.nanoTime() - start, TimeUnit.NANOSECONDS); -The timer simultaneously records four statistics: count, max, totalOfSquares, and totalTime. -The count statistic always matches the single normalized value provided by a counter as though you had called increment() once on the counter for each time you recorded a timing, so it is rarely necessary to count and time separately for a single operation. -For long-running operations, Spectator provides a special LongTaskTimer. -
-
-Spectator Gauge -Gauges show some current value, such as the size of a queue or number of threads in a running state. -Since gauges are sampled, they provide no information about how these values fluctuate between samples. -The normal use of a gauge involves registering the gauge once on initialization with an ID, a reference to the object to be sampled, and a function to get or compute a numeric value based on the object. -The reference to the object is passed in separately, and the Spectator registry keeps a weak reference to the object. -If the object is garbage collected, Spectator automatically drops the registration. -See the note in Spectator’s documentation about potential memory leaks if this API is misused. -The following listing shows how to automatically and manually sample a gauge: -// the registry automatically samples this gauge periodically -registry.gauge("gaugeName", pool, Pool::numberOfRunningThreads); - -// manually sample a value in code at periodic intervals -- last resort! -registry.gauge("gaugeName", Arrays.asList("tagKey1", "tagValue1", ...), 1000); -
-
-Spectator Distribution Summaries -A distribution summary tracks the distribution of events. -It is similar to a timer but more general in that the size does not have to be a period of time. -For example, a distribution summary could be used to measure the payload sizes of requests hitting a server. -The following example defines a distribution summary: -// the registry automatically samples this gauge periodically -DistributionSummary ds = registry.distributionSummary("dsName", "tagKey1", "tagValue1", ...); -ds.record(request.sizeInBytes()); -
-
-
-Metrics Collection: Servo - -If your code is compiled on Java 8, use Spectator instead of Servo, as Spectator is destined to replace Servo entirely. - -In Servo parlance, a monitor is a named, typed, and tagged configuration, and a metric represents the value of a given monitor at a point in time. -Servo monitors are logically equivalent to Spectator meters. -Servo monitors are created and controlled by a MonitorRegistry. -While it is still available, Servo has a wider array of monitor options than Spectator has meters. -Spring Cloud integration configures an injectable com.netflix.servo.MonitorRegistry instance for you. -Once you have created the appropriate Monitor type in Servo, the process of recording data is similar to that of Spectator. -
-Creating Servo Monitors -If you use the Servo MonitorRegistry instance provided by Spring Cloud (specifically, an instance of DefaultMonitorRegistry), Servo provides convenience classes for retrieving counters and timers. -These convenience classes ensure that only one Monitor is registered for each unique combination of name and tags. -To manually create a Monitor type in Servo, especially for the more exotic monitor types for which convenience methods are not provided, instantiate the appropriate type by providing a MonitorConfig instance, as shown in the following example: -MonitorConfig config = MonitorConfig.builder("timerName").withTag("tagKey1", "tagValue1").build(); - -// somewhere we should cache this Monitor by MonitorConfig -Timer timer = new BasicTimer(config); -monitorRegistry.register(timer); -
-
- - -Metrics Backend: Atlas -Atlas was developed by Netflix to manage dimensional time-series data for near real-time operational insight. -Atlas features in-memory data storage, letting it gather and report large numbers of metrics quickly. -Atlas captures operational intelligence. -Whereas business intelligence is data gathered for analyzing trends over time, operational intelligence provides a picture of what is currently happening within a system. -Spring Cloud provides a spring-cloud-starter-netflix-atlas that has all the dependencies you need. -Then you can annotate your Spring Boot application with @EnableAtlas and provide a location for your running Atlas server by setting the netflix.atlas.uri property. -
-Global Tags -Spring Cloud lets you add tags to every metric sent to the Atlas backend. -Global tags can be used to separate metrics by application name, environment, region, and so on. -Each bean implementing AtlasTagProvider contributes to the global tag list, as shown in the following example: -@Bean -AtlasTagProvider atlasCommonTags( - @Value("${spring.application.name}") String appName) { - return () -> Collections.singletonMap("app", appName); -} -
-Using Atlas -To bootstrap an in-memory standalone Atlas instance, use the following commands: -$ curl -LO https://github.com/Netflix/atlas/releases/download/v1.4.2/atlas-1.4.2-standalone.jar -$ java -jar atlas-1.4.2-standalone.jar - -An Atlas standalone node running on an r3.2xlarge (61GB RAM) can handle roughly 2 million metrics per minute for a given six-hour window. - -Once the application is running and you have collected a handful of metrics, you can verify that your setup is correct by listing tags on the Atlas server, as shown in the following example: -$ curl http://ATLAS/api/v1/tags - -After running several requests against your service, you can gather some basic information on the request latency of every request by pasting the following URL in your browser: http://ATLAS/api/v1/graph?q=name,rest,:eq,:avg - -The Atlas wiki contains a compilation of sample queries for various scenarios. -See the alerting philosophy and docs on using double exponential smoothing to generate dynamic alert thresholds. -
-
- Retrying Failed Requests Spring Cloud Netflix offers a variety of ways to make HTTP requests.