Monitoreo de métricas en tiempo real y con historial [2da Parte]

En esta segunda parte configuraremos nuestro netdata en modo master para recibir métricas de otros servidores con netdata slave y poder verlo todo concentrado en una sola web. Además mandar toda esa información del master a Prometheus y luego graficarlo con Grafana, tal como se mostró en la figura de la primera parte.

ÍNDICE

¿Qué es lo que se quiere?

Netdata.

¿Qué es Netdata?

Implementación y configuración de Netdata.

Prerrequisitos de instalación de Netdata sin internet.

Instalación de Netdata.

Configuración de Netdata-master.

Configurando Netdata-slave.

Proxy inverso para autenticación de Netdata.

HTTPS con certificado SSL auto-firmado para Nginx.

Configurando Nginx para usar SSL.

Creando un Fragmento de Configuración Apuntando a la Llave y Certificado SSL.

Creando una Porción de Configuración con Fuertes Opciones de Encriptación.

Ajustando la Configuración de Nginx para usar SSL.

Script anticrash para Netdata.

Prometheus.

¿Qué es Prometheus?.

Implementación y configuración de Prometheus.

Configurando Prometheus.

Iniciando Prometheus.

Comprobando resultados en servidor Prometheus.

Grafana.

¿Qué es Grafana?.

Implementación y configuración de Grafana.

Iniciando Grafana.

Integrando Prometheus con Grafana.

UFW

Usaremos una estructura como la siguiente para tener concentrada todas las metricas en un solo punto.

Como se observa en la figura todos los netdata escalvos(slave) envian al netdata master. Desde una sola ubicacion podremos ver las metricas de todos los servidores donde instalamos netdata.

Configuración de Netdata-master.

En servidor “netdata-master”:

Netdata introduce un nuevo archivo: stream.conf (para editarlo en su sistema, ejecute /etc/netdata/edit-config stream.conf). Este archivo contiene la configuración de transmisión tanto para el envío como para el receptor de Netdata. Las claves de API se utilizan para autorizar la comunicación de un par de Netdata emisores-receptores. Una vez que se autoriza la comunicación, el Netdata emisor puede enviar métricas para cualquier número de hosts. Puede generar una clave API con el comando uuidgen. Las claves de API son solo GUID aleatorios. Puede usar la misma clave API en todos sus Netdata, o usar una clave API diferente para cualquier par de Netdata de envío-recepción.

Generando el uudi para el API_KEY:

Debe devolver un ID con la misma cantidad de cifras que el siguiente ejemplo:

NOTA: Se recomienda usar la misma API key para cada plantilla de nodo efímero que se tenga, entonces todas las réplicas del mismo nodo efímero tendrán exactamente la misma configuración.

opciones para el nodo receptor (master)

Puede agregar muchas de estas secciones, una para cada clave de API. Los anteriores se utilizan como valores predeterminados para todos los hosts enviados con esta clave de API.

En el nodo receptor, [stream].enabled debe ser no. Si lo ponemos es si, el nodo receptor también transmitirá las métricas a otro nodo (es decir, será un proxy).

También puede usar el modo de memoria predeterminado (dbengine) para una clave de API o el modo de memoria (dbengine) para un solo host. El tamaño de caché de página adicional y las opciones de configuración de espacio en disco dbengine multihost se heredan de la configuración global de Netdata.
allow from = La configuración de permitir desde son patrones simples de Netdata: coincidencias de cadenas que usan * como comodín (cualquiera) y un! prefijo para una coincidencia negativa. Entonces: allow from =! 10.1.2.3 10. * permitirá todas las direcciones IP en 10. * excepto 10.1.2.3. El orden es importante: de izquierda a derecha, se utiliza la primera coincidencia positiva o negativa.

Reiniciamos el nodo netdata-master:

Aunque el servicio de netdata no esté corriendo correctamente el reinicio si hace que tome las nuevas configuraciones. Si esto no le funciona puede correr de nuevo el binario que está en /usr/sbins/netdata.

Ahora el netdata-master se encuentra listo para recibir métricas.

Configurando Netdata-slave.

Usamos el mismo procedimiento anterior solo que esta vez especificamos que seremos emisores(slave).

opciones para el nodo emisor (slave)

Aqui solo nos centraremos en la parte de stream.

Nota: Como seguro ya notaron el fichero stream.conf es único para ambas configuraciones por lo tanto solo hay que tener en cuenta la parte a llenar cuando se es master(receptor) y cuando se es slave(emisor).

Para aplicar los cambios reiniciamos el servicio y el cron:

Visualización de la web en el netdata-master:

En la figura se aprecia 3 netdatas slaves(emisores) tributando a nuestro netdata master.

Si no le sale el netdata-slave, reinicie el servicio de netdata en el netdata-master. Si aún después de eso sigue sin salir, pues reinicie el servidor netdata-master. Si luego de esto, sigue sin mostrarse, pues dele un poco de tiempo, al poco tiempo aparecerá. Los nombres que se visualizarán en el netdata-master dependerán del “hostname” de cada host. Hasta aquí usted cuenta con un sistema de monitoreo master-slave para Netdata, que brinda métricas en tiempo real de los hosts Linux que tengan instalado el programa. Las estadísticas son visualizadas desde el netdata-master, aunque por configuración, no fue deshabilitada la visualización de las estadísticas desde cada host (se debe limitar por iptables para que acceda solamente netdata-master).

Proxy inverso para autenticación de Netdata.

Netdata en sí no trae para autenticar el acceso a sus “dashboards”. Lo que propone la comunidad, como una alternativa a tener que configurar iptables, es usar un proxy inverso con Nginx. Este último método será el que usaremos en la presente guía y que es recomendable implementar en cada uno de los hosts (master o slaves).

Verificamos el estado del servicio:

Verificamos su funcionamiento via consola:

vía web: http://server_ip

Deberá recibirnos de bienvenida de Nginx, ya sea por un código HTML (vía consola) o el resultado de dicha programación en HTML, visualizado en el navegador.

Crearemos el fichero de configuración de Nginx para Netdata:

Agregamos lo siguiente, editando lo resaltado en color blanco, por el hostname de su servidor:

Creamos un enlace simbólico:

Nota: En las versiones más recientes de nginx ya esto no es necesario

Para evitar posibles problemas de memoria «hash bucket», que puedan surgir de adicionar nuevos nombres de servidores, es necesario ajustar un valor en el fichero de configuración de nginx:

Buscamos la directiva «server_names_hash_bucket_size» y la descomentamos.

Para asegurarnos de que no haya errores de sintaxis, corremos el siguiente comando:

Debe devolvernos lo siguiente:

Reiniciamos Nginx:

Creamos un fichero de autenticación:

Nos pedirá una contraseña para el usuario: “netdata”

Tras introducir la contraseña y verificarla, podremos ver que esta se guardó cifrada en el fichero:

Debe devolver algo, como lo siguiente:

Habilitamos la autenticación en el fichero de configuración creado:

Editamos, agregando lo siguiente:

Reiniciamos Nginx:

Al acceder vía web al sitio del host netdata (master), lo haremos sin especificar el puerto, ya que Nginx nos recibirá con el prompt de autenticación y una vez autenticados nos reenviará al sitio de Netdata:

http://netdata.empresa.midominio.cu

Vemos cómo Nginx nos redirecciona correctamente al sitio, sirviendo de proxy inverso:

La idea es proteger el acceso a netdata-master con un proxy inverso en Nginx. No es necesario implementar esto en cada uno de los nodos, pues el acceso a netdata en cada uno de ellos se recomienda, sea filtrado por iptables, permitiendo únicamente al servidor netdata-master. Vale aclarar, que el servidor netdata-master aun es accesible sin usar el proxy inverso, cuando se especifica el puerto, por lo que se recomienda filtrarlo para los usuarios, dejándolo solamente accesible para los servidores clientes o slaves.

HTTPS con certificado SSL auto-firmado para Nginx.

Creamos una llave y certificado auto-firmados con OpenSSL:

Antes de continuar con las preguntas que se nos harán, veamos que significa cada comando de la línea anterior:

  • openssl: Este es el comando básico para la creación y gestión de certificados, llaves y otros archivos en OpenSSL.
  • req: Especifica que queremos usar una gestión de solicitud de firma de certificado (CSR) X.509. El “X.509” es una infraestructura de llave pública estándar que SSL y TLS adhieren para sus llaves la gestión de certificados.
  • -x509: Este modifica el subcomando anterior, indicándole que queremos hacer un certificado auto-firmado en lugar de generar una solicitud de firma de certificado, como normalmente sucede.
  • -nodes: Indica a OpenSSL a saltarse la opción para asegurar nuestro certificado con una frase-contraseña. Necesitamos que Nginx sea capaz de leer este fichero, sin intervención cuando el servidor inicie.
  • -days 730: Establece la longitud de tiempo que el certificado será considerado como válido. Se establece por dos años en este caso.
  • -newkey rsa:2048: Especifica que queremos generar un nuevo certificado y llave al mismo tiempo. La porción “rsa:2048” especifica que se hará una llave RSA con longitude de 2048 bits.
  • -keyout: Indica a OpenSSL dónde plantar la generada llave privada que estamos creando.
  • -out: Indica a OpenSSL dónde plantar el certificado que estamos creando.

Ambos archivos que se crearon fueron ubicados en los subdirectorios apropiados de “/etc/ssl”. Como estamos usando OpenSSL, deberíamos también crear un grupo fuerte de Diffie-Hellman (DH), el cual es usado en la negociación Perfect Forward Secrecy (PFS) con los clientes.

Esto tomará un rato, pero cuando termine tendremos un fuerte grupo DH en “/etc/nginx/dhparam.pem” que podremos usar en nuestra configuración.

Nota: Si ya usted posee una llave y certificado de su red puede usarlo.

Configurando Nginx para usar SSL.

Haremos algunos ajustes a nuestra configuración:

  • Crearemos un fragmento de configuración conteniendo nuestras localizaciones la llave y certificado SSL.
  • Crearemos una porción de configuración conteniendo Fuertes configuraciones para SSL, que podrán ser usadas con cualquier certificado en el futuro.
  • Ajustaremos nuestro bloque de servidor para manejar solicitudes SSL y a usar los dos fragmentos anteriores.

Creando un Fragmento de Configuración Apuntando a la Llave y Certificado SSL.

Primero creamos un nuevo fragmento de configuración de Nginx en el directorio “/etc/nginx/snippets”. Para distinguir apropiadamente el propósito de este fichero, le llamaremos “self-signed.conf”:

Dentro de este fichero, necesitamos establecer la directiva “ssl_certificate” a nuestro certificado y la directive “ssl_certificate_key” a la llave asociada. En nuestro caso, esto lucirá así:

Creando una Porción de Configuración con Fuertes Opciones de Encriptación.

Crearemos otra pequeña configuración que defina algunas opciones SSL. Esto elevará a Nginx a un nivel de seguridad superior con una suite de cifrado SSL fuerte y habilitaremos algunas opciones avanzadas que nos mantendrá nuestro servidor seguro. Los parámetros que estableceremos pueden ser rehusados en futuras configuraciones de Nginx, así que se dará un nombre genérico:

Para establecer la seguridad SSL en Nginx, nos guiaremos por las recomendaciones dadas por Remy van Elst en el sitio “https://cipherli.st/”. Este sitio está diseñado para proveer un fácil consumo de opciones de encriptación para software populares. Agregamos lo siguiente:

Como estamos usando un certificado auto-firmado, el grapado SSL no será utilizado. Nginx nos alertará con una salida, por lo que deshabilitamos el grapado para nuestro certificado auto-firmado y continuamos operando correctamente.

Ajustando la Configuración de Nginx para usar SSL.

Ahora que tenemos nuestras porciones de configuración listas, podremos ajustar la configuración de Nginx para habilitar SSL y redirecionar de HTTP a HTTPS. Abrimos el fichero de configuración de Nginx para Netdata y hacemos los cambios:

Agregamos lo siguiente, desde #Configuración SSL y adaptando el hostname en cada caso:

Verificamos que la configuración no tiene errores de sintaxis:

Si todo está bien, debe devolvernos lo siguiente:

Observe la advertencia al principio. Como se señaló anteriormente, esta configuración en particular arroja una advertencia ya que nuestro certificado auto-firmado no puede usar el engrapado SSL. Esto se espera y nuestro servidor aún puede cifrar las conexiones correctamente.

Reiniciamos el servicio Nginx:

Al acceder nuevamente a la web, nos pedirá confiar o no en el certificado desconocido y la siguiente imagen demuestra que se está en presencia de una conexión cifrada:

Script anticrash para Netdata.

Este script encuesta cada 5 minutos si se puede o no acceder al “dashboard” de Netdata. Creamos el directorio de los scripts:

Editamos el fichero del script:

Agregamos lo siguiente:

Damos permisos de ejecución:

Abrimos el cron para agregar una tarea:

Agregamos lo siguiente:

Reiniciamos cron:

Hasta aquí esta segunda parte.

 

¿De cuánta utilidad te ha parecido este contenido?

¡Haz clic en una estrella para puntuar!

Promedio de puntuación 5 / 5. Recuento de votos: 3

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Sobre Alexander Rivas Alpizar 56 artículos
Administrador de Redes EMPRESTUR Cienfuegos

Sé el primero en comentar

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*