|
| 1 | +// Copyright 2019, OpenTelemetry Authors |
| 2 | +// |
| 3 | +// Licensed under the Apache License, Version 2.0 (the "License"); |
| 4 | +// you may not use this file except in compliance with the License. |
| 5 | +// You may obtain a copy of the License at |
| 6 | +// |
| 7 | +// http://www.apache.org/licenses/LICENSE-2.0 |
| 8 | +// |
| 9 | +// Unless required by applicable law or agreed to in writing, software |
| 10 | +// distributed under the License is distributed on an "AS IS" BASIS, |
| 11 | +// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 12 | +// See the License for the specific language governing permissions and |
| 13 | +// limitations under the License. |
| 14 | + |
| 15 | +syntax = "proto3"; |
| 16 | + |
| 17 | +package opentelemetry.proto.experimental.metrics.configservice; |
| 18 | + |
| 19 | +import "opentelemetry/proto/resource/v1/resource.proto"; |
| 20 | + |
| 21 | +option java_multiple_files = true; |
| 22 | +option java_package = "io.opentelemetry.proto.experimental.metrics.configservice"; |
| 23 | +option java_outer_classname = "MetricConfigServiceProto"; |
| 24 | +option go_package = "github.com/open-telemetry/opentelemetry-proto/gen/go/experimental/metrics/configservice"; |
| 25 | + |
| 26 | +// MetricConfig is a service that enables updating metric schedules, trace |
| 27 | +// parameters, and other configurations on the SDK without having to restart the |
| 28 | +// instrumented application. The collector can also serve as the configuration |
| 29 | +// service, acting as a bridge between third-party configuration services and |
| 30 | +// the SDK, piping updated configs from a third-party source to an instrumented |
| 31 | +// application. |
| 32 | +service MetricConfig { |
| 33 | + rpc GetMetricConfig (MetricConfigRequest) returns (MetricConfigResponse); |
| 34 | +} |
| 35 | + |
| 36 | +message MetricConfigRequest{ |
| 37 | + |
| 38 | + // Required. The resource for which configuration should be returned. |
| 39 | + opentelemetry.proto.resource.v1.Resource resource = 1; |
| 40 | + |
| 41 | + // Optional. The value of MetricConfigResponse.fingerprint for the last |
| 42 | + // configuration that the caller received and successfully applied. |
| 43 | + bytes last_known_fingerprint = 2; |
| 44 | +} |
| 45 | + |
| 46 | +message MetricConfigResponse { |
| 47 | + |
| 48 | + // Optional. The fingerprint associated with this MetricConfigResponse. Each |
| 49 | + // change in configs yields a different fingerprint. The resource SHOULD copy |
| 50 | + // this value to MetricConfigRequest.last_known_fingerprint for the next |
| 51 | + // configuration request. If there are no changes between fingerprint and |
| 52 | + // MetricConfigRequest.last_known_fingerprint, then all other fields besides |
| 53 | + // fingerprint in the response are optional, or the same as the last update if |
| 54 | + // present. |
| 55 | + // |
| 56 | + // The exact mechanics of generating the fingerprint is up to the |
| 57 | + // implementation. However, a fingerprint must be deterministically determined |
| 58 | + // by the configurations -- the same configuration will generate the same |
| 59 | + // fingerprint on any instance of an implementation. Hence using a timestamp is |
| 60 | + // unacceptable, but a deterministic hash is fine. |
| 61 | + bytes fingerprint = 1; |
| 62 | + |
| 63 | + // A Schedule is used to apply a particular scheduling configuration to |
| 64 | + // a metric. If a metric name matches a schedule's patterns, then the metric |
| 65 | + // adopts the configuration specified by the schedule. |
| 66 | + message Schedule { |
| 67 | + |
| 68 | + // A light-weight pattern that can match 1 or more |
| 69 | + // metrics, for which this schedule will apply. The string is used to |
| 70 | + // match against metric names. It should not exceed 100k characters. |
| 71 | + message Pattern { |
| 72 | + oneof match { |
| 73 | + string equals = 1; // matches the metric name exactly |
| 74 | + string starts_with = 2; // prefix-matches the metric name |
| 75 | + } |
| 76 | + } |
| 77 | + |
| 78 | + // Metrics with names that match a rule in the inclusion_patterns are |
| 79 | + // targeted by this schedule. Metrics that match the exclusion_patterns |
| 80 | + // are not targeted for this schedule, even if they match an inclusion |
| 81 | + // pattern. |
| 82 | + repeated Pattern exclusion_patterns = 1; |
| 83 | + repeated Pattern inclusion_patterns = 2; |
| 84 | + |
| 85 | + // Describes the collection period for each metric in seconds. |
| 86 | + // A period of 0 means to not export. |
| 87 | + int32 period_sec = 3; |
| 88 | + } |
| 89 | + |
| 90 | + // A single metric may match multiple schedules. In such cases, the schedule |
| 91 | + // that specifies the smallest period is applied. |
| 92 | + // |
| 93 | + // Note, for optimization purposes, it is recommended to use as few schedules |
| 94 | + // as possible to capture all required metric updates. Where you can be |
| 95 | + // conservative, do take full advantage of the inclusion/exclusion patterns to |
| 96 | + // capture as much of your targeted metrics. |
| 97 | + repeated Schedule schedules = 2; |
| 98 | + |
| 99 | + // Optional. The client is suggested to wait this long (in seconds) before |
| 100 | + // pinging the configuration service again. |
| 101 | + int32 suggested_wait_time_sec = 3; |
| 102 | +} |
0 commit comments