202 lines
9.2 KiB
PHP
202 lines
9.2 KiB
PHP
<?php
|
|
# Generated by the protocol buffer compiler. DO NOT EDIT!
|
|
# source: opentelemetry/proto/metrics/experimental/metrics_config_service.proto
|
|
|
|
namespace Opentelemetry\Proto\Metrics\Experimental;
|
|
|
|
use Google\Protobuf\Internal\GPBType;
|
|
use Google\Protobuf\Internal\RepeatedField;
|
|
use Google\Protobuf\Internal\GPBUtil;
|
|
|
|
/**
|
|
* Generated from protobuf message <code>opentelemetry.proto.metrics.experimental.MetricConfigResponse</code>
|
|
*/
|
|
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 <code>bytes fingerprint = 1;</code>
|
|
*/
|
|
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 <code>repeated .opentelemetry.proto.metrics.experimental.MetricConfigResponse.Schedule schedules = 2;</code>
|
|
*/
|
|
private $schedules;
|
|
/**
|
|
* Optional. The client is suggested to wait this long (in seconds) before
|
|
* pinging the configuration service again.
|
|
*
|
|
* Generated from protobuf field <code>int32 suggested_wait_time_sec = 3;</code>
|
|
*/
|
|
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 <code>bytes fingerprint = 1;</code>
|
|
* @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 <code>bytes fingerprint = 1;</code>
|
|
* @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 <code>repeated .opentelemetry.proto.metrics.experimental.MetricConfigResponse.Schedule schedules = 2;</code>
|
|
* @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 <code>repeated .opentelemetry.proto.metrics.experimental.MetricConfigResponse.Schedule schedules = 2;</code>
|
|
* @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 <code>int32 suggested_wait_time_sec = 3;</code>
|
|
* @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 <code>int32 suggested_wait_time_sec = 3;</code>
|
|
* @param int $var
|
|
* @return $this
|
|
*/
|
|
public function setSuggestedWaitTimeSec($var)
|
|
{
|
|
GPBUtil::checkInt32($var);
|
|
$this->suggested_wait_time_sec = $var;
|
|
|
|
return $this;
|
|
}
|
|
|
|
}
|
|
|