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: java-spanner/.readme-partials.yaml
+47-2Lines changed: 47 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -57,18 +57,63 @@ custom_content: |
57
57
Client-side metrics are measured from the time a request leaves your application to the time your application receives the response.
58
58
In contrast, server-side metrics are measured from the time Spanner receives a request until the last byte of data is sent to the client.
59
59
60
-
These metrics are enabled by default. You can opt out of using client-side metrics with the following code:
60
+
The default Cloud Monitoring export for these metrics is enabled by default. You can opt out of the default Cloud Monitoring export with the following code:
You can also disable these metrics by setting `SPANNER_DISABLE_BUILTIN_METRICS` to `true`.
68
+
You can also disable the default Cloud Monitoring export by setting `SPANNER_DISABLE_BUILTIN_METRICS` to `true`. If you configure a `CustomOpenTelemetryMetricsProvider` on a non-Omni client, that custom sink is independent and keeps recording.
69
69
70
70
> Note: Client-side metrics needs `monitoring.timeSeries.create` IAM permission to export metrics data. Ask your administrator to grant your service account the [Monitoring Metric Writer](https://cloud.google.com/iam/docs/roles-permissions/monitoring#monitoring.metricWriter) (roles/monitoring.metricWriter) IAM role on the project.
71
71
72
+
#### Customizing how built-in metrics are collected
73
+
74
+
How built-in metrics are collected and exported is controlled by a `MetricsProvider`,
75
+
set with `SpannerOptions.Builder.setMetricsProvider(MetricsProvider)`. The available
76
+
providers are:
77
+
78
+
* `DefaultMetricsProvider` (the default): built-in metrics are collected and exported to
79
+
Google Cloud Monitoring.
80
+
* `NoopMetricsProvider`: built-in metrics are disabled entirely. This is equivalent to
81
+
`setBuiltInMetricsEnabled(false)` only for the default provider; with a
82
+
`CustomOpenTelemetryMetricsProvider` set, `setBuiltInMetricsEnabled(false)` turns off
83
+
only the Cloud Monitoring sink while `NoopMetricsProvider` disables everything.
84
+
* `CustomOpenTelemetryMetricsProvider`: built-in metrics are additionally recorded on an
85
+
`OpenTelemetry` instance that you provide. You own the metrics pipeline (readers,
86
+
exporters and resource). On non-Omni clients this custom sink is additive to the default
87
+
Cloud Monitoring export: both can be active at once. This is also the way to collect
88
+
built-in metrics for Spanner Omni (`InstanceType.OMNI`), for which Cloud Monitoring
89
+
export is not available.
90
+
91
+
On non-Omni clients, `setBuiltInMetricsEnabled(false)` and the
92
+
`SPANNER_DISABLE_BUILTIN_METRICS` environment variable drop only the Cloud Monitoring
93
+
(GCM) sink; a custom sink set via `CustomOpenTelemetryMetricsProvider` is an independent
94
+
opt-in and keeps recording. On Omni clients, where the GCM sink is never active, the
95
+
`SPANNER_DISABLE_BUILTIN_METRICS` environment variable additionally silences the custom
96
+
sink.
97
+
98
+
When using `CustomOpenTelemetryMetricsProvider`, it is recommended to register the Spanner
99
+
built-in metric views on a dedicated `SdkMeterProviderBuilder` with
100
+
`SpannerOptions.registerBuiltInMetricViews(SdkMeterProviderBuilder)` before creating the
101
+
`OpenTelemetry` instance. The views rename the raw instruments, apply the Spanner latency
102
+
histogram buckets and restrict the recorded attributes to the supported built-in metric
Cloud Spanner client supports OpenTelemetry Traces, which gives insight into the client internals and aids in debugging/troubleshooting production issues.
Client-side metrics are measured from the time a request leaves your application to the time your application receives the response.
156
156
In contrast, server-side metrics are measured from the time Spanner receives a request until the last byte of data is sent to the client.
157
157
158
-
These metrics are enabled by default. You can opt out of using client-side metrics with the following code:
158
+
The default Cloud Monitoring export for these metrics is enabled by default. You can opt out of the default Cloud Monitoring export with the following code:
You can also disable these metrics by setting `SPANNER_DISABLE_BUILTIN_METRICS` to `true`.
166
+
You can also disable the default Cloud Monitoring export by setting `SPANNER_DISABLE_BUILTIN_METRICS` to `true`. If you configure a `CustomOpenTelemetryMetricsProvider` on a non-Omni client, that custom sink is independent and keeps recording.
167
167
168
168
> Note: Client-side metrics needs `monitoring.timeSeries.create` IAM permission to export metrics data. Ask your administrator to grant your service account the [Monitoring Metric Writer](https://cloud.google.com/iam/docs/roles-permissions/monitoring#monitoring.metricWriter) (roles/monitoring.metricWriter) IAM role on the project.
169
169
170
+
#### Customizing how built-in metrics are collected
171
+
172
+
How built-in metrics are collected and exported is controlled by a `MetricsProvider`,
173
+
set with `SpannerOptions.Builder.setMetricsProvider(MetricsProvider)`. The available
174
+
providers are:
175
+
176
+
*`DefaultMetricsProvider` (the default): built-in metrics are collected and exported to
177
+
Google Cloud Monitoring.
178
+
*`NoopMetricsProvider`: built-in metrics are disabled entirely. This is equivalent to
179
+
`setBuiltInMetricsEnabled(false)` only for the default provider; with a
180
+
`CustomOpenTelemetryMetricsProvider` set, `setBuiltInMetricsEnabled(false)` turns off
181
+
only the Cloud Monitoring sink while `NoopMetricsProvider` disables everything.
182
+
*`CustomOpenTelemetryMetricsProvider`: built-in metrics are additionally recorded on an
183
+
`OpenTelemetry` instance that you provide. You own the metrics pipeline (readers,
184
+
exporters and resource). On non-Omni clients this custom sink is additive to the default
185
+
Cloud Monitoring export: both can be active at once. This is also the way to collect
186
+
built-in metrics for Spanner Omni (`InstanceType.OMNI`), for which Cloud Monitoring
187
+
export is not available.
188
+
189
+
On non-Omni clients, `setBuiltInMetricsEnabled(false)` and the
190
+
`SPANNER_DISABLE_BUILTIN_METRICS` environment variable drop only the Cloud Monitoring
191
+
(GCM) sink; a custom sink set via `CustomOpenTelemetryMetricsProvider` is an independent
192
+
opt-in and keeps recording. On Omni clients, where the GCM sink is never active, the
193
+
`SPANNER_DISABLE_BUILTIN_METRICS` environment variable additionally silences the custom
194
+
sink.
195
+
196
+
When using `CustomOpenTelemetryMetricsProvider`, it is recommended to register the Spanner
197
+
built-in metric views on a dedicated `SdkMeterProviderBuilder` with
198
+
`SpannerOptions.registerBuiltInMetricViews(SdkMeterProviderBuilder)` before creating the
199
+
`OpenTelemetry` instance. The views rename the raw instruments, apply the Spanner latency
200
+
histogram buckets and restrict the recorded attributes to the supported built-in metric
Cloud Spanner client supports OpenTelemetry Traces, which gives insight into the client internals and aids in debugging/troubleshooting production issues.
0 commit comments