Describes the rules used to configure Mixer’s policy and telemetry features.
Action describes which Handler to invoke and what data to pass to it for processing.
The following example instructs Mixer to invoke ‘prometheus-handler’ handler and pass it the object constructed using the instance ‘RequestCountByService’.
handler: prometheus-handler instances: - RequestCountByService
AttributeManifest describes a set of Attributes produced by some component of an Istio deployment.
AttributeInfo describes the schema of an Istio
attributes to describe runtime activities of Istio services. An Istio attribute carries a specific piece of information about an activity, such as the error code of an API request, the latency of an API request, or the original IP address of a TCP connection. The attributes are often generated and consumed by different services. For example, a frontend service can generate an authenticated user attribute and pass it to a backend service for access control purpose.
To simplify the system and improve developer experience, Istio uses shared attribute definitions across all components. For example, the same authenticated user attribute will be used for logging, monitoring, analytics, billing, access control, auditing. Many Istio components provide their functionality by collecting, generating, and operating on attributes. For example, the proxy collects the error code attribute, and the logging stores it into a log.
Each Istio attribute must conform to an
AttributeInfo in an
AttributeManifest in the current Istio deployment at runtime. An
AttributeInfo is used to define an attribute’s metadata: the type of its value and a detailed description that explains the semantics of the attribute type. Each attribute’s name is globally unique; in other words an attribute name can only appear once across all manifests.
The runtime presentation of an attribute is intentionally left out of this specification, because passing attribute using JSON, XML, or Protocol Buffers does not change the semantics of the attribute. Different implementations can choose different representations based on their needs.
Because many systems already have REST APIs, it makes sense to define a standard HTTP mapping for Istio attributes that are compatible with typical REST APIs. The design is to map one attribute to one HTTP header, the attribute name and value becomes the HTTP header name and value. The actual encoding scheme will be decided later.
Connection allows the operator to specify the endpoint for out-of-process infrastructure backend. Connection is part of the handler custom resource and is specified alongside adapter specific configuration.
Handler allows the operator to configure a specific adapter implementation. Each adapter implementation defines its own
In the following example we define a
metrics handler for the
prometheus adapter. The example is in the form of a kubernetes resource: * The
metadata.name is the name of the handler * The
kind refers to the adapter name * The
spec block represents adapter-specific configuration as well as the connection information
### Sample-1: No connection specified (for compiled in adapters) ### Note: if connection information is not specified, the adapter configuration is directly inside ### `spec` block. This is going to be DEPRECATED in favor of Sample-2 apiVersion: "config.istio.io/v1alpha2" kind: prometheus metadata: name: handler namespace: istio-system spec: metrics: - name: request_count instance_name: requestcount.metric.istio-system kind: COUNTER label_names: - source_service - source_version - destination_service - destination_version --- ### Sample-2: With connection information (for out-of-process adapters) ### Note: Unlike sample-1, the adapter configuration is parallel to `connection` and is nested inside `param` block. apiVersion: "config.istio.io/v1alpha2" kind: prometheus metadata: name: handler namespace: istio-system spec: param: metrics: - name: request_count instance_name: requestcount.metric.istio-system kind: COUNTER label_names: - source_service - source_version - destination_service - destination_version connection: address: localhost:8090 ---
An Instance tells Mixer how to create instances for particular template.
Instance is defined by the operator. Instance is defined relative to a known template. Their purpose is to tell Mixer how to use attributes or literals to produce instances of the specified template at runtime.
The following example instructs Mixer to construct an instance associated with template ‘istio.mixer.adapter.metric.Metric’. It provides a mapping from the template’s fields to expressions. Instances produced with this instance can be referenced by Actions using name ‘RequestCountByService’
- name: RequestCountByService template: istio.mixer.adapter.metric.Metric params: value: 1 dimensions: source: source.service destination_ip: destination.ip
A Rule is a selector and a set of intentions to be executed when the selector is
The following example instructs Mixer to invoke ‘prometheus-handler’ handler for all services and pass it the instance constructed using the ‘RequestCountByService’ instance.
- match: destination.service == "*" actions: - handler: prometheus-handler instances: - RequestCountByService
ValueType describes the types that values in the Istio system can take. These are used to describe the type of Attributes at run time, describe the type of the result of evaluating an expression, and to describe the runtime type of fields of other descriptors.
Invalid, default value.
An undiscriminated variable-length string.
An undiscriminated 64-bit signed integer.
An undiscriminated 64-bit floating-point value.
An undiscriminated boolean value.
A point in time.
An IP address.
An email address.
A DNS name.
A span between two points in time.
A map string -> string, typically used by headers.