You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+15-14Lines changed: 15 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@
5
5
6
6
## Summary
7
7
8
-
This is a collection of support libraries for Java applications (Java 8 and above) running on Cloud Foundry that serves three main purposes: It provides (a) means to emit *structured application log messages*, (b) instrument parts of your application stack to *collect request metrics* and (c) java clients for producing*custom metrics*.
8
+
This is a collection of support libraries for Java applications (Java 8 and above) running on Cloud Foundry that serves three main purposes: It provides (a) means to emit *structured application log messages*, (b) instrument parts of your application stack to *collect request metrics* and (c) allow production of*custom metrics*.
9
9
10
10
When we say structured, we actually mean in JSON format. In that sense, it shares ideas with [logstash-logback-encoder](https://github.com/logstash/logstash-logback-encoder) (and a first internal version was actually based on it), but takes a simpler approach as we want to ensure that these structured messages adhere to standardized formats. With such standardized formats in place, it becomes much easier to ingest, process and search such messages in log analysis stacks such as [ELK](https://www.elastic.co/webinars/introduction-elk-stack).
11
11
@@ -15,7 +15,7 @@ While [logstash-logback-encoder](https://github.com/logstash/logstash-logback-en
15
15
16
16
The instrumentation part is currently focusing on providing [request filters for Java Servlets](http://www.oracle.com/technetwork/java/filters-137243.html) and [client and server filters for Jersey](https://jersey.java.net/documentation/latest/filters-and-interceptors.html), but again, we're open to contributions for other APIs and frameworks.
17
17
18
-
The custom metrics clients part allows users to easily define and push custom metrics. The clients configure all necessary components and make it possible to define custom metrics with minimal code change.
18
+
The custom metrics instrumentation allows users to easily define and emit custom metrics. The different modules configure all necessary components and make it possible to define custom metrics with minimal code change.
19
19
20
20
Lastly, there are also two sibling projects on [node.js logging support](https://github.com/SAP/cf-nodejs-logging-support) and [python logging support](https://github.com/SAP/cf-python-logging-support).
21
21
@@ -52,7 +52,7 @@ This feature only depends on the servlet API which you have included in your POM
52
52
53
53
If you want to use the `custom metrics`, just define the following dependency:
54
54
55
-
*`spring-boot client`:
55
+
*Spring Boot Support:
56
56
57
57
```xml
58
58
@@ -63,7 +63,7 @@ If you want to use the `custom metrics`, just define the following dependency:
63
63
</dependency>
64
64
```
65
65
66
-
*`java client`:
66
+
*Plain Java Support:
67
67
68
68
```xml
69
69
@@ -170,12 +170,12 @@ Here are the minimal configurations you'd need:
170
170
</Configuration>
171
171
```
172
172
173
-
## Custom metrics client usage
173
+
## Custom Metrics
174
174
175
-
With the custom metrics clients you can send metrics defined inside your code. If you choose not to use one of these clients, you can still directly push the metrics using the REST API. Once send the metrics can be consumed in Kibana.
176
-
To use the clients you'd need:
175
+
With the custom metrics feature you can send metrics defined inside your code. Metrics are emitted as log messages when your application is bound to a service called *application-logs*. This is done because of the
176
+
special format supported by the SAP BTP Application Logging Service and for compatibility with the prior apporach. To use the feature you'd need:
177
177
178
-
1.*Using spring-boot client in Spring Boot 2 application:*
178
+
1.*Instrumenting Spring Boot 2 applications:*
179
179
180
180
```xml
181
181
<dependency>
@@ -185,7 +185,7 @@ To use the clients you'd need:
185
185
</dependency>
186
186
```
187
187
188
-
The spring-boot client uses `Spring Boot Actuator` which allows to read predefined metrics and write custom metrics. The Actuator supports [Micrometer](https://github.com/micrometer-metrics/micrometer) and is part of Actuator's dependencies.
188
+
The Srpring Boot instrumentation uses `Spring Boot Actuator` which allows to read predefined metrics and write custom metrics. The Actuator supports [Micrometer](https://github.com/micrometer-metrics/micrometer) and is part of Actuator's dependencies.
189
189
In your code you work directly with `Micrometer`. Define your custom metrics and iterate with them:
190
190
191
191
```java
@@ -234,9 +234,10 @@ public class DemoController {
234
234
}
235
235
}
236
236
```
237
+
237
238
In the example above, three custom metrics are defined and used. The metrics are `Counter`, `LongTaskTimer` and `Gauge`.
238
239
239
-
2.*Using java client in Java application:*
240
+
2.*Instrumenting plain Java applications:*
240
241
241
242
```xml
242
243
<dependency>
@@ -246,7 +247,7 @@ In the example above, three custom metrics are defined and used. The metrics are
246
247
</dependency>
247
248
```
248
249
249
-
The java client uses [Dropwizard](https://metrics.dropwizard.io) which allows to define all kind of metrics supports by Dropwizard. The following metrics are available: com.codahale.metrics.Gauge, com.codahale.metrics.Counter, com.codahale.metrics.Histogram, com.codahale.metrics.Meter and com.codahale.metrics.Timer. More information about the [metric types and their usage](https://metrics.dropwizard.io/4.0.0/getting-started.html). Define your custom metrics and iterate with them:
250
+
The Java instrumentation uses [Dropwizard](https://metrics.dropwizard.io) which allows to define all kind of metrics supports by Dropwizard. The following metrics are available: com.codahale.metrics.Gauge, com.codahale.metrics.Counter, com.codahale.metrics.Histogram, com.codahale.metrics.Meter and com.codahale.metrics.Timer. More information about the [metric types and their usage](https://metrics.dropwizard.io/4.0.0/getting-started.html). Define your custom metrics and iterate with them:
250
251
251
252
```java
252
253
importjava.io.IOException;
@@ -273,13 +274,13 @@ public class CustomMetricsServlet extends HttpServlet {
273
274
}
274
275
```
275
276
276
-
## Custom metrics client configurations
277
+
## Custom metrics Configurations
277
278
278
-
This client library supports the following configurations regarding sending custom metrics:
279
+
This library supports the following configurations regarding sending custom metrics:
279
280
*`interval`: the interval for sending metrics, in millis. **Default value: `60000`**
280
281
*`enabled`: enables or disables the sending of metrics. **Default value: `true`**
281
282
*`metrics`: array of whitelisted metric names. Only mentioned metrics would be processed and sent. If it is an empty array all metrics are being sent. **Default value: `[]`**
282
-
*`metricQuantiles`: enables or disables the sending of metric's [quantiles](https://en.wikipedia.org/wiki/Quantile) like median, 95th percentile, 99th percentile. Spring-boot client does not support this configuration. **Default value: `false`**
283
+
*`metricQuantiles`: enables or disables the sending of metric's [quantiles](https://en.wikipedia.org/wiki/Quantile) like median, 95th percentile, 99th percentile. SpringBoot does not support this configuration. **Default value: `false`**
283
284
284
285
Configurations are read from environment variable named `CUSTOM_METRICS`. To change the default values, you should override the environment variable with your custom values. Example:
0 commit comments