Interface MetricConfigResponseOrBuilder
-
- All Superinterfaces:
com.google.protobuf.MessageLiteOrBuilder,com.google.protobuf.MessageOrBuilder
- All Known Implementing Classes:
MetricConfigResponse,MetricConfigResponse.Builder
public interface MetricConfigResponseOrBuilder extends com.google.protobuf.MessageOrBuilder
-
-
Method Summary
All Methods Instance Methods Abstract Methods Modifier and Type Method Description com.google.protobuf.ByteStringgetFingerprint()Optional.MetricConfigResponse.SchedulegetSchedules(int index)A single metric may match multiple schedules.intgetSchedulesCount()A single metric may match multiple schedules.List<MetricConfigResponse.Schedule>getSchedulesList()A single metric may match multiple schedules.MetricConfigResponse.ScheduleOrBuildergetSchedulesOrBuilder(int index)A single metric may match multiple schedules.List<? extends MetricConfigResponse.ScheduleOrBuilder>getSchedulesOrBuilderList()A single metric may match multiple schedules.intgetSuggestedWaitTimeSec()Optional.-
Methods inherited from interface com.google.protobuf.MessageOrBuilder
findInitializationErrors, getAllFields, getDefaultInstanceForType, getDescriptorForType, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof
-
-
-
-
Method Detail
-
getFingerprint
com.google.protobuf.ByteString getFingerprint()
Optional. The fingerprint associated with this MetricConfigResponse. Each change in configs yields a different fingerprint. The resource SHOULD copy this value to MetricConfigRequest.last_known_fingerprint for the next configuration request. If there are no changes between fingerprint and MetricConfigRequest.last_known_fingerprint, then all other fields besides fingerprint in the response are optional, or the same as the last update if present. The exact mechanics of generating the fingerprint is up to the implementation. However, a fingerprint must be deterministically determined by the configurations -- the same configuration will generate the same fingerprint on any instance of an implementation. Hence using a timestamp is unacceptable, but a deterministic hash is fine.
bytes fingerprint = 1;
-
getSchedulesList
List<MetricConfigResponse.Schedule> getSchedulesList()
A single metric may match multiple schedules. In such cases, the schedule that specifies the smallest period is applied. Note, for optimization purposes, it is recommended to use as few schedules as possible to capture all required metric updates. Where you can be conservative, do take full advantage of the inclusion/exclusion patterns to capture as much of your targeted metrics.
repeated .opentelemetry.proto.metrics.experimental.MetricConfigResponse.Schedule schedules = 2;
-
getSchedules
MetricConfigResponse.Schedule getSchedules(int index)
A single metric may match multiple schedules. In such cases, the schedule that specifies the smallest period is applied. Note, for optimization purposes, it is recommended to use as few schedules as possible to capture all required metric updates. Where you can be conservative, do take full advantage of the inclusion/exclusion patterns to capture as much of your targeted metrics.
repeated .opentelemetry.proto.metrics.experimental.MetricConfigResponse.Schedule schedules = 2;
-
getSchedulesCount
int getSchedulesCount()
A single metric may match multiple schedules. In such cases, the schedule that specifies the smallest period is applied. Note, for optimization purposes, it is recommended to use as few schedules as possible to capture all required metric updates. Where you can be conservative, do take full advantage of the inclusion/exclusion patterns to capture as much of your targeted metrics.
repeated .opentelemetry.proto.metrics.experimental.MetricConfigResponse.Schedule schedules = 2;
-
getSchedulesOrBuilderList
List<? extends MetricConfigResponse.ScheduleOrBuilder> getSchedulesOrBuilderList()
A single metric may match multiple schedules. In such cases, the schedule that specifies the smallest period is applied. Note, for optimization purposes, it is recommended to use as few schedules as possible to capture all required metric updates. Where you can be conservative, do take full advantage of the inclusion/exclusion patterns to capture as much of your targeted metrics.
repeated .opentelemetry.proto.metrics.experimental.MetricConfigResponse.Schedule schedules = 2;
-
getSchedulesOrBuilder
MetricConfigResponse.ScheduleOrBuilder getSchedulesOrBuilder(int index)
A single metric may match multiple schedules. In such cases, the schedule that specifies the smallest period is applied. Note, for optimization purposes, it is recommended to use as few schedules as possible to capture all required metric updates. Where you can be conservative, do take full advantage of the inclusion/exclusion patterns to capture as much of your targeted metrics.
repeated .opentelemetry.proto.metrics.experimental.MetricConfigResponse.Schedule schedules = 2;
-
getSuggestedWaitTimeSec
int getSuggestedWaitTimeSec()
Optional. The client is suggested to wait this long (in seconds) before pinging the configuration service again.
int32 suggested_wait_time_sec = 3;
-
-