Patrones de supervisión y registro de nubes híbridas y múltiples

Last reviewed 2023-03-29 UTC

En este documento, se analizan las arquitecturas de supervisión y registro para implementaciones de nubes híbridas y múltiples, y se proporcionan prácticas recomendadas a fin de implementarlas mediante Google Cloud. Con este documento, puedes identificar qué patrones y productos son los más adecuados para tus entornos.

Cada empresa tiene una cartera única de cargas de trabajo de aplicaciones que definen requisitos y restricciones a la arquitectura de una configuración de nube híbrida o de múltiples nubes. Aunque debes diseñar y adaptar tu arquitectura para que cumpla con estas restricciones y requisitos, puedes basarte en algunos patrones comunes.

Los patrones que se incluyen en este documento se dividen en las siguientes dos categorías:

  • En una arquitectura de panel único, la supervisión y el registro están centralizados, con el objetivo de proporcionar un único punto de acceso y control.
  • En una arquitectura de aplicación y operaciones separadas, los datos de aplicación sensibles se separan de los datos de operaciones menos sensibles, con el objetivo de satisfacer los requisitos de cumplimiento de los datos sensibles.

Elige el patrón de arquitectura

Puedes usar el árbol de decisión del siguiente diagrama a fin de identificar la mejor arquitectura para cada caso práctico.

Árbol de decisión para seleccionar una arquitectura de supervisión y registro

Los detalles de cada arquitectura se analizan con mayor precisión en este documento, pero en un nivel alto, las opciones son las siguientes:

  • Exportar de Monitoring a una solución heredada
  • Exportar directamente a la solución heredada
  • Usa Monitoring con Prometheus y Fluentd o Fluent Bit.
  • Usa Monitoring con observIQ BindPlane.

Arquitectura de panel único

Un objetivo común del sistema híbrido es integrar la información de supervisión y registro de diversas fuentes en varias aplicaciones y entornos en una sola pantalla. Este tipo de pantalla se denomina panel único.

En el siguiente diagrama, se ilustra este patrón en el que los datos de supervisión y registro de todas las aplicaciones, ya sean locales o en la nube, se centralizan en un único repositorio alojado en la nube.

Arquitectura de alto nivel para la supervisión y el registro

Esta arquitectura cuenta con las siguientes ventajas:

  • Tiene una sola vista coherente para la supervisión y el registro.
  • El almacenamiento y la retención de datos se administran desde un solo lugar.
  • La auditoría y el control de acceso están centralizados. Sin embargo, aún debes garantizar la seguridad de los datos en tránsito hacia el repositorio central.

Monitoring como panel único

Cloud Monitoring es una solución de administración y supervisión administrada por Google para servicios, contenedores, infraestructura y aplicaciones. Si deseas usar un panel único y una solución de almacenamiento sólida para las métricas, los registros, los seguimientos y los eventos, usa Google Cloud Observability. El paquete también ofrece un conjunto completo de herramientas de observabilidad, como paneles, informes y alertas.

Todos los productos y los servicios de Google Cloud se pueden integrar a Monitoring. Además, hay varias herramientas integradas que puedes usar para extender Monitoring a recursos híbridos y locales.

Las siguientes prácticas recomendadas se aplican a todas las arquitecturas que usen Monitoring como panel único:

Supervisión y registro híbridos con Monitoring y BindPlane de observIQ

Con BindPlane del socio observIQ de Google, puedes importar datos de supervisión y registro desde VM locales y otros proveedores de servicios en la nube, como Amazon Web Services (AWS), Microsoft Azure, IBM Cloud y Alibaba Cloud en Google Cloud En el siguiente diagrama, se muestra cómo Monitoring y BindPlane pueden proporcionar un panel único para una nube híbrida.

Arquitectura de alto nivel para la supervisión y el registro con BindPlane y Monitoring

Esta arquitectura cuenta con las siguientes ventajas:

Para obtener más detalles sobre la implementación de este patrón, consulta Registra y supervisa recursos locales con BindPlane.

Supervisión híbrida de Google Kubernetes Engine mediante Prometheus y Monitoring

Con Google Cloud Managed Service para Prometheus, una solución de supervisión de código abierto popular y completamente administrada por Google Cloud, puedes supervisar las aplicaciones que se ejecutan en varios clústeres de Kubernetes con Monitoring. Esta arquitectura es útil cuando se ejecutan cargas de trabajo de Kubernetes distribuidas en Google Kubernetes Engine (GKE) en clústeres de Google Cloud y de GKE en VMware en tu centro de datos local, puesto que proporciona una interfaz unificada en ambos. En el siguiente diagrama, se muestra cómo usar Prometheus y los recopiladores de Monitoring para la recopilación de datos.

Arquitectura de alto nivel para la supervisión de GKE con Prometheus y Monitoring

Esta arquitectura cuenta con las siguientes ventajas:

  • Métricas de Kubernetes coherentes en entornos en la nube y locales
  • Te permite supervisar y generar alertas sobre tus cargas de trabajo de forma global mediante Prometheus, sin tener que administrar ni operar Prometheus de forma manual a gran escala.
  • No se aplican costos de licencia adicionales por usar Prometheus. Las métricas de Prometheus se importan a Monitoring. Las importaciones son cobrables y su precio depende de la cantidad de muestras transferidas.

Esta arquitectura tiene las siguientes desventajas:

  • Prometheus solo admite la supervisión, por lo que el registro debe configurarse por separado. En la siguiente sección, se analiza una opción común para el registro mediante Fluentd o Fluent Bit.

Recomendamos lo siguiente:

  • De forma predeterminada, Prometheus recopila todas las métricas expuestas, cada una de las cuales se convierte en una métrica cobrable. Para evitar costos inesperados, considera implementar Controles de costos de Monitoring.

Registro híbrido de GKE con Fluentd o Fluent Bit y Cloud Logging

Con Fluentd o Fluent Bit, un agente de registro de código abierto popular y Cloud Logging, puedes transferir registros de aplicaciones que se ejecutan en varios clústeres de GKE a Cloud Logging. Esta arquitectura es útil cuando se ejecutan cargas de trabajo de Kubernetes distribuidas en GKE en Google Cloud y GKE en VMware en el centro de datos local, ya que proporciona una interfaz unificada en ambos. En el siguiente diagrama, se ilustra el flujo de registros.

Arquitectura de alto nivel para la supervisión de GKE con Fluentd o Fluent Bit, Monitoring y Logging.

Esta arquitectura cuenta con las siguientes ventajas:

  • Puedes tener registros de Kubernetes coherentes en entornos en la nube y locales.
  • Puedes personalizar Logging para que filtre la información sensible.
  • No se aplican costos de licencia adicionales por usar Fluentd o Fluent Bit. Los registros que se importan a Logging mediante Fluentd o Fluent Bit son cobrables.

Esta arquitectura tiene las siguientes desventajas:

Para obtener más detalles sobre cómo implementar este patrón, consulta Personaliza los registros de Logging para Google Kubernetes Engine con Fluentd o Personaliza los registros de Logging para Google Kubernetes Engine con Fluent Bit.

Servicios de socios como paneles únicos

Si ya usas un servicio de supervisión o registro de terceros, como Datadog o Splunk, puede que no quieras usar Logging. Si es así, puedes exportar datos de Google Cloud a muchos servicios comunes de supervisión y registro. Puedes elegir usar un servicio integrado de supervisión y registro, o seleccionar servicios independientes de supervisión y registro que se adapten mejor a tus necesidades.

Exporta de Logging a servicios de socios

En este patrón, debes autorizar el servicio de supervisión del socio, como Datadog, para que se conecte a la API de Cloud Monitoring. Esta autorización permite que el servicio transfiera todas las métricas disponibles a Logging, de modo que Datadog pueda funcionar como panel único para la supervisión.

Para los datos de registro, Logging proporciona exportaciones (receptores de registro) a Pub/Sub. Estas exportaciones proporcionan un método eficaz y resiliente para los servicios de registro de socios, como Elastic y SPunk, a fin de transferir grandes volúmenes de registros desde Logging en tiempo real, de modo que estos servicios de socios puedan entregar un panel único de registros.

En el siguiente diagrama, se muestra la arquitectura combinada para el registro y la supervisión.

Arquitectura de alto nivel para exportar datos de supervisión y registro a servicios de socios

Esta arquitectura cuenta con las siguientes ventajas:

  • Puedes seguir usando las herramientas conocidas.
  • La asistencia de Google Cloud sigue teniendo acceso a los registros de Logging para solucionar problemas.

Esta arquitectura tiene las siguientes desventajas:

  • Por lo general, las soluciones de socios se alojan de forma externa, por lo que podrían dejar de estar disponibles o no recopilar datos si se interrumpen las conexiones de red. A veces, puedes mitigar este riesgo si realizas el hosting tú mismo, pero también deberás mantener la infraestructura para la solución.
  • Los paneles alojados de forma externa no están disponibles directamente para la asistencia de Google Cloud. Esta falta de disponibilidad puede ralentizar la solución de problemas y la mitigación.
  • Las soluciones de socios comerciales pueden implicar más tarifas de licencia.

Entre las integraciones de ejemplo detalladas se incluyen las siguientes:

Analiza métricas de Prometheus y Logging con Grafana

Grafana es una herramienta popular de supervisión de código abierto que se suele vincular con Prometheus para recopilar métricas. En esta arquitectura, se usa Prometheus como la capa de recopilación local y Grafana como un panel único para los recursos de Google Cloud y locales. En el siguiente diagrama, se muestra una arquitectura de ejemplo que analiza las métricas de Google Cloud y de las instalaciones locales.

Arquitectura de alto nivel para la supervisión con Grafana como panel único

Esta arquitectura cuenta con las siguientes ventajas:

  • Es adecuada para entornos híbridos con VM y contenedores.
  • Si en tu organización ya se usan Prometheus y Grafana, los usuarios pueden seguir usándolos.

Esta arquitectura tiene las siguientes desventajas:

Si deseas obtener más información, consulta Mejor solución de problemas con un complemento de Cloud Logging para Grafana.

Exporta registros mediante Fluentd

Un patrón anterior abordó el uso de Fluentd o Fluent Bit como recopilador de registros para Logging. La misma arquitectura básica también se puede usar para otros sistemas de análisis de datos o registros compatibles con Fluentd o Fluent Bit, incluidos BigQuery, Elastic y Splunk. En el siguiente diagrama, se ilustra este patrón.

Arquitectura de alto nivel para exportar registros directamente desde Fluentd o Fluent Bit.

Esta arquitectura cuenta con las siguientes ventajas:

  • Es adecuada para entornos híbridos con VM y contenedores.
  • Fluentd puede leer desde muchas fuentes de datos, incluidos los registros del sistema.
  • Fluentd ofrece complementos de salida para varios sistemas populares de análisis de datos y registro de terceros.
  • Fluent Bit también puede leer desde muchas entradas, incluidos los registros del sistema.
  • Fluent Bit ofrece resultados para muchos sistemas de análisis de datos y registro de terceros populares.

Esta arquitectura tiene las siguientes desventajas:

  • Fluentd y Fluent Bit solo admiten registros, por lo que la supervisión debe configurarse por separado. En la sección anterior, se analizan las opciones comunes para la supervisión con Prometheus y Grafana.
  • Fluentd y Fluent Bit son herramientas de terceros y no productos oficiales de Google. Google no ofrece asistencia para ellas.
  • La asistencia de Google Cloud no tiene acceso a los registros exportados para solucionar problemas. En particular, Google no ofrece asistencia para clústeres de GKE en VMware sin Logging habilitado.

Separa datos de aplicaciones y de operaciones

Las arquitecturas de panel único requieren la transmisión de los datos de registro y supervisión de aplicaciones a la nube. Sin embargo, puede que haya requisitos regulatorios o de cumplimiento que exijan mantener los datos del cliente en instalaciones locales o establezcan restricciones estrictas sobre los datos que se pueden almacenar en la nube pública.

Un patrón útil para estos entornos híbridos consiste en separar los datos sensibles de aplicaciones de los datos de menor riesgo relativos a operaciones, como se ilustra en el siguiente diagrama.

Arquitectura de alto nivel para separar los datos de aplicaciones de los datos de operaciones

Separa datos del sistema y de las aplicaciones con GKE Enterprise

GKE Enterprise en VMware, que forma parte del paquete de GKE Enterprise, incluye Grafana para la supervisión de clústeres locales. Además, puedes optar por instalar una solución de socios, como Elastic Stack o Splunk, para el registro. Con estas soluciones, puedes transferir y ver datos sensibles de aplicaciones de forma local, mientras se exportan los datos del sistema a Logging en Google Cloud. En el siguiente diagrama, se ilustra esta arquitectura.

Separa datos del sistema y de las aplicaciones con GKE Enterprise.

Esta arquitectura cuenta con las siguientes ventajas:

  • Los datos sensibles de aplicaciones se conservan en las instalaciones locales.
  • La supervisión y el registro locales no tienen dependencias en la nube y permanecen disponibles aunque se interrumpa la conexión de red.
  • Todos los datos del sistema de GKE, locales o de Google Cloud, están centralizados en Logging, y la asistencia de Google Cloud puede acceder a ellos según sea necesario.

Para ver una implementación de ejemplo con Elastic Stack como la solución de socios, consulta Supervisa GKE Enterprise con Elastic Stack.

¿Qué sigue?