Eliminación de los agentes complementarios de observabilidad

• Una vez finalizada la compatibilidad con ob plugin, deberá eliminar cada componente por separado.

  1. Limpia los daemonsets y configmaps.

      kubectl delete daemonset logdna-agent -n ibm-observe
      kubectl delete daemonset sysdig-agent -n ibm-observe
      kubectl delete configmap <logdna-configmap> -n ibm-observe
      kubectl delete configmap <sysdig-configmap> -n ibm-observe
      ```
  1. Opcional: Eliminar el espacio de nombres. Después de que ningún otro recurso se esté ejecutando en el espacio de nombres.
  ```sh {: pre}
      kubectl delete namespace ibm-observe
      ```
  

Una vez eliminado el complemento, vuelve a instalar los agentes de registro y supervisión en tu clúster mediante el panel de control del clúster, Terraform o de forma manual.

Para obtener información adicional, consulte los siguientes enlaces:

• Envío de datos de registro de IBM Cloud Kubernetes Service a IBM Cloud Registros
• Supervisión de un clúster de Kubernetes

Visión general del reenvío de registros a un servidor externo

Cuando creas una configuración de registro para una fuente de tu clúster con el fin de reenviar los datos a un servidor externo, se crea un Fluentd se crea un componente en tu clúster. Fluentd recopila los registros de las vías de acceso de origen y los reenvía a un servidor externo. El tráfico entre el origen y el servicio de registro del puerto de ingestión está cifrado.

¿Para qué fuentes puedo configurar el reenvío de registros?

En la siguiente imagen puedes ver la zona de las fuentes para las que puedes configurar el registro.

1. worker: información específica de la configuración de la infraestructura que tiene para el nodo trabajador. Los registros de los trabajadores se recogen en syslog y contienen eventos del sistema operativo. En auth.log encontrará información sobre las solicitudes de autenticación que se realizan en el sistema operativo.

   Vías de acceso

   • /var/log/syslog
   • /var/log/auth.log

2. container: Información registrada por un contenedor en ejecución. Rutas: Todo lo que se escriba en STDOUT o STDERR.

3. application: información sobre los sucesos que se producen a nivel de aplicación. Podría tratarse de una notificación de que se ha producido un evento, como un inicio de sesión correcto, una advertencia sobre el almacenamiento u otras operaciones que se pueden realizar a nivel de la aplicación. Rutas: puedes configurar las rutas a las que se reenvían tus registros. Sin embargo, para que los registros se envíen, debe utilizar una vía de acceso absoluta en la configuración de registro o los registros no se pueden leer. Si la ruta está montada en tu nodo de trabajo, es posible que se haya creado un enlace simbólico. Ejemplo: Si la ruta especificada es /usr/local/spark/work/app-0546/0/stderr, pero los registros se almacenan en realidad en /usr/local/spark-1.0-hadoop-1.2/work/app-0546/0/stderr, entonces no se podrán leer.

4. storage: información sobre el almacenamiento persistente configurado en el clúster. Los registros de almacenamiento le pueden ayudar a configurar alertas y paneles de control de determinación de problemas como parte de los releases de producción y conducto de DevOps. Nota: las vías de acceso /var/log/kubelet.log y /var/log/syslog también contienen registros de almacenamiento, pero los registros de estas vías de acceso se recopilan mediante los orígenes de registro kubernetes y worker.

   Vías de acceso

   /var/log/ibmc-s3fs.log

   /var/log/ibmc-block.log

   Pods

   portworx-***

   ibmcloud-block-storage-attacher-***

   ibmcloud-block-storage-driver-***

   ibmcloud-block-storage-plugin-***

   ibmcloud-object-storage-plugin-***

5. kubernetes: información de kubelet, kube-proxy y otros sucesos de Kubernetes que se producen en el espacio de nombres kube-system del nodo trabajador.

   Vías de acceso

   /var/log/kubelet.log

   /var/log/kube-proxy.log

   /var/log/event-exporter/1..log

6. ingress: información sobre el tráfico de red que llega a un clúster a través del equilibrador de carga de aplicación de Ingress.

   Vías de acceso

   /var/log/alb/ids/*.log

   /var/log/alb/ids/*.err

   /var/log/alb/customerlogs/*.log

   /var/log/alb/customerlogs/*.err

7. kube-audit: información sobre las acciones relacionadas con el clúster que se envía al servidor de API de Kubernetes, que incluye la hora, el usuario y el recurso afectado. El origen de kube-audit se puede configurar con un webhook. Para obtener más información, consulte Reenvío de registros de auditoría de API de Kubernetes a un servidor externo.

¿Soy responsable de mantener actualizado Fluentd?

Para cambiar las configuraciones de registro o de filtro, el componente de registro Fluentd debe estar en la última versión. De forma predeterminada, las actualizaciones automáticas del complemento están habilitadas. Para inhabilitar las actualizaciones automáticas, consulte Actualización de componentes de clúster: Fluentd para registro.

¿Puedo reenviar algunos registros, pero no otros, desde una fuente de mi clúster?

Sí. Por ejemplo, si tiene un pod con muchas conversaciones, quizás desee evitar que los registros procedentes de dicho pod ocupen espacio de almacenamiento de registros, pero permitir que se reenvíen los registros de otros pods. Para evitar que se reenvíen los registros procedentes de un determinado pod, consulte Filtrado de registros.

Reenvío de registros de clúster y de app

Cree una configuración para el registro de clúster y de app. Puedes distinguir entre las distintas opciones de registro utilizando las opciones.

En la tabla siguiente se muestran las distintas opciones que tiene para configurar el registro y sus descripciones.

Reenvío de registros a su propio servidor sobre los protocolos udp o tcp

1. Asegúrate de que dispones del rol de acceso «Editor» o «Administrador» IBM Cloud en la plataforma IAM.

2. Para el clúster en el que se encuentra el origen de registro: Inicie sesión en su cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

3. Configura un servidor que admita el protocolo « syslog » de una de estas dos formas: : Puede configurar y gestionar su propio servidor o dejar que lo gestione un proveedor. Si un proveedor gestiona el servidor, obtenga el punto final de registro del proveedor de registro.

   : Ejecuta « syslog » desde un contenedor. Por ejemplo, puedes utilizar este archivo.yaml de implementación para descargar una imagen pública de Docker que ejecute un contenedor en tu clúster. La imagen publica el puerto 514 en la dirección IP del clúster público y utiliza esta dirección IP del clúster público para configurar el host de syslog.

   Puedes ver tus registros en formato JSON válido eliminando los prefijos « syslog ». Para ello, añade el siguiente código al principio del archivo « etc/rsyslog.conf » en el servidor donde se ejecuta « rsyslog »: $template customFormat,"%msg%\n"$ActionFileDefaultTemplate customFormat

4. Crear una configuración de reenvío de registro. Para obtener más información sobre los parámetros, consulte la tabla de Visión general de las opciones de configuración de registro.

   ibmcloud ks logging config create --cluster CLUSTER_NAME_OR_ID --logsource LOG_SOURCE --namespace KUBERNETES_NAMESPACE --hostname LOG_SERVER_HOSTNAME_OR_IP --port LOG_SERVER_PORT --type syslog --app-containers CONTAINER1,2 --app-paths PATHS_TO_LOGS --syslog-protocol PROTOCOL
   

Reenvío de registros a su propio servidor sobre el protocolo tls

1. Asegúrese de tener los siguientes roles de IBM Cloud IAM:

   • Rol de acceso a la plataforma Editor o Administrador para el clúster
   • Rol de acceso al servicio de Escritor o de Gestor para el espacio de nombres kube-system

2. Para el clúster en el que se encuentra el origen de registro: Inicie sesión en su cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

3. Configura un servidor que admita el protocolo « syslog » de una de estas dos formas:

   • Puede configurar y gestionar su propio servidor o dejar que lo gestione un proveedor. Si un proveedor gestiona el servidor, obtenga el punto final de registro del proveedor de registro.

   • Ejecuta « syslog » desde un contenedor. Por ejemplo, puedes utilizar este archivo.yaml de implementación para descargar una imagen pública de Docker que ejecute un contenedor en tu clúster. La imagen publica el puerto 514 en la dirección IP pública del clúster y utiliza esta dirección IP pública del clúster para configurar el host syslog. Debe inyectar la entidad emisora de certificados relevante y los certificados del lado del servidor y actualizar syslog.conf para habilitar tls en el servidor.

4. Guarde el certificado de autorización de certificado en un archivo denominado ca-cert. Debe ser ese nombre exacto.

5. Cree un secreto en el espacio de nombres kube-system para el archivo ca-cert. Cuando crees tu configuración de registro, utiliza el nombre del secreto en la opción « --ca-cert ».

   kubectl -n kube-system create secret generic --from-file=ca-cert
   

6. Crear una configuración de reenvío de registro. Para obtener más información sobre los parámetros, consulte la tabla de Visión general de las opciones de configuración de registro.

   ibmcloud ks logging config create --cluster <cluster name or id> --logsource <log source> --type syslog --syslog-protocol tls --hostname <ip address of syslog server> --port <port for syslog server, 514 is default> --ca-cert <secret name> --verify-mode <defaults to verify-none>
   

Filtrado de los registros que se reenvían

Puede elegir qué registros se deben reenviar al servidor externo filtrando registros específicos durante un periodo de tiempo. Puedes distinguir entre las distintas opciones de filtrado utilizando las opciones.

1. Cree un filtro de registro.

   ibmcloud ks logging filter create --cluster CLUSTER_NAME_OR_ID --type LOG_TYPE --logging-configs CONFIGS --namespace KUBERNETES_NAMESPACE --container CONTAINER_NAME --level LOGGING_LEVEL --regex-message MESSAGE
   

2. Visualice el filtro de registro que ha creado.

   ibmcloud ks logging filter get --cluster CLUSTER_NAME_OR_ID --id FILTER_ID --show-matching-configs
   

3. Actualice el filtro de registro que ha creado.

   ibmcloud ks logging filter update --cluster CLUSTER_NAME_OR_ID --id FILTER_ID --type SERVER_TYPE --logging-configs CONFIGS --namespace KUBERNETES_NAMESPACE --container CONTAINER_NAME --level LOGGING_LEVEL --regex-message MESSAGE
   

4. Suprima un filtro de registro que ha creado.

   ibmcloud ks logging filter rm --cluster CLUSTER_NAME_OR_ID --id FILTER_ID [--all]
   

Verificación, actualización y supresión del reenvío de registros

ibmcloud ks logging config update --cluster CLUSTER_NAME_OR_ID --id LOG_CONFIG_ID --namespace NAMESPACE --type SERVER_TYPE --syslog-protocol PROTOCOL --logsource SOURCE --hostname HOSTNAME_OR_INGESTION_URL --port PORT --app-containers CONTAINER1,2 --app-paths PATHS_TO_LOGS