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
Early versions of Couchbase Server used client-verified durablilty.
36
+
This is still available in the SDK --
37
+
see the https://docs.couchbase.com/sdk-api/couchbase-scala-client/com/couchbase/client/scala/durability/index.html[API documentation on durability] for details of `PersistTo` and `ReplicateTo` --
38
+
but in almost every case with current Couchbase Server versions it's best to use the guarantees offered by the the Server.
For now, much of the discussion (concept-level documentation) can still be found interleaved in the xref:howtos:error-handling.adoc#exception-handling[practical error handling howto doc].
Copy file name to clipboardExpand all lines: modules/howtos/pages/collecting-information-and-logging.adoc
+5-3Lines changed: 5 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
= Logging
2
2
:description: Configuring logging; working with the event bus; and log redaction for data security.
3
-
:page-topic-type: howto
4
-
:page-aliases: ROOT:logging
3
+
:page-toclevels: 3
4
+
:page-aliases: ROOT:logging.adoc
5
5
6
6
[abstract]
7
7
{description}
@@ -84,7 +84,7 @@ NOTE: Gradle automatically uses the correct SLF4J API 2.x dependency required by
84
84
====
85
85
86
86
[configuring-log4j]
87
-
==== Configuring Log4j 2 output
87
+
==== Configuring Log4j 2 Output
88
88
89
89
Log4j 2 needs a configuration file to tell it which messages to log, where to write them, and how each message should be formatted.
90
90
@@ -163,6 +163,7 @@ Add these as children of the `dependencies` element.
163
163
TIP: An alternate way to ensure Maven uses the correct version of the SLF4J API is to declare the dependency on `slf4j-jdk14` *before* the dependency on the Couchbase SDK.
164
164
See the Maven documentation on https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies[Transitive Dependencies] to learn more about how Maven resolves transitive dependency version conflicts.
165
165
--
166
+
166
167
Gradle::
167
168
+
168
169
--
@@ -176,6 +177,7 @@ NOTE: Gradle automatically uses the correct SLF4J API 2.x dependency required by
= Diagnosing and preventing Network Problems with Health Check
2
-
:description: In today's distributed and virtual environments, users will often not have full administrative control over their whole network.
3
-
:navtitle: Health Check
4
-
:page-topic-type: howto
1
+
= Health Check
2
+
:description: pass:q[Health Check provides `ping()` and `diagnostics()` tests for the health of the network and the cluster.]
3
+
:page-aliases: concept-docs:health-check.adoc
4
+
// :page-aliases: ROOT:health-check.adoc
5
+
:page-toclevels: 2
6
+
7
+
5
8
6
9
[abstract]
7
10
{description}
8
-
Health Check introduces _Ping_ to check nodes are still healthy, and to force idle connections to be kept alive in environments with eager shutdowns of unused resources.
9
-
_Diagnostics_ requests a report from all the connected sockets against the cluster (from a client point of view), giving instant, but passive health check information.
10
11
11
12
12
-
Diagnosing problems in distributed environments is far from easy, so Couchbase provides a _Health Check API_ with `Ping()` for active monitoring, and `Diagnostics()` for a look at what the client believes is the current state of the cluster.
13
-
More extensive discussion of the uses of Health Check can be found in the xref:concept-docs:health-check.adoc[Health Check Concept Guide].
13
+
14
+
In today's distributed and virtual environments, users will often not have full administrative control over their whole network.
15
+
Working in distributed environments is hard. Latencies come and go, so do connections in their entirety.
16
+
Is it a network glitch, or is the remote cluster down?
17
+
Sometimes just knowing the likely cause is enough to get a good start on a workaround, or at least avoid hours wasted on an inappropriate solution.
18
+
19
+
Health Check features _Ping_ to check nodes are still healthy, and to force idle connections to be kept alive in environments with eager shutdowns of unused resources.
20
+
_Diagnostics_ requests a report from a node, giving instant health check information.
In this example, only the Query service is included in the ping report.
42
60
43
-
Note that `ping` is available both on the `Cluster` and the `Bucket` level.
44
-
The difference is that at the cluster level, the key-value service might not be
61
+
Note that `ping` is available both at the `Cluster` and the `Bucket` level.
62
+
The difference is that at the cluster level, the key-value (Data) service might not be
45
63
included based on the Couchbase Server version in use.
46
64
If you want to make sure the key-value service is included, perform it at the bucket level.
47
65
66
+
48
67
== Diagnostics
49
68
50
69
Diagnostics works in a similar fashion to `ping` in the sense that it returns a report of how all the sockets/endpoints are doing, but the main difference is that it is passive.
@@ -53,17 +72,18 @@ This makes it much cheaper to call on a regular basis, but does not provide any
Because it is passive, diagnostics are only available at the `Cluster` level and cover everything in the current SDK state. Also, because it is not doing any I/O you cannot proactively filter the list of services that are returned, all you need to do is look only at the ones that are interesting to you.
60
79
61
-
A `DiagnosticsResult` has one interesting property over a ping result: It provides a cumulative `ClusterState` through the `state()` method.
62
-
The state can be `ONLINE`, `DEGRADED` or `OFFLINE`. This allows to give a single, although simplistic, view on how your cluster is doing from a client point of view.
80
+
A `DiagnosticsResult` has one interesting property over a ping result -- it provides a cumulative `ClusterState` through the `state()` method.
81
+
The state can be `ONLINE`, `DEGRADED` or `OFFLINE`.
82
+
This allows to give a single, although simplistic, view on how your cluster is doing from a client point of view.
63
83
The state is determined as follows:
64
84
65
85
* If at least one socket is open and all of them are connected, it is `ONLINE`
66
86
* If at least one is connected but not all are, it is `DEGRADED`
67
87
* If none are connected, it is `OFFLINE`
68
88
69
-
Of course you can iterate over the individual states and apply a different algorithm if needed.
89
+
You can iterate over the individual states and apply a different algorithm if needed.
In this case the emit interval is one minute and Key/Value requests will only be considered if their latency is greater or equal than two seconds.
@@ -69,9 +69,11 @@ More information will be provided as we get closer to stabilization.
69
69
70
70
71
71
== OpenTelemetry Integration
72
+
72
73
The built-in tracer is great if you do not have a centralized monitoring system, but if you already plug into the OpenTelemetry ecosystem we want to make sure to provide first-class support.
73
74
74
75
=== Exporting to OpenTelemetry
76
+
75
77
This method exports tracing telemetry in OpenTelemetry's standard format (OTLP), which can be sent to any OTLP-compatible receiver such as Jaeger, Zipkin or `opentelemetry-collector`.
76
78
77
79
Add this to your Maven, or the equivalent to your build tool of choice:
0 commit comments