Solicita registros de proxy
Cloud Service Mesh admite dos tipos diferentes de registros de acceso en Cloud Logging: Registros de tráfico (también conocidos como registros de acceso de Google Cloud Observability) y Registros de acceso de Envoy. En esta página, se muestra cómo habilitar, inhabilitar, ver e interpretar estos registros. Ten en cuenta que los registros de tráfico habilitado de forma predeterminada.
Habilita y habilita los registros de acceso
Cloud Service Mesh administrada
Registros de acceso de Envoy
Ejecuta el siguiente comando para habilitar los registros de acceso de Envoy y, luego, inhabilita los registros de tráfico:
cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: enable-envoy-disable-sd
namespace: istio-system
spec:
accessLogging:
- providers:
- name: envoy
- providers:
- name: stackdriver
disabled: true
EOF
Ten en cuenta que el nombre del proveedor del registro de tráfico es stackdriver
.
Registros de tráfico
De forma predeterminada, los registros de tráfico están habilitados y los registros de acceso de Envoy están inhabilitados. Si anteriormente habilitaste los registros de acceso de Envoy y quieres habilitar inhabilitar los registros de acceso de Envoy, ejecuta el siguiente comando:
cat <<EOF | kubectl apply -n istio-system -f -
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: disable-envoy-enable-sd
namespace: istio-system
spec:
accessLogging:
- providers:
- name: envoy
disabled: true
- providers:
- name: stackdriver
EOF
Ambos
Para habilitar los registros de acceso y de tráfico de Envoy, ejecuta el siguiente comando: :
cat <<EOF | kubectl apply -n istio-system -f - apiVersion: telemetry.istio.io/v1alpha1 kind: Telemetry metadata: name: enable-envoy-and-sd-access-log namespace: istio-system spec: accessLogging: - providers: - name: envoy - name: stackdriver EOF
Para inhabilitar los registros de acceso y de tráfico de Envoy, ejecuta el siguiente comando:
cat <<EOF | kubectl apply -n istio-system -f - apiVersion: telemetry.istio.io/v1alpha1 kind: Telemetry metadata: name: disable-envoy-and-sd namespace: istio-system spec: accessLogging: - providers: - name: envoy disabled: true - providers: - name: stackdriver disabled: true EOF
istiod
administrado
Registros de acceso de Envoy
Ejecuta los siguientes comandos para habilitar el registro de acceso de Envoy:
Ejecuta el siguiente comando para agregar
accessLogFile: /dev/stdout
:cat <<EOF | kubectl apply -f - apiVersion: v1 data: mesh: |- accessLogFile: /dev/stdout kind: ConfigMap metadata: name: istio-release-channel namespace: istio-system EOF
En el ejemplo anterior, release-channel es tu canal de versiones (
asm-managed
,asm-managed-stable
oasm-managed-rapid
).Ejecuta el siguiente comando para ver el configmap:
kubectl get configmap istio-release-channel -n istio-system -o yaml
Para verificar que el registro de acceso esté habilitado, asegúrate de que el La línea
accessLogFile: /dev/stdout
aparece en la secciónmesh:
.... apiVersion: v1 data: mesh: | .... accessLogFile: /dev/stdout ...
Registros de tráfico
Los registros de tráfico están habilitados de forma predeterminada.
En el clúster
Registros de acceso de Envoy
Para obtener más información, consulta Habilita el registro de acceso de Envoy.
Registros de tráfico
Los registros de tráfico están habilitados de forma predeterminada, a menos que Cloud Service Mesh esté instalado en Google Distributed Cloud con la AC de Istio (antes conocida como Citadel).
Habilitar los registros de tráfico en Google Distributed Cloud con la CA de Istio
Cuando instales Cloud Service Mesh en el clúster,
y, luego, usa la marca --option stackdriver
. Como alternativa, puedes habilitar el tráfico
registros en Google Distributed Cloud con la AC de Istio
después de instalar Cloud Service Mesh en el clúster.
Consulta los registros de acceso
Registros de acceso de Envoy
Línea de comandos
Para ver los registros de acceso de Envoy en el registro de istio-proxy, ejecuta el siguiente comando:
kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy
Explorador de registros
Para ver los registros de acceso de Envoy en Explorador de registros:
Navega al Explorador de registros:
Selecciona el proyecto de Google Cloud adecuado.
Ejecute la siguiente consulta:
resource.type="k8s_container" \
resource.labels.container_name="istio-proxy"
resource.labels.cluster_name="CLUSTER_NAME" \
resource.labels.namespace_name="NAMESPACE_NAME" \
resource.labels.pod_name="POD_NAME"
Registros de tráfico
Para ver los registros de tráfico en la Explorador de registros:
Navega al Explorador de registros:
Selecciona el proyecto de Google Cloud adecuado.
Ejecuta la siguiente consulta dependiendo de si estás viendo el cliente de acceso al servidor:
Registros del servidor
resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/server-accesslog-stackdriver"
Registros de clientes
resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/client-accesslog-stackdriver"
Para ver los registros de tráfico en la página de la malla de servicios de Cloud de un servicio durante un período específico, sigue estos pasos:
En la consola de Google Cloud, ve a la página Cloud Service Mesh.
En Services, selecciona el nombre del Service que deseas inspeccionar.
Ve a la página Métricas.
Especifica un período en el menú desplegable Intervalo de tiempo, o bien establecer un intervalo personalizado con el cronograma.
En filter_list Seleccionar una opción de filtro, haz clic en Consulta los registros de tráfico.
El registro de tráfico se llama server-accesslog-stackdriver y está conectado al recurso supervisado correspondiente (k8s_container o gce_instance) tu servicio está usan. El registro de tráfico contiene la siguiente información:
Propiedades de la solicitud HTTP, como el ID, la URL, el tamaño, la latencia y los encabezados comunes
Información de la carga de trabajo de origen y de destino, como el nombre, el espacio de nombres, la identidad y las etiquetas comunes
Información de seguimiento, como el muestreo, el ID de seguimiento y el ID del intervalo (si el seguimiento está habilitado)
A continuación, se muestra un ejemplo de una entrada de registro:
{ insertId: "1awb4hug5pos2qi" httpRequest: { requestMethod: "GET" requestUrl: "YOUR-INGRESS/productpage" requestSize: "952" status: 200 responseSize: "5875" remoteIp: "10.8.0.44:0" serverIp: "10.56.4.25:9080" latency: "1.587232023s" protocol: "http" } resource: { type: "k8s_container" labels: { location: "us-central1-a" project_id: "YOUR-PROJECT" pod_name: "productpage-v1-76589d9fdc-ptnt9" cluster_name: "YOUR-CLUSTER-NAME" container_name: "productpage" namespace_name: "default" } } timestamp: "2020-04-28T19:55:21.056759Z" severity: "INFO" labels: { destination_principal: "spiffe://cluster.local/ns/default/sa/bookinfo-productpage" response_flag: "-" destination_service_host: "productpage.default.svc.cluster.local" source_app: "istio-ingressgateway" service_authentication_policy: "MUTUAL_TLS" source_name: "istio-ingressgateway-5ff85d8dd8-mwplb" mesh_uid: "YOUR-MESH-UID" request_id: "021ce752-9001-4ac6-b6d6-3b15f5d3632" destination_namespace: "default" source_principal: "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account" destination_workload: "productpage-v1" destination_version: "v1" source_namespace: "istio-system" source_workload: "istio-ingressgateway" destination_name: "productpage-v1-76589d9fdc-ptnt9" destination_app: "productpage" } trace: "projects/YOUR-PROJECT/traces/d4197f59b7a43e3aeff3571bac99d536" receiveTimestamp: "2020-04-29T03:07:14.362416217Z" spanId: "43226343ca2bb2b1" traceSampled: true logName: "projects/YOUR-PROJECT/logs/server-accesslog-stackdriver" receiveTimestamp: "2020-04-28T19:55:32.185229100Z" }
Interpretar la telemetría de la malla de servicios de Cloud
En las siguientes secciones, se explica cómo comprobar el estado de la malla y revisar los diversos datos de telemetría que contienen detalles útiles para asistir a tu y la solución de problemas.
Interpreta las métricas del plano de control
Cloud Service Mesh administrada
Cloud Service Mesh con un plano de control administrado no es compatible con las métricas del plano de control.
istiod
administrado
Cloud Service Mesh con un plano de control istiod
administrado no admite la inspección de métricas del plano de control en esta sección.
En el clúster
Cuando instalas Cloud Service Mesh con el plano de control en el clúster, istiod
exporta las métricas a Google Cloud Observability para la supervisión, de forma predeterminada.
istiod
aplica el prefijo istio.io/control
a estas métricas y brinda estadísticas sobre el estado del plano de control, como la cantidad de proxies conectados a cada instancia del plano de control, los eventos de configuración, los envíos y las validaciones.
Sigue los pasos a continuación para observar o solucionar problemas del plano de control.
Carga un panel de muestra:
git clone https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples && cd monitoring-dashboard-samples/dashboards && git checkout servicemesh
Instala el panel de Cloud Service Mesh:
gcloud monitoring dashboards create --config-from-file=dashboards/servicemesh/anthos-service-mesh-control-plane-monitoring.json
Busca un panel llamado
Istio Control Plane Dashboard
en la lista. Para obtener más información, consulta Visualiza el panel instalado.
Para ver la lista completa de métricas disponibles, consulta Métricas exportadas.
Diagnostica demoras en la configuración
Cloud Service Mesh administrada
Cloud Service Mesh con un plano de control administrado no admite diagnósitcar retrasos en la configuración.
istiod
administrado
La malla de servicios de Cloud con un plano de control istiod administrado no es compatible y el diagnóstico de los retrasos de configuración.
En el clúster
En los siguientes pasos, se explica cómo usar la métrica pilot_proxy_convergence_time
para diagnosticar una demora entre un cambio de configuración y todos los proxies que convergen.
Ejecuta un comando de shell en un Pod:
kubectl debug --image istio/base --target istio-proxy -it $(kubectl get pod -l app=pilot -o jsonpath='{.items[0].metadata.name}' -n istio-system) -n istio-system -- curl -s
Accede a
localhost:15014
ygrep
paraconvergence
en métricas:curl http://localhost:15014/metrics | grep convergence
Interpreta los registros de tráfico
En la siguiente información, se explica cómo usar los registros de tráfico para solucionar problemas de conexión. Los registros de tráfico están habilitados de forma predeterminada.
Cloud Service Mesh exporta datos a los registros de tráfico que pueden ayudarte a depurar los siguientes tipos de problemas:
- Fallas y flujo de tráfico
- Enrutamiento de solicitudes de extremo a extremo
Los registros de tráfico están habilitados de forma predeterminada para las instalaciones de Cloud Service Mesh
Google Kubernetes Engine. Para habilitar los registros de tráfico, vuelve a ejecutar asmcli install
. Usa
las mismas opciones que instalaste originalmente, pero omite la superposición personalizada que
inhabilitado Stackdriver.
Existen dos tipos de registros de tráfico:
Los registros de acceso al servidor proporcionan una vista de las solicitudes del servidor. Se encuentran en
server-accesslog-stackdriver
, adjuntos al recurso supervisadok8s_container
. Usa la siguiente sintaxis de URL para mostrar los registros de acceso del servidor:https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"&project=PROJECT_ID
Los registros de acceso del cliente proporcionan una vista de las solicitudes del cliente. Se encuentran en
client-accesslog-stackdriver
, adjuntos al recurso supervisadok8s_pod
. Usa la siguiente sintaxis de URL para mostrar los registros de acceso del cliente:https://console.cloud.google.com/logs/viewer?advancedFilter=logName="projects/PROJECT_ID/logs/client-accesslog-stackdriver"&project=PROJECT_ID
Los registros de acceso contienen la siguiente información:
- Propiedades de la solicitud HTTP, como el ID, la URL, el tamaño, la latencia y los encabezados comunes
- Información de la carga de trabajo de origen y de destino, como el nombre, el espacio de nombres, la identidad y las etiquetas comunes
- Información de revisión y del servicio canónico de origen y destino
- Información de seguimiento de los registros, como ID de seguimiento, ID de intervalo y muestreo, si está habilitado el seguimiento
Los registros de tráfico pueden contener las siguientes etiquetas:
route_name
upstream_cluster
X-Envoy-Original-Path
Este es un ejemplo de una entrada de registro:
{ "insertId": "1j84zg8g68vb62z", "httpRequest": { "requestMethod": "GET", "requestUrl": "http://35.235.89.201:80/productpage", "requestSize": "795", "status": 200, "responseSize": "7005", "remoteIp": "10.168.0.26:0", "serverIp": "10.36.3.153:9080", "latency": "0.229384205s", "protocol": "http" }, "resource": { "type": "k8s_container", "labels": { "cluster_name": "istio-e2e22", "namespace_name": "istio-bookinfo-1-68819", "container_name": "productpage", "project_id": "***", "location": "us-west2-a", "pod_name": "productpage-v1-64794f5db4-8xbtf" } }, "timestamp": "2020-08-13T21:37:42.963881Z", "severity": "INFO", "labels": { "protocol": "http", "upstream_host": "127.0.0.1:9080", "source_canonical_service": "istio-ingressgateway", "source_namespace": "istio-system", "x-envoy-original-path": "", "source_canonical_revision": "latest", "connection_id": "32", "upstream_cluster": "inbound|9080|http|productpage.istio-bookinfo-1-68819.svc.cluster.local", "requested_server_name": "outbound_.9080_._.productpage.istio-bookinfo-1-68819.svc.cluster.local", "destination_version": "v1", "destination_workload": "productpage-v1", "source_workload": "istio-ingressgateway", "destination_canonical_revision": "v1", "mesh_uid": "cluster.local", "source_principal": "spiffe://cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account", "x-envoy-original-dst-host": "", "service_authentication_policy": "MUTUAL_TLS", "destination_principal": "spiffe://cluster.local/ns/istio-bookinfo-1-68819/sa/bookinfo-productpage", "response_flag": "-", "log_sampled": "false", "destination_service_host": "productpage.istio-bookinfo-1-68819.svc.cluster.local", "destination_name": "productpage-v1-64794f5db4-8xbtf", "destination_canonical_service": "productpage", "destination_namespace": "istio-bookinfo-1-68819", "source_name": "istio-ingressgateway-6845f6d664-lnfvp", "source_app": "istio-ingressgateway", "destination_app": "productpage", "request_id": "39013650-4e62-9be2-9d25-78682dd27ea4", "route_name": "default" }, "logName": "projects/***/logs/server-accesslog-stackdriver", "trace": "projects/***t/traces/466d77d15753cb4d7749ba5413b5f70f", "receiveTimestamp": "2020-08-13T21:37:48.758673203Z", "spanId": "633831cb1fda4fd5", "traceSampled": true }
Puedes usar este registro de varias maneras:
- Integra en Cloud Trace, que es una función opcional en la malla de servicios en la nube.
- Exporta los registros de tráfico a BigQuery, ya que allí puedes ejecutar consultas, como seleccionar todas las solicitudes que toman más de 5 segundos.
- Crea métricas basadas en registros.
- Soluciona errores
404
y503
Soluciona errores 404
y 503
En el siguiente ejemplo, se explica cómo usar este registro para solucionar problemas cuando una solicitud falla con un código de respuesta 404
o 503
.
En el registro de acceso del cliente, busca una entrada como la siguiente:
httpRequest: { requestMethod: "GET" requestUrl: "://IP_ADDRESS/src/Util/PHP/eval-stdin.php" requestSize: "2088" status: 404 responseSize: "75" remoteIp: "10.168.0.26:34165" serverIp: "10.36.3.149:8080" latency: "0.000371440s" protocol: "http" }
Navega a las etiquetas en la entrada de registro de acceso. Busca el campo
response_flag
, que tiene el siguiente aspecto:response_flag: "NR"
El valor
NR
es una sigla que significaNoRoute
, lo que indica que no se encontró ninguna ruta para el destino o que no había una cadena de filtro que coincida con una conexión descendente. Del mismo modo, también puedes usar la etiquetaresponse_flag
para solucionar los errores503
.Si ves errores
503
en los registros de acceso del cliente y del servidor, comprueba que los nombres de puertos configurados para cada servicio coincidan con el nombre del protocolo que se usa entre ellos. Por ejemplo, si un cliente del objeto binario de Golang se conecta a un servidor de Golang mediante HTTP, pero el puerto se llamahttp2
, el protocolo no negociará automáticamente de forma adecuada.
Para obtener más información, consulta Marcas de respuesta.
Interpreta los registros de acceso de Envoy
En los siguientes pasos, se explica cómo usar los registros de acceso de Envoy para mostrar el tráfico entre ambos extremos de una conexión a fin de solucionar los problemas.
Los registros de acceso de Envoy son útiles para diagnosticar problemas como los siguientes:
- Fallas y flujo de tráfico
- Enrutamiento de solicitudes de extremo a extremo
Los registros de acceso de Envoy no están habilitados de forma predeterminada en Cloud Service Mesh habilitado para los clústeres en una malla.
Para solucionar problemas de errores de conexión o solicitud, genera actividad en tu aplicación que active una solicitud HTTP y, luego, inspecciona la solicitud asociada en los registros de origen o de destino.
Si activas una solicitud y aparece en los registros del proxy de origen, indica que el redireccionamiento de tráfico de iptables
funciona de forma correcta y que el proxy de Envoy está controlando el tráfico. Si ves errores en los registros, genera un Envoy.
volcado de configuración y verifica la configuración del clúster de Envoy para asegurarte de que sea
correcto Si ves la solicitud, pero el registro no tiene errores, verifica los registros del proxy de destino en su lugar.
Si la solicitud aparece en los registros del proxy de destino, indica que la malla funciona correctamente. Si, en cambio, ves un error, ejecuta un volcado de la configuración de Envoy y verifica los valores correctos del puerto de tráfico establecido en la configuración del objeto de escucha.
Si el problema persiste después de seguir los pasos anteriores, puede que Envoy no sea capaz de negociar de forma automática el protocolo entre el archivo adicional y el pod de su aplicación. Asegúrate de que el nombre del puerto del servicio de Kubernetes, por ejemplo, http-80
, coincida con el protocolo que usa la aplicación.
Usa el Explorador de registros para consultar registros
Puedes usar la interfaz del explorador de registros para consultar registros de acceso específicos de Envoy. Por ejemplo, para consultar todas las solicitudes que
tener MULTUAL_TLS
habilitado y usar el protocolo grpc
, agregar lo siguiente al
Registros de acceso al servidor de la consulta:
labels.protocol="grpc" labels.service_authentication_policy="MULTUAL_TLS"
Establece una política de registro de acceso
Cloud Service Mesh administrada
Configurar los registros de acceso para Cloud Service Mesh con un plano de control de Cloud Service Mesh, consulta Habilita los registros de acceso.
istiod
administrado
Si deseas configurar los registros de acceso de Cloud Service Mesh con un plano de control de Istio administrado, consulta Habilita los registros de acceso.
En el clúster
A fin de establecer una política de registro de acceso para Cloud Service Mesh con el control en el clúster plano:
Crea un archivo de superposición personalizado
IstioOperator
que incluya los valoresAccessLogPolicyConfig
aplicables para tu situación.Pasa este archivo a
asmcli
con la opción--custom_overlay
para actualizar la configuración del plano de control en el clúster. Para obtener información sobre cómo ejecutarasmcli install
con un archivo de superposición personalizado, consulta Instala con funciones opcionales.
Obtén información específica del servicio o de la carga de trabajo
Si tienes un problema con un servicio o carga de trabajo en específico, en lugar de un problema en toda la malla, inspecciona los proxies de Envoy individuales y recopila información relevante sobre ellos. Para recopilar información sobre una carga de trabajo en particular y sus proxies, puedes usar pilot-agent
:
kubectl exec POD_NAME -n NAMESPACE_NAME -c istio-proxy -- pilot-agent request GET SCOPE
En el ejemplo, SCOPE es uno de los siguientes:
certs
: Certificados dentro de la instancia de Envoyclusters
: Clústeres con Envoy configuradoconfig_dump
: Vuelca la configuración de Envoylisteners
: Objetos de escucha con Envoy configuradologging
: Visualiza y cambia la configuración del registro de cambiosstats
: Estadísticas de Envoystats/prometheus
: Estadísticas de Envoy como registros de Prometheus
Visualiza los estados de los sockets del proxy
Puedes examinar directamente el estado de los sockets del proxy de Envoy mediante el siguiente proceso.
Muestra una lista de sockets establecidos, incluidos sockets en el estado
TIME_WAIT
, que pueden afectar la escalabilidad de forma negativa si su recuento es alto:kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -anopim
Muestra un resumen de las estadísticas de los sockets:
kubectl debug --image istio/base --target istio-proxy -it POD_NAME -n NAMESPACE_NAME -- ss -s
Para obtener más información, consulta Introducción al comando ss.
Registros istio-proxy
y istio-init
Además, recupera los registros istio-proxy
y revisa el contenido para detectar si hay errores que podrían sugerir la causa del problema:
kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-proxy
Puedes hacer lo mismo para el contenedor init
:
kubectl logs POD_NAME -n NAMESPACE_NAME -c istio-init
¿Qué sigue?
Integra en Cloud Trace. Cloud Trace es una función opcional en Cloud Service Mesh.