Commit d7db040b authored by Ignacio's avatar Ignacio
Browse files

Añade info sobre métricas

parent 35771c91
Loading
Loading
Loading
Loading
+27.4 KiB
Loading image diff...
+10 KiB
Loading image diff...
+9.65 KiB (41 KiB)
Loading image diff...
+18 −2
Original line number Diff line number Diff line
# Monitorización
## Métricas
Como todo buen sistema, se necesitan datos que permitan ver el rendimiento del sistema, para ello REDMIC, al usar un sistema como Docker Swarm, se ha optado por usar [SwarmProm](https://github.com/stefanprodan/swarmprom){: target="_blank"}, un proyecto que aglutina varias herramientas para realizar monitorización de un entorno Docker Swarm.

### CadAvisor
### PushGateway
### cAdavisor
cAdvisor es un sistema de monitorización de contenedores, implementado por Google, que permite analizar los recursos usados por un contenedor en ejecución así como su rendimiento.

![cadvisor-logo](images/cadvisor_logo.png){: .shadow}

### Node-exporter
Expone métricas del servidor dónde se instale, para ello recopilada datos del hardware, así como del sistema operativo expuestas por el kernel *NIX.

### dockerd-exporter
Colecta métricas del servicio de docker

### PushGatewayPus
Algunos contenedores no están continuamente en ejecución y a menudo solo se encargan de realizar una acción momentáneamente como una copia de seguridad de una base de datos, realizar una tarea de mantenimiento, etc. Este tipo funcionamiento hace que Prometheus no pueda recopilar datos de ellos, así que para resolver este problema, se utiliza PushGateway.

![pushgateway](images/pushgateway.png){: .center}

Cuando un contenedor de este tipo necesita exponer una métrica, realiza un PUT al servicio de PushGateway con la métrica, este la almacena para que Prometheus la pueda leer. La métrica no será actualizada hasta que el contenedor no vuelva a realizar un PUT con nuevos datos.

### Prometheus

+14 −7
Original line number Diff line number Diff line
@@ -7,19 +7,26 @@ La estructura actual Actualmente se cuenta con 4 servidores
Se utiliza docker swarm
![servers_infrastructure](images/servers_infrastructure.png){: .center}

Todos los servidores pertenecen a una misma red (VPC), pero cada zona cuenta con una subred más una exclusiva para el manager, es decir, existen 4 subredes. Esto hace que si en un futuro aumenta el número de servidores, los nuevos equipos se uniran a las subredes existentes.
Todos los servidores pertenecen a una misma red (VPC), pero cada zona cuenta con una subred más una exclusiva para el manager, es decir, existen 4 subredes. Esto hace que si en un futuro aumenta el número de servidores, los nuevos equipos se unirán a las subredes existentes.

El manager es el encargado de exponer de exponer los diferentes servicios a internet, es por eso que es el único servidor accesible desde el exterior, siempre controlando que puertos se exponen a través de un firewall.
El manager es el encargado de exponer de exponer los diferentes servicios a Internet, es por eso que es el único servidor accesible desde el exterior, siempre controlando que puertos se exponen a través de un firewall.

Los workers son servidores de ejecutar los servicios, están distribuidos entre las 3 zonas que provee Amazon en la región "eu-west-1", esta distribución evita que la aplicación deje de responder si alguna de las zonas cae.

Esta distribución de servidores se ha optado como esquema base para desplegar una docker swarm.
Esta distribución de servidores adoptada viene impuesta por Docker Swarm, dónde existe uno o varios managers y un conjunto de servidores workers en los cuáles se desplegan las distintas herramientas.

### Despliegue
Para el aprovisionamiento de todas estas máquinas, con sus respectivos requisitos se ha utilizado como base la plantilla de CloudFormation que proporciona [Docker](https://docs.docker.com/docker-for-aws/){: target="_blank"}.
Para el aprovisionamiento de todas estas máquinas, con sus respectivos requisitos se ha utilizado como base la plantilla de CloudFormation que proporciona [Docker](https://docs.docker.com/docker-for-aws/){: target="_blank"}. Dicha plantilla ha sido personalizada, por un lado porque se encontró un problema con el plugin ClouStor y el almacenamiento EFS, que hacia que el comportamiento de la aplicación no fuese el adecuado, así que se optó por reemplazar la imagen base utilizada, Moby Linux, por Ubuntu Server, debido ha que era la causante del problema.

En esta plantilla se definen varios parámetros:

* Nombre del stack
* Número de servidores managers y workers
* Clave SSH para conectar a las máquinas
* Tipo de instancias AWS, tanto para managers como workers
* Tipo de discos y capacidades de los mismos



Se utiliza una plantilla de CloudFormation para el despliegue de la infraestructura.

Se definen tipos de máquinas, tamaño de los discos, VPC, imagen ISO, 4 VPC
Los servidores workers no son accesibles desde fuera de VPC, el único servidor accesible es el manager, que es encargado de repartir la carga entre los workers.