The Mixer exposes three gRPC methods: Check, Report, and Quota.
All three methods use a consistent request style consisting of three
pieces of state:
-
Request Identification. An integer generated by the caller that uniquely identifies the particular request. This value is returned by the mixer in the response message which makes it possible for the caller to correlate incoming responses with the original requests it sent out.
-
Facts. A map of name/value pairs describing a set of known facts discovered and/or known by the caller. These facts are processed by the mixer to produce labels with which policy and telemetry routing operate.
-
Arguments. The operation-specific arguments for the call.
To learn more...
Service preconditions are used to restrict access by a service consumer to a service's facilities. For example, a service may need to ensure the caller is on a whitelist or not on a blacklist, or that the caller has valid credentials, etc.
The Istio mixer provides a simple Check call used to verify
preconditions. The results of a precondition check are highly
cachable and mixer clients are expected to do so for best
performance. The infrastructure is designed to facilitate this.
Once you have published a managed service, you can call the
Check method for the service without additional configuration.
The following example shows the shape of a request to perform a
single check:
TBD
The response from the Check method indicates whether the check succeeded.
The Istio mixer can be used to send logs to both service producers and service consumers. The mixer accepts structured or unstructured log data, which it batches and forwards to the appropriate configured monitoring backend such as 'Stackdriver Logging'.
Whereas Stackdriver Logging and similar systems allow a service to produce logs for
the sake of the service's producer, the Istio mixer also lets you
produce logs that are intended for the service consumers.
This makes it possible for service consumers to understand and diagnose their
use of the service.
Before you send logs to the mixer, you need to specify three different bits of information in your service configuration:
-
Log names: You can have one or more distinct logs. Each log is identified by a unique name. Individual logs make it possible for you to isolate distinct types of data if it makes the data easier to visualize or use.
-
Monitored resources: Monitored Resources control the shape of the data that is held within a given log.
-
Log configuration: Lets you specify the monitored resource associated with any log stream and the destination (producer or consumer) where each log should be sent.
In the following example of service configuration state, the log
activity_log is configured to be sent to the service consumer.
# The monitored resource to be used.
monitored_resources:
- name: api
labels:
- key: cloud.googleapis.com/location
- key: serviceruntime.googleapis.com/api_version
- key: serviceruntime.googleapis.com/api_method
- key: cloud.googleapis.com/project
- key: cloud.googleapis.com/service
# The log name to be used.
logs:
- name: activity_log
# The logging configuration.
logging:
consumer_destinations:
- monitored_resource: api
logs:
- activity_log
Once you have configured logs in the service configuration
you can call the mixer's Report API to record log entries.
The following example shows the shape of a request reporting a
single log entry.
TBD
The Istio mixer can be used to produce monitoring data to send to service producers and service consumers. Monitoring provides visibility into the performance, uptime, and overall health of individual services.
The mixer accepts metrics, which it batches and aggregates and forwards to the appropriate configured monitoring backend such as 'Stackdriver Monitoring'.
Whereas Stackdriver Monitorring and similar systems allow a service to
produce monitoring data for the sake of the service's producer, the Istio mixer is
designed to also produce monitoring data which is intended for the service's consumers.
This makes it possible for service consumers to understand and diagnose use
of the service.
Before you send monitoring data to the mixer, you need to specify three different bits of information in your service configuration:
-
Metric names: You can report one or more metrics. Each metric represents a single piece of state whose value is tracked over time.
-
Monitored resources: A Monitored Resource represents an entity that originates some monitoring data or is the subject of it.
-
Monitoring configuration: Lets you specify the metrics associated with individual monitored resources and the destination (producer or consumer) where the monitoring data should be sent.
In the following example of service configuration state, we define a
monitored resource and a metric. A client can invoke the Report
method to report values on the metric.
# The monitored resource to be used.
monitored_resources:
- name: api
labels:
- key: cloud.googleapis.com/location
- key: serviceruntime.googleapis.com/api_version
- key: serviceruntime.googleapis.com/api_method
- key: cloud.googleapis.com/project
- key: cloud.googleapis.com/service
- key: cloud.googleapis.com/uid
# The metrics to be used.
metrics:
- name: serviceruntime.googleapis.com/api/consumer/request_count
metric_kind: DELTA
value_type: INT64
labels:
- key: cloud.googleapis.com/day_of_week
# The monitoring configuration.
monitoring:
producer_destinations:
- monitored_resource: api
metrics:
- serviceruntime.googleapis.com/api/consumer/request_count
consumer_destinations:
- monitored_resource: api
metrics:
- serviceruntime.googleapis.com/api/consumer/request_count
Once you have configured metrics in the service configuration, you
can cell the mixer's Report method to record metric values.
The following example shows the shape of a request reporting a
single metric.
TBD
TBD