Collecting Metrics for TCP services
This task shows how to configure Istio to automatically gather telemetry for TCPservices in a mesh. At the end of this task, a new metric will be enabled forcalls to a TCP service within your mesh.
The Bookinfo sample application is usedas the example application throughout this task.
Before you begin
Install Istio in your cluster and deploy anapplication.
This task assumes that the Bookinfo sample will be deployed in the
default
namespace. If you use a different namespace, you will need to update theexample configuration and commands.
Collecting new telemetry data
- Apply a YAML file with configuration for the new metrics that Istiowill generate and collect automatically.
$ kubectl apply -f @samples/bookinfo/telemetry/tcp-metrics.yaml@
If you use Istio 1.1.2 or prior, please use the following configuration instead:
$ kubectl apply -f @samples/bookinfo/telemetry/tcp-metrics-crd.yaml@
Setup Bookinfo to use MongoDB.
- Install
v2
of theratings
service.
- Install
If you are using a cluster with automatic sidecar injection enabled,simply deploy the services using kubectl
:
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo-ratings-v2.yaml@
If you are using manual sidecar injection, use the following command instead:
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/platform/kube/bookinfo-ratings-v2.yaml@)
deployment "ratings-v2" configured
- Install the
mongodb
service:
If you are using a cluster with automatic sidecar injection enabled,simply deploy the services using kubectl
:
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo-db.yaml@
If you are using manual sidecar injection, use the following command instead:
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/platform/kube/bookinfo-db.yaml@)
service "mongodb" configured
deployment "mongodb-v1" configured
- The Bookinfo sample deploys multiple versions of each microservice, so you will start by creating destination rulesthat define the service subsets corresponding to each version, and the load balancing policy for each subset.
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all.yaml@
If you enabled mutual TLS, please run the following instead
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
You can display the destination rules with the following command:
$ kubectl get destinationrules -o yaml
Since the subset references in virtual services rely on the destination rules,wait a few seconds for destination rules to propagate before adding virtual services that refer to these subsets.
- Create
ratings
andreviews
virtual services:
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-ratings-db.yaml@
Created config virtual-service/default/reviews at revision 3003
Created config virtual-service/default/ratings at revision 3004
- Send traffic to the sample application.
For the Bookinfo sample, visit http://$GATEWAY_URL/productpage
in your webbrowser or issue the following command:
$ curl http://$GATEWAY_URL/productpage
- Verify that the new metric values are being generated and collected.
In a Kubernetes environment, setup port-forwarding for Prometheus byexecuting the following command:
$ 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 in the Prometheus browser window. Select Graph.Enter the istio_mongo_received_bytes
metric and select Execute.The table displayed in theConsole tab includes entries similar to:
istio_mongo_received_bytes{destination_version="v1",instance="172.17.0.18:42422",job="istio-mesh",source_service="ratings-v2",source_version="v2"}
Understanding TCP telemetry collection
In this task, you added Istio configuration that instructed Mixer toautomatically generate and report a new metric for all traffic to a TCP servicewithin the mesh.
Similar to the Collecting Metrics andLogs Task, the newconfiguration consisted of instances, a handler, and a rule. Please seethat Task for a complete description of the components of metric collection.
Metrics collection for TCP services differs only in the limited set ofattributes that are available for use in instances.
TCP attributes
Several TCP-specific attributes enable TCP policy and control within Istio.These attributes are generated by server-side Envoy proxies. They are forwarded to Mixer at connection establishment, and forwarded periodically when connection is alive (periodical report), and forwarded at connection close (final report). The default interval for periodical report is 10 seconds, and it should be at least 1 second. Additionally, context attributes provide the ability to distinguish between http
and tcp
protocols within policies.
TCP Attribute Flow
Cleanup
- Remove the new telemetry configuration:
$ kubectl delete -f @samples/bookinfo/telemetry/tcp-metrics.yaml@
If you are using Istio 1.1.2 or prior:
$ kubectl delete -f @samples/bookinfo/telemetry/tcp-metrics-crd.yaml@
- Remove the
port-forward
process:
$ killall kubectl
- If you are not planning to explore any follow-on tasks, refer to theBookinfo cleanup instructionsto shutdown the application.
See also
This task shows you how to configure Istio to collect and customize metrics.
Querying Metrics from Prometheus
This task shows you how to query for Istio Metrics using Prometheus.
Consuming External MongoDB Services
Describes a simple scenario based on Istio's Bookinfo example.
Consuming External TCP Services
Describes a simple scenario based on Istio's Bookinfo example.
Improving availability and reducing latency.
Provides an overview of Mixer's plug-in architecture.