En este documento se analizan las arquitecturas de monitorización y de almacenamiento de registros de los despliegues en entornos híbridos y multinube, y se ofrecen prácticas recomendadas para implementarlas mediante Google Cloud. Con este documento, puede identificar qué patrones y productos son los más adecuados para sus entornos.
Cada empresa tiene una cartera única de cargas de trabajo de aplicaciones que imponen requisitos y restricciones a la arquitectura de una configuración híbrida o multinube. Aunque debes diseñar y adaptar tu arquitectura para cumplir estas restricciones y requisitos, puedes usar algunos patrones comunes.
Los patrones que se describen en este documento se dividen en dos categorías:
- En una arquitectura de panel centralizado, toda la monitorización y el registro se centralizan con el objetivo de proporcionar un único punto de acceso y control.
- En una arquitectura de aplicación y operaciones independientes, los datos de aplicaciones sensibles se segregan de los datos de operaciones menos sensibles, con el objetivo de cumplir los requisitos de cumplimiento de los datos sensibles.
Elegir el patrón de arquitectura
Puedes usar el diagrama de flujo de toma de decisiones que aparece a continuación para identificar la mejor arquitectura para tu caso práctico.
En este documento se explican los detalles de cada arquitectura, pero, a grandes rasgos, estas son las opciones que tienes:
- Exportar de Monitoring a la solución antigua.
- Exportar directamente a la solución antigua.
- Usa Monitoring con Prometheus y Fluentd o Fluent Bit.
- Usa Monitoring con observIQ BindPlane.
Arquitectura de herramienta unificada
Un objetivo habitual de un sistema híbrido es integrar la información de monitorización y registro de varias fuentes en diferentes aplicaciones y entornos en una sola pantalla. Este tipo de vista se denomina herramienta unificada.
En el siguiente diagrama se ilustra este patrón, en el que los datos de monitorización y registro de todas las aplicaciones, tanto locales como en la nube, se centralizan en un único repositorio alojado en la nube.
Esta arquitectura tiene las siguientes ventajas:
- Tienes una vista única y coherente de toda la monitorización y el registro.
- Tienes un único lugar para gestionar el almacenamiento y la conservación de datos.
- Obtendrás un control de acceso y una auditoría centralizados. Sin embargo, debes asegurarte de que los datos en tránsito al repositorio central estén protegidos.
Monitorización centralizada
Cloud Monitoring es una solución de monitorización y gestión de Google para servicios, contenedores, aplicaciones e infraestructura. Si quieres tener un único panel de control y una solución de almacenamiento sólida para métricas, registros, trazas y eventos, usa Google Cloud Observability. La suite también proporciona un conjunto completo de herramientas de observabilidad, como paneles de control, informes y alertas.
Todos los Google Cloud productos y servicios admiten la integración con Monitorización. Además, hay varias herramientas integradas que puedes usar para ampliar Monitoring a recursos híbridos y locales.
Las siguientes prácticas recomendadas se aplican a todas las arquitecturas que usan Monitoring como panel de control único:
- Para cumplir los requisitos de conservación de registros, configura receptores de registros para tu organización.
- Para analizar rápidamente los eventos de registro, configura exportaciones de registros a BigQuery para obtener analíticas de seguridad y acceso.
- Para analizar los registros almacenados en tu contenedor de registros, ejecuta consultas de SQL a través de Analíticas de registros.
- En los proyectos que contengan datos sensibles, te recomendamos que habilites los registros de auditoría de acceso a datos para poder hacer un seguimiento de quién ha accedido a los datos.
- Para eliminar información sensible, como números de la seguridad social, números de tarjetas de crédito y direcciones de correo electrónico, puede filtrar los datos de registro. Puedes filtrar mediante una configuración personalizada de Fluent Bit o ingiriendo con exclusiones de registros. También puedes exportar los registros sin filtrar por separado para cumplir los requisitos.
Monitorización y registro híbridos con Monitoring y BindPlane de observIQ
Con BindPlane de observIQ, partner de Google, puedes importar datos de monitorización y registro de VMs on-premise y de otros proveedores de servicios en la nube, como Amazon Web Services (AWS), Microsoft Azure, Alibaba Cloud e IBM Cloud, a Google Cloud. En el siguiente diagrama se muestra cómo Monitoring y BindPlane pueden proporcionar un panel de control único para una nube híbrida.
Esta arquitectura tiene las siguientes ventajas:
- Además de monitorizar recursos como las máquinas virtuales, BindPlane tiene una integración profunda integrada con más de 50 fuentes de datos populares.
- No hay costes de licencia adicionales por usar BindPlane. Las métricas de BindPlane se importan a Monitoring como métricas personalizadas, que son facturables. Del mismo modo, los registros de BindPlane se cobran a la misma tarifa que otros registros de Logging.
Para obtener más información sobre cómo implementar este patrón, consulta Registro y monitorización de recursos locales con BindPlane.
Monitorización híbrida de Google Kubernetes Engine con Prometheus y Monitoring
Con Google Cloud Managed Service for Prometheus, una solución de monitorización de código abierto popular totalmente gestionada por Google Cloud, puedes monitorizar 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) on-premise y Google Distributed Cloud en tu centro de datos local, ya que proporciona una interfaz unificada en ambos.Google Cloud En el siguiente diagrama se muestra cómo usar Prometheus y los colectores de Monitoring para recopilar datos.
Esta arquitectura tiene las siguientes ventajas:
- Métricas de Kubernetes coherentes en entornos en la nube y on-premise.
- Te permite monitorizar y recibir alertas a nivel global sobre tus cargas de trabajo mediante Prometheus, sin tener que gestionar ni usar Prometheus manualmente a gran escala.
- No hay costes de licencia adicionales por usar Prometheus. Las métricas de Prometheus se importan a Monitoring. Las importaciones son facturables y se facturan según el número de muestras ingeridas.
Esta arquitectura tiene las siguientes desventajas:
- Prometheus solo admite la monitorización, por lo que el registro debe configurarse por separado. En la siguiente sección se describe una opción habitual para registrar datos mediante Fluentd o Fluent Bit.
Te recomendamos que sigas esta práctica recomendada:
- De forma predeterminada, Prometheus recoge todas las métricas expuestas, cada una de las cuales se convierte en una métrica facturable. Para evitar costes inesperados, te recomendamos que implementes controles de costes de monitorización.
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 ingerir registros de aplicaciones que se ejecutan en varios clústeres de GKE en Cloud Logging. Esta arquitectura es útil cuando se ejecutan cargas de trabajo de Kubernetes distribuidas entre GKE On-Prem y Google Distributed Cloud en tu centro de datos local, ya que proporciona una interfaz unificada en ambos. Google Cloud En el siguiente diagrama se muestra el flujo de los registros.
Esta arquitectura tiene las siguientes ventajas:
- Puedes tener un registro de Kubernetes coherente en entornos en la nube y on-premise.
- Puedes personalizar el registro para filtrar la información sensible.
- No hay costes de licencia adicionales por usar Fluentd o Fluent Bit. Los registros que se importan a Logging mediante Fluentd o Fluent Bit son de pago.
Esta arquitectura tiene las siguientes desventajas:
- Fluentd y Fluent Bit solo admiten el registro, por lo que la monitorización debe configurarse por separado. En la sección anterior se describe una opción habitual para monitorizar con Prometheus.
Para obtener más información sobre cómo implementar este patrón, consulta Personalizar Fluent Bit para los registros de Google Kubernetes Engine.
Servicios de partners como herramientas unificadas
Si ya usas un servicio de monitorización o registro de terceros, como Datadog o Splunk, puede que no quieras cambiar a Logging. Si es así, puedes exportar datos de Google Cloud a muchos servicios de monitorización y registro habituales. Puedes usar un servicio integrado de monitorización y registro, o bien seleccionar servicios de monitorización y registro independientes que se adapten mejor a tus necesidades.
Exportar de Logging a servicios de partners
En este patrón, autorizas el servicio de monitorización del partner, como Datadog, para que se conecte a la API Cloud Monitoring. Esta autorización permite que el servicio ingiera todas las métricas disponibles en Logging, de modo que Datadog pueda funcionar como un único panel de control para la monitorización.
Para los datos de registro, Logging ofrece exportaciones (sumideros de registros) a Pub/Sub. Estas exportaciones proporcionan un método eficaz y resistente para que los servicios de registro de partners, como Elastic y Splunk, ingieran grandes volúmenes de registros de Logging en tiempo real. De esta forma, estos servicios de partners pueden ofrecer un panel único para los registros.
En el siguiente diagrama se muestra la arquitectura combinada para el registro y la monitorización.
Esta arquitectura tiene las siguientes ventajas:
- Puedes seguir usando las herramientas que ya conoces.
- Google Cloud El equipo de Asistencia sigue teniendo acceso a los registros de registro para solucionar problemas.
Esta arquitectura tiene las siguientes desventajas:
- Las soluciones de partners suelen alojarse externamente, lo que significa que es posible que no estén disponibles o que no recojan datos si se interrumpen las conexiones de red. En ocasiones, puedes mitigar este riesgo mediante el alojamiento propio, pero a costa de tener que mantener tú mismo la infraestructura de la solución.
- Los paneles de control alojados externamente no están disponibles directamente para el equipo de Asistencia.Google Cloud Esta falta de disponibilidad puede ralentizar la resolución de problemas y la mitigación.
- Las soluciones de partners comerciales pueden conllevar más tarifas de licencia.
A continuación se incluyen algunos ejemplos detallados de integraciones:
- Datadog: Monitorizar métricas de Compute Engine y Recoger registros de Logging
- Elastic: Exportar registros de Logging a Elastic Cloud
- Splunk: Ejemplos de la exportación de registros
Analizar métricas de Prometheus y Logging con Grafana
Grafana es una popular herramienta de monitorización de código abierto que se suele usar junto con Prometheus para recoger métricas. En esta arquitectura, se usa Prometheus como capa de recogida local y Grafana como panel único para los recursos deGoogle Cloud y los locales. En el siguiente diagrama se muestra una arquitectura de ejemplo que analiza métricas de Google Cloud y de entornos locales.
Esta arquitectura tiene las siguientes ventajas:
- Es adecuado para entornos híbridos con máquinas virtuales y contenedores.
- Si tu organización ya usa Prometheus y Grafana, tus usuarios pueden seguir usándolos.
Esta arquitectura tiene las siguientes desventajas:
- Prometheus solo admite la monitorización, por lo que el registro debe configurarse por separado. Por ejemplo, puedes usar Fluentd o el plugin Cloud Logging para Grafana.
- Prometheus es de código abierto y extensible, pero solo admite una gama limitada de integraciones de software empresarial.
- Prometheus y Grafana son herramientas de terceros y no productos oficiales de Google. Google no ofrece asistencia para Prometheus ni Grafana.
Para obtener más información, consulta Mejorar la solución de problemas con un complemento de Cloud Logging para Grafana.
Exportar registros con Fluentd
En un patrón anterior se explicaba cómo usar Fluentd o Fluent Bit como recolector de registros para Logging. La misma arquitectura básica también se puede usar en otros sistemas de registro o de analíticas de datos que admitan Fluentd o Fluent Bit, como BigQuery, Elastic y Splunk. En el siguiente diagrama se ilustra este patrón.
Esta arquitectura tiene las siguientes ventajas:
- Es adecuado para entornos híbridos con máquinas virtuales y contenedores.
- Fluentd puede leer datos de muchas fuentes de datos, incluido el registro del sistema.
- Fluentd ofrece complementos de salida para muchos sistemas populares de registro y analíticas de datos de terceros.
- Fluent Bit también puede leer de muchas entradas, incluidos los registros del sistema.
- Fluent Bit ofrece salidas para muchos sistemas populares de registro y analíticas de datos de terceros.
Esta arquitectura tiene las siguientes desventajas:
- Fluentd y Fluent Bit solo admiten registros, por lo que la monitorización debe configurarse por separado. En la sección anterior se describen las opciones habituales para monitorizar con Prometheus y Grafana.
- Fluentd y Fluent Bit son herramientas de terceros y no productos oficiales de Google. Google no ofrece asistencia para ellos.
- Los registros exportados no están disponibles para el equipo de Asistencia de Google Cloud para solucionar problemas. En concreto, Google no ofrece asistencia para clústeres de Google Distributed Cloud sin el registro habilitado.
Datos de aplicaciones y operaciones independientes
Las arquitecturas de panel único requieren monitorización de aplicaciones de streaming y registro de datos en la nube. Sin embargo, es posible que tengas requisitos normativos o de cumplimiento que exijan que los datos de los clientes se mantengan en las instalaciones o que impongan restricciones estrictas sobre qué datos se pueden almacenar en la nube pública.
Un patrón útil para estos entornos híbridos es separar los datos de aplicaciones sensibles de los datos de operaciones de menor riesgo, tal como se muestra en el siguiente diagrama.
Separar los datos de aplicaciones y sistemas con GKE Enterprise
GKE Enterprise en VMware, que forma parte de la suite GKE Enterprise, incluye Grafana para monitorizar clústeres locales. Además, puedes instalar una solución de partner, como Elastic Stack o Splunk, para registrar los eventos. Con estas soluciones, puede ingerir y ver datos de aplicaciones sensibles por completo en las instalaciones, al tiempo que exporta datos del sistema a Logging enGoogle Cloud. En el siguiente diagrama se muestra esta arquitectura.
Esta arquitectura tiene las siguientes ventajas:
- Los datos de aplicaciones sensibles se conservan íntegramente en las instalaciones.
- La monitorización y el registro locales no tienen dependencias de la nube y siguen estando disponibles aunque se interrumpa la conexión de red.
- Todos los datos del sistema de GKE, tanto locales comoGoogle Cloud, se centralizan en Logging y también están disponibles para el Google Cloud equipo de AsistenciaGoogle Cloudcuando sea necesario.
Para ver un ejemplo de implementación con Elastic Stack como solución de partner, consulta Monitorizar GKE Enterprise con Elastic Stack.
Siguientes pasos
- Consulta más información sobre las prácticas recomendadas para entornos híbridos y multinube en la serie Patrones y prácticas para entornos híbridos y multinube, que incluye patrones de arquitectura y patrones de arquitectura de redes seguras.
- Inscríbete en la misión de prácticas recomendadas de Cloud Kubernetes para hacer ejercicios prácticos sobre observabilidad y más en GKE.
- Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.