Collecting Metrics

    The Bookinfo sample application is usedas the example application throughout this task.

    • Apply a YAML file with configuration for the new metricthat Istio will generate and collect automatically.

    If you use Istio 1.1.2 or prior, please use the following configuration instead:

    Zip

    1. $ kubectl apply -f @samples/bookinfo/telemetry/metrics-crd.yaml@
    • Send traffic to the sample application.

    For the Bookinfo sample, visit in your webbrowser or issue the following command:

    • Verify that the new metric values are being generated and collected.

    In a Kubernetes environment, setup port-forwarding for Prometheus byexecuting the following command:

    1. $ kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=prometheus -o jsonpath='{.items[0].metadata.name}') 9090:9090 &

    View values for the new metric via the Prometheus UI.

    The provided link opens the Prometheus UI and executes a query for values ofthe istio_double_request_count metric. The table displayed in theConsole tab includes entries similar to:

    For more on querying Prometheus for metric values, see the task.

    In this task, you added Istio configuration that instructed Mixer toautomatically generate and report a new metric for alltraffic within the mesh.

    The added configuration controlled three pieces of Mixer functionality:

    • Creation of handlers (configured Mixer adapters) capable of processinggenerated instances

    • Dispatch of instances to handlers according to a set of rules

    The metrics configuration directs Mixer to send metric values to Prometheus. Ituses three stanzas (or blocks) of configuration: instance configuration,handler configuration, and rule configuration.

    The kind: instance stanza of configuration defines a schema for generated metric values(or instances) for a new metric named doublerequestcount. This instanceconfiguration tells Mixer how to generate metric values for any given request,based on the attributes reported by Envoy (and generated by Mixer itself).

    For each instance of doublerequestcount, the configuration directs Mixer tosupply a value of 2 for the instance. Because Istio generates an instance foreach request, this means that this metric records a value equal to twice thetotal number of requests received.

    A set of dimensions are specified for each doublerequestcountinstance. Dimensions provide a way to slice, aggregate, and analyze metric dataaccording to different needs and directions of inquiry. For instance, it may bedesirable to only consider requests for a certain destination service whentroubleshooting application behavior.

    The configuration instructs Mixer to populate values for these dimensions basedon attribute values and literal values. For instance, for the dimension, the new configuration requests that the value be taken from thesource.workload.name attribute. If that attribute value is not populated, the ruleinstructs Mixer to use a default value of "unknown". For the messagedimension, a literal value of "twice the fun!" will be used for all instances.

    The kind: handler stanza of configuration defines a handler nameddoublehandler. The handler spec configures how the Prometheus adapter codetranslates received metric instances into Prometheus-formatted values that canbe processed by a Prometheus backend. This configuration specified a newPrometheus metric named doublerequest_count. The Prometheus adapter prependsthe istio namespace to all metric names, therefore this metric will show upin Prometheus as istio_double_request_count. The metric has three labelsmatching the dimensions configured for instances.

    Mixer instances are matched to Prometheus metrics via the instance_name parameter.The instance_name values must be the fully-qualified name for Mixer instances (example:doublerequestcount.instance.istio-system).

    The kind: rule stanza of configuration defines a new rule named doubleprom. Therule directs Mixer to send all doublerequestcount instances to thedoublehandler handler. Because there is no match clause in therule, and because the rule is in the configured default configuration namespace(istio-system), the rule is executed for all requests in the mesh.

    • Remove the new metrics configuration:

    Zip

    1. $ kubectl delete -f @samples/bookinfo/telemetry/metrics.yaml@

    • Remove any processes that may still be running:
      • If you are not planning to explore any follow-on tasks, refer to theBookinfo cleanup instructionsto shutdown the application.

      This task shows you how to query for Istio Metrics using Prometheus.

      收集 TCP 服务指标

      本任务展示了如何配置 Istio 进行 TCP 服务的指标收集。

      Improving availability and reducing latency.

      Mixer Adapter Model

      Provides an overview of Mixer's plug-in architecture.

      了解如何配置代理以向 Jaeger 发送追踪请求。

      How to configure the proxies to send tracing requests to LightStep.