This package defines the Mixer API that the sidecar proxy uses to perform precondition checks, manage quotas, and report telemetry.



Mixer provides three core features:

  • Precondition Checking. Enables callers to verify a number of preconditions before responding to an incoming request from a service consumer. Preconditions can include whether the service consumer is properly authenticated, is on the service‚Äôs whitelist, passes ACL checks, and more.

  • Quota Management. Enables services to allocate and free quota on a number of dimensions, Quotas are used as a relatively simple resource management tool to provide some fairness between service consumers when contending for limited resources. Rate limits are examples of quotas.

  • Telemetry Reporting. Enables services to report logging and monitoring. In the future, it will also enable tracing and billing streams intended for both the service operator as well as for service consumers.

rpc Check(CheckRequest) returns (CheckResponse)

Checks preconditions and allocate quota before performing an operation. The preconditions enforced depend on the set of supplied attributes and the active configuration.

rpc Report(ReportRequest) returns (ReportResponse)

Reports telemetry, such as logs and metrics. The reported information depends on the set of supplied attributes and the active configuration.



Attributes represents a set of typed name/value pairs. Many of Mixer’s API either consume and/or return attributes.

Istio uses attributes to control the runtime behavior of services running in the service mesh. Attributes are named and typed pieces of metadata describing ingress and egress traffic and the environment this traffic occurs in. An Istio attribute carries a specific piece of information such as the error code of an API request, the latency of an API request, or the original IP address of a TCP connection. For example:

request.path: xyz/abc
request.size: 234
request.time: 12:34:56.789 04/17/2017
target.service: example

A given Istio deployment has a fixed vocabulary of attributes that it understands. The specific vocabulary is determined by the set of attribute producers being used in the deployment. The primary attribute producer in Istio is Envoy, although specialized Mixer adapters and services can also generate attributes.

The common baseline set of attributes available in most Istio deployments is defined here.

Attributes are strongly typed. The supported attribute types are defined by ValueType. Each type of value is encoded into one of the so-called transport types present in this message.

Defines a map of attributes in uncompressed format. Following places may use this message: 1) Configure Istio/Proxy with static per-proxy attributes, such as source.uid. 2) Service IDL definition to extract api attributes for active requests. 3) Forward attributes from client proxy to server proxy for HTTP requests.


A map of attribute name to its value.


Specifies one attribute value with different type.

stringValuestring (oneof)

Used for values of type STRING, DNSNAME, EMAILADDRESS, and URI

int64Valueint64 (oneof)

Used for values of type INT64

doubleValuedouble (oneof)

Used for values of type DOUBLE

boolValuebool (oneof)

Used for values of type BOOL

bytesValuebytes (oneof)

Used for values of type BYTES

timestampValuegoogle.protobuf.Timestamp (oneof)

Used for values of type TIMESTAMP

durationValuegoogle.protobuf.Duration (oneof)

Used for values of type DURATION

stringMapValueAttributes.StringMap (oneof)

Used for values of type STRING_MAP


Defines a string map.


Holds a set of name/value pairs.


Used to get a thumbs-up/thumbs-down before performing an action.


The attributes to use for this request.

Mixer’s configuration determines how these attributes are used to establish the result returned in the response.


The number of words in the global dictionary, used with to populate the attributes. This value is used as a quick way to determine whether the client is using a dictionary that the server understands.


Used for deduplicating Check calls in the case of failed RPCs and retries. This should be a UUID per call, where the same UUID is used for retries of the same call.


The individual quotas to allocate


parameters for a quota allocation


Amount of quota to allocate


When true, supports returning less quota than what was requested.


The response generated by the Check method.


The precondition check results.


The resulting quota, one entry per requested quota.


Expresses the result of a precondition check.


A status code of OK indicates all preconditions were satisfied. Any other code indicates not all preconditions were satisfied and details describe why.


The amount of time for which this result can be considered valid.


The number of uses for which this result can be considered valid.


The attributes returned by Mixer.

The exact set of attributes returned is determined by the set of adapters Mixer is configured with. These attributes are used to ferry new attributes that Mixer derived based on the input set of attributes and its configuration.


The total set of attributes that were used in producing the result along with matching conditions.


Expresses the result of a quota allocation.


The amount of time for which this result can be considered valid.


The amount of granted quota. When QuotaParams.best_effort is true, this will be >= 0. If QuotaParams.best_effort is false, this will be either 0 or >= QuotaParams.amount.


The total set of attributes that were used in producing the result along with matching conditions.


Defines a list of attributes in compressed format optimized for transport. Within this message, strings are referenced using integer indices into one of two string dictionaries. Positive integers index into the global deployment-wide dictionary, whereas negative integers index into the message-level dictionary instead. The message-level dictionary is carried by the words field of this message, the deployment-wide dictionary is determined via configuration.


The message-level dictionary.


Holds attributes of type STRING, DNSNAME, EMAILADDRESS, URI


Holds attributes of type INT64


Holds attributes of type DOUBLE


Holds attributes of type BOOL


Holds attributes of type TIMESTAMP


Holds attributes of type DURATION


Holds attributes of type BYTES


Holds attributes of type STRING_MAP


Describes the attributes that were used to determine the response. This can be used to construct a response cache.


The message-level dictionary. Refer to CompressedAttributes for information on using dictionaries.


Describes a set of attributes.


Describes a single attribute match.


The name of the attribute. This is a dictionary index encoded in a manner identical to all strings in the CompressedAttributes message.


The kind of match against the attribute value.


If a REGEX condition is provided for a STRING_MAP attribute, clients should use the regex value to match against map keys.


A key in a STRINGMAP. When multiple keys from a STRINGMAP attribute were referenced, there will be multiple AttributeMatch messages with different mapkey values. Values for mapkey SHOULD be ignored for attributes that are not STRING_MAP.

Indices for the keys are used (taken either from the message dictionary from the words field or the global dictionary).

If no mapkey value is provided for a STRINGMAP attribute, the entire STRING_MAP will be used.


How an attribute’s value was matched


should not occur


match when attribute doesn’t exist


match when attribute value is an exact byte-for-byte match


match when attribute value matches the included regex


Used to report telemetry after performing one or more actions.


The attributes to use for this request.

Each Attributes element represents the state of a single action. Multiple actions can be provided in a single message in order to improve communication efficiency. The client can accumulate a set of actions and send them all in one single message.

Although each Attributes message is semantically treated as an independent stand-alone entity unrelated to the other attributes within the message, this message format leverages delta-encoding between attribute messages in order to substantially reduce the request size and improve end-to-end efficiency. Each individual set of attributes is used to modify the previous set. This eliminates the need to redundantly send the same attributes multiple times over within a single request.

If a client is not sophisticated and doesn’t want to use delta-encoding, a degenerate case is to include all attributes in every individual message.


The default message-level dictionary for all the attributes. Individual attribute messages can have their own dictionaries, but if they don’t then this set of words, if it is provided, is used instead.

This makes it possible to share the same dictionary for all attributes in this request, which can substantially reduce the overall request size.


The number of words in the global dictionary. To detect global dictionary out of sync between client and server.


Used to carry responses to telemetry reports


A map of string to string. The keys and values in this map are dictionary indices (see the Attributes message for an explanation)


Holds a set of name/value pairs.


The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. The error model is designed to be:

  • Simple to use and understand for most users
  • Flexible enough to meet unexpected needs


The Status message contains three pieces of data: error code, error message, and error details. The error code should be an enum value of google.rpc.Code, but it may accept additional error codes if needed. The error message should be a developer-facing English message that helps developers understand and resolve the error. If a localized user-facing error message is needed, put the localized message in the error details or localize it in the client. The optional error details may contain arbitrary information about the error. There is a predefined set of error detail types in the package google.rpc that can be used for common error conditions.

Language mapping

The Status message is the logical representation of the error model, but it is not necessarily the actual wire format. When the Status message is exposed in different client libraries and different wire protocols, it can be mapped differently. For example, it will likely be mapped to some exceptions in Java, but more likely mapped to some error codes in C.

Other uses

The error model and the Status message can be used in a variety of environments, either with or without APIs, to provide a consistent developer experience across different environments.

Example uses of this error model include:

  • Partial errors. If a service needs to return partial errors to the client, it may embed the Status in the normal response to indicate the partial errors.

  • Workflow errors. A typical workflow has multiple steps. Each step may have a Status message for error reporting.

  • Batch operations. If a client uses batch request and batch response, the Status message should be used directly inside batch response, one for each error sub-response.

  • Asynchronous operations. If an API call embeds asynchronous operation results in its response, the status of those operations should be represented directly using the Status message.

  • Logging. If some API errors are stored in logs, the message Status could be used directly after any stripping needed for security/privacy reasons.


The status code, which should be an enum value of google.rpc.Code.


A developer-facing error message, which should be in English. Any user-facing error message should be localized and sent in the google.rpc.Status.details field, or localized by the client.


A list of messages that carry the error details. There is a common set of message types for APIs to use.