Reorganize the Telemetry tasks (#3707)

* Reorg the Telemetry tasks

* Address review comments

* update aliases

* Update links in old blogs, notes, and tasks

content/about/feature-stages/index.md

@@ -51,16 +51,16 @@ Below is our list of existing features and their current phases. This informatio
 
 | Feature           | Phase
 |-------------------|-------------------
-| [Prometheus Integration](/docs/tasks/telemetry/querying-metrics/) | Stable
-| [Local Logging (STDIO)](/docs/tasks/telemetry/) | Stable
+| [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
-| [Service Dashboard in Grafana](/docs/tasks/telemetry/using-istio-dashboard/) | Stable
-| [Istio Component Dashboard in Grafana](/docs/tasks/telemetry/using-istio-dashboard/) | 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
 | [Stackdriver Integration](/docs/reference/config/policy-and-telemetry/adapters/stackdriver/) | Beta
 | [Distributed Tracing to Zipkin / Jaeger](/docs/tasks/telemetry/distributed-tracing/) | Beta
 | [Service Tracing](/docs/tasks/telemetry/distributed-tracing/) | Beta
-| [Logging with Fluentd](/docs/tasks/telemetry/fluentd/) | Beta
+| [Logging with Fluentd](/docs/tasks/telemetry/logs/fluentd/) | Beta
 | [Trace Sampling](/docs/tasks/telemetry/distributed-tracing/overview/#trace-sampling) | Beta
 
 ### Security and Policy Enforcement

content/about/notes/older/0.5/index.md

@@ -35,7 +35,7 @@ providing a flexible fine-grained access control mechanism. [Learn more](https:/
 [Learn more](/docs/concepts/security/#authorization)
 
 - **Fluentd**. Mixer now has an adapter for log collection through [Fluentd](https://www.fluentd.org).
-[Learn more](/docs/tasks/telemetry/fluentd/)
+[Learn more](/docs/tasks/telemetry/logs/fluentd/)
 
 - **Stdio**. The stdio adapter now lets you log to files with support for log rotation & backup, along with a host
 of controls.

content/blog/2018/egress-monitoring-access-control/index.md

@@ -39,9 +39,8 @@ will prevent any possibility for a malicious application to access the forbidden
 * The [Egress Gateway with TLS Origination](/docs/examples/advanced-gateways/egress-gateway-tls-origination/) example
   demonstrates how to allow applications to send HTTP requests to external servers that require HTTPS, while directing
   traffic through egress gateway.
-* The [Collecting Metrics and Logs](/docs/tasks/telemetry/metrics-logs/) task describes how to configure metrics and
-  logs for services in a mesh.
-* The [Visualizing Metrics with Grafana](/docs/tasks/telemetry/using-istio-dashboard/)
+* The [Collecting Metrics](/docs/tasks/telemetry/metrics/collecting-metrics/) task describes how to configure metrics for services in a mesh.
+* The [Visualizing Metrics with Grafana](/docs/tasks/telemetry/metrics/using-istio-dashboard/)
   describes the Istio Dashboard to monitor mesh traffic.
 * The [Basic Access Control](/docs/tasks/policy-enforcement/denial-and-list/) task shows how to control access to
   in-mesh services.

content/blog/2018/soft-multitenancy/index.md

@@ -290,7 +290,7 @@ Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list p
 {{< /text >}}
 
 If the [add-on tools](/docs/tasks/telemetry/), example
-[Prometheus](/docs/tasks/telemetry/querying-metrics/), are deployed
+[Prometheus](/docs/tasks/telemetry/metrics/querying-metrics/), are deployed
 (also limited by an Istio `namespace`) the statistical results returned would represent only
 that traffic seen from that tenant's application namespace.
 

content/docs/tasks/security/mtls-migration/index.md

@@ -20,7 +20,7 @@ and mutual TLS traffic.
 You can configure Istio services to send mutual
 TLS traffic to that service while connections from legacy services will not
 lose communication. Moreover, you can use the
-[Grafana dashboard](/docs/tasks/telemetry/using-istio-dashboard/) to check which services are
+[Grafana dashboard](/docs/tasks/telemetry/metrics/using-istio-dashboard/) to check which services are
 still sending plain text traffic to the service in "PERMISSIVE" mode and choose to lock
 down once the migration is done.
 
@@ -104,7 +104,7 @@ $ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sle
 
 You can also specify a subset of the clients' request to use `ISTIO_MUTUAL` mutual TLS in
 [`DestinationRule`](/docs/reference/config/networking/v1alpha3/destination-rule/).
-After verifying it works by checking [Grafana to monitor](/docs/tasks/telemetry/using-istio-dashboard/),
+After verifying it works by checking [Grafana to monitor](/docs/tasks/telemetry/metrics/using-istio-dashboard/),
 then increase the rollout scope and finally apply to all Istio client services.
 
 ## Lock down to mutual TLS (optional)

content/docs/tasks/telemetry/distributed-tracing/_index.md

@@ -1,6 +1,6 @@
 ---
 title: Distributed Tracing
 description: This task shows you how to configure Istio-enabled applications to collect trace spans.
-weight: 10
+weight: 30
 keywords: [telemetry,tracing]
 ---

content/docs/tasks/telemetry/logs/_index.md

@@ -0,0 +1,5 @@
+---
+title: Logs
+description: Demonstrates the configuration, collection, and processing of Istio mesh logs.
+weight: 20
+---

content/docs/tasks/telemetry/logs/access-log/index.md

@@ -1,8 +1,10 @@
 ---
 title: Getting Envoy's Access Logs
 description: This task shows you how to configure Envoy proxies to print access log to their standard output.
-weight: 9
+weight: 10
 keywords: [telemetry]
+aliases:
+    - /docs/tasks/telemetry/access-log
 ---
 
 The simplest kind of Istio logging is

content/docs/tasks/telemetry/logs/collecting-logs/index.md

@@ -0,0 +1,179 @@
+---
+title: Collecting Logs
+description: This task shows you how to configure Istio to collect and customize logs.
+weight: 10
+keywords: [telemetry,logs]
+---
+
+This task shows how to configure Istio to automatically gather telemetry for
+services in a mesh. At the end of this task, a new log stream will be enabled
+for calls to services within your mesh.
+
+The [Bookinfo](/docs/examples/bookinfo/) sample application is used
+as the example application throughout this task.
+
+## Before you begin
+
+* [Install Istio](/docs/setup/kubernetes) in your cluster and deploy an
+  application. This task assumes that Mixer is setup in a default configuration
+  (`--configDefaultNamespace=istio-system`). If you use a different
+  value, update the configuration and commands in this task to match the value.
+
+## Collecting new logs data
+
+1.  Create a new YAML file to hold configuration for the new log
+    stream that Istio will generate and collect automatically.
+
+    Save the following as `new_logs.yaml`:
+
+    {{< text yaml plain "new_logs.yaml" >}}
+    # Configuration for logentry instances
+    apiVersion: "config.istio.io/v1alpha2"
+    kind: logentry
+    metadata:
+      name: newlog
+      namespace: istio-system
+    spec:
+      severity: '"warning"'
+      timestamp: request.time
+      variables:
+        source: source.labels["app"] | source.workload.name | "unknown"
+        user: source.user | "unknown"
+        destination: destination.labels["app"] | destination.workload.name | "unknown"
+        responseCode: response.code | 0
+        responseSize: response.size | 0
+        latency: response.duration | "0ms"
+      monitored_resource_type: '"UNSPECIFIED"'
+    ---
+    # Configuration for a stdio handler
+    apiVersion: "config.istio.io/v1alpha2"
+    kind: stdio
+    metadata:
+      name: newhandler
+      namespace: istio-system
+    spec:
+     severity_levels:
+       warning: 1 # Params.Level.WARNING
+     outputAsJson: true
+    ---
+    # Rule to send logentry instances to a stdio handler
+    apiVersion: "config.istio.io/v1alpha2"
+    kind: rule
+    metadata:
+      name: newlogstdio
+      namespace: istio-system
+    spec:
+      match: "true" # match for all requests
+      actions:
+       - handler: newhandler.stdio
+         instances:
+         - newlog.logentry
+    ---
+    {{< /text >}}
+
+1.  Push the new configuration.
+
+    {{< text bash >}}
+    $ kubectl apply -f new_logs.yaml
+    Created configuration logentry/istio-system/newlog at revision 1973038
+    Created configuration stdio/istio-system/newhandler at revision 1973039
+    Created configuration rule/istio-system/newlogstdio at revision 1973041
+    {{< /text >}}
+
+1.  Send traffic to the sample application.
+
+    For the Bookinfo sample, visit `http://$GATEWAY_URL/productpage` in your web
+    browser or issue the following command:
+
+    {{< text bash >}}
+    $ curl http://$GATEWAY_URL/productpage
+    {{< /text >}}
+
+1.  Verify that the log stream has been created and is being populated for
+    requests.
+
+    In a Kubernetes environment, search through the logs for the `istio-telemetry` pods as
+    follows:
+
+    {{< text bash json >}}
+    $ kubectl logs -n istio-system -l istio-mixer-type=telemetry -c mixer | grep \"instance\":\"newlog.logentry.istio-system\" | grep -v '"destination":"telemetry"' | grep -v '"destination":"pilot"' | grep -v '"destination":"policy"' | grep -v '"destination":"unknown"'
+    {"level":"warn","time":"2018-09-15T20:46:36.009801Z","instance":"newlog.logentry.istio-system","destination":"details","latency":"13.601485ms","responseCode":200,"responseSize":178,"source":"productpage","user":"unknown"}
+    {"level":"warn","time":"2018-09-15T20:46:36.026993Z","instance":"newlog.logentry.istio-system","destination":"reviews","latency":"919.482857ms","responseCode":200,"responseSize":295,"source":"productpage","user":"unknown"}
+    {"level":"warn","time":"2018-09-15T20:46:35.982761Z","instance":"newlog.logentry.istio-system","destination":"productpage","latency":"968.030256ms","responseCode":200,"responseSize":4415,"source":"istio-ingressgateway","user":"unknown"}
+    {{< /text >}}
+
+## Understanding the logs configuration
+
+In this task, you added Istio configuration that instructed Mixer to
+automatically generate and report a new log stream for all
+traffic within the mesh.
+
+The added configuration controlled three pieces of Mixer functionality:
+
+1. Generation of *instances* (in this example, log entries)
+   from Istio attributes
+
+1. Creation of *handlers* (configured Mixer adapters) capable of processing
+   generated *instances*
+
+1. Dispatch of *instances* to *handlers* according to a set of *rules*
+
+The logs configuration directs Mixer to send log entries to stdout. It uses
+three stanzas (or blocks) of configuration: *instance* configuration, *handler*
+configuration, and *rule* configuration.
+
+The `kind: logentry` stanza of configuration defines a schema for generated log entries
+(or *instances*) named `newlog`. This instance configuration tells Mixer _how_
+to generate log entries for requests based on the attributes reported by Envoy.
+
+The `severity` parameter is used to indicate the log level for any generated
+`logentry`. In this example, a literal value of `"warning"` is used. This value will
+be mapped to supported logging levels by a `logentry` *handler*.
+
+The `timestamp` parameter provides time information for all log entries. In this
+example, the time is provided by the attribute value of `request.time`, as
+provided by Envoy.
+
+The `variables` parameter allows operators to configure what values should be
+included in each `logentry`. A set of expressions controls the mapping from Istio
+attributes and literal values into the values that constitute a `logentry`.
+In this example, each `logentry` instance has a field named `latency` populated
+with the value from the attribute `response.duration`. If there is no known
+value for `response.duration`, the `latency` field will be set to a duration of
+`0ms`.
+
+The `kind: stdio` stanza of configuration defines a *handler* named `newhandler`. The
+handler `spec` configures how the `stdio` adapter code processes received
+`logentry` instances. The `severity_levels` parameter controls how `logentry`
+values for the `severity` field are mapped to supported logging levels. Here,
+the value of `"warning"` is mapped to the `WARNING` log level. The
+`outputAsJson` parameter directs the adapter to generate JSON-formatted log
+lines.
+
+The `kind: rule` stanza of configuration defines a new *rule* named `newlogstdio`. The
+rule directs Mixer to send all `newlog.logentry` instances to the
+`newhandler.stdio` handler. Because the `match` parameter is set to `true`, the
+rule is executed for all requests in the mesh.
+
+A `match: true` expression in the rule specification is not required to
+configure a rule to be executed for all requests. Omitting the entire `match`
+parameter from the `spec` is equivalent to setting `match: true`. It is included
+here to illustrate how to use `match` expressions to control rule execution.
+
+## Cleanup
+
+*   Remove the new logs configuration:
+
+    {{< text bash >}}
+    $ kubectl delete -f new_logs.yaml
+    {{< /text >}}
+
+*   Remove any `kubectl port-forward` processes that may still be running:
+
+    {{< text bash >}}
+    $ killall kubectl
+    {{< /text >}}
+
+* If you are not planning to explore any follow-on tasks, refer to the
+  [Bookinfo cleanup](/docs/examples/bookinfo/#cleanup) instructions
+  to shutdown the application.

content/docs/tasks/telemetry/logs/fluentd/index.md

@@ -1,8 +1,10 @@
 ---
 title: Logging with Fluentd
 description: This task shows you how to configure Istio to log to a Fluentd daemon.
-weight: 60
+weight: 90
 keywords: [telemetry,logging]
+aliases:
+    - /docs/tasks/telemetry/fluentd/
 ---
 
 This task shows how to configure Istio to create custom log entries

content/docs/tasks/telemetry/metrics/_index.md

@@ -0,0 +1,5 @@
+---
+title: Metrics
+description: Demonstrates the configuration, collection, and processing of Istio mesh metrics.
+weight: 1
+---

content/docs/tasks/telemetry/metrics/collecting-metrics/index.md

@@ -1,34 +1,35 @@
 ---
-title: Collecting Metrics and Logs
-description: This task shows you how to configure Istio to collect metrics and logs.
-weight: 20
+title: Collecting Metrics
+description: This task shows you how to configure Istio to collect and customize metrics.
+weight: 10
 keywords: [telemetry,metrics]
 aliases:
     - /docs/tasks/metrics-logs.html
+    - /docs/tasks/telemetry/metrics-logs/
 ---
 
 This task shows how to configure Istio to automatically gather telemetry for
-services in a mesh. At the end of this task, a new metric and a new log stream
-will be enabled for calls to services within your mesh.
+services in a mesh. At the end of this task, a new metric will be enabled for
+calls to services within your mesh.
 
 The [Bookinfo](/docs/examples/bookinfo/) sample application is used
 as the example application throughout this task.
 
 ## Before you begin
 
-* [Install Istio](/docs/setup/) in your cluster and deploy an
+* [Install Istio](/docs/setup/kubernetes) in your cluster and deploy an
   application. This task assumes that Mixer is setup in a default configuration
   (`--configDefaultNamespace=istio-system`). If you use a different
   value, update the configuration and commands in this task to match the value.
 
-## Collecting new telemetry data
+## Collecting new metrics
 
 1.  Create a new YAML file to hold configuration for the new metric and log
     stream that Istio will generate and collect automatically.
 
-    Save the following as `new_telemetry.yaml`:
+    Save the following as `new_metrics.yaml`:
 
-    {{< text yaml >}}
+    {{< text yaml plain "new_metrics.yaml" >}}
     # Configuration for metric instances
     apiVersion: "config.istio.io/v1alpha2"
     kind: metric
@@ -72,61 +73,15 @@ as the example application throughout this task.
       - handler: doublehandler.prometheus
         instances:
         - doublerequestcount.metric
-    ---
-    # Configuration for logentry instances
-    apiVersion: "config.istio.io/v1alpha2"
-    kind: logentry
-    metadata:
-      name: newlog
-      namespace: istio-system
-    spec:
-      severity: '"warning"'
-      timestamp: request.time
-      variables:
-        source: source.labels["app"] | source.workload.name | "unknown"
-        user: source.user | "unknown"
-        destination: destination.labels["app"] | destination.workload.name | "unknown"
-        responseCode: response.code | 0
-        responseSize: response.size | 0
-        latency: response.duration | "0ms"
-      monitored_resource_type: '"UNSPECIFIED"'
-    ---
-    # Configuration for a stdio handler
-    apiVersion: "config.istio.io/v1alpha2"
-    kind: stdio
-    metadata:
-      name: newhandler
-      namespace: istio-system
-    spec:
-     severity_levels:
-       warning: 1 # Params.Level.WARNING
-     outputAsJson: true
-    ---
-    # Rule to send logentry instances to a stdio handler
-    apiVersion: "config.istio.io/v1alpha2"
-    kind: rule
-    metadata:
-      name: newlogstdio
-      namespace: istio-system
-    spec:
-      match: "true" # match for all requests
-      actions:
-       - handler: newhandler.stdio
-         instances:
-         - newlog.logentry
-    ---
     {{< /text >}}
 
 1.  Push the new configuration.
 
     {{< text bash >}}
-    $ kubectl apply -f new_telemetry.yaml
+    $ kubectl apply -f new_metrics.yaml
     Created configuration metric/istio-system/doublerequestcount at revision 1973035
     Created configuration prometheus/istio-system/doublehandler at revision 1973036
     Created configuration rule/istio-system/doubleprom at revision 1973037
-    Created configuration logentry/istio-system/newlog at revision 1973038
-    Created configuration stdio/istio-system/newhandler at revision 1973039
-    Created configuration rule/istio-system/newlogstdio at revision 1973041
     {{< /text >}}
 
 1.  Send traffic to the sample application.
@@ -161,30 +116,17 @@ as the example application throughout this task.
     {{< /text >}}
 
     For more on querying Prometheus for metric values, see the
-    [Querying Istio Metrics](/docs/tasks/telemetry/querying-metrics/) task.
+    [Querying Istio Metrics](/docs/tasks/telemetry/metrics/querying-metrics/) task.
 
-1.  Verify that the logs stream has been created and is being populated for
-    requests.
-
-    In a Kubernetes environment, search through the logs for the `istio-telemetry``` pods as
-    follows:
-
-    {{< text bash json >}}
-    $ kubectl logs -n istio-system -l istio-mixer-type=telemetry -c mixer | grep \"instance\":\"newlog.logentry.istio-system\" | grep -v '"destination":"telemetry"' | grep -v '"destination":"pilot"' | grep -v '"destination":"policy"' | grep -v '"destination":"unknown"'
-    {"level":"warn","time":"2018-09-15T20:46:36.009801Z","instance":"newlog.logentry.istio-system","destination":"details","latency":"13.601485ms","responseCode":200,"responseSize":178,"source":"productpage","user":"unknown"}
-    {"level":"warn","time":"2018-09-15T20:46:36.026993Z","instance":"newlog.logentry.istio-system","destination":"reviews","latency":"919.482857ms","responseCode":200,"responseSize":295,"source":"productpage","user":"unknown"}
-    {"level":"warn","time":"2018-09-15T20:46:35.982761Z","instance":"newlog.logentry.istio-system","destination":"productpage","latency":"968.030256ms","responseCode":200,"responseSize":4415,"source":"istio-ingressgateway","user":"unknown"}
-    {{< /text >}}
-
-## Understanding the telemetry configuration
+## Understanding the metrics configuration
 
 In this task, you added Istio configuration that instructed Mixer to
-automatically generate and report a new metric and a new log stream for all
+automatically generate and report a new metric for all
 traffic within the mesh.
 
 The added configuration controlled three pieces of Mixer functionality:
 
-1. Generation of *instances* (in this example, metric values and log entries)
+1. Generation of *instances* (in this example, metric values)
    from Istio attributes
 
 1. Creation of *handlers* (configured Mixer adapters) capable of processing
@@ -192,8 +134,6 @@ The added configuration controlled three pieces of Mixer functionality:
 
 1. Dispatch of *instances* to *handlers* according to a set of *rules*
 
-### Understanding the metrics configuration
-
 The metrics configuration directs Mixer to send metric values to Prometheus. It
 uses three stanzas (or blocks) of configuration: *instance* configuration,
 *handler* configuration, and *rule* configuration.
@@ -241,56 +181,12 @@ rule directs Mixer to send all `doublerequestcount.metric` instances to the
 rule, and because the rule is in the configured default configuration namespace
 (`istio-system`), the rule is executed for all requests in the mesh.
 
-### Understanding the logs configuration
-
-The logs configuration directs Mixer to send log entries to stdout. It uses
-three stanzas (or blocks) of configuration: *instance* configuration, *handler*
-configuration, and *rule* configuration.
-
-The `kind: logentry` stanza of configuration defines a schema for generated log entries
-(or *instances*) named `newlog`. This instance configuration tells Mixer _how_
-to generate log entries for requests based on the attributes reported by Envoy.
-
-The `severity` parameter is used to indicate the log level for any generated
-`logentry`. In this example, a literal value of `"warning"` is used. This value will
-be mapped to supported logging levels by a `logentry` *handler*.
-
-The `timestamp` parameter provides time information for all log entries. In this
-example, the time is provided by the attribute value of `request.time`, as
-provided by Envoy.
-
-The `variables` parameter allows operators to configure what values should be
-included in each `logentry`. A set of expressions controls the mapping from Istio
-attributes and literal values into the values that constitute a `logentry`.
-In this example, each `logentry` instance has a field named `latency` populated
-with the value from the attribute `response.duration`. If there is no known
-value for `response.duration`, the `latency` field will be set to a duration of
-`0ms`.
-
-The `kind: stdio` stanza of configuration defines a *handler* named `newhandler`. The
-handler `spec` configures how the `stdio` adapter code processes received
-`logentry` instances. The `severity_levels` parameter controls how `logentry`
-values for the `severity` field are mapped to supported logging levels. Here,
-the value of `"warning"` is mapped to the `WARNING` log level. The
-`outputAsJson` parameter directs the adapter to generate JSON-formatted log
-lines.
-
-The `kind: rule` stanza of configuration defines a new *rule* named `newlogstdio`. The
-rule directs Mixer to send all `newlog.logentry` instances to the
-`newhandler.stdio` handler. Because the `match` parameter is set to `true`, the
-rule is executed for all requests in the mesh.
-
-A `match: true` expression in the rule specification is not required to
-configure a rule to be executed for all requests. Omitting the entire `match`
-parameter from the `spec` is equivalent to setting `match: true`. It is included
-here to illustrate how to use `match` expressions to control rule execution.
-
 ## Cleanup
 
-*   Remove the new telemetry configuration:
+*   Remove the new metrics configuration:
 
     {{< text bash >}}
-    $ kubectl delete -f new_telemetry.yaml
+    $ kubectl delete -f new_metrics.yaml
     {{< /text >}}
 
 *   Remove any `kubectl port-forward` processes that may still be running:

content/docs/tasks/telemetry/metrics/querying-metrics/index.md

@@ -3,6 +3,8 @@ title: Querying Metrics from Prometheus
 description: This task shows you how to query for Istio Metrics using Prometheus.
 weight: 30
 keywords: [telemetry,metrics]
+aliases:
+    - /docs/tasks/telemetry/querying-metrics/
 ---
 
 This task shows you how to query for Istio Metrics using Prometheus. As part of

content/docs/tasks/telemetry/metrics/tcp-metrics/index.md

@@ -1,8 +1,10 @@
 ---
 title: Collecting Metrics for TCP services
 description: This task shows you how to configure Istio to collect metrics for TCP services.
-weight: 25
+weight: 20
 keywords: [telemetry,metrics,tcp]
+aliases:
+    - /docs/tasks/telemetry/tcp-metrics
 ---
 
 This task shows how to configure Istio to automatically gather telemetry for TCP
@@ -14,7 +16,7 @@ as the example application throughout this task.
 
 ## Before you begin
 
-* [Install Istio](/docs/setup/) in your cluster and deploy an
+* [Install Istio](/docs/setup/kubernetes) in your cluster and deploy an
 application.
 
 * This task assumes that the Bookinfo sample will be deployed in the `default`
@@ -208,7 +210,7 @@ automatically generate and report a new metric for all traffic to a TCP service
 within the mesh.
 
 Similar to the [Collecting Metrics and
-Logs](/docs/tasks/telemetry/metrics-logs/) Task, the new
+Logs](/docs/tasks/telemetry/metrics/collecting-metrics/) Task, the new
 configuration consisted of _instances_, a _handler_, and a _rule_. Please see
 that Task for a complete description of the components of metric collection.
 

content/docs/tasks/telemetry/metrics/using-istio-dashboard/index.md

@@ -3,6 +3,8 @@ title: Visualizing Metrics with Grafana
 description: This task shows you how to setup and use the Istio Dashboard to monitor mesh traffic.
 weight: 40
 keywords: [telemetry,visualization]
+aliases:
+    - /docs/tasks/telemetry/using-istio-dashboard/
 ---
 
 This task shows you how to setup and use the Istio Dashboard to monitor mesh

content/help/faq/metrics-and-logs/accessing-telemetry-via-rest.md

@@ -3,5 +3,5 @@ title: Can Istio metrics be accessed through REST?
 weight: 0
 ---
 
-You can collect telemetry data about Istio using [Prometheus](/docs/tasks/telemetry/querying-metrics/). And then use
+You can collect telemetry data about Istio using [Prometheus](/docs/tasks/telemetry/metrics/querying-metrics/). And then use
 [Prometheus’s HTTP API](https://prometheus.io/docs/prometheus/latest/querying/api/) to query that data.

content_zh/docs/tasks/telemetry/querying-metrics/index.md

@@ -53,7 +53,7 @@ keywords: [telemetry,metrics]
 
 结果将类似于：
 
-{{< image link="/docs/tasks/telemetry/querying-metrics/prometheus_query_result.png" caption="Prometheus 查询结果" >}}
+{{< image link="/docs/tasks/telemetry/metrics/querying-metrics/prometheus_query_result.png" caption="Prometheus 查询结果" >}}
 
 其他查询尝试：
 

content_zh/docs/tasks/telemetry/tcp-metrics/index.md

@@ -186,7 +186,7 @@ _instances_ 中属性集的可选范围不同，是 TCP 服务的指标收集过
 
 TCP 相关的属性是 Istio 中 TCP 策略和控制的基础。这些属性是由服务端的 Envoy 代理生成的。它们在连接建立时发给 Mixer，在连接的存活期间周期性的进行发送（周期性报告），最后在连接关闭时再次发送（最终报告）。周期性报告的缺省间隔时间为 10 秒钟，最小取值为 1 秒。另外上下文属性让策略有了区分 `http` 和 `tcp` 协议的能力。
 
-{{< image link="/docs/tasks/telemetry/tcp-metrics/istio-tcp-attribute-flow.svg"
+{{< image link="/docs/tasks/telemetry/metrics/tcp-metrics/istio-tcp-attribute-flow.svg"
     alt="Istio 服务网格中的 TCP 服务属性生成流程"
     caption="TCP 属性流程"
     >}}

content_zh/docs/tasks/telemetry/using-istio-dashboard/index.md

@@ -49,7 +49,7 @@ keywords: [telemetry,visualization]
 
     Istio Dashboard 大致会显示如下内容：
 
-    {{< image link="./grafana-istio-dashboard.png" caption="Istio Dashboard" >}}
+    {{< image link="/docs/tasks/telemetry/metrics/using-istio-dashboard/grafana-istio-dashboard.png" caption="Istio Dashboard" >}}
 
 1. 向网格中发送流量。
 
@@ -67,7 +67,7 @@ keywords: [telemetry,visualization]
 
     再次打开 Istio Dashboard，会看到其中显示了刚刚生成的流量，大致如图所示：
 
-    {{< image link="./dashboard-with-traffic.png" caption="Istio Dashboard" >}}
+    {{< image link="/docs/tasks/telemetry/metrics/using-istio-dashboard/dashboard-with-traffic.png" caption="Istio Dashboard" >}}
 
     这里给出的是全网格范围内服务和工作负载的概况。可以浏览每个服务或工作负载，来获取特定目标的 Dashboard。下面会进行简单的介绍。
 
@@ -77,7 +77,7 @@ keywords: [telemetry,visualization]
 
     Istio 的服务 Dashboard 大致如图所示：
 
-    {{< image link="./istio-service-dashboard.png" caption="Istio 服务 Dashboard" >}}
+    {{< image link="/docs/tasks/telemetry/metrics/using-istio-dashboard/istio-service-dashboard.png" caption="Istio 服务 Dashboard" >}}
 
     这里给出了指定服务的详细指标，还有该服务的客户端工作负载（正在调用这一服务的工作负载）以及服务端工作负载（提供服务的工作负载）。
 
@@ -87,7 +87,7 @@ keywords: [telemetry,visualization]
 
     Istio 工作负载 Dashboard 大致如图所示：
 
-    {{< image link="./istio-workload-dashboard.png" caption="Istio 工作负载 Dashboard" >}}
+    {{< image link="/docs/tasks/telemetry/metrics/using-istio-dashboard/istio-workload-dashboard.png" caption="Istio 工作负载 Dashboard" >}}
 
     这里展示了每个工作负载的指标数据，还有相关的入站工作负载（向本工作负载发送请求的工作负载）以及该工作负载请求的服务。