Fixing observability concept doc. (#4448)

* fix(telemetry docs): replace p&t concept doc with observability doc

* Fixed broken links

* Fixed one internal and one external link

* Added links and fixed two typos

* Title and links changes

* Added Policies conceptual section

* Fixed broken links in commands reference and traffic mnanagement

content/_index.md

@@ -73,7 +73,7 @@ description: Connect, secure, control, and observe services.
         </div>
 
         <div id="panel3" class="panel">
-            <a href="/docs/concepts/policies-and-telemetry/">
+            <a href="/docs/reference/config/policy-and-telemetry/">
                 <div class="panel-img-top">
                     {{< inline_image "landing/policy-enforcement.svg" >}}
                 </div>
@@ -89,7 +89,7 @@ description: Connect, secure, control, and observe services.
         </div>
 
         <div id="panel4" class="panel">
-            <a href="/docs/concepts/policies-and-telemetry/">
+            <a href="/docs/reference/config/policy-and-telemetry/">
                 <div class="panel-img-top">
                     {{< inline_image "landing/telemetry-and-reporting.svg" >}}
                 </div>

content/about/feature-stages/index.md

@@ -59,7 +59,7 @@ The `Sidecar` runtime is considered Beta.  However, its API is still subject to
 | [Prometheus Integration](/docs/tasks/telemetry/metrics/querying-metrics/) | Stable
 | [Local Logging (STDIO)](/docs/tasks/telemetry/logs/collecting-logs/) | Stable
 | [Statsd Integration](/docs/reference/config/policy-and-telemetry/adapters/statsd/) | Stable
-| [Client and Server Telemetry Reporting](/docs/concepts/policies-and-telemetry/) | Stable
+| [Client and Server Telemetry Reporting](/docs/reference/config/policy-and-telemetry/) | Stable
 | [Service Dashboard in Grafana](/docs/tasks/telemetry/metrics/using-istio-dashboard/) | Stable
 | [Istio Component Dashboard in Grafana](/docs/tasks/telemetry/metrics/using-istio-dashboard/) | Stable
 | [Distributed Tracing](/docs/tasks/telemetry/distributed-tracing/) | Stable

content/blog/2017/adapter-model/index.md

@@ -26,10 +26,10 @@ Adapters are Go packages that are directly linked into the Mixer binary. It’s
 
 ## Philosophy
 
-Mixer is essentially an attribute processing and routing machine. The proxy sends it [attributes](/docs/concepts/policies-and-telemetry/#attributes) as part of doing precondition checks and telemetry reports, which it turns into a series of calls into adapters. The operator supplies configuration which describes how to map incoming attributes to inputs for the adapters.
+Mixer is essentially an attribute processing and routing machine. The proxy sends it [attributes](/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes) as part of doing precondition checks and telemetry reports, which it turns into a series of calls into adapters. The operator supplies configuration which describes how to map incoming attributes to inputs for the adapters.
 
 {{< image width="60%"
-    link="/docs/concepts/policies-and-telemetry/machine.svg"
+    link="/docs/reference/config/policy-and-telemetry/mixer-overview/machine.svg"
     caption="Attribute Machine"
     >}}
 
@@ -39,7 +39,7 @@ Configuration is a complex task. In fact, evidence shows that the overwhelming m
 
 Each adapter that Mixer uses requires some configuration to operate. Typically, adapters need things like the URL to their backend, credentials, caching options, and so forth. Each adapter defines the exact configuration data it needs via a [protobuf](https://developers.google.com/protocol-buffers/) message.
 
-You configure each adapter by creating [*handlers*](/docs/concepts/policies-and-telemetry/#handlers) for them. A handler is a
+You configure each adapter by creating [*handlers*](/docs/reference/config/policy-and-telemetry/mixer-overview/#handlers) for them. A handler is a
 configuration resource which represents a fully configured adapter ready for use. There can be any number of handlers for a single adapter, making it possible to reuse an adapter in different scenarios.
 
 ## Templates: adapter input schema
@@ -54,11 +54,11 @@ Each template is specified as a [protobuf](https://developers.google.com/protoco
 ## Instances: attribute mapping
 
 You control which data is delivered to individual adapters by creating
-[*instances*](/docs/concepts/policies-and-telemetry/#instances).
-Instances control how Mixer uses the [attributes](/docs/concepts/policies-and-telemetry/#attributes) delivered
+[*instances*](/docs/reference/config/policy-and-telemetry/mixer-overview/#instances).
+Instances control how Mixer uses the [attributes](/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes) delivered
 by the proxy into individual bundles of data that can be routed to different adapters.
 
-Creating instances generally requires using [attribute expressions](/docs/concepts/policies-and-telemetry/#attribute-expressions). The point of these expressions is to use any attribute or literal value in order to produce a result that can be assigned to an instance’s field.
+Creating instances generally requires using [attribute expressions](/docs/reference/config/policy-and-telemetry/expression-language/). The point of these expressions is to use any attribute or literal value in order to produce a result that can be assigned to an instance’s field.
 
 Every instance field has a type, as defined in the template, every attribute has a
 [type](https://github.com/istio/api/blob/master/policy/v1beta1/value_type.proto), and every attribute expression has a type.
@@ -68,7 +68,7 @@ to a string field.  This kind of strong typing is designed to minimize the risk
 ## Rules: delivering data to adapters
 
 The last piece to the puzzle is telling Mixer which instances to send to which handler and when. This is done by
-creating [*rules*](/docs/concepts/policies-and-telemetry/#rules). Each rule identifies a specific handler and the set of
+creating [*rules*](/docs/reference/config/policy-and-telemetry/mixer-overview/#rules). Each rule identifies a specific handler and the set of
 instances to send to that handler. Whenever Mixer processes an incoming call, it invokes the indicated handler and gives it the specific set of instances for processing.
 
 Rules contain matching predicates. A predicate is an attribute expression which returns a true/false value. A rule only takes effect if its predicate expression returns true. Otherwise, it’s like the rule didn’t exist and the indicated handler isn’t invoked.
@@ -85,6 +85,6 @@ The refreshed Mixer adapter model is designed to provide a flexible framework to
 
 Handlers provide configuration data for individual adapters, templates determine exactly what kind of data different adapters want to consume at runtime, instances let operators prepare this data, rules direct the data to one or more handlers.
 
-You can learn more about Mixer's overall architecture [here](/docs/concepts/policies-and-telemetry/), and learn the specifics of templates, handlers,
+You can learn more about Mixer's overall architecture [here](/docs/reference/config/policy-and-telemetry/mixer-overview/), and learn the specifics of templates, handlers,
 and rules [here](/docs/reference/config/policy-and-telemetry). You can find many examples of Mixer configuration resources in the Bookinfo sample
 [here]({{< github_tree >}}/samples/bookinfo).

content/blog/2017/mixer-spof-myth/index.md

@@ -10,7 +10,7 @@ aliases:
     - /blog/mixer-spof-myth.html
 ---
 
-As [Mixer](/docs/concepts/policies-and-telemetry/) is in the request path, it is natural to question how it impacts
+As [Mixer](/docs/reference/config/policy-and-telemetry/) is in the request path, it is natural to question how it impacts
 overall system availability and latency. A common refrain we hear when people first glance at Istio architecture diagrams is
 "Isn't this just introducing a single point of failure?"
 

content/docs/concepts/observability/index.md

@@ -0,0 +1,160 @@
+---
+title: Observability
+description: Describes the telemetry and monitoring features provided by Istio.
+weight: 40
+keywords: [policies,telemetry,control,config]
+aliases:
+    - /docs/concepts/policy-and-control/mixer.html
+    - /docs/concepts/policy-and-control/mixer-config.html
+    - /docs/concepts/policy-and-control/attributes.html
+    - /docs/concepts/policies-and-telemetry/overview/
+    - /docs/concepts/policies-and-telemetry/config/
+    - /docs/concepts/policies-and-telemetry/
+---
+
+Istio generates detailed telemetry for all service communications within a mesh. This telemetry provides *observability* of service behavior,
+empowering operators to troubleshoot, maintain, and optimize their applications -- without imposing any additional burdens on service developers. Through
+Istio, operators gain a thorough understanding of how monitored services are interacting, both with other services and with the Istio components themselves.
+
+Istio generates the following types of telemetry in order to provide overall service mesh observability:
+
+- [**Metrics**](#metrics). Istio generates a set of service metrics based on the four "golden signals" of monitoring (latency, traffic, errors, and
+  saturation). Istio also provides detailed metrics for the [mesh control plane](/docs/concepts/what-is-istio/#architecture).
+  A default set of mesh monitoring dashboards built on top of these metrics is also provided.
+- [**Distributed Traces**](#distributed-traces). Istio generates distributed trace spans for each service, providing operators with a detailed understanding
+  of call flows and service dependencies within a mesh.
+- [**Access Logs**](#access-logs). As traffic flows into a service within a mesh, Istio can generate a full record of each request, including source and
+  destination metadata. This information enables operators to audit service behavior down to the individual
+  [workload instance](http://localhost:1313/docs/reference/glossary/#workload-instance) level.
+
+## Metrics
+
+Metrics provide a way of monitoring and understanding behavior in aggregate.
+
+To monitor service behavior, Istio generates metrics for all service traffic in, out, and within an Istio service mesh. These metrics provide information on
+behaviors such as the overall volume of traffic, the error rates within the traffic, and the response times for requests.
+
+In addition to monitoring the behavior of services within a mesh, it is also important to monitor the behavior of the mesh itself. Istio components export
+metrics on their own internal behaviors to provide insight on the health and function of the mesh control plane.
+
+Istio metrics collection is driven by operator configuration. Operators select how and when to collect metrics, as well as how detailed the metrics themselves
+should be. This enables operators to flexibly tune metrics collection to meet their individual needs.
+
+### Proxy-level Metrics
+
+Istio metrics collection begins with the sidecar proxies (Envoy). Each proxy generates a rich set of metrics about all traffic passing through the proxy (both
+inbound and outbound). The proxies also provide detailed statistics about the administrative functions of the proxy itself, including configuration and health
+information.
+
+Envoy-generated metrics provide monitoring of the mesh at the granularity of Envoy resources (such as listeners and clusters). As a result, understanding the
+connection between mesh services and Envoy resources is required for monitoring the Envoy metrics.
+
+Istio enables operators to select which of the Envoy metrics are generated and collected at each workload instance. By default, Istio enables only a small
+subset of the Envoy-generated statistics to avoid overwhelming metrics backends and to reduce the CPU overhead associated with metrics collection. However,
+operators can easily expand the set of collected proxy metrics when required. This enables targeted debugging of networking behavior, while reducing the
+overall cost of monitoring across the mesh.
+
+The [Envoy documentation site](https://www.envoyproxy.io/docs/envoy/latest/) includes a detailed overview of [Envoy statistics collection](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/statistics.html?highlight=statistics).
+The operations guide on [Envoy Statistics](/docs/ops/telemetry/envoy-stats/) provides more information on controlling the generation of proxy-level metrics.
+
+Example proxy-level Metrics:
+
+```json
+envoy_cluster_internal_upstream_rq{response_code_class="2xx",cluster_name="xds-grpc"} 7163
+
+envoy_cluster_upstream_rq_completed{cluster_name="xds-grpc"} 7164
+
+envoy_cluster_ssl_connection_error{cluster_name="xds-grpc"} 0
+
+envoy_cluster_lb_subsets_removed{cluster_name="xds-grpc"} 0
+
+envoy_cluster_internal_upstream_rq{response_code="503",cluster_name="xds-grpc"} 1
+```
+
+### Service-level Metrics
+
+In addition to the proxy-level metrics, Istio provides a set of service-oriented metrics for monitoring service communications. These metrics cover the four
+basic service monitoring needs: latency, traffic, errors, and saturation. Istio ships with a default set of
+[dashboards](/docs/tasks/telemetry/metrics/using-istio-dashboard/) for monitoring service behaviors based on these metrics.
+
+The [default Istio metrics](/docs/reference/config/policy-and-telemetry/metrics/) are defined by a set of configuration artifacts that ship with Istio and are
+exported to [Prometheus](http://localhost:1313/docs/reference/config/policy-and-telemetry/adapters/prometheus/) by default. Operators are free to modify the
+shape and content of these metrics, as well as to change their collection mechanism, to meet their individual monitoring needs.
+
+The [Collecting Metrics](/docs/tasks/telemetry/metrics/collecting-metrics/) task provides more information on customizing Istio metrics generation.
+
+Use of the service-level metrics is entirely optional. Operators may choose to turn off generation and collection of these metrics to meet their individual
+needs.
+
+Example service-level metric:
+
+```json
+istio_requests_total{
+  connection_security_policy="mutual_tls",
+  destination_app="details",
+  destination_principal="cluster.local/ns/default/sa/default",
+  destination_service="details.default.svc.cluster.local",
+  destination_service_name="details",
+  destination_service_namespace="default",
+  destination_version="v1",
+  destination_workload="details-v1",
+  destination_workload_namespace="default",
+  reporter="destination",
+  request_protocol="http",
+  response_code="200",
+  response_flags="-",
+  source_app="productpage",
+  source_principal="cluster.local/ns/default/sa/default",
+  source_version="v1",
+  source_workload="productpage-v1",
+  source_workload_namespace="default"
+} 214
+```
+
+### Control Plane Metrics
+
+Each Istio component (Pilot, Galley, Mixer) also provides a collection of self-monitoring metrics. These metrics allow monitoring of the behavior
+of Istio itself (as distinct from that of the services within the mesh).
+
+For more information on which metrics are maintained, please refer to the reference documentation for each of the components:
+
+- [Pilot](/docs/reference/commands/pilot-discovery/#metrics)
+- [Galley](/docs/reference/commands/galley/#metrics)
+- [Mixer](/docs/reference/commands/mixs/#metrics)
+- [Citadel](/docs/reference/commands/istio_ca/#metrics)
+
+## Distributed Traces
+
+Distributed tracing provides a way to monitor and understand behavior by monitoring individual requests as they flow through a mesh.
+Traces empower mesh operators to understand service dependencies and the sources of latency within their service mesh.
+
+Istio supports distributed tracing through the Envoy proxies. The proxies automatically generate trace spans on behalf of the applications they proxy,
+requiring only that the applications forward the appropriate request context.
+
+Istio supports a number of tracing backends, including [Zipkin](/docs/tasks/telemetry/distributed-tracing/zipkin/),
+[Jaeger](/docs/tasks/telemetry/distributed-tracing/jaeger/), [LightStep](/docs/tasks/telemetry/distributed-tracing/lightstep/), and
+[Datadog](https://www.datadoghq.com/blog/monitor-istio-with-datadog/). Operators control the sampling rate for trace generation (that is, the rate at
+which tracing data is generated per request). This allows operators to control the amount and rate of tracing data being produced for their mesh.
+
+More information about Distributed Tracing with Istio is found in our [FAQ on Distributed Tracing](/faq/distributed-tracing/).
+
+Example Istio-generated distributed trace for a single request:
+
+{{< image link="/docs/tasks/telemetry/distributed-tracing/zipkin/istio-tracing-details-zipkin.png" caption="Distributed Trace for a single request" >}}
+
+## Access Logs
+
+Access logs provide a way to monitor and understand behavior from the perspective of an individual workload instance.
+
+Istio can generate access logs for service traffic in a configurable set of formats, providing operators with full control of the how, what, when and where of
+logging. Istio exposes a full set of source and destination metadata to the access logging mechanisms, allowing detailed audit of network transactions.
+
+Access logs may be generated locally or exported to custom backends, including [Fluentd](/docs/tasks/telemetry/logs/fluentd/).
+
+More information on access logging is provided in the [Collecting Logs](/docs/tasks/telemetry/logs/collecting-logs/) and the [Getting Envoy's Access Logs](/docs/tasks/telemetry/logs/access-log/) tasks.
+
+Example Istio access log (formatted in JSON):
+
+```json
+{"level":"info","time":"2019-06-11T20:57:35.424310Z","instance":"accesslog.instance.istio-control","connection_security_policy":"mutual_tls","destinationApp":"productpage","destinationIp":"10.44.2.15","destinationName":"productpage-v1-6db7564db8-pvsnd","destinationNamespace":"default","destinationOwner":"kubernetes://apis/apps/v1/namespaces/default/deployments/productpage-v1","destinationPrincipal":"cluster.local/ns/default/sa/default","destinationServiceHost":"productpage.default.svc.cluster.local","destinationWorkload":"productpage-v1","httpAuthority":"35.202.6.119","latency":"35.076236ms","method":"GET","protocol":"http","receivedBytes":917,"referer":"","reporter":"destination","requestId":"e3f7cffb-5642-434d-ae75-233a05b06158","requestSize":0,"requestedServerName":"outbound_.9080_._.productpage.default.svc.cluster.local","responseCode":200,"responseFlags":"-","responseSize":4183,"responseTimestamp":"2019-06-11T20:57:35.459150Z","sentBytes":4328,"sourceApp":"istio-ingressgateway","sourceIp":"10.44.0.8","sourceName":"ingressgateway-7748774cbf-bvf4j","sourceNamespace":"istio-control","sourceOwner":"kubernetes://apis/apps/v1/namespaces/istio-control/deployments/ingressgateway","sourcePrincipal":"cluster.local/ns/istio-control/sa/default","sourceWorkload":"ingressgateway","url":"/productpage","userAgent":"curl/7.54.0","xForwardedFor":"10.128.0.35"}
+```

content/docs/concepts/security/index.md

@@ -1,8 +1,8 @@
 ---
-title: Security
+title: Policies and Security
 description: Describes Istio's authorization and authentication functionality.
 weight: 30
-keywords: [security,authentication,authorization,rbac,access-control]
+keywords: [security,policy,policies,authentication,authorization,rbac,access-control]
 aliases:
     - /docs/concepts/network-and-auth/auth.html
     - /docs/concepts/security/authn-policy/
@@ -40,6 +40,18 @@ and audit (AAA) tools to protect your services and data. The goals of Istio secu
 Visit our [Mutual TLS Migration docs](/docs/tasks/security/mtls-migration/) to start using Istio security features with your deployed services.
 Visit our [Security Tasks](/docs/tasks/security/) for detailed instructions to use the security features.
 
+## Policies
+
+Istio lets you configure custom policies for your application to enforce rules at runtime such as:
+
+- Rate limiting to dynamically limit the traffic to a service
+- Denials, whitelists, and blacklists, to restrict access to services
+- Header rewrites and redirects
+
+Istio also lets you create your own [policy adapters](/docs/tasks/policy-enforcement/control-headers) to add, for example, your own custom authorization behavior.
+
+You must enable policy enforcement for your mesh to use this feature.
+
 ## High-level architecture
 
 Security in Istio involves multiple components:
@@ -191,7 +203,7 @@ The photo SRE team creates two service accounts to run `photo-frontend` and
 `photo-backend` respectively in the `photo-ns` namespace. The datastore SRE
 team creates one service account to run the `datastore` service in the
 `datastore-ns` namespace. Moreover, we need to enforce the service access
-control in [Istio Mixer](/docs/concepts/policies-and-telemetry/) such that
+control in [Istio Mixer](/docs/reference/config/policy-and-telemetry/) such that
 `photo-frontend` cannot access datastore.
 
 In this setup, Kubernetes can isolate the operator privileges on managing the services.
@@ -899,4 +911,4 @@ spec:
 
 While we strongly recommend using the Istio authorization mechanisms,
 Istio is flexible enough to allow you to plug in your own authentication and authorization mechanisms via the Mixer component.
-To use and configure plugins in Mixer, visit our [policies and telemetry adapters docs](/docs/concepts/policies-and-telemetry/#adapters).
+To use and configure plugins in Mixer, visit our [policies and telemetry adapters docs](/docs/reference/config/policy-and-telemetry/adapters).

content/docs/concepts/traffic-management/index.md

@@ -260,7 +260,7 @@ and specify the [routing rules](/docs/concepts/traffic-management/#routing-rules
 
 The advantage of this configuration method is that it decouples the application
 code from the evolution of its dependent services. This in turn provides
-monitoring benefits. For details, see [Mixer policies and telemetry](/docs/concepts/policies-and-telemetry/).
+monitoring benefits. For details, see [Mixer policies and telemetry](/docs/reference/config/policy-and-telemetry/).
 
 #### Canary rollouts with autoscaling {#canary}
 

content/docs/concepts/what-is-istio/index.md

@@ -107,7 +107,7 @@ plane**.
 * The **data plane** is composed of a set of intelligent proxies
   ([Envoy](https://www.envoyproxy.io/)) deployed as sidecars. These proxies
   mediate and control all network communication between microservices along
-  with [Mixer](/docs/concepts/policies-and-telemetry/), a general-purpose
+  with [Mixer](/docs/reference/config/policy-and-telemetry/), a general-purpose
   policy and telemetry hub.
 
 * The **control plane** manages and configures the proxies to route traffic.
@@ -143,8 +143,8 @@ for example:
 Envoy is deployed as a **sidecar** to the relevant service in the same
 Kubernetes pod. This deployment allows Istio to extract a wealth of signals
 about traffic behavior as
-[attributes](/docs/concepts/policies-and-telemetry/#attributes). Istio can, in
-turn, use these attributes in [Mixer](/docs/concepts/policies-and-telemetry/)
+[attributes](/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes). Istio can, in
+turn, use these attributes in [Mixer](/docs/reference/config/policy-and-telemetry/)
 to enforce policy decisions, and send them to monitoring systems to provide
 information about the behavior of the entire mesh.
 
@@ -155,14 +155,14 @@ Goals](/docs/concepts/what-is-istio/#design-goals).
 
 ### Mixer
 
-[Mixer](/docs/concepts/policies-and-telemetry/) is a platform-independent
+[Mixer](/docs/reference/config/policy-and-telemetry/) is a platform-independent
 component. Mixer enforces access control and usage policies across the service
 mesh, and collects telemetry data from the Envoy proxy and other services. The
 proxy extracts request level
-[attributes](/docs/concepts/policies-and-telemetry/#attributes), and sends them
+[attributes](/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes), and sends them
 to Mixer for evaluation. You can find more information on this attribute
 extraction and policy evaluation in our [Mixer Configuration
-documentation](/docs/concepts/policies-and-telemetry/#configuration-model).
+documentation](/docs/reference/config/policy-and-telemetry/mixer-overview/#configuration-model).
 
 Mixer includes a flexible plugin model. This model enables Istio to interface
 with a variety of host environments and infrastructure backends. Thus, Istio

content/docs/reference/commands/galley/index.html

@@ -560,8 +560,8 @@ These resource annotations are used by the <code>galley</code> command.
 </tr>
 </tbody>
 </table>
-<h2 id=\"metrics\">Exported Metrics</h2>
-<table class=\"metrics\">
+<h2 id="metrics">Exported Metrics</h2>
+<table class="metrics">
 <thead>
 <tr><th>Metric Name</th><th>Type</th><th>Description</th></tr>
 </thead>

content/docs/reference/commands/istio_ca/index.html

@@ -389,8 +389,8 @@ These resource annotations are used by the <code>istio_ca</code> command.
 </tr>
 </tbody>
 </table>
-<h2 id=\"metrics\">Exported Metrics</h2>
-<table class=\"metrics\">
+<h2 id="metrics">Exported Metrics</h2>
+<table class="metrics">
 <thead>
 <tr><th>Metric Name</th><th>Type</th><th>Description</th></tr>
 </thead>

content/docs/reference/commands/istioctl/index.html

@@ -1965,8 +1965,8 @@ These resource annotations are used by the <code>istioctl</code> command.
 </tr>
 </tbody>
 </table>
-<h2 id=\"metrics\">Exported Metrics</h2>
-<table class=\"metrics\">
+<h2 id="metrics">Exported Metrics</h2>
+<table class="metrics">
 <thead>
 <tr><th>Metric Name</th><th>Type</th><th>Description</th></tr>
 </thead>

content/docs/reference/commands/mixs/index.html

@@ -391,8 +391,8 @@ These resource annotations are used by the <code>mixs</code> command.
 </tr>
 </tbody>
 </table>
-<h2 id=\"metrics\">Exported Metrics</h2>
-<table class=\"metrics\">
+<h2 id="metrics">Exported Metrics</h2>
+<table class="metrics">
 <thead>
 <tr><th>Metric Name</th><th>Type</th><th>Description</th></tr>
 </thead>

content/docs/reference/commands/pilot-discovery/index.html

@@ -647,8 +647,8 @@ These resource annotations are used by the <code>pilot-discovery</code> command.
 </tr>
 </tbody>
 </table>
-<h2 id=\"metrics\">Exported Metrics</h2>
-<table class=\"metrics\">
+<h2 id="metrics">Exported Metrics</h2>
+<table class="metrics">
 <thead>
 <tr><th>Metric Name</th><th>Type</th><th>Description</th></tr>
 </thead>

content/docs/reference/config/policy-and-telemetry/attribute-vocabulary/index.md

@@ -8,7 +8,7 @@ aliases:
 ---
 
 Attributes are a central concept used throughout Istio. You can find a description of what attributes are
-and what they are used for [here](/docs/concepts/policies-and-telemetry/#attributes).
+and what they are used for [here](/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes).
 
 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

content/docs/reference/config/policy-and-telemetry/expression-language/index.md

@@ -10,7 +10,7 @@ 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](/docs/concepts/policies-and-telemetry/#attribute-expressions). CEXL expressions map a set of typed [attributes](/docs/concepts/policies-and-telemetry/#attributes) and constants to a typed
+Mixer configuration uses an expression language (CEXL) to specify match expressions and [mapping expressions](/docs/reference/config/policy-and-telemetry/mixer-overview/#attribute-expressions). CEXL expressions map a set of typed [attributes](/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes) and constants to a typed
 [value](https://github.com/istio/api/blob/master/policy/v1beta1/value_type.proto).
 
 ## Syntax

content/docs/reference/config/policy-and-telemetry/metrics/index.md

@@ -13,29 +13,27 @@ We will describe metrics first and then the labels for each metric.
 
 ## Metrics
 
-*   **Request Count**: This is a `COUNTER` incremented for every
-    request handled by an Istio proxy.
+For HTTP, HTTP/2, and GRPC traffic, Istio generates the following metrics:
 
-*   **Request Duration**: This is a `DISTRIBUTION` which measures the
-    duration of the request.
+*   **Request Count** (`istio_requests_total`): This is a `COUNTER` incremented for every request handled by an Istio proxy.
 
-*   **Request Size**: This is a `DISTRIBUTION` which measures the size
-    of the HTTP request’s body size.
+*   **Request Duration** (`istio_request_duration_seconds`): This is a `DISTRIBUTION` which measures the duration of requests.
 
-*   **Response Size**: This is a `DISTRIBUTION` which measures the size of
-    the HTTP response body size.
+*   **Request Size** (`istio_request_bytes`): This is a `DISTRIBUTION` which measures HTTP request body sizes.
 
-*   **Tcp Byte Sent**: This is a `COUNTER` which measures the size of total
-    bytes sent during response in case of a TCP connection.
+*   **Response Size** (`istio_response_bytes`): This is a `DISTRIBUTION` which measures HTTP response body sizes.
 
-*   **Tcp Byte Received**: This is a `COUNTER` which measures the size of total
+For TCP traffic, Istio generates the following metrics:
+
+*   **Tcp Byte Sent** (`istio_tcp_sent_bytes_total`): This is a `COUNTER` which measures the size of total bytes sent during response in case of a TCP
+    connection.
+
+*   **Tcp Byte Received** (`istio_tcp_received_bytes_total`): This is a `COUNTER` which measures the size of total
     bytes received during request in case of a TCP connection.
 
-*   **Tcp Connections Opened**: This is a `COUNTER` incremented for every opened
-    tcp connection.
+*   **Tcp Connections Opened** (`istio_tcp_connections_opened_total`): This is a `COUNTER` incremented for every opened connection.
 
-*   **Tcp Connections Closed**: This is a `COUNTER` incremented for every closed
-    tcp connection.
+*   **Tcp Connections Closed** (`istio_tcp_connections_closed_total`): This is a `COUNTER` incremented for every closed connection.
 
 ## Labels
 

content/docs/reference/config/policy-and-telemetry/mixer-overview/index.md

@@ -1,7 +1,7 @@
 ---
-title: Policies and Telemetry
-description: Describes the policy enforcement and telemetry mechanisms.
-weight: 40
+title: Mixer Configuration Model 
+description: Describes the configuration model for Istio's policy enforcement and telemetry mechanisms.
+weight: 5
 keywords: [policies,telemetry,control,config]
 aliases:
     - /docs/concepts/policy-and-control/mixer.html
@@ -41,8 +41,6 @@ At a high level, Mixer provides:
 
 * **Intermediation**. Mixer allows operators to have fine-grained control over all interactions between the mesh and infrastructure backends.
 
-Beyond these purely functional aspects, Mixer also has [reliability and scalability](#reliability-and-latency) benefits as outlined below.
-
 Policy enforcement and telemetry collection are entirely driven from configuration.
 Policy check is disabled by default, avoiding the need to go through the Mixer policy component.
 Refer to [Installation Options](/docs/reference/config/installation-options/) for more information.
@@ -68,30 +66,6 @@ extended to target new or custom infrastructure backends.
 
 Learn more about the [set of supported adapters](/docs/reference/config/policy-and-telemetry/adapters/).
 
-## Reliability and latency
-
-Mixer is a highly available component whose design helps increase overall availability and reduce average latency
-of services in the mesh. Key aspects of its design deliver these benefits:
-
-* **Statelessness**. Mixer is stateless in that it doesn’t manage any persistent storage of its own.
-
-* **Hardening**. Mixer proper is designed to be a highly reliable component. The design intent is to achieve > 99.999% uptime for any individual Mixer instance.
-
-* **Caching and Buffering**. Mixer is designed to accumulate a large amount of transient ephemeral state.
-
-The sidecar proxies that sit next to each service instance in the mesh must necessarily be frugal in terms of memory consumption, which constrains the possible amount of local
-caching and buffering. Mixer, however, lives independently and can use considerably larger caches and output buffers. Mixer thus acts as a highly-scaled and highly-available second-level
-cache for the sidecars.
-
-{{< image width="65%" link="./topology-with-cache.svg" caption="Mixer Topology" >}}
-
-Since Mixer’s expected availability is considerably higher than most infrastructure backends (those often have availability of perhaps 99.9%). Mixer's local
-caches and buffers not only contribute to reduce latency, they also help mask infrastructure backend failures by being able to continue operating
-even when a backend has become unresponsive.
-
-Finally, Mixer's caching and buffering helps reduce the frequency of calls to backends, and can sometimes reduce the amount of data
-sent to backends (through local aggregation). Both of these can reduce operational expense in certain cases.
-
 ## Attributes
 
 Attributes are an essential concept to Istio's policy and telemetry functionality.

content/docs/reference/glossary/adapters.md

@@ -2,10 +2,10 @@
 title: Adapters
 ---
 
-Adapters are plug-ins to Mixer, Istio's [policy and telemetry](/docs/concepts/policies-and-telemetry/) component, which enable it to interface
+Adapters are plug-ins to Mixer, Istio's [policy and telemetry](/docs/reference/config/policy-and-telemetry/) component, which enable it to interface
 with an open-ended set of infrastructure backends that deliver core functionality, such as logging,
 monitoring, quotas, ACL checking, and more.
 The exact set of adapters used at runtime is determined through configuration and can easily be
 extended to target new or custom infrastructure backends.
 
-[Learn more about adapters](/docs/concepts/policies-and-telemetry/#adapters).
+[Learn more about adapters](/docs/reference/config/policy-and-telemetry/adapters).

content/docs/reference/glossary/attribute.md

@@ -16,4 +16,4 @@ source.ip: 192.168.0.1
 destination.workload.name: example
 {{< /text >}}
 
-Attributes are used by Istio's [policy and telemetry](/docs/concepts/policies-and-telemetry/) features.
+Attributes are used by Istio's [policy and telemetry](/docs/reference/config/policy-and-telemetry/) features.

content/docs/reference/glossary/mixer.md

@@ -4,4 +4,4 @@ title: Mixer
 
 The Istio component is responsible for enforcing access control and usage policies across the [service mesh](#service-mesh) and collecting telemetry data
 from [Envoy](#envoy) and other services.
-[Learn more about Mixer](/docs/concepts/policies-and-telemetry/).
+[Learn more about Mixer](/docs/reference/config/policy-and-telemetry/).

content_zh/blog/2017/adapter-model/index.md

@@ -26,7 +26,7 @@ Mixer 服务作为 Istio 和一套开放式基础设施之间的抽象层。Isti
 Mixer 本质上就是一个处理属性和路由的机器。代理将[属性](/zh/docs/concepts/policies-and-telemetry/#属性)作为预检和遥测报告的一部分发送出来，并且转换为一系列对适配器的调用。运维人员提供了用于描述如何将传入的属性映射为适配器的配置。
 
 {{< image width="60%"
-    link="/docs/concepts/policies-and-telemetry/machine.svg"
+    link="/docs/reference/config/policy-and-telemetry/mixer-overview/machine.svg"
     caption="Attribute Machine"
     >}}
 

content_zh/docs/concepts/policies-and-telemetry/index.md

@@ -13,7 +13,7 @@ Istio 提供统一抽象，使得 Istio 可以与一组开放式基础设施后
 
 Mixer 是负责提供策略控制和遥测收集的 Istio 组件：
 
-{{< image width="75%" link="topology-without-cache.svg" caption="Mixer 拓扑" >}}
+{{< image width="75%" link="/docs/reference/config/policy-and-telemetry/mixer-overview/topology-without-cache.svg" caption="Mixer 拓扑" >}}
 
 在每次请求执行先决条件检查之前以及在每次报告遥测请求之后，Envoy sidecar 在逻辑上调用 Mixer。
 该 Sidecar 具有本地缓存​，从而可以在缓存中执行相对较大比例的前提条件检查。此外，sidecar 缓冲出站遥测，使其实际上不需要经常调用 Mixer。
@@ -33,7 +33,7 @@ Mixer 是高度模块化和可扩展的组件。它的一个关键功能就是
 
 Mixer 处理不同基础设施后端的灵活性是通过使用通用插件模型实现的。每个插件都被称为 **Adapter**，Mixer 通过它们与不同的基础设施后端连接，这些后端可提供核心功能，例如日志、监控、配额、ACL 检查等。通过配置能够决定在运行时使用的确切的适配器套件，并且可以轻松扩展到新的或定制的基础设施后端。
 
-{{< image width="35%" link="adapters.svg"
+{{< image width="35%" link="/docs/reference/config/policy-and-telemetry/mixer-overview/adapters.svg"
     alt="显示 Mixer 及其适配器"
     caption="Mixer 及其适配器"
     >}}
@@ -50,7 +50,7 @@ Mixer 是一个高可用的组件，其设计有助于提高整体可用性并
 
 网格中每个服务都会有对应的 Sidecar 代理在运行，因此在内存消耗方面，Sidecar 必须厉行节约，这就限制了本地缓存和缓冲的可能数量。然而，独立运行 的 Mixer 可以使用相当大的缓存和输出缓冲区。因此，Mixer 可用作 Sidecar 的高度扩展且高度可用的二级缓存。
 
-{{< image width="75%" link="topology-with-cache.svg"  caption="Mixer 拓扑" >}}
+{{< image width="75%" link="/docs/reference/config/policy-and-telemetry/mixer-overview/topology-with-cache.svg"  caption="Mixer 拓扑" >}}
 
 由于 Mixer 的预期可用性远高于大多数基础设施后端（通常这些可用性可能达到 99.9％）。Mixer 的本地缓存和缓冲不仅有助于减少延迟，而且即使在后端无响应时也能继续运行，从而有助于屏蔽基础设施后端故障。
 
@@ -74,7 +74,7 @@ destination.service: example
 
 Mixer 本质上是一个属性处理机。每个经过 Envoy sidecar 的请求都会调用 Mixer，为 Mixer 提供一组描述请求和请求周围环境的属性。基于 Envoy sidecar 的配置和给定的特定属性集，Mixer 会调用各种基础设施后端。
 
-{{< image width="60%" link="machine.svg" caption="属性机" >}}
+{{< image width="60%" link="/docs/reference/config/policy-and-telemetry/mixer-overview/machine.svg" caption="属性机" >}}
 
 ### 属性词汇