Veremos cómo funciona Zabbix con la base de datos TimescaleDB como backend. Le mostraremos cómo empezar desde cero y cómo migrar desde PostgreSQL. También proporcionaremos pruebas de rendimiento comparativas de las dos configuraciones.
HighLoad++ Siberia 2019. Salón Tomsk. 24 de junio, 16:00 horas. Tesis y . La próxima conferencia HighLoad++ se llevará a cabo los días 6 y 7 de abril de 2020 en San Petersburgo. Detalles y entradas .
Andrey Gushchin (en adelante – AG): – Soy ingeniero de soporte técnico de ZABBIX (en adelante “Zabbix”), formador. Trabajo en soporte técnico desde hace más de 6 años y tengo experiencia directa con el desempeño. Hoy hablaré sobre el rendimiento que TimescaleDB puede proporcionar en comparación con PostgreSQL 10 normal. Además, una parte introductoria sobre cómo funciona en general.
Principales desafíos de productividad: desde la recopilación de datos hasta la limpieza de datos
Para empezar, existen ciertos desafíos de desempeño que todo sistema de monitoreo enfrenta. El primer desafío de productividad es recopilar y procesar datos rápidamente.
Un buen sistema de monitoreo debe recibir todos los datos de manera rápida y oportuna, procesarlos de acuerdo con expresiones desencadenantes, es decir, procesarlos de acuerdo con algunos criterios (esto es diferente en diferentes sistemas) y guardarlos en una base de datos para poder utilizar estos datos en el futuro.
El segundo desafío de rendimiento es el almacenamiento del historial. Almacene en una base de datos con frecuencia y tenga acceso rápido y conveniente a estas métricas que se recopilaron durante un período de tiempo. Lo más importante es que estos datos sean convenientes de obtener, utilizarlos en informes, gráficos, disparadores, en algunos valores de umbral, para alertas, etc.
El tercer desafío de rendimiento es la limpieza del historial, es decir, cuando se llega al punto en el que no es necesario almacenar ninguna métrica detallada que se haya recopilado durante 5 años (incluso meses o dos meses). Se eliminaron algunos nodos de red o algunos hosts; las métricas ya no son necesarias porque ya están desactualizadas y ya no se recopilan. Todo esto debe limpiarse para que su base de datos no crezca demasiado. En general, borrar el historial suele ser una prueba seria para el almacenamiento; a menudo tiene un impacto muy fuerte en el rendimiento.
¿Cómo solucionar problemas de almacenamiento en caché?
Ahora hablaré específicamente de Zabbix. En Zabbix, la primera y segunda llamada se resuelven mediante almacenamiento en caché.
Recopilación y procesamiento de datos: utilizamos RAM para almacenar todos estos datos. Estos datos se discutirán ahora con más detalle.
También en el lado de la base de datos hay algo de almacenamiento en caché para las selecciones principales, para gráficos y otras cosas.
Almacenamiento en caché en el lado del propio servidor Zabbix: tenemos ConfigurationCache, ValueCache, HistoryCache, TrendsCache. ¿Lo que es?
ConfigurationCache es el caché principal en el que almacenamos métricas, hosts, elementos de datos y activadores; todo lo que necesita para procesar el preprocesamiento, recopilar datos, de qué hosts recopilarlos y con qué frecuencia. Todo esto se almacena en ConfigurationCache para no acudir a la base de datos y crear consultas innecesarias. Una vez que se inicia el servidor, actualizamos este caché (lo creamos) y lo actualizamos periódicamente (según los ajustes de configuración).
Almacenamiento en caché en Zabbix. Recopilación de datos
Aquí el diagrama es bastante grande:
Los principales del esquema son estos coleccionistas:
Estos son los propios procesos de montaje, varios “encuestadores” que se encargan de diferentes tipos de montajes. Recopilan datos a través de icmp, ipmi y varios protocolos y los transfieren todos para preprocesamiento.
Historial de preprocesamientoCache
Además, si tenemos elementos de datos calculados (aquellos que están familiarizados con Zabbix lo saben), es decir, elementos de datos calculados y agregados, los tomamos directamente de ValueCache. Más adelante os cuento cómo se llena. Todos estos recopiladores utilizan ConfigurationCache para recibir sus trabajos y luego pasarlos al preprocesamiento.
El preprocesamiento también utiliza ConfigurationCache para obtener pasos de preprocesamiento y procesa estos datos de varias maneras. A partir de la versión 4.2, lo hemos movido a un proxy. Esto es muy conveniente porque el preprocesamiento en sí es una operación bastante difícil. Y si tiene un Zabbix muy grande, con una gran cantidad de elementos de datos y una alta frecuencia de recopilación, esto simplifica enormemente el trabajo.
En consecuencia, después de haber procesado estos datos de alguna manera mediante el preprocesamiento, los guardamos en HistoryCache para poder procesarlos más. Con esto concluye la recolección de datos. Pasamos al proceso principal.
El trabajo del sincronizador de historia.
El proceso principal en Zabbix (ya que es una arquitectura monolítica) es el sincronizador de historia. Este es el proceso principal que se ocupa específicamente del procesamiento atómico de cada elemento de datos, es decir, de cada valor:
- el valor viene (lo toma de HistoryCache);
- comprueba en el Sincronizador de configuración: si hay activadores para el cálculo; los calcula;
si lo hay, crea eventos, crea una escalada para crear una alerta, si es necesario según la configuración; - activadores de registros para su posterior procesamiento y agregación; si agrega durante la última hora y así sucesivamente, ValueCache recuerda este valor para no ir a la tabla de historial; Por lo tanto, ValueCache se llena con los datos necesarios para calcular activadores, elementos calculados, etc.;
- luego, el sincronizador de historial escribe todos los datos en la base de datos;
- la base de datos los escribe en el disco; aquí es donde finaliza el proceso de procesamiento.
Base de datos. Almacenamiento en caché
En el lado de la base de datos, cuando desea ver gráficos o algunos informes sobre eventos, existen varios cachés. Pero en este informe no hablaré de ellos.
Para MySQL existe Innodb_buffer_pool y un montón de cachés diferentes que también se pueden configurar.
Pero estos son los principales:
- buffers_compartidos;
- tamaño_cache_efectivo;
- piscina compartida.
Para todas las bases de datos, dije que existen ciertos cachés que le permiten almacenar en la RAM los datos que a menudo se necesitan para las consultas. Tienen sus propias tecnologías para esto.
Acerca del rendimiento de la base de datos
En consecuencia, existe un entorno competitivo, es decir, el servidor Zabbix recopila datos y los registra. Cuando se reinicia, también lee el historial para llenar ValueCache, etc. Aquí puede tener scripts e informes que utilizan la API de Zabbix, que está construida en una interfaz web. Zabbix API ingresa a la base de datos y recibe los datos necesarios para obtener gráficos, informes o algún tipo de lista de eventos, problemas recientes.
También una solución de visualización muy popular es Grafana, que utilizan nuestros usuarios. Capaz de iniciar sesión directamente tanto a través de la API de Zabbix como a través de la base de datos. También crea cierta competencia por la obtención de datos: se necesita un ajuste más fino y mejor de la base de datos para cumplir con la entrega rápida de resultados y pruebas.
Borrar historial. Zabbix tiene ama de llaves
La tercera llamada que se utiliza en Zabbix es borrar el historial usando Housekeeper. Housekeeper sigue todas las configuraciones, es decir, nuestros elementos de datos indican cuánto tiempo almacenar (en días), cuánto tiempo almacenar las tendencias y la dinámica de los cambios.
No hablé de TrendCache, que calculamos sobre la marcha: llegan los datos, los agregamos durante una hora (principalmente son números de la última hora), la cantidad es media/mínima y la registramos una vez por hora en el tabla de la dinámica de cambios (“Tendencias”). "Housekeeper" inicia y elimina datos de la base de datos mediante selecciones regulares, lo que no siempre es efectivo.
¿Cómo entender que es ineficaz? Puede ver la siguiente imagen en los gráficos de rendimiento de los procesos internos:
Su sincronizador de historial está constantemente ocupado (gráfico rojo). Y el gráfico “rojo” que va encima. Este es un "ama de llaves" que se inicia y espera a que la base de datos elimine todas las filas que ha especificado.
Tomemos un ID de artículo: debes eliminar los últimos 5 mil; por supuesto, por índices. Pero normalmente el conjunto de datos es bastante grande: la base de datos aún lo lee del disco y lo guarda en la caché, y esta es una operación muy costosa para la base de datos. Dependiendo de su tamaño, esto puede provocar ciertos problemas de rendimiento.
Puede desactivar Housekeeper de forma sencilla: tenemos una interfaz web familiar. En la configuración de Administración general (configuración para “Ama de llaves”) deshabilitamos la limpieza interna para el historial y las tendencias internas. En consecuencia, Housekeeper ya no controla esto:
¿Qué puedes hacer a continuación? Lo apagaste, tus gráficos se han nivelado... ¿Qué otros problemas podrían surgir en este caso? ¿Qué puede ayudar?
Particionar (seccionar)
Normalmente, esto se configura de forma diferente en cada base de datos relacional que he enumerado. MySQL tiene su propia tecnología. Pero en general son muy similares cuando se trata de PostgreSQL 10 y MySQL. Por supuesto, existen muchas diferencias internas en cómo se implementa todo y cómo afecta el rendimiento. Pero, en general, la creación de una nueva partición también suele provocar ciertos problemas.
Dependiendo de su configuración (cuántos datos crea en un día), generalmente establecen el mínimo: 1 día / lote, y para "tendencias", dinámica de cambios: 1 mes / nuevo lote. Esto puede cambiar si tiene una configuración muy grande.
Digamos de inmediato sobre el tamaño de la configuración: hasta 5 mil nuevos valores por segundo (los llamados nvps); esto se considerará una pequeña "configuración". Promedio: de 5 a 25 mil valores por segundo. Todo lo anterior ya son instalaciones grandes y muy grandes que requieren una configuración muy cuidadosa de la base de datos.
En instalaciones muy grandes, 1 día puede no ser lo óptimo. Personalmente he visto particiones en MySQL de 40 gigabytes por día (y puede que haya más). Se trata de una gran cantidad de datos, lo que puede provocar algunos problemas. Es necesario reducirlo.
¿Por qué necesitas particionar?
Lo que proporciona la partición, creo que todo el mundo lo sabe, es la partición de tablas. A menudo, se trata de archivos separados en el disco y solicitudes de extensión. Selecciona una partición de manera más óptima si es parte de una partición normal.
Para Zabbix, en particular, se usa por rango, por rango, es decir, usamos una marca de tiempo (un número regular, el tiempo desde el comienzo de la época). Usted especifica el inicio/final del día y esta es la partición. En consecuencia, si solicita datos que tienen dos días de antigüedad, todo se recupera de la base de datos más rápido, porque solo necesita cargar un archivo en el caché y devolverlo (en lugar de una tabla grande).
Muchas bases de datos también aceleran la inserción (inserción en una tabla secundaria). Por ahora hablo de forma abstracta, pero esto también es posible. La partición suele ayudar.
Búsqueda elástica para NoSQL
Recientemente, en 3.4, implementamos una solución NoSQL. Se agregó la capacidad de escribir en Elasticsearch. Puedes escribir ciertos tipos: tú eliges: escribir números o algunos signos; tenemos texto de cadena, puede escribir registros en Elasticsearch... En consecuencia, la interfaz web también accederá a Elasticsearch. Esto funciona muy bien en algunos casos, pero por el momento se puede utilizar.
Escala de tiempoDB. hipertablas
Para 4.4.2 prestamos atención a algo como TimescaleDB. ¿Lo que es? Esta es una extensión para PostgreSQL, es decir, tiene una interfaz nativa de PostgreSQL. Además, esta extensión le permite trabajar de manera mucho más eficiente con datos de series temporales y tener particiones automáticas. Cómo se ve:
Esto es hipertable; existe tal concepto en Timescale. Esta es una hipertabla que usted crea y contiene fragmentos. Los fragmentos son particiones, son tablas secundarias, si no me equivoco. Es realmente efectivo.
Escala de tiempoDB y PostgreSQL
Como aseguran los fabricantes de TimescaleDB, utilizan un algoritmo más correcto para procesar consultas, en particular inserciones, lo que permite un rendimiento aproximadamente constante con un tamaño cada vez mayor de la inserción del conjunto de datos. Es decir, después de 200 millones de filas de Postgres, el habitual comienza a hundirse mucho y pierde rendimiento literalmente a cero, mientras que Timescale le permite insertar inserciones de la manera más eficiente posible con cualquier cantidad de datos.
¿Cómo instalar TimescaleDB? ¡Es sencillo!
Está en la documentación, está descrito: puedes instalarlo desde paquetes para cualquier... Depende de los paquetes oficiales de Postgres. Se puede compilar manualmente. Dio la casualidad de que tuve que compilar para la base de datos.
En Zabbix simplemente activamos Extensión. Creo que los que usaron Extensión en Postgres... Simplemente activan Extensión, la crean para la base de datos Zabbix que están usando.
Y el último paso...
Escala de tiempoDB. Migración de tablas de historial.
Necesitas crear una hipertabla. Hay una función especial para esto: crear hipertabla. En él, el primer parámetro es la tabla que se necesita en esta base de datos (para la cual es necesario crear una hipertabla).
El campo mediante el cual crear y chunk_time_interval (este es el intervalo de fragmentos (particiones que deben usarse). 86 es un día.
Parámetro Migrate_data: si lo inserta en verdadero, esto migrará todos los datos actuales a fragmentos creados previamente.
Yo mismo he usado migrar_data; lleva bastante tiempo, dependiendo del tamaño de su base de datos. Tenía más de un terabyte; me llevó más de una hora crearlo. En algunos casos, durante las pruebas, eliminé datos históricos de texto (history_text) y cadena (history_str) para no transferirlos; realmente no me interesaban.
Y hacemos la última actualización en nuestra db_extention: instalamos timescaledb para que la base de datos y, en particular, nuestro Zabbix entienda que existe db_extention. Lo activa y utiliza la sintaxis y consultas correctas a la base de datos, utilizando aquellas "características" que son necesarias para TimescaleDB.
Configuración del servidor
Usé dos servidores. El primer servidor es una máquina virtual bastante pequeña, 20 procesadores, 16 gigabytes de RAM. Configuré Postgres 10.8 en él:
El sistema operativo era Debian, el sistema de archivos era xfs. Hice configuraciones mínimas para usar esta base de datos en particular, menos lo que usará Zabbix. En la misma máquina había un servidor Zabbix, PostgreSQL y agentes de carga.
He usado 50 agentes activos que usan LoadableModule para generar rápidamente diferentes resultados. Ellos son quienes generaron las cadenas, los números, etc. Llené la base de datos con muchos datos. Inicialmente, la configuración contenía 5 mil elementos de datos por host, y aproximadamente cada elemento de datos contenía un disparador, para que esto fuera una configuración real. A veces incluso es necesario utilizar más de un disparador.
Regulé el intervalo de actualización y la carga en sí no solo usando 50 agentes (agregando más), sino también usando elementos de datos dinámicos y reduciendo el intervalo de actualización a 4 segundos.
Prueba de rendimiento. PostgreSQL: 36 mil NVP
El primer lanzamiento, la primera configuración que tuve fue en PostreSQL 10 puro en este hardware (35 mil valores por segundo). En general, como puede ver en la pantalla, insertar datos toma fracciones de segundo: todo es bueno y rápido, unidades SSD (200 gigabytes). Lo único es que 20 GB se llenan bastante rápido.
Habrá muchos gráficos de este tipo en el futuro. Este es un panel de rendimiento del servidor Zabbix estándar.
El primer gráfico es el número de valores por segundo (azul, arriba a la izquierda), 35 mil valores en este caso. Esto (arriba en el centro) es la carga de procesos de compilación, y esto (arriba a la derecha) es la carga de procesos internos: sincronizadores de historial y ama de llaves, que aquí (abajo en el centro) han estado ejecutándose durante bastante tiempo.
Este gráfico (parte inferior central) muestra el uso de ValueCache: cuántas visitas de ValueCache para los activadores (varios miles de valores por segundo). Otro gráfico importante es el cuarto (abajo a la izquierda), que muestra el uso de HistoryCache, del que hablé, que es un buffer antes de insertarlo en la base de datos.
Prueba de rendimiento. PostgreSQL: 50 mil NVP
A continuación, aumenté la carga a 50 mil valores por segundo en el mismo hardware. Cuando Housekeeper lo cargó, se registraron 10 mil valores en 2-3 segundos con cálculo. Lo que, de hecho, se muestra en la siguiente captura de pantalla:
El “ama de llaves” ya está empezando a interferir con el trabajo, pero en general, la carga sobre los tramperos históricos todavía está en el nivel del 60% (tercer gráfico, arriba a la derecha). HistoryCache ya comienza a llenarse activamente mientras se ejecuta Housekeeper (abajo a la izquierda). Tenía alrededor de medio gigabyte, un 20% de su capacidad.
Prueba de rendimiento. PostgreSQL: 80 mil NVP
Luego lo aumenté a 80 mil valores por segundo:
Fueron aproximadamente 400 mil elementos de datos, 280 mil activadores. El inserto, como puede ver, en cuanto a la carga de plomos históricos (eran 30) ya era bastante alto. Luego aumenté varios parámetros: hundimientos de historial, caché... En este hardware, la carga de los hundimientos de historial comenzó a aumentar al máximo, casi "en el estante"; en consecuencia, HistoryCache entró en una carga muy alta:
Durante todo este tiempo supervisé todos los parámetros del sistema (cómo se usa el procesador, RAM) y descubrí que la utilización del disco era máxima: logré la capacidad máxima de este disco en este hardware, en esta máquina virtual. "Postgres" comenzó a volcar datos de forma bastante activa con tal intensidad, y el disco ya no tenía tiempo de escribir, leer...
Tomé otro servidor que ya tenía 48 procesadores y 128 gigabytes de RAM:
También lo "sintonicé": instalé el sincronizador de historial (60 piezas) y logré un rendimiento aceptable. De hecho, no estamos “en el estante”, pero este es probablemente el límite de la productividad, donde ya es necesario hacer algo al respecto.
Prueba de rendimiento. TimescaleDB: 80 mil NVP
Mi tarea principal era utilizar TimescaleDB. Cada gráfico muestra una caída:
Estos fallos son precisamente la migración de datos. Después de eso, en el servidor Zabbix, el perfil de carga de los sinkers históricos, como puede ver, cambió mucho. Le permite insertar datos casi 3 veces más rápido y utilizar menos HistoryCache; en consecuencia, recibirá los datos a tiempo. Nuevamente, 80 mil valores por segundo es una tasa bastante alta (por supuesto, no para Yandex). En general, se trata de una configuración bastante grande, con un solo servidor.
Prueba de rendimiento de PostgreSQL: 120 mil NVP
A continuación, aumenté el valor de la cantidad de elementos de datos a medio millón y obtuve un valor calculado de 125 mil por segundo:
Y obtuve estos gráficos:
En principio, esta es una configuración que funciona y puede funcionar durante bastante tiempo. Pero como sólo tenía un disco de 1,5 terabytes, lo usé en un par de días. Lo más importante es que al mismo tiempo se crearon nuevas particiones en TimescaleDB, y esto pasó completamente desapercibido para el rendimiento, lo que no se puede decir de MySQL.
Normalmente, las particiones se crean por la noche, porque esto generalmente bloquea la inserción y el trabajo con tablas y puede provocar la degradación del servicio. ¡En este caso no es así! La tarea principal fue probar las capacidades de TimescaleDB. El resultado fue la siguiente cifra: 120 mil valores por segundo.
También hay ejemplos en la comunidad:
La persona también activó TimescaleDB y la carga del uso de io.weight cayó en el procesador; y el uso de elementos de procesos internos también ha disminuido debido a la inclusión de TimescaleDB. Además, estos son discos tipo panqueque normales, es decir, una máquina virtual normal en discos normales (no SSD).
Para algunas configuraciones pequeñas que están limitadas por el rendimiento del disco, TimescaleDB, en mi opinión, es una muy buena solución. Le permitirá continuar trabajando antes de migrar a un hardware más rápido para la base de datos.
Los invito a todos a nuestros eventos: Conferencia en Moscú, Cumbre en Riga. Utilice nuestros canales: Telegram, foro, IRC. Si tienes alguna duda acércate a nuestro escritorio, podemos hablar de todo.
Preguntas de la audiencia
Pregunta de la audiencia (en adelante, A): - Si TimescaleDB es tan fácil de configurar y ofrece tal aumento de rendimiento, ¿quizás esto debería usarse como una mejor práctica para configurar Zabbix con Postgres? ¿Y hay trampas y desventajas en esta solución, o después de todo, si decido hacer Zabbix por mí mismo, puedo tomar Postgres fácilmente, instalar Timescale allí de inmediato, usarlo y no pensar en ningún problema?
AG: – Sí, diría que es una buena recomendación: utilice Postgres inmediatamente con la extensión TimescaleDB. Como ya dije, muchas buenas críticas, a pesar de que esta "característica" es experimental. Pero en realidad las pruebas muestran que esta es una gran solución (con TimescaleDB) y creo que evolucionará. Estamos monitoreando cómo se desarrolla esta extensión y haremos los cambios necesarios.
Incluso durante el desarrollo, confiamos en una de sus "características" más conocidas: era posible trabajar con fragmentos de forma un poco diferente. Pero luego lo eliminaron en la siguiente versión y ya no tuvimos que depender de este código. Recomendaría usar esta solución en muchas configuraciones. Si usa MySQL... Para configuraciones promedio, cualquier solución funciona bien.
A: – En los últimos gráficos de la comunidad, había un gráfico con “Housekeeper”:
Continuó trabajando. ¿Qué hace Housekeeper con TimescaleDB?
AG: – Ahora no puedo decirlo con seguridad – Miraré el código y te lo contaré con más detalle. Utiliza consultas de TimescaleDB no para eliminar fragmentos, sino para agregarlos de alguna manera. Todavía no estoy listo para responder esta pregunta técnica. Descubriremos más en el stand hoy o mañana.
A: – Tengo una pregunta similar – sobre el rendimiento de la operación de eliminación en Timescale.
R (respuesta de la audiencia): – Cuando elimina datos de una tabla, si lo hace mediante eliminación, entonces necesita revisar la tabla: eliminar, limpiar y marcar todo para una futura limpieza. En Timescale, como tienes fragmentos, puedes soltarlos. En términos generales, simplemente le dice al archivo que está en big data: "¡Eliminar!".
Timescale simplemente entiende que ese fragmento ya no existe. Y dado que está integrado en el planificador de consultas, utiliza enlaces para detectar sus condiciones en operaciones de selección u otras operaciones e inmediatamente comprende que este fragmento ya no existe: "¡Ya no volveré allí!". (informacion no disponible). ¡Eso es todo! Es decir, un escaneo de tabla se reemplaza por una eliminación de un archivo binario, por lo que es rápido.
A: – Ya hemos tocado el tema de no SQL. Hasta donde tengo entendido, Zabbix realmente no necesita modificar los datos, y todo esto es algo así como un registro. ¿Es posible utilizar bases de datos especializadas que no pueden cambiar sus datos, pero que al mismo tiempo guardan, acumulan y distribuyen mucho más rápido (Clickhouse, por ejemplo, algo parecido a Kafka)?... ¡Kafka también es un registro! ¿Es posible integrarlos de alguna manera?
AG: - Se puede realizar la descarga. Tenemos una cierta “característica” desde la versión 3.4: puedes escribir todos los archivos históricos, eventos y todo lo demás en archivos; y luego enviarlo a cualquier otra base de datos usando algún controlador. De hecho, muchas personas reelaboran y escriben directamente en la base de datos. Sobre la marcha, los receptores de historia escriben todo esto en archivos, los rotan, etc., y usted puede transferirlos a Clickhouse. No puedo decir sobre los planes, pero tal vez continúe el soporte adicional para las soluciones NoSQL (como Clickhouse).
A: – En general, ¿resulta que puedes deshacerte completamente de Postgres?
AG: – Por supuesto, la parte más difícil en Zabbix son las tablas históricas, que crean la mayor cantidad de problemas y eventos. En este caso, si no almacena eventos durante mucho tiempo y almacena el historial con tendencias en algún otro almacenamiento rápido, entonces, en general, creo que no habrá problemas.
A: – ¿Puedes estimar cuánto más rápido funcionará todo si te cambias a Clickhouse, por ejemplo?
AG: – No lo he probado. Creo que al menos se pueden conseguir los mismos números de forma bastante sencilla, teniendo en cuenta que Clickhouse tiene su propia interfaz, pero no puedo decirlo con seguridad. Es mejor probar. Todo depende de la configuración: cuántos hosts tengas, etc. Insertar es una cosa, pero también necesita recuperar estos datos: Grafana u otra cosa.
A: – ¿Entonces estamos hablando de una lucha igualada y no de la gran ventaja de estas rápidas bases de datos?
AG: – Creo que cuando nos integremos, habrá pruebas más precisas.
A: – ¿Adónde se fue el bueno de RRD? ¿Qué te hizo cambiar a las bases de datos SQL? Inicialmente, todas las métricas se recopilaron en RRD.
AG: – Zabbix tenía RRD, quizás en una versión muy antigua. Siempre ha habido bases de datos SQL, un enfoque clásico. El enfoque clásico es MySQL, PostgreSQL (existen desde hace mucho tiempo). Casi nunca utilizamos una interfaz común para bases de datos SQL y RRD.
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com