Los clústeres de Anthos en VMware ahora son Google Distributed Cloud (solo software) para VMware. Para obtener más información, consulta la descripción general del producto.

Se usó la API de Cloud Translation para traducir esta página.

Usa el registro y la supervisión para los componentes del sistema

En este documento, se muestra cómo configurar el registro y la supervisión de los componentes del sistema en Google Distributed Cloud (solo software) para VMware.

De forma predeterminada, Cloud Logging, Cloud Monitoring y Google Cloud Managed Service para Prometheus están habilitados.

Para obtener más información sobre las opciones, consulta la descripción general del registro y la supervisión.

Recursos supervisados

Los recursos supervisados son la forma en que Google representa recursos como clústeres, nodos, Pods y contenedores. Para obtener más información, consulta la documentación de los Tipos de recursos supervisados de Cloud Monitoring.

Para consultar los registros y las métricas, debes conocer al menos estas etiquetas de recursos:

project_id: ID del proyecto del proyecto de supervisión de registro del clúster. Proporcionaste este valor en el campo stackdriver.projectID del archivo de configuración del clúster.
location: Es una Google Cloud región en la que deseas enrutar y almacenar tus métricas de Cloud Monitoring. Especificas la región durante la instalación en el campo stackdriver.clusterLocation del archivo de configuración del clúster. Te recomendamos que elijas una región cercana a tu centro de datos local.

Especificas la ubicación de almacenamiento y enrutamiento de los registros de Cloud Logging en la configuración del router de registros. Para obtener más información sobre el enrutamiento de registros, consulta Descripción general del enrutamiento y el almacenamiento.
cluster_name: Es el nombre del clúster que elegiste cuando creaste el clúster.

Puedes recuperar el valor cluster_name para el clúster de administrador o de usuario si inspeccionas el recurso personalizado de Stackdriver:
```
kubectl get stackdriver stackdriver --namespace kube-system \
--kubeconfig CLUSTER_KUBECONFIG --output yaml | grep 'clusterName:'
```
donde
- CLUSTER_KUBECONFIG es la ruta de acceso al archivo kubeconfig del clúster de administrador o del clúster de usuario para el que se requiere el nombre del clúster.

Enrutamiento de registros y métricas

El servidor de reenvío de registros de Stackdriver (stackdriver-log-forwarder) envía registros de cada máquina de nodo a Cloud Logging. De manera similar, el agente de métricas de GKE (gke-metrics-agent) envía métricas de cada máquina de nodo a Cloud Monitoring. Antes de que se envíen los registros y las métricas, el operador de Stackdriver (stackdriver-operator) adjunta el valor del campo clusterLocation en el recurso personalizado stackdriver a cada entrada de registro y métrica antes de que se enruten a Google Cloud. Además, los registros y las métricas se asocian con el proyecto de Google Cloud especificado en las especificaciones del recurso personalizado stackdriver (spec.projectID). El recurso stackdriver obtiene valores para los campos clusterLocation y projectID de los campos stackdriver.clusterLocation y stackdriver.projectID en la sección clusterOperations del recurso de clúster en el momento de su creación.

Todas las métricas y entradas de registro que envían los agentes de Stackdriver se enrutan a un extremo de transferencia global. Desde allí, los datos se reenvían al extremo Google Cloud regional más cercano al que se puede acceder para garantizar la confiabilidad del transporte de datos.

Una vez que el extremo global recibe la métrica o la entrada de registro, lo que sucede a continuación depende del servicio:

Cómo se configura el enrutamiento de registros: Cuando el extremo de registro recibe un mensaje de registro, Cloud Logging lo pasa a través del enrutador de registros. Los sinks y los filtros en la configuración del router de registros determinan cómo enrutar el mensaje. Puedes enrutar entradas de registro a destinos como los bucket de registros regionales, que almacenan la entrada de registro, o a Pub/Sub. Para obtener más información sobre cómo funciona el enrutamiento de registros y cómo configurarlo, consulta Descripción general del enrutamiento y el almacenamiento.

Ni el campo clusterLocation en el recurso personalizado stackdriver ni el campo clusterOperations.location en la especificación del clúster se consideran en este proceso de enrutamiento. En el caso de los registros, clusterLocation se usa solo para etiquetar entradas de registro, lo que puede ser útil para filtrar en el Explorador de registros.
Cómo se configura el enrutamiento de métricas: Cuando el extremo de métricas recibe una entrada de métrica, Cloud Monitoring la enruta automáticamente a la ubicación que especifica la métrica. La ubicación en la métrica proviene del campo clusterLocation en el recurso personalizado stackdriver.
Planifica tu configuración: Cuando configures Cloud Logging y Cloud Monitoring, configura el enrutador de registros y especifica un clusterLocation apropiado con las ubicaciones que mejor se adapten a tus necesidades. Por ejemplo, si deseas que los registros y las métricas vayan a la misma ubicación, configura clusterLocation en la misma Google Cloud región que usa Log Router para tu proyecto de Google Cloud.
Actualiza la configuración cuando sea necesario: Puedes realizar cambios en cualquier momento en la configuración de destino de los registros y las métricas debido a requisitos empresariales, como los planes de recuperación ante desastres. Los cambios en la configuración del router de registros en Google Cloud y el campo clusterLocation en el recurso personalizado stackdriver se aplican rápidamente.

Usa Cloud Logging

No es necesario que realices ninguna acción para habilitar Cloud Logging en un clúster. Sin embargo, debes especificar el proyecto de Google Cloud en el que deseas ver los registros. En el archivo de configuración del clúster, especificas el proyecto de Google Cloud en la sección stackdriver.

Puedes acceder a los registros con el Explorador de registros de la consola de Google Cloud. Por ejemplo, para acceder a los registros de un contenedor, sigue estos pasos:

En la consola de Google Cloud, abre el Visor de registros del proyecto.
Busca los registros para un contenedor de la siguiente manera:
1. Haz clic en el cuadro desplegable del catálogo de registros en la parte superior izquierda y selecciona Contenedor de Kubernetes.
2. Selecciona el nombre del clúster, el espacio de nombres y un contenedor de la jerarquía.

Visualiza los registros de los controladores en el clúster de arranque

Busca el nombre del Pod onprem-admin-cluster-controller o clusterapi-controllers

De forma predeterminada, el nombre del clúster de tipo es gkectl-bootstrap-cluster.
```
"ADMIN_CLUSTER_NAME"
resource.type="k8s_container"
resource.labels.cluster_name="gkectl-bootstrap-cluster"
```

Modifica la consulta con el nombre del pod que encuentres y obtén el registro.

resource.type="k8s_container"
resource.labels.cluster_name="gkectl-bootstrap-cluster"
resource.labels.pod_name="POD_NAME"

Usar Cloud Monitoring

No es necesario que realices ninguna acción para habilitar Cloud Monitoring en un clúster. Sin embargo, debes especificar el proyecto de Google Cloud en el que deseas ver las métricas. En el archivo de configuración del clúster, especificas el proyecto de Google Cloud en la sección stackdriver.

Puedes elegir entre más de 1,500 métricas mediante el Explorador de métricas. Para acceder al Explorador de métricas, sigue estos pasos:

En la consola de Google Cloud, selecciona Monitoring o usa el siguiente botón:

Ir a Monitoring
Selecciona Recursos > Explorador de métricas.

También puedes ver las métricas en los paneles de la consola de Google Cloud. Para obtener información sobre cómo crear paneles y ver métricas, consulta Cómo crear paneles.

Cómo ver los datos de supervisión a nivel de la flota

Para obtener una vista general del uso de recursos de tu flota con los datos de Cloud Monitoring, incluidos tus clústeres de Google Distributed Cloud, puedes usar la descripción general de Google Kubernetes Engine en la consola de Google Cloud. Consulta Administra clústeres desde la consola de Google Cloud para obtener más información.

Límites predeterminados de cuota de Cloud Monitoring

La supervisión de Google Distributed Cloud tiene un límite predeterminado de 6,000 llamadas a la API por minuto para cada proyecto. Si superas este límite, es posible que no se muestren las métricas. Si necesitas un límite de supervisión más alto, solicita uno a través de la consola de Google Cloud.

Cómo usar el servicio administrado para Prometheus

Google Cloud Managed Service para Prometheus forma parte de Cloud Monitoring y está disponible de forma predeterminada. Los beneficios de Managed Service para Prometheus incluyen los siguientes:

Puedes seguir usando tu supervisión existente basada en Prometheus sin alterar tus alertas ni paneles de Grafana.
Si usas GKE y Google Distributed Cloud, puedes usar la misma PromQL para las métricas de todos tus clústeres. También puedes usar la pestaña PROMQL en el Explorador de métricas de la consola de Google Cloud.

Habilita y, luego, inhabilita Managed Service para Prometheus

El servicio administrado para Prometheus está habilitado de forma predeterminada en Google Distributed Cloud.

Para inhabilitar Managed Service para Prometheus en un clúster, haz lo siguiente:

Abre el objeto de Stackdriver llamado stackdriver para editarlo:

kubectl --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system \
    edit stackdriver stackdriver

Agrega el interruptor de función enableGMPForSystemMetrics y configúralo en false:

apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  featureGates:
    enableGMPForSystemMetrics: false

Cierra la sesión de edición.

Cómo ver los datos de las métricas

Cuando se habilita el servicio administrado para Prometheus, las métricas de los siguientes componentes tienen un formato diferente para la forma en que se almacenan y consultan en Cloud Monitoring:

kube-apiserver
kube-scheduler
kube-controller-manager
kubelet y cAdvisor
kube-state-metrics
exportador de nodos

En el nuevo formato, puedes consultar las métricas anteriores con PromQL o lenguaje de consulta de Monitoring (MQL).

Ejemplo de PromQL:

histogram_quantile(0.95, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))

Para usar MQL, establece el recurso supervisado en prometheus_target y agrega el tipo de Prometheus como sufijo a la métrica.

Ejemplo de MQL:

fetch prometheus_target
| metric 'kubernetes.io/anthos/apiserver_request_duration_seconds/histogram'
| align delta(5m)
| every 5m
| group_by [], [value_histogram_percentile: percentile(value.histogram, 95)]

Cómo configurar paneles de Grafana con el servicio administrado para Prometheus

Para usar Grafana con datos de métricas del servicio administrado para Prometheus, sigue los pasos que se indican en Consulta con Grafana para autenticar y configurar una fuente de datos de Grafana para consultar datos del servicio administrado para Prometheus.

Se proporciona un conjunto de paneles de Grafana de muestra en el repositorio anthos-samples en GitHub. Para instalar los paneles de ejemplo, haz lo siguiente:

Descarga los archivos .json de muestra:

git clone https://github.com/GoogleCloudPlatform/anthos-samples.git
cd anthos-samples/gmp-grafana-dashboards

Si tu fuente de datos de Grafana se creó con un nombre diferente a Managed Service for Prometheus, cambia el campo datasource en todos los archivos .json:
```
sed -i "s/Managed Service for Prometheus/[DATASOURCE_NAME]/g" ./*.json
```
Reemplaza [DATASOURCE_NAME] por el nombre de la fuente de datos de tu Grafana que se dirigió al servicio frontend de Prometheus.
Accede a la IU de Grafana desde tu navegador y selecciona + Importar en el menú Paneles de control.
Sube el archivo .json o copia y pega su contenido y selecciona Cargar. Una vez que se cargue correctamente el contenido del archivo, selecciona Importar. De manera opcional, también puedes cambiar el nombre y el UID del panel antes de realizar la importación.
El panel importado debería cargarse correctamente si Google Distributed Cloud y la fuente de datos están configurados correctamente. Por ejemplo, en la siguiente captura de pantalla, se muestra el panel configurado por cluster-capacity.json.

Recursos adicionales

Para obtener más información sobre el servicio administrado para Prometheus, consulta los siguientes recursos:

Usa Prometheus y Grafana

A partir de la versión 1.16, Prometheus y Grafana no están disponibles en los clústeres nuevos. Te recomendamos que uses el servicio administrado para Prometheus como un reemplazo de la supervisión en el clúster.

Si actualizas un clúster 1.15 que tiene Prometheus y Grafana habilitados a la versión 1.16, Prometheus y Grafana seguirán funcionando tal como están, pero no se actualizarán ni se les proporcionarán parches de seguridad.

Si quieres borrar todos los recursos de Prometheus y Grafana después de la actualización a la versión 1.16, ejecuta el siguiente comando:

kubectl --kubeconfig KUBECONFIG delete -n kube-system \
    statefulsets,services,configmaps,secrets,serviceaccounts,clusterroles,clusterrolebindings,certificates,deployments \
    -l addons.gke.io/legacy-pg=true

Como alternativa al uso de los componentes de Prometheus y Grafana incluidos en versiones anteriores de Google Distributed Cloud, puedes cambiar a una versión comunitaria de código abierto de Prometheus y Grafana.

Problema conocido

En los clústeres de usuario, Prometheus y Grafana se inhabilitan automáticamente durante las actualizaciones. Sin embargo, los datos y las métricas de configuración no se pierden.

Para solucionar este problema, después de la actualización, abre monitoring-sample a fin de editarlo y establece enablePrometheus en true.

Accede a las métricas de supervisión desde los paneles de Grafana

Grafana muestra las métricas recopiladas de los clústeres. Para ver estas métricas, debes acceder a los paneles de Grafana:

Obtén el nombre del Pod de Grafana que se ejecuta en el espacio de nombres kube-system de un clúster de usuario:
```
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system get pods
```
En el ejemplo anterior, [USER_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de usuario.
El Pod de Grafana tiene un servidor HTTP que escucha en el puerto localhost 3000 de TCP. Reenvía un puerto local al puerto 3000 en el Pod para que puedas ver los paneles de Grafana desde un navegador web.

Por ejemplo, supongamos que el nombre del Pod es grafana-0. Para reenviar el puerto 50000 al puerto 3000 en el Pod, ingresa este comando:
```
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system port-forward grafana-0 50000:3000
```
Desde un navegador web, ve a http://localhost:50000.
En la página de acceso, accede admin para el nombre de usuario y la contraseña.
Si el acceso se realiza correctamente, verás un mensaje para cambiar la contraseña. Después de cambiar la contraseña predeterminada, se debe cargar el panel principal de Grafana del clúster de usuario.
Para acceder a otros paneles, haz clic en el menú desplegable Página principal en la esquina superior izquierda de la página.

Para ver un ejemplo del uso de Grafana, consulta Crea un panel de Grafana.

Accede a las alertas

Prometheus Alertmanager recopila alertas del servidor de Prometheus. Puedes ver estas alertas en un panel de Grafana. Para ver las alertas, debes acceder al panel:

El contenedor en el Pod alertmanager-0 escucha en el puerto TCP 9093. Reenvía un puerto local al puerto 9093 en el Pod:
```
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward \
   -n kube-system alertmanager-0 50001:9093
```
Desde un navegador web, ve a http://localhost:50001.

Cambia la configuración de Prometheus Alertmanager

Puedes cambiar la configuración predeterminada de Prometheus Alertmanager si editas el archivo monitoring.yaml del clúster de usuario. Debes hacerlo si deseas enviar alertas a un destino específico, en lugar de mantenerlas en el panel. Puedes obtener información sobre cómo configurar Alertmanager en la documentación de Configuración de Prometheus.

Para cambiar la configuración de Alertmanager, sigue estos pasos:

Realiza una copia del archivo de manifiesto monitoring.yaml del clúster de usuario:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] -n kube-system \
   get monitoring monitoring-sample -o yaml > monitoring.yaml

Para configurar Alertmanager, realiza los cambios en los campos de spec.alertmanager.yml. Cuando termines, guarda el manifiesto que cambiaste.

Aplica el manifiesto al clúster:

kubectl apply --kubeconfig [USER_CLUSTER_KUBECONIFG] -f monitoring.yaml

Crea un panel de Grafana

Implementaste una aplicación que expone una métrica, verificaste que la métrica se exponga y verificaste que Prometheus recopile la métrica. Ahora puedes agregar la métrica a nivel de la aplicación a un panel personalizado de Grafana.

Para crear un panel de Grafana, sigue estos pasos:

Si es necesario, obtén acceso a Grafana.
En el Panel principal, haz clic en el menú desplegable Página principal en la esquina superior izquierda de la página.
En el menú del lado derecho, haz clic en Panel nuevo.
En la sección Panel nuevo, haz clic en Grafo. Aparecerá un panel de grafo vacío.
Haz clic en Título del panel y, luego, en Editar. En el panel Grafo inferior, se abrirá en la pestaña Métricas.
En el menú desplegable Fuente de datos, selecciona usuario. Haz clic en Agregar consulta y, luego, ingresa foo en el campo búsqueda.
Haz clic en el botón Volver al panel en la esquina superior derecha de la pantalla. Se muestra el panel.
Para guardar el panel, haz clic en Guardar panel en la esquina superior derecha de la pantalla. Elige un nombre para el panel y, luego, haz clic en Guardar.

Inhabilita Prometheus y Grafana

A partir de la versión 1.16, Prometheus y Grafana ya no están controlados por el campo enablePrometheus en el objeto monitoring-sample. Consulta Usa Prometheus y Grafana para obtener más información.

Ejemplo: agrega métricas a nivel de la aplicación a un panel de Grafana

En las siguientes secciones, se explica cómo agregar métricas en una aplicación. En esta sección, completarás las siguientes tareas:

Implementar una aplicación de ejemplo que exponga una métrica llamada foo
Verificar que Prometheus exponga y extraiga la métrica
Crear un panel de Grafana personalizado

Implementa la aplicación de ejemplo

La aplicación de ejemplo se ejecuta en un Pod único. El contenedor del Pod expone una métrica, foo, con un valor constante de 40.

Crea el siguiente manifiesto del Pod, pro-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: prometheus-example
  annotations:
    prometheus.io/scrape: 'true'
    prometheus.io/port: '8080'
    prometheus.io/path: '/metrics'
spec:
  containers:
  - image: registry.k8s.io/prometheus-dummy-exporter:v0.1.0
    name: prometheus-example
    command:
    - /bin/sh
    - -c
    - ./prometheus_dummy_exporter --metric-name=foo --metric-value=40 --port=8080

Luego, aplica el manifiesto del Pod al clúster de usuario:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f pro-pod.yaml

Verifica que la métrica esté expuesta y recopilada

El contenedor en el Pod prometheus-example escucha en el puerto TCP 8080. Reenvía un puerto local al puerto 8080 en el Pod:
```
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-example 50002:8080
```
Para verificar que la aplicación exponga la métrica, ejecuta el siguiente comando:
```
curl localhost:50002/metrics | grep foo
```
El comando muestra el siguiente resultado:
```
# HELP foo Custom metric
# TYPE foo gauge
foo 40
```
El contenedor en el Pod prometheus-0 escucha en el puerto TCP 9090. Reenvía un puerto local al puerto 9090 en el Pod:
```
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] port-forward prometheus-0 50003:9090
```
Para verificar que Prometheus copie la métrica, navega a http://localhost:50003/targets, que te llevará al Pod prometheus-0 en el grupo de destino prometheus-io-pods.
Para ver las métricas en Prometheus, navega a http://localhost:50003/graph. En el campo de búsqueda, ingresa foo y, luego, haz clic en Ejecutar. La página debe mostrar la métrica.

Cómo configurar el recurso personalizado de Stackdriver

Cuando creas un clúster, Google Distributed Cloud crea automáticamente un recurso personalizado de Stackdriver. Puedes editar la especificación en el recurso personalizado a fin de anular los valores predeterminados para las solicitudes de CPU y memoria y los límites de un componente de Stackdriver, y puedes anular por separado el tamaño y la clase de almacenamiento predeterminados.

Anula valores predeterminados para solicitudes y límites de CPU y memoria

Sigue estos pasos para anular estos valores predeterminados:

Abre tu recurso personalizado de Stackdriver en un editor de línea de comandos:
```
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
```
donde KUBECONFIG es la ruta de acceso a tu archivo kubeconfig del clúster. Puede ser un clúster de administrador o de usuario.
En el recurso personalizado de Stackdriver, agrega el campo resourceAttrOverride en la sección spec:
```
resourceAttrOverride:
      POD_NAME_WITHOUT_RANDOM_SUFFIX/CONTAINER_NAME:
        LIMITS_OR_REQUESTS:
          RESOURCE: RESOURCE_QUANTITY
```
Ten en cuenta que el campo resourceAttrOverride anula todos los límites y solicitudes predeterminados existentes para el componente que especificas. Los siguientes componentes son compatibles con resourceAttrOverride:
- gke-metrics-agent/gke-metrics-agent
- stackdriver-log-forwarder/stackdriver-log-forwarder
- stackdriver-metadata-agent-cluster-level/metadata-agent
- node-exporter/node-exporter
- kube-state-metrics/kube-state-metrics

Un archivo de ejemplo se ve de la siguiente manera:

apiVersion: addons.gke.io/v1alpha1
    kind: Stackdriver
    metadata:
      name: stackdriver
      namespace: kube-system
    spec:
      projectID: my-project
      clusterName: my-cluster
      clusterLocation: us-west-1a
      resourceAttrOverride:
        gke-metrics-agent/gke-metrics-agent:
          requests:
            cpu: 110m
            memory: 240Mi
          limits:
            cpu: 200m
            memory: 4.5Gi

Guarda los cambios y cierra el editor de línea de comandos.

Verifica el estado de los Pods:

kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep gke-metrics-agent

Por ejemplo, un Pod en buen estado se ve de la siguiente manera:

gke-metrics-agent-4th8r                                1/1     Running   0          5d19h

Verifica las especificaciones del pod del componente para asegurarte de que los recursos estén configurados correctamente.

kubectl --kubeconfig=KUBECONFIG -n kube-system describe pod POD_NAME

En el ejemplo anterior, POD_NAME es el nombre del Pod que acabas de cambiar. Por ejemplo, stackdriver-prometheus-k8s-0

La respuesta es similar a la siguiente:

  Name:         gke-metrics-agent-4th8r
  Namespace:    kube-system
  ...
  Containers:
    gke-metrics-agent:
      Limits:
        cpu: 200m
        memory: 4.5Gi
      Requests:
        cpu: 110m
        memory: 240Mi
      ...

Anula los valores predeterminados del tamaño de almacenamiento

Sigue estos pasos para anular estos valores predeterminados:

Abre tu recurso personalizado de Stackdriver en un editor de línea de comandos:
```
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
```

Agrega el campo storageSizeOverride en la sección spec. Puedes usar el componente stackdriver-prometheus-k8s o stackdriver-prometheus-app. Esta sección tiene el siguiente formato:

storageSizeOverride:
STATEFULSET_NAME: SIZE

En este ejemplo, se usan el statefulset stackdriver-prometheus-k8s y el tamaño 120Gi.

apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  storageSizeOverride:
    stackdriver-prometheus-k8s: 120Gi

Guarda los cambios y sal del editor de línea de comandos.

Verifica el estado de los Pods:

kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver

Por ejemplo, un Pod en buen estado se ve de la siguiente manera:

stackdriver-prometheus-k8s-0                                2/2     Running   0          5d19h

Verifica las especificaciones del Pod del componente para asegurarte de que el tamaño de almacenamiento se anule de forma correcta.

kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME

La respuesta es similar a la siguiente:

Volume Claims:
 Name:          my-statefulset-persistent-volume-claim
 StorageClass:  my-storage-class
 Labels:
 Annotations:
 Capacity:      120Gi
 Access Modes:  [ReadWriteOnce]

Anula los valores predeterminados de la clase de almacenamiento

Requisito previo

Primero debes crear una StorageClass que desees usar.

A fin de anular la clase de almacenamiento predeterminada para volúmenes persistentes reclamados por componentes de registro y supervisión, sigue estos pasos:

Abre tu recurso personalizado de Stackdriver en un editor de línea de comandos:
```
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
```
donde KUBECONFIG es la ruta de acceso a tu archivo kubeconfig del clúster. Puede ser un clúster de administrador o de usuario.

Agrega el campo storageClassName en la sección spec:

storageClassName: STORAGECLASS_NAME

Ten en cuenta que el campo storageClassName anula la clase de almacenamiento predeterminada existente y se aplica a todos los componentes de registro y supervisión con volúmenes persistentes reclamados. Un archivo de ejemplo se ve de la siguiente manera:

apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  proxyConfigSecretName: my-secret-name
  enableVPC: 
  optimizedMetrics: true
  storageClassName: my-storage-class

Guarden los cambios.

Verifica el estado de los Pods:

kubectl --kubeconfig=KUBECONFIG -n kube-system get pods | grep stackdriver

Por ejemplo, un Pod en buen estado se ve de la siguiente manera:

stackdriver-prometheus-k8s-0                                1/1     Running   0          5d19h

Verifica las especificaciones del pod de un componente para asegurarte de que la clase de almacenamiento esté configurada correctamente.

kubectl --kubeconfig=KUBECONFIG -n kube-system describe statefulset STATEFULSET_NAME

Por ejemplo, si usas el conjunto con estado stackdriver-prometheus-k8s, la respuesta se verá de la siguiente manera:

Volume Claims:
 Name:          stackdriver-prometheus-data
 StorageClass:  my-storage-class
 Labels:
 Annotations:
 Capacity:      120Gi
 Access Modes:  [ReadWriteOnce]

Inhabilita las métricas optimizadas

De forma predeterminada, los agentes de métricas que se ejecutan en el clúster recopilan y crean informes de un conjunto optimizado de métricas de contenedores, kubelet y kube-state-metrics para Stackdriver. Si necesitas métricas adicionales, te recomendamos encontrar un reemplazo de la lista de métricas de GKE Enterprise.

Estos son algunos ejemplos de reemplazos que puedes usar:

Métrica inhabilitada	Reemplazos
`kube_pod_start_time`	`container/uptime`
`kube_pod_container_resource_requests`	`container/cpu/request_cores` `container/memory/request_bytes`
`kube_pod_container_resource_limits`	`container/cpu/limit_cores` `container/memory/limit_bytes`

Para inhabilitar la configuración predeterminada de las métricas optimizadas de kube-state-metrics (no recomendado), haz lo siguiente:

Abre tu recurso personalizado de Stackdriver en un editor de línea de comandos:
```
kubectl --kubeconfig=KUBECONFIG -n kube-system edit stackdriver stackdriver
```
donde KUBECONFIG es la ruta de acceso a tu archivo kubeconfig del clúster. Puede ser un clúster de administrador o de usuario.

Configura el campo optimizedMetrics como false:

apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  proxyConfigSecretName: my-secret-name
  enableVPC: 
  optimizedMetrics: false
  storageClassName: my-storage-class

Guarda los cambios y sal del editor de línea de comandos.

Problema conocido: condición de error de Cloud Monitoring

(ID de problema 159761921)

En ciertas condiciones, el pod predeterminado de Cloud Monitoring, implementado de forma predeterminada en cada clúster nuevo, puede dejar de responder. Cuando se actualizan los clústeres, por ejemplo, los datos de almacenamiento se pueden dañar cuando se reinician los pods en statefulset/prometheus-stackdriver-k8s.

En particular, el pod de supervisión stackdriver-prometheus-k8s-0 puede originar un bucle cuando los datos dañados evitan que prometheus-stackdriver-sidecar escriba en el PersistentVolume de almacenamiento del clúster.

Sigue los pasos que aparecen a continuación para diagnosticar y recuperar el error de forma manual.

Diagnostica la falla de Cloud Monitoring

Cuando el pod de supervisión tenga errores, los registros informarán lo siguiente:

{"log":"level=warn ts=2020-04-08T22:15:44.557Z caller=queue_manager.go:534 component=queue_manager msg=\"Unrecoverable error sending samples to remote storage\" err=\"rpc error: code = InvalidArgument desc = One or more TimeSeries could not be written: One or more points were written more frequently than the maximum sampling period configured for the metric.: timeSeries[0-114]; Unknown metric: kubernetes.io/anthos/scheduler_pending_pods: timeSeries[196-198]\"\n","stream":"stderr","time":"2020-04-08T22:15:44.558246866Z"}

{"log":"level=info ts=2020-04-08T22:15:44.656Z caller=queue_manager.go:229 component=queue_manager msg=\"Remote storage stopped.\"\n","stream":"stderr","time":"2020-04-08T22:15:44.656798666Z"}

{"log":"level=error ts=2020-04-08T22:15:44.663Z caller=main.go:603 err=\"corruption after 29032448 bytes: unexpected non-zero byte in padded page\"\n","stream":"stderr","time":"2020-04-08T22:15:44.663707748Z"}

{"log":"level=info ts=2020-04-08T22:15:44.663Z caller=main.go:605 msg=\"See you next time!\"\n","stream":"stderr","time":"2020-04-08T22:15:44.664000941Z"}

Recuperación del error de Cloud Monitoring

Para recuperar manualmente Cloud Monitoring, haz lo siguiente:

Detén la supervisión del clúster. Reduce el operador stackdriver para evitar la conciliación de la supervisión:

kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas 0

Borra las cargas de trabajo de la canalización de supervisión:

kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete statefulset stackdriver-prometheus-k8s

Borra PersistentVolumeClaims (PVC) de la canalización de supervisión:

kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system delete pvc -l app=stackdriver-prometheus-k8s

Reinicia la supervisión del clúster. Escala verticalmente el operador de Stackdriver para volver a instalar una nueva canalización de supervisión y reanudar la conciliación:
```
kubectl --kubeconfig /ADMIN_CLUSTER_KUBCONFIG --namespace kube-system scale deployment stackdriver-operator --replicas=1
```