Updated documentation.

Author: RobWin

resilience4j-documentation/src/docs/asciidoc/addon_guides/micrometer.adoc

@@ -16,20 +16,11 @@ final Bulkhead foo = bulkheadRegistry.bulkhead("foo");
 final Bulkhead boo = bulkheadRegistry.bulkhead("boo");
 
 // Register all bulkheads at once
-BulkheadMetrics bulkheadMetrics = BulkheadMetrics.ofBulkheadRegistry(bulkheadRegistry);
-bulkheadMetrics.bindTo(meterRegistry);
-
-// Or for tag based metrics
 TaggedBulkheadMetrics.ofBulkheadRegistry(bulkheadRegistry).bindTo(meterRegistry);
 --
 
 For each bulkhead this registry will export:
 
-* `available_concurrent_calls` - instantaneous read of the number of currently available concurrent calls `[int]`
-* `max_allowed_concurrent_calls` - maximum number of allowed concurrent calls `[int]`
-
-Tag based metrics:
-
 * `resilience4j_bulkhead_available_concurrent_calls{name="name of bulkhead"}` - number of available concurrent calls
 * `resilience4j_bulkhead_max_allowed_concurrent_calls{name="name of bulkhead"}` - maximum number of allowed concurrent calls
 
@@ -42,24 +33,11 @@ final CircuitBreaker foo = circuitBreakerRegistry.circuitBreaker("foo");
 final CircuitBreaker boo = circuitBreakerRegistry.circuitBreaker("boo");
 
 // Register all circuit breakers at once
-CircuitBreakerMetrics circuitBreakerMetrics = CircuitBreakerMetrics.ofCircuitBreakerRegistry(circuitBreakerRegistry);
-circuitBreakerMetrics.bindTo(meterRegistry);
-
-// Or for tag based metrics
 TaggedCircuitBreakerMetrics.ofCircuitBreakerRegistry(circuitBreakerRegistry).bindTo(meterRegistry);
 --
 
 For each circuit breaker this registry will export:
 
-* `state` - instantaneous read of the current state where 0-CLOSED, 1-OPEN, 2-HALF-OPEN `[int]`
-* `successful` - current number of successful calls `[int]`
-* `failed` - current number of failed calls `[int]`
-* `buffered` - current number of buffered calls `[int]`
-* `buffered_max` - maximum number of buffered calls `[int]`
-* `not_permitted` - current number of not permitted calls `[int]`
-
-Tag based metrics:
-
 * `resilience4j_circuitbreaker_state{name="name of circuitbreaker"}` - the state of the circuit breaker where 0-CLOSED, 1-OPEN, 2-HALF-OPEN
 * `resilience4j_circuitbreaker_calls{name="name of circuitbreaker", kind="one of the values below"}` - the number of calls of a certain kind
   - `successful` - indicates successful calls
@@ -76,20 +54,11 @@ final RateLimiterRegistry rateLimiterRegistry = RateLimiterRegistry.ofDefaults()
 final RateLimiter rateLimiter = rateLimiterRegistry.rateLimiter("testLimit");
 
 // Register rate limiters at once
-RateLimiterMetrics rateLimiterMetrics = RateLimiterMetrics.ofRateLimiterRegistry(rateLimiterRegistry);
-rateLimiterMetrics.bindTo(meterRegistry);
-
-// Or for tag based metrics
 TaggedRateLimiterMetrics.ofRateLimiterRegistry(rateLimiterRegistry).bindTo(meterRegistry);
 --
 
 For each rate limiter this registry will export:
 
-* `available_permissions` - current number of available permissions `[int]`
-* `number_of_waiting_threads` - current number of threads waiting for permission `[int]`
-
-Tag based metrics:
-
 * `resilience4j_ratelimiter_available_permissions{name="name of ratelimiter"}` - the number of available permissions
 * `resilience4j_ratelimiter_waiting_threads{name="name of ratelimiter"}` - the number of threads waiting for permission
 
@@ -102,26 +71,15 @@ final RetryRegistry retryRegistry = RetryRegistry.ofDefaults();
 final Retry retry = retryRegistry.retry("testLimit");
 
 // Register all retries at once
-RetryMetrics retryMetrics = RetryMetrics.ofRetryRegistry(retryRegistry);
-retryMetrics.bindTo(meterRegistry);
-
-// Or for tag baed metrics
 TaggedRetryMetrics.ofRetryRegistry(retryRegistry).bindTo(meterRegistry);
 --
 
 For each retry this registry will export:
 
-* `successful_calls_without_retry` - the number of successful calls without a retry attempt `[long]`
-* `successful_calls_with_retry` - the number of successful calls after a retry attempt `[long]`
-* `failed_calls_without_retry` - the number of failed calls without a retry attempt `[long]`
-* `failed_calls_with_retry` - the number of failed calls after all retry attempts `[long]`
-
-Tag based metrics:
-
 * `resilience4j_retry_calls{name="retry name", kind="one of the values below"}` - the number of calls of a certain kind
-  - `successful_without_retry` - indicates successful calls without retry
-  - `successful_with_retry` - indicates successful calls with retry
-  - `failed_without_retry` - indicates failed calls without retry
-  - `failed_with_retry` - indicates failed calls with retry
+- `successful_without_retry` - indicates successful calls without retry
+- `successful_with_retry` - indicates successful calls with retry
+- `failed_without_retry` - indicates failed calls without retry
+- `failed_with_retry` - indicates failed calls with retry
 
 Note the same set of metrics is exposed for async retry, metric name is `resilience4j_async_retry_calls`.

resilience4j-documentation/src/docs/asciidoc/addon_guides/prometheus.adoc

@@ -4,56 +4,7 @@
 
 Integration with https://github.com/prometheus/client_java[Prometheus simple client]
 
-Module provides exporters for `CircuitBreaker`, `RateLimiter` and `Bulkhead` metrics.
-Every metric has `name` label indicating the relation to certain object, object category
-such as `bulkhead` is inlined to the metric name, so that the combination of metric name + `name` label
-uniquely identifies metric per backend. For example:
-
-```
-resilience4j_bulkhead_available_concurrent_calls{name="Backend1"}
-resilience4j_circuitbreaker_buffered_calls{name="Backend1"}
-resilience4j_ratelimiter_waiting_threads{name=Backend1"}
-```
-
-For every `CircuitBreaker` the library exports the following metrics:
-
-1. `resilience4j_circuitbreaker_state` - the state of the circuit breaker, possible values:
-
-    - 0 - CLOSED
-    - 1 - OPEN
-    - 2 - HALF_OPEN
-
-2. `resilience4j_circuitbreaker_calls` - the number of recorded calls,
-the additional `kind` label indicates type of calls being recorded, the possible
-`kind` values are `successful`, `failed` or `not_permitted`.
-
-3. `resilience4j_circuitbreaker_buffered_calls` - the number of buffered calls
-
-4. `resilience4j_circuitbreaker_max_buffered_calls` - the maximum number of buffered calls
-
-For every `RateLimiter` the library exports the following metrics:
-
-1. `resilience4j_ratelimiter_available_permissions` - the number of available permissions
-2. `resilience4j_ratelimiter_waiting_threads` - the number of waiting threads
-
-For every `Bulkhead` the library exports the following metrics:
-
-1. `resilience4j_bulkhead_available_concurrent_calls` - the number of available concurrent calls
-2. `resilience4j_bulkhead_max_allowed_concurrent_calls` - the maximum number of allowed concurrent calls
-
-
-This module also provides `CallMeter` -- a composite metric to measure single call/request metrics such as:
-    - execution time distribution,
-    - number of attempts and
-    - number of failures.
-
-It is implemented in Prometheus simple client's style, supports labels and produces histogram and counter metrics.
-
-Usage examples provided bellow in this section.
-
-==== Dashboard Example
-
-image::images/prometheus-dashboard.png[Circuit Breaker Dashboard Example]
+This add-on provides Prometheus collectors for `CircuitBreaker`, `RateLimiter` and `Bulkhead` metrics.
 
 ==== Usage
 
@@ -100,44 +51,4 @@ final Bulkhead boo = bulkheadRegistry.bulkhead("boo");
 
 // Registering metrics in prometeus CollectorRegistry
 collectorRegistry.register(BulkheadMetricsCollector.ofBulkheadRegistry(rateLimiterRegistry));
---
-
-Every collector exposes more methods for binding corresponding objects, for example,
-you can use suppliers, collections or even collect metrics for a single object.
-
-===== Call Meter
-
-Simple example without labels
-
-[source,java]
---
-final CollectorRegistry registry = new CollectorRegistry();
-
-final CallMeter meter = CallMeter.of("foo_call", "Foo call help", registry);
-
-CallMeter.decorateCompletionStageSupplier(meter, () -> supplyAsync(() -> { /* ... */ }));
---
-
-Advanced example with labels
-
-[source,java]
---
-final CollectorRegistry registry = new CollectorRegistry();
-
-final CallMeter meter = CallMeter
-        .builder()
-        .name("foo_call")
-        .help("Foo call help")
-        .labelNames("label_1")
-        .build()
-        .register(registry);
-
-meter.labels("boo").executeRunnable(() -> { /* ... */ });
-
-CallMeter.decorateCompletionStageSupplier(
-    meter.labels("baz"),
-    () -> supplyAsync(() -> { /* ... */ })
-);
-
---
-
+--

resilience4j-documentation/src/docs/asciidoc/addon_guides/springboot.adoc

@@ -2,7 +2,8 @@
 
 ==== Gradle
 
-Add the Spring Boot Starter of Resilience4j to your compile dependency:
+Add the Spring Boot Starter of Resilience4j to your compile dependency.
+You also need Spring Boot Actuator and Spring Boot AOP.
 
 [source,groovy, subs="attributes"]
 ----
@@ -14,40 +15,22 @@ repositories {
 
 dependencies {
 	compile('io.github.resilience4j:resilience4j-spring-boot:{release-version}')
+    compile('org.springframework.boot:spring-boot-starter-actuator')
+    compile('org.springframework.boot:spring-boot-starter-aop')
 }
 ----
 
 ==== Supported Types by Spring boot starter resilience aspects
 
-Rate limiter , Retry , Circuit breaker and Bulkhead now support Synchronous return types ,CompletableFutures , RxJava2 types and Reactor types .
+RateLimiter, Retry, CircuitBreaker and Bulkhead annotations support synchronous return types, asynchronous types like CompletableFutures and reactive types like RxJava2 and Reactor.
 
 ==== Monitoring
 
 Spring Boot Actuator health information can be used to check the status of your running application.
 It is often used by monitoring software to alert someone if a production system has serious issues.
 
-==== Retry
-When you enable retry, metrics are automatically published on the metrics endpoint.
-
-For example:
-
-[source,json]
-----
-{
-    "names": [
-        "resilience4j.retry.backendA.failedCallsWithoutRetry",
-        "resilience4j.retry.backendA.failedCallsWithRetry",
-        "resilience4j.retry.backendA.successCalls",
-        "resilience4j.retry.backendA.successCallsWithRetry"
-        ]
-}
-----
-
-When you want to publish Retry/AsyncRetry endpoints on the Prometheus endpoint, you have to add the dependency `io.micrometer:micrometer-registry-prometheus`.
-and you have same metrics exposed there , check circuit breaker below for more information about the example.
-
 ==== CircuitBreaker
-This demo publishes the status and metrics of all CircuitBreakers via a custom `CircuitBreakerHealthIndicator`.
+The starter publishes the status and metrics of all CircuitBreakers via a custom `CircuitBreakerHealthIndicator`.
 A closed CircuitBreaker state is mapped to UP, an open state to DOWN and a half-open state to UNKNOWN.
 
 For example:
@@ -123,8 +106,28 @@ resilience4j_circuitbreaker_states{name="backendA",state="open",} 0.0
 resilience4j_circuitbreaker_states{name="backendA",state="half_open",} 0.0
 ----
 
+==== Retry
+When you enable retry, metrics are automatically published on the metrics endpoint.
+
+For example:
+
+[source,json]
+----
+{
+    "names": [
+        "resilience4j.retry.backendA.failedCallsWithoutRetry",
+        "resilience4j.retry.backendA.failedCallsWithRetry",
+        "resilience4j.retry.backendA.successCalls",
+        "resilience4j.retry.backendA.successCallsWithRetry"
+        ]
+}
+----
+
+When you want to publish Retry/AsyncRetry endpoints on the Prometheus endpoint, you have to add the dependency `io.micrometer:micrometer-registry-prometheus`.
+and you have same metrics exposed there , check circuit breaker below for more information about the example.
+
 ==== RateLimiter
-This demo publishes the status and metrics of all RateLimiter via a custom `RateLimiterHealthIndicator`.
+The starter publishes the status and metrics of all RateLimiter via a custom `RateLimiterHealthIndicator`.
 RateLimiterHealthIndicator changes its state DOWN only if there is some permission waiting threads
 and they won't be able to unblock until timeout.