opentelemetry.proto.metrics.experimental.MetricConfigResponse */ class MetricConfigResponse extends \Google\Protobuf\Internal\Message { /** * 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. * * Generated from protobuf field bytes fingerprint = 1; */ protected $fingerprint = ''; /** * 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. * * Generated from protobuf field repeated .opentelemetry.proto.metrics.experimental.MetricConfigResponse.Schedule schedules = 2; */ private $schedules; /** * Optional. The client is suggested to wait this long (in seconds) before * pinging the configuration service again. * * Generated from protobuf field int32 suggested_wait_time_sec = 3; */ protected $suggested_wait_time_sec = 0; /** * Constructor. * * @param array $data { * Optional. Data for populating the Message object. * * @type string $fingerprint * 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. * @type \Opentelemetry\Proto\Metrics\Experimental\MetricConfigResponse\Schedule[]|\Google\Protobuf\Internal\RepeatedField $schedules * 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. * @type int $suggested_wait_time_sec * Optional. The client is suggested to wait this long (in seconds) before * pinging the configuration service again. * } */ public function __construct($data = NULL) { \GPBMetadata\Opentelemetry\Proto\Metrics\Experimental\MetricsConfigService::initOnce(); parent::__construct($data); } /** * 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. * * Generated from protobuf field bytes fingerprint = 1; * @return string */ public function getFingerprint() { return $this->fingerprint; } /** * 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. * * Generated from protobuf field bytes fingerprint = 1; * @param string $var * @return $this */ public function setFingerprint($var) { GPBUtil::checkString($var, False); $this->fingerprint = $var; return $this; } /** * 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. * * Generated from protobuf field repeated .opentelemetry.proto.metrics.experimental.MetricConfigResponse.Schedule schedules = 2; * @return \Google\Protobuf\Internal\RepeatedField */ public function getSchedules() { return $this->schedules; } /** * 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. * * Generated from protobuf field repeated .opentelemetry.proto.metrics.experimental.MetricConfigResponse.Schedule schedules = 2; * @param \Opentelemetry\Proto\Metrics\Experimental\MetricConfigResponse\Schedule[]|\Google\Protobuf\Internal\RepeatedField $var * @return $this */ public function setSchedules($var) { $arr = GPBUtil::checkRepeatedField($var, \Google\Protobuf\Internal\GPBType::MESSAGE, \Opentelemetry\Proto\Metrics\Experimental\MetricConfigResponse\Schedule::class); $this->schedules = $arr; return $this; } /** * Optional. The client is suggested to wait this long (in seconds) before * pinging the configuration service again. * * Generated from protobuf field int32 suggested_wait_time_sec = 3; * @return int */ public function getSuggestedWaitTimeSec() { return $this->suggested_wait_time_sec; } /** * Optional. The client is suggested to wait this long (in seconds) before * pinging the configuration service again. * * Generated from protobuf field int32 suggested_wait_time_sec = 3; * @param int $var * @return $this */ public function setSuggestedWaitTimeSec($var) { GPBUtil::checkInt32($var); $this->suggested_wait_time_sec = $var; return $this; } }