Las soluciones de monitorización listas para usar son cada vez más difíciles de implementar. Además, es posible que no tengan las funciones que necesita y siempre se vuelven más caras. No es de extrañar que esté tratando de crear una solución rentable a través de la administración de costos de monitoreo de infraestructura por su cuenta utilizando una combinación de su talento de desarrollo en el sitio y algunas bibliotecas de código abierto. En este artículo, aprenderá cómo equilibrar las soluciones de monitoreo de software como servicio (SaaS) y de cosecha propia en la nube que elija, cómo hacer que estas soluciones sean rentables y cómo administrar sus costos ocultos asociados.
Construir una pila de monitoreo de infraestructura
En esencia, una aplicación de monitoreo consta de tres partes. El nivel web es la interfaz que utilizan los administradores para interactuar con el sistema. El nivel de aplicación es donde ocurre todo el manejo y procesamiento de datos. Esencialmente, aquí es donde el monitor “escucha” todo lo que sucede en su entorno. Por último, el nivel de la base de datos almacena de forma segura los datos persistentes para que se puedan recuperar fácilmente para ejecutar informes en un momento posterior.
A medida que cree la solución que mejor se adapte a sus necesidades, se dará cuenta de que no es necesario que lo construya todo desde cero. Hay muchas tecnologías en la nube y en las instalaciones que se pueden reutilizar fácilmente. Un ejemplo de un SaaS que querrá incorporar es una cola de eventos. AWS llama a esta tecnología Simple Queue Service (SQS). En Azure, se lo conoce como Azure Event Hubs . Puede utilizar un servicio local para proporcionar esta misma funcionalidad. Puede poner en marcha, administrar y orquestar su propia implementación de Apache Kafka o RabbitMQ . Sin embargo, si está implementando su propia supervisión de infraestructura, automatizar la parte difícil mediante el uso de una solución SaaS nativa basada en la nube es una mejor opción que agregar complejidad adicional.
Ya hemos hablado de los beneficios del monitoreo nativo en la nube . La conclusión es que elegir hacer girar una pila ELK en la nube le ahorrará tiempo, dinero y recursos que podrían implementarse mejor en otros lugares.
Gestión de costos de monitoreo de infraestructura
Construir su infraestructura de monitoreo de manera efectiva es clave para crear una solución rentable. Usted debe evitar el exceso de gastos, asegurando que su solución tiene el tamaño y la escala para sus necesidades de manera apropiada. Si no lo hace, está dejando dinero sobre la mesa.
El análisis de la arquitectura nativa de la nube puede ayudarlo a determinar las áreas de gasto excesivo o insuficiente. Los servicios de análisis como AWS Well-Architected Framework y Azure Advisor le muestran cuáles de sus recursos están aprovisionados incorrectamente. Pueden ayudarlo a proporcionar su implementación para evitar gastos excesivos en áreas como almacenamiento e IOPS.
Además, puede alojar su propia pila de ELK para supervisar e informar sobre la facturación de AWS. Para hacer esto, habilite los informes de facturación de AWS y envíe los registros con AWS Lambda. Una vez exportados, los registros se pueden consultar y analizar en busca de áreas de mejora. Finalmente, herramientas como AWS Well-Architected Framework, una pila de ELK personalizada o Azure Advisor pueden monitorear la facturación de su infraestructura de monitoreo.
Gestión de costes multicloud
La administración de costos entre múltiples proveedores agrega complejidad y desafíos. Desafortunadamente, no hay forma de administrar sus gastos de Azure con un servicio nativo de AWS, o viceversa. Cuando se trata de gastos multinube, debe obtener los fundamentos correctos siguiendo las tres pautas que se describen a continuación.
- Desactive los servicios y servidores inactivos
Aunque esto puede parecer un punto básico, es importante analizar sus recursos en la nube aprovisionados automáticamente y con escalado automático. Si está ampliando su plataforma de forma agresiva y ninguno de sus puntos finales se ejecuta por encima del 25% de su capacidad, tiene una gran oportunidad para ahorrar costes.
De manera similar, si tiene un mínimo de 50 servidores definidos en un grupo de autoescalado y su aplicación solo necesita 20, no es necesario que esos 30 servidores adicionales consuman sus recursos y su presupuesto. En consecuencia, los requisitos de carga de trabajo de su aplicación pueden contribuir en gran medida a mantener bajos los costos.
- Reducir los recursos aprovisionados en exceso
A veces se siente bien tener una flota de 100 servidores inactivos listos para manejar una ráfaga repentina de tráfico. Sin embargo, el mantenimiento de esta flota aumenta drásticamente sus gastos. Una mejor manera de manejar un aumento en la actividad es mediante el uso de contenedores u orquestación para poner en marcha rápidamente nuevos servidores cuando note el cambio. DevOps puede ayudarlo aquí.
- Reevalúe periódicamente sus entornos de no producción para identificar el gasto excesivo
Aunque se recomienda que sus entornos de no producción reflejen la producción, es posible que desee considerar el costo que esto conlleva. Puede escalar su entorno de no producción con un impacto mínimo en sus recursos de producción. Por ejemplo, puede aumentar los requisitos antes de expandir sus grupos de autoescalado en la no producción para evitar ejecutar varios cientos de servidores completos para una carga de prueba.
Administrar los costos de múltiples nubes no es imposible. Simplemente no tiene la automatización que tiene en un entorno de nube nativo. Ser consciente de lo que implementa y administrar los costos en un nivel de servicio por servicio le permitirá ahorrar tiempo, dinero y recursos.
Administre los costos ocultos del monitoreo de la infraestructura
Hasta ahora, hemos cubierto los costos “conocidos conocidos”, como el gasto de las infraestructuras de nube aprovisionadas. Lo que no hemos discutido todavía son los costos “desconocidos conocidos”: los costos de recuperación de datos, ajuste de escala automático y mantenimiento. Al implementar una solución de monitorización personalizada, la monitorización en la nube tiene algunas “trampas” a las que debe prestar atención.
El primero involucra datos en tránsito. Ya sabe que existen costos asociados con el almacenamiento de datos en la nube en reposo. También se pueden acumular costos para los datos en tránsito. La mayoría de los proveedores de la nube le permiten poner datos en la nube de forma gratuita. Esto es excelente si desea crear un lago de datos, almacenar de forma segura los archivos de su empresa o incluso abrir una tubería para que fluyan todos sus datos de monitoreo. La nube se vuelve costosa cuando desea extraer los datos. Tanto AWS como Azure cobran por ejecutar consultas y recuperar datos.
El siguiente lugar en el que podría tropezar es en el mantenimiento de la solución. Es comprensible pensar que el soporte está integrado cuando implementa varias soluciones de código abierto. Esto no podría estar más lejos de la verdad. Uno de los beneficios de usar software de monitoreo de código abierto es que se puede adquirir de forma gratuita. Sin embargo, el mantenimiento, soporte y desarrollo personalizado de la solución tendrá sus propios costos únicos.
Resumen
Las soluciones de monitoreo de infraestructura personalizadas están comenzando a tener más sentido, dado el panorama de monitoreo en constante cambio. En su mayor parte, las soluciones de código abierto pueden competir con muchos grandes nombres, pero recuerde que todavía existen costos ocultos.
Por consiguiente. La administración de costos es vital para ejecutar su pila de monitoreo de infraestructura. Con la preparación adecuada y las expectativas adecuadas, puede crear una solución de monitoreo que le brindará exactamente lo que necesita a un costo que puede predecir. La implementación de las mejores prácticas para la nube nativa, la nube híbrida y las soluciones multinube le permitirá aprovechar al máximo todas las tecnologías disponibles.
Gedalyah Reback (2020) How to Create Cost-Effective Infrastructure Monitoring. Recuperado de: https://logz.io/blog/
