mirror of https://github.com/istio/istio.io.git
15 lines
5.1 KiB
XML
15 lines
5.1 KiB
XML
<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Policies and Telemetry on Istio</title><link>/v1.3/docs/reference/config/policy-and-telemetry/</link><description>Recent content in Policies and Telemetry on Istio</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><atom:link href="/v1.3/docs/reference/config/policy-and-telemetry/feed.xml" rel="self" type="application/rss+xml"/><item><title>Mixer Configuration Model</title><link>/v1.3/docs/reference/config/policy-and-telemetry/mixer-overview/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/policy-and-telemetry/mixer-overview/</guid><description>Istio provides a flexible model to enforce authorization policies and collect telemetry for the services in a mesh.
|
|
Infrastructure backends are designed to provide support functionality used to build services. They include such things as access control systems, telemetry capturing systems, quota enforcement systems, billing systems, and so forth. Services traditionally directly integrate with these backend systems, creating a hard coupling and baking-in specific semantics and usage options.
|
|
Istio provides a uniform abstraction that makes it possible for Istio to interface with an open-ended set of infrastructure backends.</description></item><item><title>Attribute Vocabulary</title><link>/v1.3/docs/reference/config/policy-and-telemetry/attribute-vocabulary/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/policy-and-telemetry/attribute-vocabulary/</guid><description>Attributes are a central concept used throughout Istio. You can find a description of what attributes are and what they are used for here.
|
|
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 Mixer and services can also introduce attributes.</description></item><item><title>Expression Language</title><link>/v1.3/docs/reference/config/policy-and-telemetry/expression-language/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/policy-and-telemetry/expression-language/</guid><description>This page describes how to use the Mixer configuration expression language (CEXL).
|
|
Background Mixer configuration uses an expression language (CEXL) to specify match expressions and mapping expressions. CEXL expressions map a set of typed attributes and constants to a typed value.
|
|
Syntax CEXL accepts a subset of Go expressions, which defines the syntax. CEXL implements a subset of the Go operators that constrains the set of accepted Go expressions. CEXL also supports arbitrary parenthesization.</description></item><item><title>Default Metrics</title><link>/v1.3/docs/reference/config/policy-and-telemetry/metrics/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/policy-and-telemetry/metrics/</guid><description>This page presents details about the metrics that Istio collects when using its initial configuration. You can add and remove metrics by changing configuration at any time, but this is the built-in set. They can be found here under the section with &ldquo;kind: metric”. It uses metric template to define these metrics.
|
|
We will describe metrics first and then the labels for each metric.
|
|
Metrics For HTTP, HTTP/2, and GRPC traffic, Istio generates the following metrics:</description></item><item><title>Mixer Client</title><link>/v1.3/docs/reference/config/policy-and-telemetry/istio.mixer.v1.config.client/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/policy-and-telemetry/istio.mixer.v1.config.client/</guid><description>Describes the configuration state for the Mixer client library that&rsquo;s built into Envoy.
|
|
APIKey APIKey defines the explicit configuration for generating the request.api_key attribute from HTTP requests.
|
|
See API Keys for a general overview of API keys as defined by OpenAPI.
|
|
Field Type Description query string (oneof) API Key is sent as a query parameter. query represents the query string parameter name.
|
|
For example, query=api_key should be used with the following request:</description></item><item><title>Rules</title><link>/v1.3/docs/reference/config/policy-and-telemetry/istio.policy.v1beta1/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/v1.3/docs/reference/config/policy-and-telemetry/istio.policy.v1beta1/</guid><description>Describes the rules used to configure Mixer&rsquo;s policy and telemetry features.
|
|
Action Action describes which Handler to invoke and what data to pass to it for processing.
|
|
The following example instructs Mixer to invoke &lsquo;prometheus-handler&rsquo; handler and pass it the object constructed using the instance &lsquo;RequestCountByService&rsquo;.
|
|
handler: prometheus-handler instances: - RequestCountByService Field Type Description handler string Required. Fully qualified name of the handler to invoke.</description></item></channel></rss> |