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;
}
}