Y pues, de a poco fueron solicitando el monitoreo de kubernetes en AWS, un servicio llamado EKS, hasta que empezaron a pedir otras cosas, toco hacer desarrollo nuevo
La historia se escribe algo así.
- Necesitamos monitoreo de los nodos de eks
- done, mediante reglas de descubrimiento de nodos y un pequeño desarrollo
- Ahora necesitamos monitoreo de los pods dentro del eks
- done, mediante reglas de descubrimiento de pods y un pequeño desarrollo
- Ahora necesitamos que si se dispara una alarma de cpu o memoria en un pod solo alarme cuando el nodo se alarme
- Work In Progress….
Y ahí reside un problema ya que al tener todo con descubrimiento es imposible asociar los triggers entre si de forma automática, si bien se pueden hacer de forma manual dado el dinamismo de los pods de eks resulta en una práctica casi imposible.
¿Solución? pues después de pensar un poco decidí usar una herramienta que hasta ahora no hemos explotado en el monitoreo de mi empresa, los prototipos de hosts.
Para esto, lo primero que hice fue crear un host, que en mi caso llamare Creador de hosts. También pude haber utilizado el host del proxy, lo importante es que este hosts este añadido al equipo que tenga acceso al EKS
Como el monitoreo se esta realizando desde un proxy especifico este hosts lo añadimos al mismo proxy y le damos la ip de localhost 127.0.0.1 y lo asignamos a un grupo, en mi caso creare un grupo llamado «cloud/aws/eks»
Luego configuraremos la regla de descubrimiento necesaria, en mi caso use como nombre de la regla de descubrimiento
Descubrimiento de nodos EKS
y definí la key
DiscoveryNode[<Nombre Cliente>]
Como se puede apreciar en la siguiente imagen
En estos casos, como la key debemos crearla (ya que en versiones antiguas de Zabbix no tenemos integración con AWS) es irrelevante el nombre que decidamos utilizar siempre y cuando usemos los mismos nombres en la configuración del agente y del frontend. La configuración de las keys las veremos en un próximo post.
Siempre que realicemos estas configuraciones para crear nuevas reglas de descubrimiento tenemos que tener claro cuales serán las macros que necesitaremos, en mi caso particular me gusta pensar toda la estructura y trabajar sobre ella, para este desarrollo he decidido que tenga esta estructura, donde cliente será el parámetro que le envíe por medio de la key de descubrimiento y sea devuelta dentro del mismo json del descubrimiento
{
"data":[
{
"{#NOMBRENODO}":"<nombre nodo1 eks>",
"{#CLIENTE}":"<nombre cliente1>"
},
{
"{#NOMBRENODO}":"<nombre nodo2 eks>",
"{#CLIENTE}":"<nombre cliente1>"
},
{
"{#NOMBRENODO}":"<nombre nodo3 eks>",
"{#CLIENTE}":"<nombre cliente1>"
},
{
"{#NOMBRENODO}":"<nombre nodo1 eks>",
"{#CLIENTE}":"<nombre cliente2>"
}
]
}
considero que solo necesito estas 2 macros para, por un lado colocar el nombre del hosts descubierto y por otro lado asignarle un grupo según el cliente (que francamente dudo se implemente otro cliente con esta tecnología en la empresa)
Con esta estructura, y ya con la regla de descubrimiento creada nos vamos al lugar oscuro y desconocido conocido en esta ocasión como «Host prototypes» para configurar cómo tenemos pensado utilizar nuestras macros, en esta sección usaré la macro {#NOMBRENODO} para definir el hostname y en el nombre visible CL|{#CLIENTE}|00|{#NOMBRENODO} (esto por protocolos internos) quedando de esta forma
Finalmente tenemos que asignar un grupo de forma obligatoria, y un template para que tenga sentido crear el host (no nos sirve un host sin items, triggers o gráficas)
En mi caso he utilizado 2 grupos y la macro {#CLIENTE} como un sub grupo de Cloud/aws/eks/ para el grupo dinámico
Finalmente añado un template, que contiene items para consultar el estado del nodo y una regla de descubrimiento para añadir items por cada pod corriendo en ese nodo, este template lo veremos en el próximo post. Sin embargo para fines de este post bastará con decir que he llamado a este template «Pods EKS por nodo»
Con esto ya tenemos una jerarquía similar a lo que vemos en eks donde de un nodo dependen uno o varios pods y podemos relacionar las alarmas del nodo con un pod especifico.
En próximos posts veremos como trabajé en las distintas keys y la integración de los pods.
fuentes: