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

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
  • Usar Monitoring con Prometheus y Fluentd
  • Usar Monitoring con Blue Medora 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. El paquete de operaciones de Google Cloud ofrece un panel único y una solución de almacenamiento sólida para las métricas, los registros, los seguimientos y los eventos. 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 Blue Medora BindPlane

Con el socio de Google Blue Medora BindPlane, puedes importar a Monitoring datos de supervisión y registro de VM locales y otros proveedores de servicios en la nube, como Amazon Web Services (AWS), Microsoft Azure, IBM Cloud y Alibaba 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 Blue Medora.

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

Con Prometheus, una solución popular de supervisión de código abierto, y el sidecar de Prometheus para Monitoring, 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 Anthos alojados 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 el sidecar 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
  • No se aplican costos de licencia adicionales por usar Prometheus. Las métricas de Prometheus se importan a Monitoring como métricas personalizadas, que se cobran según las tarifas estándar

Esta arquitectura tiene las siguientes desventajas:

  • El archivo adicional de Prometheus para Monitoring solo se admite en los entornos de GKE.
  • Prometheus solo admite la supervisión, por lo que el registro debe configurarse por separado. En la siguiente sección, se analiza Fluentd, una opción común para el registro.

Recomendamos lo siguiente:

  • De forma predeterminada, Prometheus recopila todas las métricas expuestas, cada una de las cuales se convierte en una métrica personalizada que se cobra. Si deseas evitar costos inesperados, implementa los controles de costos de Monitoring y considera agregar filtros al archivo adicional de Prometheus para Monitoring a fin de limitar la transferencia.

Para obtener más información sobre cómo implementar este patrón, consulta Supervisa las apps que se ejecutan en varios clústeres de GKE mediante Prometheus y Monitoring.

Registro híbrido de GKE con Fluentd y Logging

Con Fluentd, un agente popular de registro de código abierto, 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 clústeres de Google Cloud y de Anthos alojados en VMware en tu centro de datos local, puesto 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, 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. Los registros de Fluentd importados a Logging se cobran según las tarifas estándar.

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.

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:

Exporta métricas de Prometheus y Logging a 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 exporta métricas locales y de Google Cloud.

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:

  • Prometheus y Grafana solo admiten la supervisión, por lo que el registro debe configurarse por separado, por ejemplo, mediante Fluentd.
  • Prometheus es de código abierto y extensible, pero solo admite un rango limitado de integraciones de software de nivel empresarial.
  • Prometheus y Grafana son herramientas de terceros, no son productos oficiales de Google. Google no ofrece asistencia para Prometheus o Grafana.

Si deseas obtener más información, consulta Introducción a Logging como fuente de datos para Grafana. Para ver un instructivo detallado sobre cómo implementar Prometheus y Grafana con GKE y Logging, consulta Usa Prometheus y Grafana para la supervisión de IoT.

Exporta registros mediante Fluentd

Un patrón anterior se trató mediante Fluentd 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, incluido BigQuery, Elastic y Splunk. En el siguiente diagrama, se ilustra este patrón.

Arquitectura de alto nivel para exportar registros directamente desde Fluentd

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.

Esta arquitectura tiene las siguientes desventajas:

Para ver un ejemplo de integración de Fluentd con BigQuery, consulta Analiza registros en tiempo real mediante Fluentd y BigQuery.

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 Anthos

Anthos en VMware, que forma parte del paquete de Anthos, 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 Anthos.

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 un ejemplo de implementación en el que se usa Elastic Stack como la solución de socio, consulta Supervisa Anthos con Elastic Stack.

¿Qué sigue?