Agregando monitoreo de EKS en una versión antigua de Zabbix P2

por | 27 octubre, 2023

En esta parte veremos como funciona el template «Pods EKS por nodo» que utilizamos anteriormente

En el post anterior vimos como utilizamos un prototipo de host para crear nodos de eks de forma automática. En este post nos centraremos en el template que le cargamos para el descubrimiento de los pods que estén operando en el nodo y en el próximo post veremos la definición de las keys.

Un pequeño disclaimer, el descubrimiento de pods lo realizó mi compañero en python por lo que yo no entraré en profundidad de como obtuvo los distintos valores pero si utilizare esa misma salida (que va directo a un archivo) para trabajar sobre lo que me pidieron

Como mencione en el post anterior, para mi la parte mas relevante cuando desarrollo un nuevo descubrimiento, debemos tener claro que macros utilizaremos y definir la estructura que devolverá la key que usemos. En este caso la estructura será algo así

{
   "data":[
      {
         "{#NOMBRE}":"<pod 1 cliente 1>",
         "{#NODO}":"<nodo 1 cliente 1>",
         "{#NOMBRE_CORTO}":"<nombre pod 1 cliente 1>"
      },
      {
         "{#NOMBRE}":"<pod 2 cliente 1>",
         "{#NODO}":"<nodo 1 cliente 1>",
         "{#NOMBRE_CORTO}":"<nombre pod 2 cliente 1>"
      },
      {
         "{#NOMBRE}":"<pod 3 cliente 1>",
         "{#NODO}":"<nodo 1 cliente 1>",
         "{#NOMBRE_CORTO}":"<nombre pod 3 cliente 1>"
      },
      {
         "{#NOMBRE}":"<pod 1 cliente 1>",
         "{#NODO}":"<nodo 2 cliente 1>",
         "{#NOMBRE_CORTO}":"<nombre pod 1 cliente 1>"
      },
      {
         "{#NOMBRE}":"<pod 2 cliente 1>",
         "{#NODO}":"<nodo 2 cliente 1>",
         "{#NOMBRE_CORTO}":"<nombre pod 2 cliente 1>"
      },
      {
         "{#NOMBRE}":"<pod 1 cliente 2>",
         "{#NODO}":"<nodo 1 cliente 2>",
         "{#NOMBRE_CORTO}":"<nombre pod 1 cliente 2>"
      },
      {
         "{#NOMBRE}":"<pod 2 cliente 2>",
         "{#NODO}":"<nodo 1 cliente 2>",
         "{#NOMBRE_CORTO}":"<nombre pod 2 cliente 2>"
      },
      {
         "{#NOMBRE}":"<pod 1 cliente 2>",
         "{#NODO}":"<nodo 2 cliente 2>",
         "{#NOMBRE_CORTO}":"<nombre pod 1 cliente 2>"
      }
   ]
}

Hice un poco más larga la estructura para que se noten los distintos cambios, pero básicamente tendremos 3 macros {#NOMBRE}, {#NODO} y {#NOMBRE_CORTO}.

En un principio pensaba aplicar el filtro en la regla de descubrimiento usando la macro {#NODO}, pero conversando con mi compañero nos dimos cuenta que es mucho más eficiente filtrar durante la obtención de la información que después por lo que el filtrado lo aplicaremos directamente en la key de descubrimiento, aún así decidimos mantener la macro para fines de troubleshooting. La macro {#NOMBRE_CORTO} fue debido a una solicitud existente ya que los pods siempre traerán un identificador único aleatorio y necesitamos aplicar umbrales específicos a determinados pods, por lo que eliminamos este identificador para poder aplicar el umbral según lo necesitado. Esto último lo veremos pronto.

Recordemos que estamos trabajando en el template llamado «Pods EKS por nodo» el cual añadimos al prototipo de host creado en el post anterior.

Dentro de este template, definiremos dos items para el monitoreo del nodo como tal, cpu y memoria

Dado que el hostname del host que crearemos tendrá el nombre real del nodo utilizaré la macro {HOST.HOST} para poder consultar específicamente por los datos de ese nodo y no otro.

Tambien realizamos la definicion de los triggers para estos items.

Al tratarse de un template que ira atachado a un host definí las macros de usuario para poder personalizar los umbrales en caso de requerirlo.

Continuando dentro del template vamos a crear la regla de descubrimiento para los pods.

Para esto utilice la key «DiscoveryPods[{HOST.HOST}]», a diferencia del discovery que creamos en el host del post anterior, en este reducimos el tiempo de sondeo y de mantención de los datos descubiertos, ya que en kubernetes, o en este caso EKS, es más frecuente que se cree un nuevo pod que un nuevo nodo.

Pudimos haber creado mas macros de descubrimiento para poder realizar el filtrado de los items que se crearan, para por ejemplo evitar que los pods en determinados namespaces sean creados, pero se tendría que realizar un trabajo adicional sobre el desarrollo hecho por mi compañero y estamos cortos de tiempo.

Dentro de esta regla de descubrimiento creamos los items necesarios, en nuestro caso hemos utilizado solo 3, memoria, cpu y estado del nodo como pueden apreciar en la siguiente imagen

con sus respectivos triggers

Noten que a diferencia de los triggers para el nodo, aquí cree trigers con macros contextuales, ya que como comenté anteriormente una de las necesidades es poder definir umbrales personalizados por pod.

Y con eso estamos listos, en el próximo post veremos todas las keys creadas y su sintaxis por si les sirve de ejemplo

Recordemos los pasos que hemos realizado hasta el momento

  • Creamos un host atachado a un proxy especifico con una regla de descubrimiento llamada «Descubrimiento de nodos EKS» y utiliza la key DiscoveryNode[<nombre Cliente>]
  • Esta regla tiene un prototipo de host que usara de nombre de host {#NOMBRENODO}, como nombre visible tendrá CL|{#CLIENTE}|PS|{#NOMBRENODO} y se añadira a los grupos Cloud/aws Cloud/aws/eks y al grupo prototipo Cloud/aws/eks/{#CLIENTE}
  • A este hosts se le añade un template que fue el trabajado en este post llamado Pods EKS por nodo

En el próximo post veremos cuales son las keys que utilizamos y como se diseño para obtener la información necesaria

fuentes:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *