Rendimiento en Zabbix ¿se puede mejorar?

Buenas,

Por fin volvemos a la carga con un contenido con sentido técnico de primer orden 🙂

El rendimiento de Zabbix y la efectividad de la BBDD se empieza a plantear cuando tienes una BBDD cercana al Terabyte, notas que tus gráficas empiezan a tener huecos puntuales, cuando tu proceso de housekeeper se hace eterno y tus triggers de nodata empiezan a saltar.

Tenemos que tener muy en cuenta qué hace que nuestro sistema de monitorización sea lento:

  • Procesos propios de la monitorización (p.e. Pollers por doquier)
  • Procesos propios de la BBDD (p.e. Housekeeper agresivo)
  • Procesos externos (p.e.  Apache sin configuración explicita)

Empecemos a analizar el primero de ellos, un proceso propio de la monitorización en zabbbix el Poller process.

Como consejo diré que es muy necesario para el administrador de monitorización tener controlado el porcentaje de ocupación del proceso de Polling con la gráfica que viene de serie (Data gathering process busy %) en conjunción con la gráfica de procesos internos de la propia herramienta (Internal process busy %).

En estas gráficas podemos ver cómo existe una relación directa entre el número de procesos que tenemos arrancados de Polling con el porcentaje de ocupación (Busy podemos traducirlo como ocupación? 🙂 ) dentro del sistema y ver cómo si  arrancamos un número elevado de pollers hace que el proceso de sincronización de memoria con la BBDD se vuelva un desastre por estar al 100% (El proceso en sí es el “busy history syncer processes”)

Es por ello que debemos ajustar muy concienzudamente el número de procesos arrancados para no saturar otros procesos.

El primero de la clase en procesos que saturan nuestra BBDD no es otro que nuestro amigo “housekeeping”, si tienes configurado un housekeeper muy agresivo es muy probable que solo te salve de un sistema lento el poner discos de SSD. No hay más solución porque el proceso en sí consume un I/O de disco tanto de lectura como de escritura brutal.

La configuración del housekeeper que tengo actualmente configurada es que se ejecute cada hora y como máximo borre 500 registros:

HousekeepingFrequency=1
MaxHousekeeperDelete=500

Si pusieramos el MaxHousekeeperDelete a 1500 o 2000 valores veríamos como nuestro sistema está constantemente overload por culpa de este proceso.

Para ver la duración de este proceso y las tareas que ha realizado podemos hacer lo siguiente:

cat /ruta_al_directorio_zabbix/log/zabbix_server.log | grep -i deleted | tail -1

15745:20150330:054430.946 housekeeper [deleted 11580210 hist/trends, 681913 items, 21871 events, 0 sessions, 4 alarms, 108 audit items in 15259.935981 sec, idle 1 hour(s)]

En el podemos ver cómo este proceso ha eliminado bastante dato obsoleto en nuestra BBDD.

Si entramos en MySQL podemos consultar cuantos datos, en número, debe borrar el proceso de housekeeper con la siguiente query:

mysql> select count(*) from housekeeper;
+———-+
| count(*) |
+———-+
| 722 |
+———-+
1 row in set (0.00 sec)

Si os interesa además saber  de qué tablas son los datos que va a borrar se puede saber con esta query:

mysql> select count(*), tablename from housekeeper group by tablename;
+———-+————–+
| count(*) | tablename |
+———-+————–+
| 407 | history |
| 2 | history_text |
| 311 | history_uint |
| 2 | trends |
+———-+————–+
4 rows in set (0.01 sec)

Con esto podemos tener más controlado el proceso de housekeeper sin olvidar que nada de lo anterior tiene sentido si tenemos la BBDD particionada ya que el proceso debe ser detenido para que los propios procedimientos de particionado borren lo obsoleto.

Por último y no por ello menos importante tenemos los procesos de Apache, Apache está realmente bien documentado y es posible que cualquiér cheat que queramos aplicar esté explicado en miles de sites de internet por lo que aquí me limitaré a dar unos pequeños retoques en el httpd.conf.

Es necesario medir el número de conexiones que puede tener nuestro frontend para ajustar lo máximo posible el número de los parámetros MaxClients, MaxSpareThreads y MaxRequestsPerChild.

Por otro lado, Apache viene con bastante módulos arrancados… ¿Son necesarios para nuestro Zabbix?. La respuesta es un claro no.

Se debe revisar qué módulos arrancamos, investigar sobre ellos y ver si podemos deshabilitar la mayoría. Esto hace que no los arranque y podamos contar con más memoria para repartir.

Bueno, creo que este es el post más largo que he escrito hasta ahora y espero que sea de alguna ayuda a alguno de vosotros.

Un saludo.

E agora uma tradução tentativa para nossos amigos brasileiros:

Bom,

Finalmente voltamos para a briga com um conteúdo técnico de primeira ordem 🙂

Zabbix desempenho e eficácia do DB começa a levantar quando você tem um DB perto de Terabyte, você percebe que seus gráficos começar a ter de ponta oca, quando o seu processo de governanta é eterno e seus gatilhos para NODATA começar a estalar.

Temos de ter em mente o que torna o nosso sistema de monitoramento é lento:

  • próprios processos de monitoramento (por exemplo, em todos os lugares pollers)
  • Processos próprios bancos de dados (por exemplo, Governanta agressivo)
  • processos externos (por exemplo, configuração do Apache, sem explícito)

Comece a analisar o primeiro, um processo patenteado de monitoramento zabbbix o processo Poller.

Como uma dica vou dizer que é muito necessário para o acompanhamento administrador ter controlado a taxa de ocupação do processo de Polling com os gráficos que vem (processo de coleta de dados ocupado%) padrão em conjunto com o gráfico de processos dentro da própria ferramenta (Internal Processo ocupado%).

Nestes gráficos, podemos ver como há uma relação direta entre o número de processos que foram arrancados de Polling com a taxa de ocupação (Busy pode traduzir como atividade profissional? :)) Dentro do sistema e ver como se você começar um grande número de marcas pollers o processo de sincronização com a memória DB se torna um desastre por ser 100% (O processo em si é a “processos história Syncer ocupados”)

É por isso que temos de ajustar o número muito completamente desenraizados para evitar a saturação outros processos processos.

A primeira classe de processos que saturam nossa DB não é outro senão o nosso amigo “housekeeping”, se você definir uma dona de casa muito agressivo é muito provável que apenas salvá-lo de um sistema lento colocando discos SSD. Não há uma solução, porque o próprio processo consome um disco I / O lidos tanto brutal e escrita.

Configurando a governanta que eu tenho atualmente definido é executado a cada hora e um máximo de 500 registros excluídos:

HousekeepingFrequency = 1

MaxHousekeeperDelete = 500

Se colocarmos o MaxHousekeeperDelete 1500 ou 2000 valores gostaríamos que o nosso sistema é constantemente sobrecarga por causa deste processo.

Para a duração deste processo e as tarefas que ele tem feito, podemos fazer o seguinte:

/ruta_al_directorio_zabbix/log/zabbix_server.log gato | grep -i excluída | tail -1

15745: 20150330: 054430.946 governanta [suprimido 11580210 hist / tendências, 681.913 itens, eventos 21871, 0 sessões, 4 alarmes, 108 itens de auditoria em 15259,935981 segundo, uma hora de marcha lenta (s)]

Aqui podemos ver como esse processo eliminou informações bastante obsoleto em nossos bancos de dados.

Se entrarmos em MySQL podemos verificar a quantidade de dados, em número, você deve excluir o processo governanta com a seguinte consulta:

mysql> select count (*) from governanta;

+ ———- +

| Contagem (*) |

+ ———- +

| 722 |

+ ———- +

1 row in set (0.00 sec)

Se você também estiver interessado em saber quais são as tabelas de dados de ser suprimido, pode saber com esta consulta:

mysql> select count (*) do grupo nometabela por nometabela governanta;

+ ———- + ————– +

| Contagem (*) | nometabela |

+ ———- + ————– +

| 407 | história |

| 2 | history_text |

| 311 | history_uint |

| 2 | tendências |

+ ———- + ————– +

4 linhas em conjunto (0.01 sec)

Com isso, podemos ser governanta processo mais controlado sem esquecer que nada disso faz sentido se dividido bancos de dados, porque o processo deve ser parado para particionar próprios procedimentos excluídos obsoleto.

Por último, mas não menos importante, temos os processos de Apache, Apache é muito bem documentada e é possível que qualquer enganar você deseja aplicar é explicado em milhares de sites da internet por isso aqui vou apenas dar alguns pequenos ajustes para o httpd conf.

É necessário medir o número de conexões que podem ter a nossa frontend para ajustar o máximo possível o número de MaxClients, MaxSpareThreads e parâmetros MaxRequestsPerChild.

Por outro lado, o Apache vem com módulos bastante rasgadas … Elas são necessárias para o nosso Zabbix?. A resposta é um claro não.

Eles devem verificar quais módulos começamos a pesquisar sobre eles e ver se podemos desativar a maioria. Isso faz com que começando e não pode ter mais memória para alocar.

Bem, eu acho que este é o post mais longo que eu escrevi até agora e espero que seja de alguma ajuda para alguns de vocês.

Uma saudação.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s