Skip to main content
Drupal API
User account menu
  • Log in

Breadcrumb

  1. Drupal Core 11.1.x

MetricConfigResponse.php

Namespace

Opentelemetry\Proto\Metrics\Experimental

File

vendor/open-telemetry/gen-otlp-protobuf/Opentelemetry/Proto/Metrics/Experimental/MetricConfigResponse.php

View source
<?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;
    }

}

Classes

Title Deprecated Summary
MetricConfigResponse Generated from protobuf message <code>opentelemetry.proto.metrics.experimental.MetricConfigResponse</code>

API Navigation

  • Drupal Core 11.1.x
  • Topics
  • Classes
  • Functions
  • Constants
  • Globals
  • Files
  • Namespaces
  • Deprecated
  • Services
RSS feed
Powered by Drupal