Entendiendo el panorama: ¿Por qué es importante la monitorización?

Antes de entrar en materia, es fundamental entender el por qué de todo esto. En un entorno de Kubernetes, tienes muchos microservicios corriendo simultáneamente. Si uno de estos falla, puede afectar a todo el sistema. Así que, ¡imagínate lo complicado que puede ser detectar un fallo en uno de estos servicios si no cuentas con herramientas adecuadas!

Por otro lado, comprender cómo se comportan tus aplicaciones te da una ventaja competitiva. Puedes anticiparte a problemas, optimizar tus recursos y garantizar que todo funcione como un reloj suizo.

Adentrándonos en las herramientas: EFK y ELK

Elasticsearch, Logstash y Kibana (ELK): Seguramente has escuchado de esta combinación estelar. Es una de las pilas más populares cuando hablamos de análisis de logs en entornos de producción. Te lo desgrano un poco:

• Elasticsearch: Se encarga de almacenar y buscar logs. Imagínatelo como ese amigo organizado que sabe dónde está todo en su habitación.
• Logstash: Es el encargado de procesar y enviar logs a Elasticsearch. Es el intermediario que se asegura de que todo esté en su sitio.
• Kibana: Es la cara bonita del equipo. Con Kibana puedes visualizar y navegar a través de tus logs de una manera gráfica y sencilla. Es el escaparate donde ves cómo va todo.

Ahora, te presento una variante: Elasticsearch, Fluentd y Kibana (EFK). Aquí, Fluentd reemplaza a Logstash. Es ligero, fácil de configurar y se integra perfectamente con Kubernetes. Es como si Logstash hubiera ido al gimnasio y se hubiera puesto en forma para correr maratones.

Prometheus y Grafana: El dúo dinámico

Sí, sé que estamos hablando de logs, pero no podemos dejar de mencionar a Prometheus y Grafana. Estas herramientas se centran más en la monitorización de métricas, pero complementan perfectamente a nuestras pilas ELK o EFK.

Prometheus recopila métricas y permite configurar alertas, mientras que Grafana las hace visibles y entendibles para meros mortales como tú y yo. Así que, si estás pensando en tener un control total sobre tus aplicaciones en Kubernetes, te recomiendo encarecidamente considerar este dúo.

Loki: El hermano pequeño

Loki es relativamente nuevo en la fiesta, pero ha llegado pisando fuerte. Creado por Grafana Labs, Loki se diseñó para trabajar en estrecha colaboración con Prometheus y Grafana. A diferencia de otras herramientas que indexan todo el contenido del log, Loki indexa solo ciertos metadatos, lo que lo hace más ligero y rápido.

Imagínatelo como ese hermano pequeño que, aunque es más joven, muchas veces es más astuto y eficiente.

Jaeger y OpenTracing: En el corazón del código

Si necesitas un nivel más profundo de visibilidad, especialmente cuando se trata de rastrear transacciones a través de múltiples microservicios, Jaeger y OpenTracing son tus aliados. Con ellos, puedes visualizar flujos de transacciones, identificar cuellos de botella y entender mejor cómo fluyen los datos.

Es como tener rayos X y poder ver el interior de tus aplicaciones. Eso sí, requieren algo más de integración, ya que tienes que instrumentar tu código para que genere trazas.

No todo es herramientas: Las mejores prácticas

Más allá de las herramientas, es vital tener en cuenta las mejores prácticas:

• Consistencia: Asegúrate de que todos tus servicios registren de la misma manera. Esto facilita enormemente el análisis.
• Rotación y retención: No guardes logs eternamente. Establece políticas claras de cuánto tiempo los conservas y cuándo los rotas.
• Seguridad: ¡No olvides esto! Asegúrate de que tus logs no contengan información sensible y de que el acceso a ellos esté restringido.

Aprovecha al máximo Kubernetes

Ahora que conoces las herramientas más potentes y las prácticas recomendadas, es tu turno. Profundiza en cada una, elige la que mejor se adapte a tus necesidades y comienza a sacarle el máximo partido a tus aplicaciones en Kubernetes.

Y recuerda, como siempre, si tienes dudas o quieres aprender más, no dudes en seguir investigando y conectando con la comunidad. ¡Hasta la próxima!

La entrada ¿Cuáles son las herramientas y tecnologías para la monitorización y el análisis de logs en Kubernetes? se publicó primero en Aprende IT.

La entrada Monitorización de Aplicaciones en Tiempo Real con Datadog: Transforma la Experiencia de Tus Usuarios se publicó primero en Aprende IT.

Cómo configurar la red de la iLO de una bahía desde la shell de la OA hponcfg

Para configurar la red de la iLO de una bahía desde la shell de la Onboard Administrator (OA) utilizando hponcfg y XML inline, sigue estos pasos:

Inicia sesión en la consola SSH de la OA utilizando tu cliente SSH favorito (como PuTTY u OpenSSH).

Para configurar la iLO del servidor en la bahía deseada (por ejemplo, bahía 7), ejecuta el siguiente comando con el contenido XML inline. Reemplaza las direcciones IP y las contraseñas según sea necesario:

hponcfg 7 << end_marker
<RIBCL VERSION="2.0">
<LOGIN USER_LOGIN="Administrator" PASSWORD="password">
<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<IP_ADDRESS VALUE="192.168.1.100"/>
<SUBNET_MASK VALUE="255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE="192.168.1.1"/>
<PRIM_DNS_SERVER VALUE=""/>
<DHCP_ENABLE VALUE="N"/>
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
</LOGIN>
</RIBCL>
end_marker

Verifica que la configuración de red de la iLO se haya aplicado correctamente. Puedes hacer esto utilizando el comando show server info seguido del número de bahía del servidor blade. Por ejemplo:

show server info 7

Busca la información de la dirección IP de la iLO en la salida del comando. La dirección IP debe coincidir con la que configuraste en el contenido XML inline.

Cómo configurar el gateway de la iLO conectándose desde la OA

Si necesitas configurar el gateway de la iLO y no puedes hacerlo usando hponcfg, puedes conectarte directamente a la iLO desde la OA utilizando el comando «connect». Sigue estos pasos:

Inicia sesión en la consola SSH de la Onboard Administrator utilizando tu cliente SSH favorito (como PuTTY u OpenSSH).

Para conectarte a la iLO del servidor en la bahía deseada (por ejemplo, bahía 7), ejecuta:

connect server 7

Ahora deberías estar en la interfaz de comandos de la iLO.

Para cambiar la configuración del gateway, primero, ingresa al modo de configuración de la red iLO utilizando el comando:

cd /map1/enetport1/lanendpt1/ipendpt1

Configura la puerta de enlace predeterminada para la iLO utilizando el comando set seguido del parámetro correspondiente. Por ejemplo, si deseas configurar una puerta de enlace de 192.168.1.1, ejecuta:

set GatewayIPAddress=192.168.1.1

Guarda los cambios y reinicia la iLO para aplicar la configuración. Para hacer esto, regresa al directorio principal de la iLO y ejecuta el comando reset:

cd ..
reset

Una vez que hayas completado estos pasos, la configuración del gateway de la iLO debería actualizarse según el valor que estableciste.

Consejos para la configuración de la iLO en un chasis HPE C7000

Mantén tus servidores actualizados: Asegúrate de que el firmware de la iLO y la Onboard Administrator estén actualizados a las últimas versiones para garantizar la compatibilidad y aprovechar las mejoras de seguridad y rendimiento.

Utiliza contraseñas seguras: Asegúrate de utilizar contraseñas seguras y únicas para la iLO y la Onboard Administrator. Las contraseñas débiles pueden comprometer la seguridad de tus servidores y exponerlos a posibles ataques.

Configura alertas de correo electrónico: La iLO te permite configurar alertas de correo electrónico para eventos críticos del sistema, como fallas de hardware o problemas de temperatura. Aprovecha esta función para mantenerte informado sobre el estado de tus servidores.

Monitorea tus servidores de forma regular: Utiliza las herramientas de monitoreo y registro de la iLO y la Onboard Administrator para supervisar el rendimiento y la salud de tus servidores. Esto te ayudará a detectar y solucionar problemas antes de que se conviertan en problemas más graves.

En resumen, en este artículo, hemos cubierto cómo configurar la red de la iLO de una bahía en un chasis HPE C7000 utilizando dos métodos diferentes: a través de la shell de la OA usando hponcfg con XML inline y conectándose directamente a la iLO desde la OA para configurar el gateway. Ambos métodos son útiles en diferentes escenarios y te permitirán gestionar de manera efectiva la red de la iLO en tus servidores HPE C7000.

La entrada Cómo configurar la red de la iLO de una bahía en un chasis HPE C7000 se publicó primero en Aprende IT.

- name: Update packages on all hosts
  become: true
  apt:
    upgrade: yes

- name: Verify compliance with security policies
  become: true
  apt:
    name: aide
    state: present
  command: aideinit

ansible-playbook playbook.yml

La entrada ¿Conoces las mejores prácticas para la automatización de tareas de seguridad en sistemas informáticos? se publicó primero en Aprende IT.

Identificando problemas con DNS en un dominio

Cuando cambiamos los servidores DNS de un dominio de un proveedor por los de otro proveedor (O los de un nuevo VPS) es posible que algo vaya mal y acabemos con una pantalla como esta cuando accedamos a la web:

El error «DNS_PROBE_FINISHED_NXDOMAIN» (De Chrome), nos hace sospechar que existe un problema con los servidores DNS.

Según vemos esta pantalla u otra similar dependiendo del navegador, lo primero que debemos hacer es tracer paso a paso la resolución DNS de nuestro dominio para ver en qué punto está habiendo problemas.

Para ello yo seguiría estos pasos:

1. Ver con whois que DNS tiene el dominio
2. Comprobar si esos DNS resuelven el dominio correctamente
3. Ver si se están propagando cambios

Vamos a describir con mas detalles el proceso paso a paso a continuación.

Ver con «whois» que DNS tiene el dominio

El comando whois sirve para obtener información de un dominio o una IP. Con el podemos ver:

• Nombre y apellidos del titular
• Contacto del titular
• Datos del proveedor (Registrar en el caso de los dominios y Hosting en el caso de la IP)
• Contacto para casos de mal uso
• Datos de servidores DNS

Para utilizar whois de linea de comandos, se debe o bien tener instalada la herramienta whois de Linux. Sin embargo en otros sistemas deberás utilizar herramientas en linea como https://lookup.icann.org/  el cual sirve para la mayoria de dominios (.com, .org, .net, etc) o  https://www.nic.es/sgnd/dominio/publicInformacionDominios.action para los dominios .es. 

Si hacemos un whois al dominio de este sitio web, Aprendeit.com nos aparecerá lo siguiente:

gerardo@ubuntu-dev01:~$ whois aprendeit.com
   Domain Name: APRENDEIT.COM
   Registry Domain ID: 2012671312_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.nicline.com
   Registrar URL: http://www.nicline.com
   Updated Date: 2021-01-05T12:40:14Z
   Creation Date: 2016-03-16T01:02:09Z
   Registry Expiry Date: 2021-03-16T01:02:09Z
   Registrar: Arsys Internet, S.L. dba NICLINE.COM
   Registrar IANA ID: 379
   Registrar Abuse Contact Email:
   Registrar Abuse Contact Phone:
   Domain Status: ok https://icann.org/epp#ok
   Name Server: NS1.APRENDEIT.COM
   Name Server: NS2.APRENDEIT.COM
   DNSSEC: unsigned
   URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2021-02-08T05:46:52Z <<<

Como se ha podido ver en el fragmento anterior, tenemos 2 nameservers para el dominio:

Name Server: NS1.APRENDEIT.COM 
Name Server: NS2.APRENDEIT.COM

Ahora lo siguiente es comprobar si estos DNS no funcionan correctamente.

Comprobar los DNS resuelven el dominio

Para ver si un dominio se resuelve correctamente desde los servidores DNS que aparecen en su whois debemos ejecutar varias consultas desde la utilidad nslookup de linea de comandos, presente en la mayoría de los sistemas.

Debemos comprobar si:

• La entrada de tipo A para el dominio resuelve
• La entrada NS que aparece en  el whois resuelve
• Si hay una entrada A para la entrada NS que aparece en el whois

Si no sabes los tipos de entradas ni sus diferencias puedes consultarlos en https://en.wikipedia.org/wiki/List_of_DNS_record_types

Para el dominio aprendeit.com comprobaremos los servidores DNS ns1.aprendeit.com y ns2.aprendeit.com. Para ver como funciona por encima nslookup voy a hacer una explicación básica:

• Ejecutamos nslookup
• Definimos el tipo de entrada DNS que vamos a utilizar (usaremos en este caso A y NS) con set q=TIPO_DE_ENTRADA
• Definimos el servidor DNS con server=SERVIDOR_DNS
• A continuación escribimos la entrada DNS que queremos consultar (en esta consulta es aprendeit.com)

Comprobamos la entrada A con cada servidor DNS

gerardo@ubuntu-dev01:~$ nslookup
> set q=a
> server ns1.aprendeit.com
Default server: ns1.aprendeit.com
Address: 51.195.93.177#53
> aprendeit.com
Server: ns1.aprendeit.com
Address: 51.195.93.177#53

Name: aprendeit.com
Address: 51.195.93.180
>

Viendo que el servidor DNS resuelve la IP comprobamos con el segundo servidor:

gerardo@ubuntu-dev01:~$ nslookup
> server ns2.aprendeit.com
Default server: ns2.aprendeit.com
Address: 51.195.93.179#53
> set q=a
> aprendeit.com
Server: ns2.aprendeit.com
Address: 51.195.93.179#53

Name: aprendeit.com
Address: 51.195.93.180
>

Ambos devuelven la misma IP para el dominio, y todo está correcto, ahora comprobaríamos la entrada NS de del dominio (lo voy a hacer con un solo servidor DNS pero debería hacerse con los dos):

gerardo@ubuntu-dev01:~$ nslookup 
> set q=ns
> server ns1.aprendeit.com
Default server: ns1.aprendeit.com
Address: 51.195.93.177#53
> aprendeit.com
Server: ns1.aprendeit.com
Address: 51.195.93.177#53

aprendeit.com nameserver = ns2.aprendeit.com.
aprendeit.com nameserver = ns1.aprendeit.com.
>

Por ultimo comprobaríamos (con ambos servidores DNS) que las entradas NS tengan su respectiva entrada A, es decir, que en el caso de aprendeit.com que ns1.aprendeit.com y ns2.aprendeit.com se resuelva con una dirección IP:

gerardo@ubuntu-dev01:~$ nslookup 
> set q=a
> server ns1.aprendeit.com
Default server: ns1.aprendeit.com
Address: 51.195.93.177#53
> ns1.aprendeit.com
Server: ns1.aprendeit.com
Address: 51.195.93.177#53

Name: ns1.aprendeit.com
Address: 51.195.93.177
> ns2.aprendeit.com
Server: ns1.aprendeit.com
Address: 51.195.93.177#53

Name: ns2.aprendeit.com
Address: 51.195.93.179
>

Si alguna entrada no resuelve o no coincide hay que revisar las entradas DNS.

Ver si se están propagando cambios

La web https://www.whatsmydns.net/ nos sirve para comprobar si los cambios DNS se han propagado.
En esta web se puede comprobar desde varios servidores desplegados por todo el mundo si tiene los datos antiguos de DNS.

La propagación DNS puede tardar en completarse hasta 72h, pero si no se ven cambios al poco tiempo puede haber un problema con alguno de los servidores DNS o con el registrar. Deberíamos comprobar lo que hemos visto anteriormente para cerciorarnos que que todo es correcto.

Otras herramientas

https://intodns.com/
https://dnschecker.org/
https://tools.pingdom.com/

La entrada Diagnosticar problemas con DNS y corregirlos se publicó primero en Aprende IT.

Como hemos visto en otros posts docker es una tecnología muy versátil y cada día mas extendida. Por eso hoy queremos mostrar como se puede levantar de forma muy sencilla un servidor de monitorización con zabbix.

Te recomendamos visitar el post sobre como empezar con docker para ver como utilizar los comandos mas básicos de docker.

¡Empezamos!

Creando el servidor de MySQL

Lo primero para crear los servidores de docker es crear un servidor de bases de datos. En nuestro caso usaremos MySQL 5.7.

Para empezar a crearlo, lo primero es crear la estructura de directorios.

Directorios de volumen de MySQL

Tenemos que crear el directorio que se montará en /var/lib/mysql en el contenedor de MySQL, para ello ejecutamos:

mkdir -p /var/dockervolumes/db01/mysql

Luego creamos el fichero /var/dockervolumes/db01/docker.cnf que contendra la configuración de MySQL para nuestro Zabbix. En este fichero se puede añadir el tunning que necesites para MySQL:

skip-host-cache
skip-name-resolve
server_id=1
expire_logs_days = 10
query_cache_size=0
query_cache_type=0

Para crear el servidor de base de datos ejecutamos el siguiente comando sustituyendo «PASSWD_ROOT» por nuestra contraseña:

docker run --name db  -d --restart always -e "MYSQL_ROOT_PASSWORD=PASSWD_ROOT" -v /var/dockervolumes/db01/mysql/:/var/lib/mysql -v /var/dockervolumes/db01/docker.cnf:/etc/mysql/conf.d/docker.cnf mysql:5.7

Crear servidor de Zabbix

Al igual que hemos hecho antes, para crear el servidor de zabbix necesitamos crear el arbol de directorio a utilizar, para ello ejecutamos:

mkdir -p /var/dockervolumes/zabbix_server

Y luego para crear el servidor de Zabbix solo debemos ejecutar el siguiente comando sustituyendo «PASSWD_ROOT» por la password que hemos definido en la base de datos y «PASSWD» por la password que queramos poner en nuestro usuario de base de datos zabbix:

docker run -it -d --restart unless-stopped --link db -p 10051:10051 -e "DB_SERVER_HOST=db" -e "MYSQL_USER=zabbix" -e "MYSQL_PASSWORD=PASSWD" -e "MYSQL_ROOT_PASSWORD=PASSWD_ROOT" -e "MYSQL_DATABASE=zabbix" -e "ZBX_STARTJAVAPOLLERS=5" -e "TZ=Europe/Madrid" --label "traefik.enable=false" --label "com.zabbix.os:'alpine'" --label "com.zabbix.dbtype:'mysql'" --label "com.zabbix.component:'zabbix-server'" -v /var/dockervolumes/zabbix_server/externalscripts:/usr/lib/zabbix/externalscripts:ro -v /var/dockervolumes/zabbix_server/alertscripts:/usr/lib/zabbix/alertscripts:ro -v /var/dockervolumes/zabbix_server/modules:/var/lib/zabbix/modules:ro -v /var/dockervolumes/zabbix_server/enc:/var/lib/zabbix/enc:ro -v /var/dockervolumes/zabbix_server/ssh_keys:/var/lib/zabbix/ssh_keys:ro -v /var/dockervolumes/zabbix_server/mibs:/var/lib/zabbix/mibs:ro -v /var/dockervolumes/zabbix_server/snmptraps:/var/lib/zabbix/snmptraps:ro --name zabbix-server zabbix/zabbix-server-mysql:alpine-latest

Panel de control web de Zabbix

Con esto ya tendríamos un servidor de zabbix sin la parte web. Para crear la parte web debemos ejecutar la siguiente instrucción en la cual hay que sustituir «PASSWD_ROOT» por la password que hemos definido en la base de datos y «PASSWD» por la password que queramos poner en nuestro usuario de base de datos zabbix y MI_SERVER_DE_ZABBIX por el hostname de tu zabbix:

docker run -it -d --restart unless-stopped --link db -e "DB_SERVER_HOST=db" -e "MYSQL_USER=zabbix" -e "MYSQL_PASSWORD=PASSWD" -e "MYSQL_ROOT_PASSWORD=PASSWD_ROOT" -e "MYSQL_DATABASE=zabbix" -e "ZBX_SERVER_NAME=MI_SERVER_DE_ZABBIX" -e "PHP_TZ=Europe/Madrid" -e "TZ=Europe/Madrid" --label "traefik.backend=zabbix" --label "com.zabbix.os:'alpine'" --label "com.zabbix.dbtype:'mysql'" -p 80:8080 --label "com.zabbix.component:'zabbix-web'" --label "traefik.enable=false" --link zabbix-server --name zabbix-web zabbix/zabbix-web-apache-mysql:alpine-latest

Tras esto ya podemos hacer login en nuestro nuevo Zabbix nos dirigimos a la dirección del servidor anfitrión donde lo hemos instalado así: http://DIRECCION (o si lo hemos hecho en nuestro docker local, en http://localhost ). Allí nos pedira usuario y contraseña, por defecto es:

Usuario: Admin
Password: zabbix

Debes cambiarlo al acceder la primera vez.

Mas adelante crearemos artículos configurar el agente y para añadir alertas con telegram.

Si estás interesado en aprender Docker puedes puedes adquirir nuestro libro aquí.

Docker para novatos

Bonus: SMTP TRAPS

Si quieres utilizar las traps de SMTP debes crear otro servidor para ello, primero creamos el arbol de directorios:

mkdir -p /var/dockervolumes/zabbix_snmptraps/snmptraps

Para crear el servicio se hace de la siguiente forma:

docker run -it -d --restart unless-stopped -v /var/dockervolumes/zabbix_snmptraps/snmptraps:/var/lib/zabbix/snmptraps:rw --user root --label "traefik.enable=false" --label "com.zabbix.component:'snmptraps'" --label "com.zabbix.os:'ubuntu'"  -p 162:162/udp --name zabbix-snmptraps zabbix/zabbix-snmptraps:ubuntu-latest

La entrada Levantar un servidor de Zabbix con docker en menos de 5 minutos se publicó primero en Aprende IT.