chore: custom exporter for Client Built-in Metrics#3164
chore: custom exporter for Client Built-in Metrics#3164gcf-merge-on-green[bot] merged 4 commits intogoogleapis:mainfrom
Conversation
7f9c298 to
a7cbc5f
Compare
a7cbc5f to
071ccc0
Compare
071ccc0 to
1274a7d
Compare
| throws IOException { | ||
| MetricServiceSettings.Builder settingsBuilder = MetricServiceSettings.newBuilder(); | ||
| CredentialsProvider credentialsProvider; | ||
| if (credentials == null) { |
There was a problem hiding this comment.
Normally, when a user has not set any credentials, we will use the default credentials found in the environment. Is that what will normally happen here as well?
Put another way: Will we normally call SpannerCloudMonitoringExporter.create(..) with the default credentials when the user has not set any specific credentials?
There was a problem hiding this comment.
My plan was to use getCredentials when I call SpannerCloudMonitoringExporter.create(..)
There was a problem hiding this comment.
Do you mean this method:
That method is only usable in case the user uses the Connection API (which no one uses directly, meaning it is only usable in combination with the JDBC driver). But you could use the same type of logic and/or move that logic to a place where it is usable directly in the client library.
Would it maybe make more sense to make the Credentials input argument non-nullable, and force anyone who wants to use NoCredentials to supply that explicitly? That would only be for testing purposes, meaning that it would be something that we normally control.
There was a problem hiding this comment.
Sorry, not getCredentials .
We will use GoogleCredentials.getApplicationDefault() , similar to how it is used here
Keeping it Nullable for now, this was referred from the current user facing exporter.
olavloite
left a comment
There was a problem hiding this comment.
LGTM, with some minor questions/assumptions.
| for (AttributeKey<?> key : attributes.asMap().keySet()) { | ||
| if (SPANNER_PROMOTED_RESOURCE_LABELS.contains(key)) { |
There was a problem hiding this comment.
It's interesting all the MonitoredResource labels are coming from metric level attributes instead of OTel Resource attributes. None of these could be set in the OTel resource?
There was a problem hiding this comment.
@aabmass It can be set, but does it really make a difference if these Monitored resource labels comes from metrics attributes or OTel resource attributes ?
|
|
||
| // These metric labels will be promoted to the spanner monitored resource fields | ||
| public static final Set<AttributeKey<String>> SPANNER_PROMOTED_RESOURCE_LABELS = | ||
| ImmutableSet.of(PROJECT_ID_KEY, INSTANCE_ID_KEY, INSTANCE_CONFIG_ID_KEY, LOCATION_ID_KEY); |
There was a problem hiding this comment.
nit, iirc the project_id MonitoredResource label must always match the project the metrics are being written to, and so it is unnecessary to send it. We've taken this approach in our exporters since there is no benefit in sending it
psx95
left a comment
There was a problem hiding this comment.
Left some thoughts about handling the shutdown mechanism of the exporter.
eff37f6 to
67ebc99
Compare
odeke-em
left a comment
There was a problem hiding this comment.
Thanks @surbhigarg92, just some drive by nits/comments.
| @Override | ||
| public CompletableResultCode export(Collection<MetricData> collection) { | ||
| if (client.isShutdown()) { | ||
| logger.log(Level.WARNING, "Exporter is shut down"); |
There was a problem hiding this comment.
Nit: "Exporter was already shut down"
There was a problem hiding this comment.
Also I think it is an error to try to use an already shutdown exporter, hence perhaps change the log level to Error?
| .collect(Collectors.toList()); | ||
|
|
||
| // Skips exporting if there's none | ||
| if (spannerMetricData.isEmpty()) { |
There was a problem hiding this comment.
Useful to perform an info log so that debugging will reveal truly that .isEmpty() and that data wasn't exported, instead of one scratching their head wondering why metrics weren't exported.
|
|
||
| private static MetricKind convertMetricKind(MetricData metricData) { | ||
| switch (metricData.getType()) { | ||
| case HISTOGRAM: |
There was a problem hiding this comment.
I'd suggest avoiding the fall through and instead explicitly add common cases on the same line so: case HISTOGRAM, EXPONENTIAL_HISTOGRAM for clarity and to help avoid any future unexpected issues.
| case HISTOGRAM: | ||
| case EXPONENTIAL_HISTOGRAM: | ||
| return convertHistogramType(metricData.getHistogramData()); | ||
| case LONG_GAUGE: |
There was a problem hiding this comment.
Ditto about not allowing fall through and instead putting similar case values on the same line.
No description provided.