Hay dos opciones de asistencia de Monitoring y Logging en Google Kubernetes Engine (GKE):
Logging y Monitoring heredados: Para ver la documentación, consulta las páginas Monitoring heredado y Logging heredado.
Operaciones en la nube para GKE: Consulta Operaciones en la nube para GKE a fin de obtener documentación.
En esta página, se explican las diferencias entre estas dos opciones y lo que debes cambiar con el fin de migrar de Logging y Monitoring heredados a operaciones en la nube para GKE.
¿Cuándo debo migrar?
Puedes migrar la configuración existente de Cloud Monitoring y Cloud Logging desde Logging y Monitoring heredados hasta las operaciones en la nube para GKE en cualquier momento. Sin embargo, ten en cuenta que Logging y Monitoring heredados no son compatibles con la versión 1.18 de GKE.
En la siguiente tabla, se resumen las opciones de supervisión y registro disponibles en cada versión de actualización de GKE:
Versión de GKE | Logging y Monitoring heredados | Operaciones en la nube para GKE |
---|---|---|
1.10-1.12.5 | Valor predeterminado | Disponible (beta) |
1.12.7 | Valor predeterminado | Disponible |
1.13 | Valor predeterminado | Disponible |
1.14 | Disponible | Valor predeterminado |
1.15 | Disponible | Valor predeterminado |
1.16 | Disponible | Predeterminada |
1.17 | Disponible | Predeterminada |
1.18 | No disponible | Predeterminado |
Si deseas obtener información sobre la baja de Logging y Monitoring heredados, consulta la guía Asistencia heredada para la baja de GKE.
¿Cuáles son los beneficios de usar las operaciones en la nube para GKE?
Las operaciones en la nube para GKE te brindan beneficios importantes, como los siguientes:
Supervisión de infraestructura mejorada. El panel de GKE incluye más métricas listas para usar en el nivel gratuito, un aumento de 17 métricas heredadas a 44 métricas nuevas.
Más tipos de recursos a fin de diferenciar mejor los recursos de Kubernetes y más metadatos para filtrar y agrupar métricas.
Compatibilidad de la supervisión orientada al servicio con la supervisión de SLO para GKE.
Modelos de recursos coherentes en Cloud Logging y Cloud Monitoring.
Mejoras de rendimiento para todas las métricas nuevas de GKE.
¿Qué aspectos cambiarán?
En las operaciones en la nube para GKE, se usa un modelo de recursos distinto que Logging y Monitoring heredados a fin de organizar las métricas, los registros y los metadatos. Estos son algunos de los cambios específicos de los clústeres que usan operaciones en la nube para GKE:
Cambios en la navegación: El panel de Cloud Monitoring se llama GKE. Este panel no aparecerá si no tienes clústeres que usen las operaciones en la nube para GKE.
Cambios en los nombres de tipos de recursos supervisados: por ejemplo, tus nodos de Kubernetes se enumeran en el tipo de recurso supervisado k8s_node, que es un nodo de Kubernetes, en lugar de gce_instance (instancia de VM de Compute Engine).
Cambios en los nombres de las métricas de Kubernetes: En las operaciones en la nube para GKE, los nombres de tipos de métricas ahora comienzan con el prefijo
kubernetes.io/
en lugar decontainer.googleapis.com/
.Cambios en los metadatos de logEntry: Las entradas de registro de las operaciones en la nube para GKE cambiaron los nombres de algunos campos
resource.label
ylabels
. Por ejemplo, el camporesource.labels.namespace_id
cambió aresource.labels.namespace_name
, pero el valor no cambió.Cambios en logName: Las entradas de registros de las operaciones en la nube para GKE usan
stdout
ostderr
en sus nombres de registro, mientras que Logging y Monitoring heredados usan una variedad más amplia de nombres, incluido el nombre del contenedor. El nombre del contenedor aún está disponible en las operaciones en la nube para GKE como una etiqueta de recurso enresource.labels.container_name
.
En la siguiente tabla, se resumen los cambios mencionadas antes:
Cambio | Logging y Monitoring heredados (antiguo) | Operaciones en la nube para GKE (nuevo) |
---|---|---|
Menús del panel | Paneles > Clústeres de GKE | Paneles > GKE |
Prefijos de métricas | container.googleapis.com
|
kubernetes.io
|
Tipos de recursos de métricas | gke_container
gce_instance
(ninguno) |
k8s_container
k8s_node
k8s_pod |
Tipos de recursos de registros | container
gke_cluster
gce_instance
gke_nodepool
|
k8s_container
k8s_cluster
gke_cluster (solo registros de auditoría)
k8s_node
k8s_pod |
Cambios en los tipos de recursos
Las operaciones en la nube para GKE tienen nuevos nombres de tipos de recursos, nuevos nombres visibles de tipos de recursos y nombres nuevos para las etiquetas que identifican recursos específicos. Estos cambios se enumeran en la siguiente tabla.
Tipo de recurso de Logging y Monitoring heredados (antiguo) | Tipos de recursos de las operaciones en la nube para GKE (nuevo) | |||
---|---|---|---|---|
Notas al pie de la tabla: 1 En el tipo de recurso nuevo usado (solo) en la supervisión, instance_id se convierte en node_name en metadata.system_labels .
2 zone hace referencia a la ubicación de este contenedor o instancia. location hace referencia a la ubicación del nodo de la instancia principal del clúster.
3 metadata.system_labels.node_name no está disponible en los tipos de recursos k8s_container utilizados para los registros. No puedes buscar registros por nombre de nodo.
4 El tipo de recurso gce_instance puede representar nodos de Kubernetes, así como instancias de VM que no son de Kubernetes. Cuando se actualiza a las operaciones en la nube para GKE, los usos relacionados con nodos se cambian a fin de usar el tipo de recurso nuevo, k8s_node , incluidos los registros a nivel de nodo con los siguientes nombres: kubelet , docker , kube-proxy , startupscript y node-problem-detector .
5 Los nodos k8s_pod y k8s_cluster pueden incluir registros que no están presentes en la asistencia de Logging y Monitoring heredados.
|
||||
Solo Monitoring:
gke_container
(contenedor de GKE)Etiquetas:
container
(contenedor de GKE)Etiquetas: |
Monitoring y Logging:
k8s_container
(contenedor de Kubernetes)Etiquetas: |
|||
Solo Logging::
gce_instance
(instancia de VM de Compute Engine) 4Etiquetas: cluster_name instance_id project_id zone 2 |
Monitoring y Logging:
k8s_node 4 (nodo de Kubernetes) Etiquetas: cluster_name node_name project_id location 2 |
|||
(ninguno) |
Monitoring y Logging:
k8s_pod 5 (pod de Kubernetes)Etiquetas: |
|||
Solo Logging
gke_cluster (GKE_cluster)Etiquetas: |
Monitoring y Logging:
k8s_cluster 5 (clúster de Kubernetes)
Etiquetas:
|
¿Qué debo hacer?
En esta sección, se incluye información más específica sobre los cambios del modelo de recursos en las operaciones en la nube para GKE y su impacto en la configuración existente de Monitoring y Logging.
Debes realizar los siguientes pasos con el fin de migrar tu clúster a las operaciones en la nube para GKE:
Identifica tus opciones de configuración de Logging y Monitoring: Identifica las opciones de configuración de Logging y Monitoring que podrían estar usando valores que cambiaron entre las funciones de Logging y Monitoring heredados y las operaciones en la nube para GKE.
Actualiza tu configuración de Logging y Monitoring: Actualiza cualquier opción de configuración de Logging y Monitoring con el fin de que se reflejen los cambios presentes en las operaciones en la nube para GKE.
Actualiza la configuración de tu clúster de GKE: Actualiza tu clúster de GKE con el fin de que use la configuración de las operaciones en la nube para GKE.
Debido a que los modelos de recursos y los logNames cambiaron entre las versiones heredadas de Logging y Monitoring y las operaciones en la nube para GKE, también deben actualizarse los parámetros de configuración de Logging o Monitoring que hagan referencia a los cambios en los modelos de recursos. La migración puede requerir que actualices los parámetros de configuración de Logging y Monitoring, incluidos, entre otros, los siguientes:
- Paneles personalizados
- Gráficos
- Filtros de grupo
- Políticas de alertas
- Receptores de registros
- Exclusiones de registros
- Métricas basadas en registros en Cloud Logging y Cloud Monitoring
Identifica clústeres con Logging y Monitoring heredados
Existen 2 maneras de identificar qué clústeres de un proyecto usan Logging y Monitoring heredados.
Usa la herramienta de línea de comandos de
gcloud
por proyectoPuedes usar el siguiente comando de
gcloud
para enumerar los valores deloggingService
ymonitoringService
de cada clúster en el proyecto actual.gcloud container clusters list | tail +2 | while read name loc rest ; do echo $name ; gcloud container clusters describe $name --zone $loc | egrep 'loggingService|monitoringService' ; echo ; done
Deberías ver un resultado del comando similar al siguiente texto.
cluster-1 loggingService: logging.googleapis.com monitoringService: monitoring.googleapis.com cluster-2 loggingService: logging.googleapis.com/kubernetes monitoringService: monitoring.googleapis.com/kubernetes cluster-3 loggingService: logging.googleapis.com/kubernetes monitoringService: none
Si el resultado de un clúster contiene
loggingService: logging.googleapis.com
omonitoringService: monitoring.googleapis.com
, entonces el clúster usa Logging y Monitoring heredados.Si el resultado de un clúster contiene
loggingService: logging.googleapis.com/kubernetes
omonitoringService:monitoring.googleapis.com/kubernetes
, entonces el clúster usa Cloud Operations para GKE.Usa el panel de clústeres de GKE de Cloud Monitoring
- Haz clic en el panel de clústeres de GKE de Cloud Monitoring.
- Selecciona el “Workspace”, que incluye el proyecto de Google Cloud que deseas revisar para los clústeres que ejecutan Logging y Monitoring heredados.
Visualiza la lista de clústeres en el panel. Solo los clústeres que usan Logging y Monitoring heredados aparecen en el panel.
Por ejemplo, en la siguiente captura de pantalla, hay 4 clústeres que usan Logging y Monitoring heredados.
Migra tus recursos de supervisión
Si usas Logging y Monitoring heredados con un clúster de GKE cuya versión del plano de control es 1.15 o posterior, las métricas de tu clúster están disponibles en los modelos de recursos de Monitoring y Cloud Operations para GKE. Esto significa que, incluso antes de migrar tus clústeres a las operaciones de Cloud para GKE, tus clústeres comenzarán a generar métricas con el modelo de datos nuevo sin costo adicional.
A partir de enero de 2021, tus paneles y alertas personalizados se actualizarán de forma automática para hacer referencia a las métricas nuevas del modelo de recursos. Si deseas migrar tus propias configuraciones de Cloud Monitoring (gráficos en paneles personalizados, alertas y grupos), debes actualizar cada configuración para reflejar el modelo de recursos nuevo.
También deberás migrar tus configuraciones si mantienes tu configuración en Terraform o algún otro administrador de implementaciones y sincronizas automáticamente los cambios.
Determina si un clúster se publica en ambos modelos de datos
Para determinar si un clúster publica métricas de Monitoring heredadas, completa los siguientes pasos:
En Google Cloud Console, ve a Monitoring:
En el panel de navegación de Monitoring, haz clic en
Explorador de métricas.
Consulta el tipo de recurso
gke_container
y la métricacontainer.googleapis.com/container/cpu/usage_time
.Para limitar la consulta al clúster que verificas, agrega un filtro para cluster_name=CLUSTER_NAME.
Si el clúster publica métricas de Monitoring heredadas, el gráfico mostrará los datos especificados. Si el clúster no publica métricas heredadas de Monitoring, el gráfico mostrará el mensaje No hay datos disponibles en el período seleccionado.
Para determinar si un clúster publica métricas de operaciones de Cloud para GKE, completa los siguientes pasos:
En el Explorador de métricas, consulta el tipo de recurso
k8s_container
y la métricakubernetes.io/container/cpu/core_usage_time
.Para limitar la consulta al clúster que verificas, agrega un filtro para cluster_name=CLUSTER_NAME.
Si el clúster publica las métricas de operaciones de Cloud para GKE, en el gráfico se mostrarán los datos especificados. Si el clúster no publica las métricas de operaciones de Cloud para GKE, el gráfico muestra el mensaje No hay datos disponibles para el período seleccionado.
Identifica las configuraciones para el modelo de datos anterior
Para identificar la configuración de Cloud Monitoring que debes actualizar como parte de la migración a las operaciones de Cloud para GKE, consulta el panel Estado de migración de Kubernetes:
En Cloud Console, ve a Monitoring:
En el panel de navegación de Monitoring, haz clic en Configuración (Settings) y, luego, selecciona la pestaña Kubernetes Migration Status.
En el siguiente panel de ejemplo, se muestra que debe actualizarse 1 política de alertas:
Actualiza la configuración de Cloud Monitoring
Si tu clúster se publica en ambos modelos de datos, tienes dos opciones para migrar tus configuraciones.
Clona las configuraciones y actualiza los clones. Con esta opción, se crea una copia de los paneles, políticas de alertas y grupos existentes, y migras las copias al nuevo modelo de recursos. De esa manera, puedes seguir usando Monitoring para tu clúster con el modelo de datos anterior y el nuevo de manera simultánea. Por ejemplo, con esta opción, tendrías 2 paneles: el original que continúa usando el modelo de recursos original y una clonación del panel original que usa el nuevo modelo de recursos.
Actualiza las configuraciones afectadas. En esta opción, se cambia al modelo de datos nuevo de Cloud Monitoring de inmediato.
En las siguientes secciones, se proporcionan instrucciones para migrar tus configuraciones de paneles, políticas de alertas y grupos.
Un aspecto para decidir qué opción elegir es qué historial de supervisión deseas tener disponible. Actualmente, Cloud Monitoring ofrece 6 semanas de datos históricos de tus clústeres. Después de la actualización del clúster de GKE que comienza a escribir dos veces en los modelos de datos, el modelo de datos anterior aún tiene las métricas históricas para el clúster, mientras que el modelo de datos nuevo solo tiene métricas que comienzan en el momento de la actualización.
Si no necesitas los datos históricos, puedes actualizar las configuraciones al nuevo modelo de datos nuevo en cualquier momento. Si los datos históricos son importantes, puedes clonar las configuraciones y actualizar las clonaciones para usar los nuevos tipos de modelos de recursos.
También puedes esperar 6 semanas después de que tu clúster comience a escribir dos veces en ambos modelos de datos. Después de seis semanas, ambos modelos de datos tienen los mismos datos históricos, por lo que puedes actualizar las configuraciones implementadas y cambiar al modelo de datos nuevo.
Actualiza paneles
Para ver tus paneles, completa los siguientes pasos:
Desde Cloud Console, ve a Monitoring:
Selecciona Paneles.
Para clonar un panel y actualizar la clonación, completa los siguientes pasos:
Busca el panel que deseas clonar.
Haz clic en Copiar panel (
) y, luego, ingresa un nombre para el panel clonado.Actualiza las configuraciones del panel nuevo según sea necesario.
Para actualizar las definiciones de gráfico en el panel, completa los siguientes pasos:
Haga clic en Más opciones de gráficos (⋮) del gráfico que deseas editar.
Selecciona Editar para abrir el panel Editar gráfico.
Cambia el tipo de recurso y el nombre de la métrica para traducir al nuevo modelo de datos. También puedes actualizar los campos Filtrar y Agrupar por según sea necesario.
Actualiza las políticas de alertas
Para ver tus políticas de alertas, completa los siguientes pasos:
Desde Cloud Console, ve a Monitoring:
Selecciona Alertas.
Para clonar y actualizar una política de alertas, completa los siguientes pasos:
Selecciona la política que deseas clonar desde la tabla Políticas.
Haz clic en Copiar para comenzar el flujo de creación de la copia de la política de alertas.
Edita las condiciones que hacen referencia al modelo de datos anterior para actualizar el tipo de recurso y el nombre de la métrica.
El último paso del flujo te permite ingresar un nombre para la política clonada.
Para editar una política de alertas en su lugar, completa los siguientes pasos:
Selecciona la política que deseas editar en la tabla Políticas.
Haz clic en Editar para actualizar la política.
Actualiza las condiciones que hacen referencia al modelo de datos anterior.
Actualiza grupos
No puedes clonar un grupo a través de Google Cloud Console, por lo que si deseas duplicar un grupo, debes crear un grupo nuevo con el mismo filtro.
Un filtro de grupo puede hacer referencia al modelo de datos anterior de varias maneras.
Tipo de recurso: un grupo puede definir un filtro
resource.type="gke_container"
. Porque elgke_container
se puede usar para hacer referencia a varios tipos diferentes de entidades de GKE, debes actualizar el filtro al tipo de recurso que en realidad quieres hacer coincidir:k8s_container
,k8s_pod
ok8s_node
. Si deseas hacer coincidir varios tipos, define un filtro con varias cláusulas combinadas con el operadorOR
.Etiqueta
cloud_account
: un grupo puede definir un filtroresource.metadata.cloud_account="<var>CLOUD_ACCOUNT_ID</<var>"
. Como parte de una baja independiente, el campo de metadatoscloud_account
ya no está disponible. Considera usar la etiquetaresource.labels.project_id
.Etiqueta
region
: un grupo puede definir un filtroresource.metadata.region="<var>REGION_NAME</<var>"
. El campo de metadatosregion
ya no está disponible en el modelo de datos nuevo. Si deseas hacer coincidir las entidades de GKE según la ubicación geográfica, considera usar la etiquetaresource.labels.location
.
Asigna métricas entre modelos de datos
En esta sección, se describe cómo asignar métricas del modelo de datos anterior a las métricas en el nuevo modelo de datos. En el modelo de datos anterior, se publicaron 17 métricas diferentes, que se enumeran en las tablas a continuación. Algunas de estas métricas se publicaron en varios tipos de entidades de GKE, lo que da como resultado más de 17 asignaciones para traducir todas las métricas.
Cuando asignes métricas, recuerda lo siguiente:
El prefijo para las métricas anteriores es
container.googleapis.com/
. El prefijo para las métricas nuevas eskubernetes.io/
.En el modelo de datos anterior, el único tipo de recurso es
gke_container
. Según cómo hayas definido las etiquetas de recursos, este tipo de recurso puede referirse a contenedores de GKE, pods, daemons del sistema y máquinas, que corresponden a nodos de GKE.Puedes consultar la API de Monitoring con combinaciones de
pod_id
ycontainer_name
que no coincidan con las enumeradas en la siguiente tabla. Los datos que muestran esas consultas no están definidos y no se proporcionan asignaciones de estos estados indefinidos.Tipo de entidad de GKE Filtro Contenedor pod_id != '' y container_name != ''
(pod_id
no es la string vacía ycontainer_name
no es la string vacía)Pod pod_id != '' y container_name == ''
(pod_id
no es la string vacía ycontainer_name
es la string vacía)Daemon del sistema pod_id == '' and container_name != 'machine'
(pod_id
es la string vacía ycontainer_name
es uno dedocker-daemon
,kubelets
opods
)Machine pod_id == '' and container_name == 'machine'
(pod_id
es la string vacía ycontainer_name
es la stringmachine
)
Las tablas enumeran tres tipos de asignaciones:
Asignación directa entre los modelos de datos antiguos y nuevos.
Asignaciones que requieren configuración.
Asignaciones de métricas antiguas que no tienen un equivalente directo en el modelo nuevo.
Asignación directa
Las siguientes métricas se traducen directamente entre los modelos de datos antiguos y los nuevos.
Nombre de la métrica anterior | Tipo de entidad de GKE anterior | Nombre de la métrica nueva | Nuevo tipo de recurso de GKE | Notas |
---|---|---|---|---|
container/accelerator/ duty_cycle |
Contenedor | container/accelerator/ duty_cycle |
k8s_container | |
container/accelerator/ memory_total |
Contenedor | container/accelerator/ memory_total |
k8s_container | |
container/accelerator/ memory_used |
Contenedor | container/accelerator/ memory_used |
k8s_container | |
container/accelerator/ request |
Contenedor | container/accelerator/ request |
k8s_container | |
container/cpu/ reserved_cores |
Contenedor | container/cpu/ limit_cores |
k8s_container | Consulta Asignaciones que requieren configuración para asignar cuando el recurso es pod |
container/cpu/ usage_time |
Contenedor | container/cpu/ core_usage_time |
k8s_container | Consulta Asignaciones que requieren configuración para asignar cuando el recurso es pod |
container/cpu/ usage_time |
Daemon del sistema | node_daemon/cpu/ core_usage_time |
k8s_node | En el modelo de datos anterior, gke_container.container_name es uno de docker-daemon , kubelets o pods . Estos valores de filtro coinciden con los valores del nuevo campo de modelo de datos metric.component . |
container/cpu/ utilization |
Contenedor | container/cpu/ limit_utilization |
k8s_container | |
container/disk/ bytes_total |
Pod | pod/volume/ total_bytes |
k8s_pod | gke_container.device_name (Volume:config-volume) se traduce a k8s_pod.volume_name (config-volume) quitando el Volume: que se antepone. |
container/disk/bytes_used | Pod | pod/volume/ used_bytes |
k8s_pod | gke_container.device_name (Volume:config-volume) se traduce a k8s_pod.volume_name (config-volume) quitando el Volume: que se antepone. |
container/memory/ bytes_total |
Contenedor | container/memory/ limit_bytes |
k8s_container | |
container/memory/ bytes_used |
Contenedor | container/memory/ used_bytes |
k8s_container | |
container/memory/ bytes_used |
Daemon del sistema | node_daemon/memory/ used_bytes |
k8s_node | En el modelo de datos anterior, gke_container.container_name es uno de docker-daemon , kubelets o pods . Estos valores de filtro coinciden con los valores del nuevo campo de modelo de datos metric.component . |
container/disk/ inodes_free |
Machine | node/ephemeral_storage/ inodes_free |
k8s_node | El modelo de datos anterior tiene el campo instance_id , un ID de número al azar. El nuevo modelo de datos tiene node_name , un nombre legible. |
container/disk/ inodes_total |
Machine | node/ephemeral_storage/ inodes_total |
k8s_node | El modelo de datos anterior tiene el campo instance_id , un ID de número al azar. El nuevo modelo de datos tiene node_name , un nombre legible. |
container/pid_limit | Machine | node/pid_limit | k8s_node | El modelo de datos anterior tiene el campo instance_id , un ID de número al azar. El nuevo modelo de datos tiene node_name , un nombre legible. |
container/pid_used | Machine | node/pid_used | k8s_node | El modelo de datos anterior tiene el campo instance_id , un ID de número al azar. El nuevo modelo de datos tiene node_name , un nombre legible. |
Asignaciones que requieren configuración
Las siguientes métricas traducen desde el modelo de datos anterior al nuevo modelo de datos con cierta manipulación básica.
Nombre de la métrica anterior | Tipo de entidad de GKE anterior | Nombre de la métrica nueva | Nuevo tipo de recurso de GKE | Notas |
---|---|---|---|---|
container/cpu/ reserved_cores |
Pod | SUM container/cpu/limit_cores GROUP BY pod_name |
k8s_container | El modelo de datos anterior tiene un campo pod_id , un UUID. El nuevo modelo de datos tiene pod_name , un nombre legible. |
container/cpu/ usage_time |
Pod | SUM container/cpu/core_usage_time GROUP BY pod_name |
k8s_container | El modelo de datos anterior tiene un campo pod_id , un UUID. El nuevo modelo de datos tiene un pod_name , un nombre legible. |
container/disk/ bytes_total |
Contenedor | node/ephemeral_storage/ total_bytes |
k8s_container | gke_container.device_name es uno de / o logs . Cada uno de estos valores es igual al nuevo. |
container/disk/ bytes_used |
Contenedor | container/ephemeral_storage/ used_bytes |
k8s_container | gke_container.device_name es uno de / o logs . Se deben agregar estos 2 valores para obtener el valor nuevo. En el nuevo modelo de datos, no puedes obtener el valor de / y logs por separado. |
container/memory/ bytes_total |
Pod | SUM container/memory/limit_bytes GROUP BY pod_name |
k8s_container | El modelo de datos anterior tiene un campo pod_id , un UUID. El nuevo modelo de datos tiene pod_name , un nombre legible. |
container/memory/ bytes_used |
Pod | SUM container/memory/used_bytes GROUP BY pod_name |
k8s_container | El modelo de datos anterior tiene un campo pod_id , un UUID. El nuevo modelo de datos tiene pod_name , un nombre legible. |
Asignaciones que no tienen un equivalente directo en el modelo nuevo
Las siguientes métricas no tienen un equivalente en el nuevo modelo de datos.
- Uso de CPU para el pod
- En el modelo de datos anterior, esta métrica, según el límite de CPU para cada contenedor, es un promedio ponderado del uso de CPU en todos los contenedores de un pod.
- En el nuevo modelo de datos, este valor no existe y debe calcularse del lado del cliente según el límite y el uso de cada contenedor.
- Tiempo de actividad
- En el modelo de datos anterior, esta métrica es una métrica acumulativa que representa la fracción de tiempo que un contenedor está disponible en unidades ms/s. Para un contenedor que siempre está disponible, el valor es de alrededor de 1000 ms/s.
- En el nuevo modelo de datos, esta métrica es una métrica de indicador en horas que informa cuánto tiempo se ha ejecutado cada parte del sistema sin interrupciones.
Cambios en los grupos de recursos
Si defines tus propios grupos de recursos y usas cualquiera de los tipos de recursos de Logging y Monitoring heredados que aparecen en la tabla Cambios en los tipos de recursos anterior, cambia esos tipos a los correspondientes a las operaciones en la nube para GKE. Si tu grupo de recursos incluye gráficos personalizados, es posible que debas cambiarlos.
Migra tus recursos de registro
Para migrar tus recursos de registro, completa los pasos en las siguientes secciones.
Cambios en el contenido de la entrada de registro
Cuando actualizas a las operaciones en la nube para GKE, es posible que descubras que cierta información de las entradas de registro se trasladó a campos con nombres diferentes. Esta información puede aparecer en las consultas de registros que se usan en las métricas basadas en registros, los receptores de registros y las exclusiones de registros.
En la siguiente tabla, Cambios en las entradas de registro, se enumeran las etiquetas y los campos nuevos. A continuación, presentamos un breve resumen:
- Verifica el campo
logName
en los filtros. Las entradas de registro de las operaciones en la nube para GKE usanstdout
ostderr
en sus nombres de registro, mientras que Logging y Monitoring heredados usan una variedad más amplia de nombres, incluido el nombre del contenedor. El nombre del contenedor aún está disponible como etiqueta de recurso. - Verifica el campo
labels
en las entradas de registro. Es posible que este campo contenga información que anteriormente se encontraba en los campos de entrada de registrometadata
. - Comprueba el campo
resource.labels
en las entradas de registro. Los tipos de recursos nuevos tienen valores de etiqueta adicionales.
Entradas de registro de Logging y Monitoring heredados (antiguo) | Entradas de registro de las operaciones en la nube para GKE (nuevo) | |||
---|---|---|---|---|
Notas al pie de tabla: 1 Las etiquetas de recursos identifican recursos específicos que generan métricas, como clústeres y nodos determinados. 2 El campo labels aparece en entradas de registro nuevas que forman parte de operaciones en la nube para GKE y, en ocasiones, en algunas entradas de registro de Logging y Monitoring heredados.
En las operaciones en la nube para GKE, se usa a fin de almacenar información que antes se encontraba en los campos de entrada de registro metadata .
|
||||
Recursos de entrada de registroresource.labels (etiquetas de recursos 1) |
Recursos de entrada de registroresource.labels (etiquetas de recursos 1) |
|||
Metadatos de entradas de registrolabels (etiquetas de entradas de registro 2)etiquetas (ejemplos) compute.googleapis.com/resource_name:
container.googleapis.com/namespace_name:
container.googleapis.com/pod_name:
container.googleapis.com/stream:
|
Metadatos de entradas de registrolabels etiquetas (ejemplos) k8s-pod/app:
k8s-pod/pod-template-hash:
k8s-pod/istio_io/rev:
k8s-pod/service_istio_io/canonical-name:
|
Registros de ejemplo:
Cambios en los tipos de recursos de contenedor:
El texto rojo y en negrita destaca las diferencias entre los modelos de recursos de Logging y Monitoring heredados y los de las operaciones en la nube para GKE.
Modelo de recursos | Registros de ejemplo |
---|---|
Logging y Monitoring heredados | { "insertId": "fji4tsf1a8o5h", "jsonPayload": { "pid": 1, "name": "currencyservice-server", "v": 1, "message": "conversion request successful", "hostname": "currencyservice-6995d74b95-zjkmj" }, "resource": { "type": "container", "labels": { "project_id": "my-test-project", "cluster_name": "my-test-cluster", "pod_id": "currencyservice-6995d74b95-zjkmj", "zone": "us-central1-c", "container_name": "server", "namespace_id": "default", "instance_id": "1234567890" } }, "timestamp": "2020-10-02T19:02:47.575434759Z", "severity": "INFO", "labels": { "container.googleapis.com/pod_name": "currencyservice-6995d74b95-zjkmj", "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk", "container.googleapis.com/stream": "stdout", "container.googleapis.com/namespace_name": "default" }, "logName": "projects/my-test-project/logs/server", "receiveTimestamp": "2020-10-02T19:02:50.972304596Z" } |
Operaciones en la nube para GKE | { "insertId": "mye361s5zfcl55amj", "jsonPayload": { "v": 1, "name": "currencyservice-server", "pid": 1, "hostname": "currencyservice-5b69f47d-wg4zl", "message": "conversion request successful" }, "resource": { "type": "k8s_container", "labels": { "container_name": "server", "project_id": "my-test-project", "pod_name": "currencyservice-5b69f47d-wg4zl", "namespace_name": "onlineboutique", "location": "us-central1-c", "cluster_name": "my-prod-cluster" } }, "timestamp": "2020-10-02T18:41:55.359669767Z", "severity": "INFO", "labels": { "k8s-pod/app": "currencyservice", "k8s-pod/pod-template-hash": "5b69f47d", "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk" }, "logName": "projects/my-test-project/logs/stdout", "receiveTimestamp": "2020-10-02T18:41:57.930654427Z" } |
Cambios en los tipos de recursos del clúster:
El texto rojo y en negrita destaca las diferencias entre los modelos de recursos de Logging y Monitoring heredados y los de las operaciones en la nube para GKE.
Modelo de recursos | Registros de ejemplo |
---|---|
Logging y Monitoring heredados | { "insertId": "962szqg9uiyalt", "jsonPayload": { "type": "Normal", "involvedObject": { "apiVersion": "policy/v1beta1", "uid": "a1bc2345-12ab-12ab-1234-123456a123456", "resourceVersion": "50968", "kind": "PodDisruptionBudget", "namespace": "knative-serving", "name": "activator-pdb" }, "apiVersion": "v1", "reason": "NoPods", "source": { "component": "controllermanager" }, "message": "No matching pods found", "kind": "Event", "metadata": { "selfLink": "/api/v1/namespaces/knative-serving/events/activator-pdb.163a42fcb707c1fe", "namespace": "knative-serving", "name": "activator-pdb.163a42fcb707c1fe", "uid": "a1bc2345-12ab-12ab-1234-123456a123456", "creationTimestamp": "2020-10-02T19:17:50Z", "resourceVersion": "1917" } }, "resource": { "type": "gke_cluster", "labels": { "project_id": "my-test-project", "location": "us-central1-c", "cluster_name": "my-prod-cluster" } }, "timestamp": "2020-10-02T21:33:20Z", "severity": "INFO", "logName": "projects/my-test-project/logs/events", "receiveTimestamp": "2020-10-02T21:33:25.510671123Z" } |
Operaciones en la nube para GKE | { "insertId": "1qzipokg6ydoesp", "jsonPayload": { "involvedObject": { "uid": "a1bc2345-12ab-12ab-1234-123456a123456", "name": "istio-telemetry", "apiVersion": "autoscaling/v2beta2", "resourceVersion": "90505937", "kind": "HorizontalPodAutoscaler", "namespace": "istio-system" }, "source": { "component": "horizontal-pod-autoscaler" }, "kind": "Event", "type": "Warning", "message": "missing request for cpu", "metadata": { "resourceVersion": "3071416", "creationTimestamp": "2020-08-22T14:18:59Z", "name": "istio-telemetry.162d9ce2894d6642", "selfLink": "/api/v1/namespaces/istio-system/events/istio-telemetry.162d9ce2894d6642", "namespace": "istio-system", "uid": "a1bc2345-12ab-12ab-1234-123456a123456" }, "apiVersion": "v1", "reason": "FailedGetResourceMetric" }, "resource": { "type": "k8s_cluster", "labels": { "project_id": "my-test-project" "location": "us-central1-a", "cluster_name": "my-prod-cluster1", } }, "timestamp": "2020-10-02T21:39:07Z", "severity": "WARNING", "logName": "projects/my-test-project/logs/events", "receiveTimestamp": "2020-10-02T21:39:12.182820672Z" } |
Cambios en los tipos de recursos de nodo:
El texto rojo y en negrita destaca las diferencias entre los modelos de recursos de Logging y Monitoring heredados y los de las operaciones en la nube para GKE.
Modelo de recursos | Registros de ejemplo |
---|---|
Logging y Monitoring heredados | { "insertId": "16qdegyg9t3n2u5", "jsonPayload": { "SYSLOG_IDENTIFIER": "kubelet", [...] "PRIORITY": "6", "_COMM": "kubelet", "_GID": "0", "_MACHINE_ID": "9565f7c82afd94ca22612c765ceb1042", "_SYSTEMD_UNIT": "kubelet.service", "_EXE": "/home/kubernetes/bin/kubelet" }, "resource": { "type": "gce_instance", "labels": { "instance_id": "1234567890", "zone": "us-central1-a", "project_id": "my-test-project" } }, "timestamp": "2020-10-02T21:43:14.390150Z", "labels": { "compute.googleapis.com/resource_name": "gke-legacy-monitoring-default-pool-b58ff790-29rr" }, "logName": "projects/my-test-project/logs/kubelet", "receiveTimestamp": "2020-10-02T21:43:20.433270911Z" } |
Operaciones en la nube para GKE | { "insertId": "kkbgd6e5tmkpmvjji", "jsonPayload": { "SYSLOG_IDENTIFIER": "kubelet", [...] "_CAP_EFFECTIVE": "3fffffffff", "_HOSTNAME": "gke-standard-cluster-1-default-pool-f3929440-f4dy", "PRIORITY": "6", "_COMM": "kubelet", "_TRANSPORT": "stdout", "_GID": "0", "MESSAGE": "E1002 21:43:14.870346 1294 pod_workers.go:190] Error syncing pod 99ba1919-d633-11ea-a5ea-42010a800113 (\"stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\"), skipping: failed to \"StartContainer\" for \"metadata-agent\" with CrashLoopBackOff: \"Back-off 5m0s restarting failed container=metadata-agent pod=stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\"" }, "resource": { "type": "k8s_node", "labels": { "cluster_name": "my-prod-cluster-1", "location": "us-central1-a", "node_name": "gke-standard-cluster-1-default-pool-f3929440-f4dy" "project_id": "my-test-project", } }, "timestamp": "2020-10-02T21:43:14.870426Z", "logName": "projects/my-test-project/logs/kubelet", "receiveTimestamp": "2020-10-02T21:43:20.788933199Z" } |
Actualizaciones de la configuración de Logging
En esta sección, se describen los cambios que debes realizar en la configuración de Cloud Logging como parte de una migración a las operaciones en la nube para GKE. También deberás migrar tus configuraciones si mantienes tu configuración en Terraform o algún otro administrador de implementaciones y sincronizas automáticamente los cambios.
Consultas de Logging
Si usas consultas para buscar y filtrar tus registros en Cloud Logging y usas cualquiera de los tipos de recursos de Logging y Monitoring heredados que se muestran en la tabla Cambios en los tipos de recursos anterior, cambia esos tipos por los tipos correspondientes de las operaciones en la nube para GKE.
Métricas basadas en registros
Si defines tus propias métricas basadas en registros y usas las métricas o los tipos de recursos de Logging y Monitoring heredados que se muestran en las tablas anteriores Cambios en los nombres de las métricas o Cambios en los tipos de recursos, cambia las métricas y los tipos de recursos a los correspondientes de las operaciones en la nube para GKE.
Puedes usar el siguiente comando de la herramienta de gcloud
para encontrar tus métricas basadas en registros:
gcloud logging metrics list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'
gcloud logging metrics list --filter='filter~resource.labels.namespace_id'
gcloud logging metrics list --filter='filter~resource.labels.pod_id'
gcloud logging metrics list --filter='filter~resource.labels.zone'
Puedes usar el siguiente comando de la herramienta de gcloud
para actualizar tus métricas basadas en registros.
gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'
gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'
gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'
gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'
Como alternativa, puedes actualizar las métricas basadas en registros en Cloud Console.
Exportaciones de registros
Si exportas algún registro, y si la exportación usa los tipos de recursos de Logging y Monitoring heredados que aparecen en la tabla Cambios en los tipos de recursos anterior, haz cambios en la exportación a fin de que use los tipos de recursos correspondientes de las operaciones en la nube para GKE.
Puedes usar los siguientes comandos de la herramienta de línea de comandos de gcloud
para encontrar tus receptores de Logging afectados:
gcloud logging sinks list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'
gcloud logging sinks list --filter='filter~resource.labels.namespace_id'
gcloud logging sinks list --filter='filter~resource.labels.pod_id'
gcloud logging sinks list --filter='filter~resource.labels.zone'
Puedes usar el siguiente comando de la herramienta de gcloud
para actualizar tus receptores de Logging.
gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'
gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'
gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'
gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'
Como alternativa, puedes actualizar las métricas basadas en registros en Cloud Console.
Exclusiones de registros
Si excluyes algún registro, y si los filtros de exclusión usan los tipos de recursos de Logging y Monitoring heredados que aparecen en la tabla Cambios en los tipos de recursos anterior, haz cambios en los filtros de exclusión a fin de que usen los tipos de recursos correspondientes de las operaciones en la nube para GKE.
Si deseas obtener información para ver las exclusiones de registros, consulta la guía Visualiza filtros de exclusión.
Cambios en las ubicaciones de los registros
En Cloud Logging, los registros se almacenan con el tipo de recurso que los generó. Debido a que estos tipos cambiaron en las operaciones en la nube para GKE, asegúrate de buscar los registros en los tipos de recursos nuevos, como Kubernetes Container
, en lugar de hacerlo en los tipos de Logging y Monitoring heredados, como GKE Container
.
¿Qué sigue?
- A fin de obtener más información sobre el panel nuevo de operaciones en la nube para GKE, consulta Observa tu sistema.
- Si deseas obtener información para ver tus registros, consulta Visualiza tus registros de GKE.