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
Netdata.
Implementación y configuración de Netdata.
Prerrequisitos de instalación de Netdata sin internet.
Configuración de Netdata-master.
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.
Implementación y configuración de Prometheus.
Comprobando resultados en servidor Prometheus.
Grafana.
Implementación y configuración de Grafana.
Integrando Prometheus con Grafana.
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:
uuidgen
Debe devolver un ID con la misma cantidad de cifras que el siguiente ejemplo:
556dacf0-f115-4a8b-9e7d-5cdd1c3525a1
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.
/etc/netdata/edit-config stream.conf
opciones para el nodo receptor (master)
stream.conf se ve así luego de editar lo que nos interesa:
[stream]
enabled = no
# replace API_KEY with your uuidgen generated GUID
[556dacf0-f115-4a8b-9e7d-5cdd1c3525a1]
enabled = yes
default history = 3600
default memory mode = save
health enabled by default = auto
allow from = *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:
systemctl restart netdata.service
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.
[stream]
enabled = yes
destination = IP:PORT[:SSL] ...
api key = XXXXXXXXXXX
Con nuestro ejemplo quedaria asi:
[stream]
enabled = yes
destination = netdata.empresa.midominio.cu:19999
api key = 556dacf0-f115-4a8b-9e7d-5cdd1c3525a1Nota: 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:
systemctl restart netdata.service systemctl restart cron.service
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).
apt install nginx -y
Verificamos el estado del servicio:
systemctl status nginx.service
Verificamos su funcionamiento via consola:
curl -4 server_ip
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:
nano /etc/nginx/sites-available/netdata.conf
Agregamos lo siguiente, editando lo resaltado en color blanco, por el hostname de su servidor:
upstream backend {
# the Netdata server
server 127.0.0.1:19999;
keepalive 64;
}
server {
# nginx listens to this
listen 80;
# the virtual host name of this
server_name netdata.empresa.midominio.cu;
location / {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_pass_request_headers on;
proxy_set_header Connection "keep-alive";
proxy_store off;
}
}
Creamos un enlace simbólico:
ln -s /etc/nginx/sites-available/netdata.conf /etc/nginx/sites-enabled/
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:
nano /etc/nginx/nginx.conf
Buscamos la directiva «server_names_hash_bucket_size» y la descomentamos.
Para asegurarnos de que no haya errores de sintaxis, corremos el siguiente comando:
nginx -t
Debe devolvernos lo siguiente:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
Reiniciamos Nginx:
systemctl restart nginx.service
Creamos un fichero de autenticación:
printf "netdata:$(openssl passwd -apr1)" > /etc/nginx/.htpasswd
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:
cat /etc/nginx/.htpasswd
Debe devolver algo, como lo siguiente:
netdata:$apr1$j8rSvmDx$HK4Lt/AyKPnugubgc.vwW1
Habilitamos la autenticación en el fichero de configuración creado:
nano /etc/nginx/sites-available/netdata.conf
Editamos, agregando lo siguiente:
# [...]
location / {
# authetication
auth_basic "Contenido Protegido";
auth_basic_user_file /etc/nginx/.htpasswd;
# [...]
Reiniciamos Nginx:
systemctl restart nginx.service
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:
openssl req -x509 -nodes -days 730 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt
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.
openssl dhparam -out /etc/nginx/dhparam.pem 3072
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”:
nano /etc/nginx/snippets/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í:
ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt; ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
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:
nano /etc/nginx/snippets/ssl-params.conf
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:
ssl_protocols TLSv1.3 TLSv1.2; # Requires nginx >= 1.13.0 else use TLSv1.2 ssl_prefer_server_ciphers on; ssl_dhparam /etc/nginx/dhparam.pem; # ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305-OLD:ECDHE-RSA-CHACHA20-POLY1305-OLD:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256; # ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0 ssl_session_timeout 10m; ssl_session_cache shared:SSL:10m; ssl_session_tickets off; # Requires nginx >= 1.5.9 ssl_stapling on; # Requires nginx >= 1.3.7 ssl_stapling_verify on; # Requires nginx => 1.3.7 # resolver NS1 NS2 valid=300s; resolver ns1.empresa.midominio.cu valid=300s; resolver_timeout 5s; # Disable strict transport security for now. You can uncomment the following # line if you understand the implications. # add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"; add_header X-Frame-Options DENY; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block";
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:
nano /etc/nginx/sites-available/netdata.conf
Agregamos lo siguiente, desde #Configuración SSL y adaptando el hostname en cada caso:
upstream backend {
# the Netdata server
server 127.0.0.1:19999;
keepalive 64;
}
server {
# nginx listens to this
listen 80;
# the virtual host name of this
server_name netdata.empresa.midominio.cu;
location / {
# authetication
auth_basic "Contenido Protegido";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_pass_request_headers on;
proxy_set_header Connection "keep-alive";
proxy_store off;
}
#Configuracion SSL
# Redirect to HTTPS
return 302 https://$server_name$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
include snippets/self-signed.conf;
include snippets/ssl-params.conf;
server_name netdata.empresa.midominio.cu;
location / {
# authetication
auth_basic "Contenido Protegido";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_pass_request_headers on;
proxy_set_header Connection "keep-alive";
proxy_store off;
}
}
Verificamos que la configuración no tiene errores de sintaxis:
nginx -t
Si todo está bien, debe devolvernos lo siguiente:
nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt" nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
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:
systemctl restart nginx.service
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:
mkdir -p /config/scripts
Editamos el fichero del script:
nano /config/scripts/netdata-anticrash.sh
Agregamos lo siguiente:
#!/bin/bash
FECHA="$(date +%d-%b-%Y-%H:%M)"
logfile="/var/log/netdata/mynetdata.log"
curl -4 localhost:19999 > /tmp/x-netdata
x='cat /tmp/x-netdata | grep -w "Failed to connect to"'
if [ "x" = "Failed to connect to" ];
then
systemctl restart netdata.service
service nginx restart
echo "$FECHA: Se reinicio el servicio netdata" >> $logfile
fi
Damos permisos de ejecución:
chmod +x /config/scripts/netdata-anticrash.sh
Abrimos el cron para agregar una tarea:
crontab -e
Agregamos lo siguiente:
*/5 * * * * /config/scripts/netdata-anticrash.sh
Reiniciamos cron:
systemctl restart cron.service
Hasta aquí esta segunda parte.
Dejar una contestacion