Veieu els canvis més importants per a aquesta versió.
El programari Zabbix ara és escrit i distribuït sota la llicència AGPL-3.0 (anteriorment sota llicència GPL v2.0).
Ara s'afegeix una comprovació d'actualització de programari de manera predeterminada a les instal·lacions noves i existents: la interfície Zabbix es comunicarà amb el punt final Zabbix públic per comprovar si hi ha actualitzacions.
Les notícies sobre les actualitzacions de programari Zabbix disponibles es mostren a Informes -> Informació del sistema i (opcionalment) al tauler de control, al giny Informació del sistema.
Podeu desactivar la comprovació d'actualització del programari configurant AllowSoftwareUpdateCheck=0 a la configuració del servidor.
S'han afegit nous processos d'enquestador capaços d'executar múltiples comprovacions al mateix temps:
agent enquestador
http agent poller
snmp poller
(per als elements walk[OID]
i get[OID]
)Aquests enquestadors són asíncrons: són capaços d'iniciar noves comprovacions sense necessitat d'esperar una resposta, amb concurrència que es pot configurar fins a 1000 comprovacions simultànias.
Els enquestadors asíncrons s'han desenvolupat perquè, en comparació, els processos de sondeig síncron només poden executar una comprovació al mateix temps i la major part del seu temps es dediquen a esperar la resposta. Així, l'eficiència es podria augmentar iniciant nous controls paral·lels mentre s'espera la resposta de la xarxa, i els nous enquestadors ho fan.
Podeu iniciar enquestadors d'agents asíncrons modificant el valor de StartAgentPollers - un nou paràmetre de servidor/proxy. Els sondedors d'agents HTTP es poden iniciar modificant StartHTTPAgentPollers respectivament. Els enquestadors SNMP es poden iniciar modificant StartSNMPPollers respectivament.
MaxConcurrentChecksPerPoller defineix la concurrència màxima per als enquestadors asíncrons (agent, agent HTTP i SNMP).
Tingueu en compte que, després de l'actualització, totes les comprovacions de l'agent, de l'agent HTTP i de l'SNMP walk[OID]
es traslladaran a enquestadors asíncrons.
Com a part del desenvolupament, s'ha afegit la funció cURL de connexions persistents a les comprovacions de l'agent HTTP.
L'equilibri de càrrega del proxy s'implementa mitjançant la introducció de grups de proxys a Zabbix. Els grups de proxys proporcionen distribució automàtica d'equips entre proxys, reequilibri de càrrega de proxysi alta disponibilitat: quan un proxy es desconnecta, els seus equips es distribueixen immediatament entre altres proxys del grup.
Per obtindre més informació, veieu equilibri de càrrega de proxy i alta disponibilitat.
S'ha desenvolupat un buffer de memòria per al proxy Zabbix. El buffer de memòria permet emmagatzemar dades noves (valors d'elements, descobriment de xarxa, registre automàtic de l'equip) a la memòria intermèdia i pujar al servidor Zabbix sense accedir a la base de dades.
En instal·lacions anteriors a Zabbix 7.0, les dades recollides es van emmagatzemar a la base de dades abans de pujar-les al servidor Zabbix. Per a aquestes instal·lacions aquest segueix sent el comportament predeterminat després de l'actualització.
Per obtindre un rendiment optimitzat, es recomana configurar l'ús de la memòria intermèdia al proxy. Això és possible modificant el valor de ProxyBufferMode del "disc" (codificada per defecte per a instal·lacions existents) a "híbrid" (recomanat) o "memòria". També cal establir la mida del buffer de memòria (paràmetre ProxyMemoryBufferSize).
En el mode híbrid, el buffer està protegit de la pèrdua de dades enviant les dades no enviades a la base de dades si el proxy s'atura, la memòria intermèdia està plena o les dades són massa antigues. Quan tots els valors s'han buidat a la base de dades, el servidor intermediari torna a utilitzar la memòria intermèdia.
En mode de memòria, s'emprarà la memòria intermèdia, però no hi ha protecció contra la pèrdua de dades. Si el proxy s'atura, o la memòria s'omple, les dades no enviades s'eliminaran.
El mode híbrid (ProxyBufferMode=hybrid) s'aplica a totes les instal·lacions noves des de Zabbix 7.0.
Paràmetres addicionals com ara ProxyMemoryBufferSize i ProxyMemoryBufferAge definir la mida de la memòria intermèdia i l'edat màxima de les dades a la memòria intermèdia, respectivament.
Nous elements interns [s'han afegit] (#internal_items) per monitorar la memòria intermèdia de proxy.
Els usuaris aprovisionats anteriorment es limitaven només als suports creats durant l'aprovisionament sense la flexibilitat d'editar propietats com ara les hores de treball o la gravetat.
Ara hi ha més flexibilitat disponible per als usuaris subministrats a Zabbix:
A més, quan es configura el mapa de mitjans d'usuari per subministrar camps com ara Quan és actiu, Emprar si la gravetat i Activat ara són disponibles. Tingueu en compte que els canvis al formulari d'assignació de tipus de suport d'usuari només tindran efecte per als suports nous creats durant l'aprovisionament.
S'ha implementat un protocol basat en JSON per a comprovacions d'agent passiu.
Per a la compatibilitat amb agents antics, s'ha afegit una migració per error al protocol antic de text sense format. Si l'agent retorna "ZBX_NOTSUPPORTED", Zabbix emmagatzemarà la interfície com a protocol antic i retornarà a provar la comprovació enviant només la clau de l'element de text sense format.
Zabbix get ara es pot executar amb una nova opció -P --protocol <valor>
on "valor" és:
Si una clau d'element no és compatible, Zabbix retornarà el codi de sortida 1
.
Els protocols de l'agent Zabbix i l'agent 2 s'han unificat canviant l'agent Zabbix al protocol de l'agent 2 de Zabbix. La diferència entre les sol·licituds/respostes de l'agent Zabbix i l'agent Zabbix 2 s'expressa pel valor de l'etiqueta "variant" ("1" - agent Zabbix, "2" - agent Zabbix 2).
Veieu també: Comprovacions d'agent passiu i actiu.
Els intervals flexibles/de programació ara són compatibles amb les comprovacions actives tant per l'agent Zabbix com per l'agent Zabbix 2 (abans només l'agent Zabbix 2).
La configuració del temps d'espera per element ara és disponible per a més tipus d'elements (consulteu els tipus d'elements admesos). A més d'establir els valors de temps d'espera al nivell d'element, és possible definir temps d'espera globals i de proxy per a diversos tipus d'elements.
Els temps d'espera configurats al nivell d'element tenen la prioritat més alta. Per defecte, els temps d'espera global s'apliquen a tots els elements; tanmateix, si s'estableixen temps d'espera del proxy, substituiran els globals.
Els recursos que ja no es troben per una descoberta de baix nivell ara es poden desactivar automàticament. Es poden desactivar immediatament, després d'un període de temps especificat o mai (veieu el nou paràmetre Desactivar recursos perduts a la configuració de la regla de descoberta).
Els recursos perduts (equips, elements, triggers) es marquen amb una icona a la columna d'informació. El text d'informació eines proporciona detalls sobre el seu estat.
Dins del mateix desenvolupament, el paràmetre Conservar el període de recursos perduts va canviar el nom a Esborrar els recursos perduts amb opcions per esborrar-los immediatament, després d'un període de temps especificat o mai.
L'entrada manual de l'usuari per als scripts d'interfície permet proporcionar un paràmetre personalitzat a cada execució de l'script. Això estalvia la necessitat de crear diversos scripts d'usuari similars amb només una diferència de paràmetres.
Per exemple, és possible que vulgueu proporcionar un nombre enter diferent o una adreça URL diferent a l'script durant l'execució.
Per habilitar l'entrada manual de l'usuari:
Amb l'entrada de l'usuari habilitada, abans de l'execució de l'script, apareixerà una finestra emergent Entrada manual a l'usuari demanant que proporcioni un valor personalitzat. El valor proporcionat substituirà {MANUALINPUT} a l'script.
En funció de la configuració, se li demanarà a l'usuari que introdueixi un valor de cadena o seleccioneu el valor d'un desplegable d'opcions predeterminades.
El suport per a Oracle com a base de dades de fons ha quedat obsolet i s'espera que s'esborri completament a versions futures.
Anteriorment, es podia enviar dades específiques al servidor Zabbix mitjançant la utilitat Zabbix sender o implementant un protocol de comunicació personalitzat basat en JSON similar a l'emprat al Zabbix sender.
Ara també és possible enviar dades al servidor Zabbix mitjançant el protocol HTTP mitjançant el mètode API history.push
. Tingueu en compte que la recepció de dades enviades requereix un element trapper o un element d'agent HTTP (amb la captura activada).
A més, les operacions correcció history.push
es registren a Informes → Registre d'auditoria que té opcions de filtrat addicionals (una nova acció Push i un recurs Historial), i el mètode de l'API history.push
també és disponible a la llista Allow/Deny de mètodes API quan es configura un rol d'usuari.
Anteriorment, els manteniments es recalculaven només cada minut, provocant una possible latència de fins a 60 segons per iniciar o aturar un període de manteniment.
Ara els manteniments encara es tornen a calcular cada minut o tan aviat com es torna a carregar la memòria cau de configuració si hi ha canvis en el període de manteniment.
Cada segon, el procés del temporitzador comprova si s'ha d'iniciar/aturar algun manteniment en funció de si hi ha canvis als períodes de manteniment després de l'actualització de la configuració. Així, la velocitat d'inici/aturada dels períodes de manteniment depèn de la configuració interval d'actualització (10 segons per defecte). Tingueu en compte que els canvis del període de manteniment no inclouen la configuració de Actiu des de/Activat fins a. A més, si s'afegeix un equip/grup d'equips a un període de manteniment actiu existent, els canvis només s'activaran mitjançant el procés del temporitzador a l'inici del minut següent.
Les comprovacions de permisos s'han fet molt més ràpides introduint diverses taules intermèdies per comprovar els permisos dels usuaris no privilegiats.
Aquestes taules mantenen els hash (SHA-256) dels conjunts de grups d'usuaris i conjunts de grups d'amfitrió per a cada usuari/equiprespectivament. A més, hi ha una taula de permisos que emmagatzema només les combinacions accessibles d'usuaris i equips, especificades pels ID hash.
Aquesta millora fa que la càrrega de pàgines interfícies amb molts permisos (és a dir, equips, problemes) sigui molt més ràpida. Tingueu en compte que els hash i els permisos no es calculen per als usuaris superadministradors.
L'acció de trigger, l'operació de recuperació i l'execució de l'operació d'actualització al servidor Zabbix ara es produeix immediatament (menys de 100 mil·lisegons) després d'un canvi d'estat del trigger, mentre que abans els usuaris podien experimentar fins a 4 segons de latència.
La reducció de la latència és possible mitjançant la implementació de mecanismes de comunicació entre processos (IPC) entre múltiples processos (escala mecànica i iniciador d'escalades, escala mecànica i alertador, gestor de preprocessament). i sincronitzador de l'historial).
Ara és possible restringir algunes funcions de Zabbix per reforçar la seguretat de l'entorn del servidor:
$ALLOW_HTTP_AUTH=false
al fitxer de configuració de la interfície (zabbix.conf.php).S'ha afegit la possibilitat de validar el fitxer de configuració a les ordres de manteniment del servidor, proxy, agent, agent 2 i servei web de Zabbix. La validació es pot fer mitjançant l'opció -T --test-config. En cas de validació correcta, el codi de sortida serà "0"; en cas contrari, el component sortirà amb un codi de sortida diferent de zero i un missatge d'error corresponent. Els advertiments (p. ex., en cas d'un paràmetre obsolet) no afectaran el codi de sortida correcte.
L'opció per definir el tipus d'inici del servei de Windows agent/agent 2 de Zabbix (-S --startup-type
) s'ha afegit. Aquesta opció permet configurar el servei agent/agent 2 perquè s'iniciï automàticament a l'inici de Windows ('automàtic'), després que els serveis iniciats automàticament hagin finalitzat l'inici ('retardat'), quan l'iniciï manualment un usuari o aplicació ('manual') o per desactivar completament el servei ('desactivat').
Quan es realitza la instal·lació de l'agent de Windows des de MSI, el tipus d'inici predeterminat a Windows Server 2008/Vista i versions posteriors ara es "retardeix" si no s'especifica el contrari a l'"STARTUPTYPE" ordre- paràmetre de línia. Això millora la fiabilitat i el rendiment del servei Zabbix agent/agent 2 de Windows, especialment durant el reinici del sistema.
S'han afegit diversos ginys nous a la nova versió, mentre que la funcionalitat disponible en altres s'ha millorat. A més, els ginys del tauler de control ara es poden connectar i comunicar-se entre ells, fent que els ginys i taulers de control siguin més dinàmics.
S'ha afegit un giny Calibre a ginys del tauler de control, que permet mostrar el valor d'un sol element com a indicador. Per obtindre més informació, veieu Calibre.
S'ha afegit un giny gràfic de pastís a widgets del tauler de control, que permet mostrar els valors dels elements seleccionats com:
Diagrama de sectors. |
Gràfic de donuts. |
Per obtindre més informació, veieu Gràfic de pastís.
Com a part d'aquest desenvolupament, s'ha afegit una casella de selecció Mostra la funció d'agregació al gràfic configuració del giny (a la pestanya Llegenda).
S'ha afegit un giny Triggers principals a Ginys del tauler, que permet visualitzar els triggers amb el major nombre de problemes.
Per obtindre més informació, consulteu: Triggers principals.
S'ha afegit un giny Bresca a ginys del tauler de control, que ofereix una visió general dinàmica i vibrant de la infraestructura i els recursos de xarxa monitorats, on els grups d'equips, com ara màquines virtuals i els dispositius de xarxa, juntament amb els seus respectius elements, es representen visualment com a cel·les hexagonals interactives. Per obtindre més informació, consulteu Bresca.
Els ginys Navegador d'eequip i Navegador d'elements s'han afegit a ginys del tauler de control. Aquests ginys mostren equips o elements, respectivament, basats en diverses opcions de filtrat i agrupació, i permeten controlar la informació que es mostra en altres ginys en funció de l'equip o element seleccionat. Per obtindre més informació, consulteu Navegador d'equips i Navegador d'elements.
El nou giny de tauler ha substituït el giny Text sense format, oferint diverses millores.
A diferència del giny Text normal, que només mostrava les dades d'elements més recents en text sense format, el giny Historial d'elements admet diverses opcions de visualització per a diversos tipus d'element (numèric, caràcter, registre, text i binari). Per exemple, pot mostrar barres o indicadors de progrés, imatges per a tipus de dades binàries (útils per a elements del navegador) i ressaltar valors de text (útils per a control de fitxers de registre).
Per obtindre més informació, consulteu Historial d'elements. Per obtindre més informació sobre la substitució del giny Text sense format, veieu Notes d'actualització per a 7.0.0.
Els períodes de temps ara es poden configurar als ginys Valor d'element i Equips principals.
Ara també és possible mostrar un valor agregat al giny del valor de l'element per al període escollit. El valor agregat es pot mostrar com:
Aquestes funcions afegides són útils per crear ginys de comparació de dades. Per exemple, en un giny podeu mostrar el valor més recent, mentre que en un altre el valor mitjà per a un període més llarg. O es poden emprar diversos ginys per a la comparació paral·lela de valors agregats de diversos períodes del passat.
Anteriorment, en un tauler de plantilla, només podríeu crear els ginys següents: Rellotge, Gràfic (clàssic), Prototip de gràfic, Valor de l'element, Text sense format, URL.
Ara els taulers de plantilla admeten la creació de tots els ginys.
Ara, a més d'ordenar per Valor de l'element, també és possible establir la columna Nom de l'equip o la columna Text com a columna de comanda. al giny Equips principals.
Els ginys del tauler de control ara es poden connectar i comunicar-se entre ells, fent que els ginys i taulers de control siguin més dinàmics. Diversos ginys tenen paràmetres que els permeten compartir dades de configuració entre ginys compatibles o el tauler.
Aquesta característica introdueix els canvis següents:
Segons el giny i els seus paràmetres, la font de dades pot ser un giny compatible del mateix tauler o el mateix tauler. Per obtindre més informació, veieu Ginys del tauler de control.
Per obtindre canvis a les plantilles d'estoc que s'envien amb Zabbix, consulteu Canvis de plantilla.
Disponibilitat de l'equip ara permet mostrar els equips amb la interfície agent Zabbix (comprovacions actives). S'ha afegit un estat de disponibilitat més, és a dir, Mixt, que correspon a la situació en què almenys una interfície no està disponible i almenys una està disponible o desconegut. A més, s'ha afegit la possibilitat de veure només el total d'equips, sense desglossament per interfícies.
El giny Gràfic ara admet la configuració d'un nombre variable de fileres llegenda determinat pel nombre d'elements configurats.
S'han afegit funcions noves per emprar-les en expressions de trigger i elements calculats:
Veieu també: Funcions de cadena
S'han actualitzat diverses funcions:
El període predeterminat per mantenir l'historial d'elements s'ha fet coherent en 31 dies a la interfície i a la base de dades. Aquest canvi afecta els formularis de configuració de l'element, l'element de plantilla i el prototip d'element, així com la substitució del període d'emmagatzematge de l'historial a la descoberta de baix nivell.
Ara, si es rep un valor de coma flotant per a un element enter sense signe, el valor es retallarà de la part decimal i es desarà com a nombre enter. Abans, un valor de coma flotant feia que un element enter no s'admetés.
S'ha afegit un nou element eventlog.count
a l'agent/agent 2 del Zabbix a Windows. Aquest element retorna un valor enter amb el recompte de línies al registre d'esdeveniments de Windows en funció dels paràmetres especificats.
S'ha afegit un nou element SNMP get[OID]
que permet consultar un únic valor OID de manera asíncrona.
S'ha afegit un nou tipus d'element - Element navegador a Zabbix, que permet el monitoratge de llocs web i aplicacions web complexes mitjançant un navegador. Els elements del navegador permeten l'execució de codi JavaScript definit per l'usuari per simular accions relacionades amb el navegador, com ara fer clic, introduir text, navegar per pàgines web, etc.
Aquest element recopila dades mitjançant HTTP/HTTPS i implementa parcialment l'estàndard W3C WebDriver amb Selenium Server o un WebDriver normal (per exemple, ChromeDriver) com a punt final de prova.
Tingueu en compte que el suport dels elements del navegador és actualment experimental.
A més, aquesta característica afegeix la plantilla Website by Browser i nous elements a l'exportació/importació de configuració, fitxers de configuració del servidor/proxy Zabbix, temps d'espera i la utilitat de línia d'ordres zabbix_js
. Per obtindre més informació, veieu le Notes d'actualització a 7.0.0.
S'han afegit elements interns per monitorar el buffer de memòria proxy:
zabbix[proxy_buffer,buffer,<mode>]
- retorna les estadístiques d'ús de la memòria intermedia del proxy;zabbix[proxy_buffer,state,changes]
- retorna el nombre de canvis d'estat entre els modes de memòria intermèdia de disc/memòria des de l'inici;zabbix[proxy_buffer,state,current]
- retorna l'estat de treball actual on s'emmagatzemen les dades noves.També s'han afegit els següents elements interns:
zabbix[discovery_queue]
- permet controlar el nombre de comprovacions de escoberta a la cua;zabbix[vps,written]
- permet controlar el nombre total de valors de l'historial escrits a la base de dades.S'han afegit nous elements a l'agent/agent 2 de Zabbix:
net.dns.perf
retorna el nombre de segons dedicats a esperar una resposta d'un servei, cronometrant el net.dns
execució de l'element.net.dns.get
L'element Zabbix agent 2 retorna informació detallada del registre DNS.S'han actualitzat els elements següents de l'agent/agent 2 de Zabbix:
net.dns
i net.dns.record
els elements ara accepten el nom DNS en format invertit i no invertit quan es realitzen cerques de DNS inverses;proc.get
en mode "procés" i "resum" també retornen la memòria PSS (mida proporcional conjunta) a Linux;system.sw.packages
i system.sw.packages.get
ara són compatibles amb Gentoo Linux;system.hostname
ara pot retornar un nom de domini totalment qualificat, si la nova opció fqdn s'especifica a tipus paràmetre;wmi.get
i wmi.getall
els elements utilitzats amb l'agent Zabbix 2 ara retornen JSON amb valors booleans representats com a cadenes (per exemple, "RealTimeProtectionEnabled": "True"
en lloc de "RealTimeProtectionEnabled": true
retornat anteriorment) per coincidir amb el format de sortida d'aquests elements a l'agent Zabbix;oracle.ts.discovery
L'element Zabbix agent 2 ara retorna un nou {#CON_NAME} macro LLD amb nom del contenidor;oracle.ts.stats
L'element Zabbix agent 2 té un nou paràmetre conname per especificar el nom del contenidor de destinació. S'ha actualitzat el format JSON de les dades retornades. Quan no s'especifica tablespace, type o conname als paràmetres clau, les dades retornades inclouran un nivell JSON addicional amb el nom del contenidor, que permetrà diferenciar els contenidors.L'element vmware.eventlog
ara admet el filtrat opcional per gravetat al tercer paràmetre.
L'element vmware.vm.discovery
ara també retorna dades a les interfícies de xarxa de màquines virtuals. Aquestes dades es poden emprar per configurar [interfícies d'amfitrió] personalitzades (/manual/discovery/low_level_discovery/host_prototypes#host-interfaces).
L'element vmware.vm.net.if.discovery
ara també retorna una matriu de xarxa adreces de la interfície.
S'ha afegit un nou paràmetre opcions als elements següents:
Aquest paràmetre es pot emprar per especificar si les respostes redireccionades s'han de tractar com a equip destí actiu o com a equip destí caigut. Veieu comprovacions simples per a més detalls.
Els identificadors del motor a SNMPv3 s'utilitzen com a identificadors únics del dispositiu. De vegades, els identificadors del motor són els mateixos en diversos dispositius a causa d'una configuració incorrecta o de la configuració de fàbrica. Com que els estàndards SNMP requereixen que els identificadors de motor siguin únics, els elements que comparteixen el mateix identificador de motor no s'admeten a Zabbix, provocant problemes de disponibilitat amb aquests dispositius.
Per ajudar a solucionar aquests problemes, el servidor Zabbix registrarà periòdicament la informació sobre els dispositius SNMPv3 que comparteixen el mateix ID de motor. Tingueu en compte que la detecció d'ID de motor duplicada funciona a cada sondador SNMP per separat.
Cada element estàndard ara té un enllaç directe des de la interfície a la seva pàgina de documentació.
Els enllaços es col·loquen sota la icona del signe d'interrogació, quan s'obre la finestra d'ajuda d'elements des del formulari de configuració de l'element (feu clic a Triar al costat del camp de la clau de l'element).
La gestió d'errors en cas de fallada per recuperar el valor d'un element (i, per tant, no s'admetia) anteriorment no tenia la capacitat de distingir el motiu o l'etapa d'execució on el procés fallava. Tots els errors s'havien de gestionar mitjançant una mateixa opció per a la gestió d'errors, ja sigui per descartar el valor, establir un valor especificat o establir un missatge d'error especificat.
Ara és possible fer coincidir el missatge d'error amb una expressió regular. Si l'error coincideix (o no coincideix), és possible especificar com s'ha de processar el cas d'error. Per exemple, un missatge d'error específic es pot "assignar" a un cas més general per fer-lo coincidir i tractar-lo mitjançant un pas de preprocessament addicional, o algun problema intermitent (per exemple, la connectivitat de la xarxa) es pot gestionar de manera diferent a un error definitiu per adquirir el valor de l'article.
Ara es poden afegir diversos passos de preprocessament Comprovar si no és compatible. Tingueu en compte que només hi pot haver un pas de coincidència de "qualsevol error" al final de la investigació de la canalització de l'estat no compatible de l'element. Si és present, s'activa si cap de les comprovacions específiques (mal) coincideix amb el patró corresponent, o si s'ha transmès un missatge d'error (modificat), és a dir, no ha tingut efecte cap anul·lació de "Descartar valor" o "Establir valor a".
Vegeu també: Comproveu el valor no admès
El disseny anterior del formulari d'actualització massiva d'articles no era prou clar si l'actualització de la passa de preprocessament afegiria o substituiria les passes de preprocessament. En el nou disseny Reemplaçar i Esborrar-ho tot s'han afegit botons d'opció, que deixen clar als usuaris què esperar com a resultat de la passa de preprocessament actualització massiva:
Les macros d'usuari ara són compatibles amb els noms d'elements i els noms dels prototips d'elements.
Tingueu en compte que el suport de macros d'usuari es va treure dels noms de prototips d'elements/elements a Zabbix 6.0. Ara s'ha restaurat. Ara també s'admet per cercar el nom de l'element amb les macros resoltes, que abans no era compatible.
El nom de l'element amb macros resoltes s'emmagatzema en una taula de base de dades independent ('item_rtname'), que és una extensió de la taula d'elements. Per a cada registre de la taula d'elements, es crea un registre item_rtname
corresponent (excepte per als prototips d'elements, els elements de regles de descobriment i els elements de plantilla). El nom amb macros resoltes és limitat a 2048 caràcters.
El nom de l'element amb macros resoltes es mostra a totes les ubicacions de la interfície excepte a la secció Recull de dades.
S'ha afegit un nou procés de servidor "configuration syncer worker" que s'encarrega de resoldre i sincronitzar els valors de macro d'usuari als noms dels elements.
Les funcions de macro ara s'admeten amb tot tipus de macros:
Les funcions de macro es poden emprar a totes les ubicacions que admeten les macros enumerades. Això s'aplica tret que s'indiqui explícitament que només s'espera una macro (per exemple, quan es configuren macros d'equips o filtres de regla de descoberta de baix nivell).
La funcionalitat informes programats ja no és experimental.
Per als taulers de control de diverses pàgines, ara es tornen els informes amb totes les pàgines del tauler, amb cada pàgina PDF corresponent a una pàgina del tauler. Abans, aquesta funcionalitat es limitava a retornar només la primera pàgina del tauler.
Ara és possible executar ordres remotes en un agent de la versió 7.0 que està operant en mode actiu. Una vegada que l'execució d'una ordre remota s'activa mitjançant una acció d'operació o una execució manual d'un script, l'ordre s'inclourà a la configuració de comprovacions actives i s'executarà un cop l'agent actiu la rebi. Tingueu en compte que els agents actius més antics ignoraran les ordres remotes incloses a la configuració de comprovacions actives. Per obtindre més informació, veieu Comprovacions d'agents passius i actius.
El processament de les etiquetes retornades per l'script webhook ara també és compatible amb esdeveniments interns.
A més, les macros {EVENT.TAGS.<nom de l'etiqueta>}, {EVENT.TAGS}, {EVENT.TAGSJSON}, {EVENT.RECOVERY.TAGS}, {EVENT.RECOVERY.TAGSJSON} ara s'admeten per a les notificacions d'esdeveniments interns .
Aquests canvis permeten emprar webhooks per actualitzar o tancar un bitllet de problema/assistència externa mitjançant una notificació interna de recuperació d'esdeveniments.
La taula auditlog
s'ha convertit a hipertaula a TimescaleDB a noves instal·lacions, per aprofitar el particionat automàtic en temps (7 dies, per defecte) i un millor rendiment.
Per actualitzar correctament les instal·lacions existents, veieu actualitzant l'esquema de TimescaleDB.
Veieu també: Versions de TimescaleDB admeses.
Els registres de proxy s'han mogut fora de la taula "equips" i ara s'emmagatzemen a la nova taula proxy
.
A més, les dades operatives dels proxys (com ara el darrer accés, la versió, la compatibilitat) s'han mogut de la taula host_rtdata
i ara s'emmagatzemen a la nova taula proxy_rtdata
.
S'han fet diversos canvis com a part de la transició a una arquitectura multiprocés:
--with-stacksize
. Aquest paràmetre permet anul·lar la mida de pila de fils predeterminada que utilitza el sistema (en kilooctets).Les funcions de la biblioteca cURL anteriorment es van detectar en el moment de la creació del servidor, proxy o agent Zabbix. Si s'actualitzaven les característiques de cURL, per fer-ne ús s'havia de recompilar el component Zabbix respectiu.
Ara només cal un reinici perquè les funcions actualitzades de la biblioteca cURL estiguin disponibles a Zabbix. La recompilació ja no és necessària. Això és cert per al servidor, el proxy o l'agent Zabbix.
Consulteu també les notes d'actualització.
Els fitxers de configuració zabbix_server.conf i zabbix_proxy.conf s'han complementat amb un nou paràmetre opcional Vault Prefix
; zabbix.conf.php s'ha complementat amb l'opció $DB['VAULT_PREFIX']
, i setup.php s'ha actualitzat en conseqüència.
Per tant, els camins de volta per a CyberArk i HashiCorp ja no estan codificats per permetre desplegaments de volta amb camins no estàndard.
Mida del buffer
El valor predeterminat del paràmetre de configuració BufferSize per a l'agent Zabbix 2 s'ha augmentat de 100 a 1000.
Valors buits permesos
Els valors buits ara es permeten als paràmetres de configuració relacionats amb els connectors a l'agent Zabbix 2.
L'antic estil de valors de coma flotant, anteriorment obsolet, ja no s'admet, ja que s'utilitzen valors numèrics d'interval estès.
Anteriorment, cada regla de descobriment de xarxa era processada per un procés de descoberta. Per tant, només es podrien realitzar totes les comprovacions de servei dins de la regla seqüencialment.
A la nova versió, el procés de descoberta de la xarxa s'ha reelaborat per permetre la concurrència entre les comprovacions del servei. S'ha afegit un nou procés de gestor de descobriment juntament amb un nombre configurable de treballadors de descoberta (o fils).
El gestor de descobertaprocessa les regles de descobertai crea un treball de descoberta per cada regla amb tasques (comprovacions de servei). Les comprovacions del servei són recollides i realitzades pels treballadors de la descoberta. Només les comprovacions que tenen la mateixa IP i port ho són programat de manera seqüencial perquè és possible que alguns dispositius no permetin connexions simultànies al mateix port.
Un nou element intern zabbix[discovery_queue]
permet controlar el nombre de comprovacions de descoberta a la cua.
El paràmetre StartDiscoverers ara determina el nombre total de treballadors de descoberta disponibles per al descobriment. El nombre predeterminat de StartDiscoverers s'ha augmentat d'1 a 5 i l'interval de 0-250 a 0-1000. Els processos "descoberta" de versions anteriors de Zabbix s'han esborrat.
Addicionalment:
Ara hi ha operacions addicionals disponibles per a esdeveniments de descoberta i registre automàtic:
Les regles de descoberta de baix nivell ara poden enllaçar grups d'equips ja trobats i existents amb equips creats per les mateixes regles de descoberta de baix nivell. Això afecta els grups d'equips descoberts i creats prèviament per altres regles de descoberta de baix nivell basades en els [prototips de grup] especificats (/manual/discovery/low_level_discovery/host_prototypes#configuration).
La funcionalitat streaming de dades ja no és experimental.
Quan es transmeten valors d'element des de Zabbix a sistemes externs, ara podeu configurar quins valors d'element ha de transmetre el connector en funció del seu tipus d'informació (numèrica (sense signar), numèrica (flotant), caràcter, etc.).
A més, per evitar intents infructuosos de transmetre valors o esdeveniments d'elements (per exemple, si el punt final HTTP és ocupat o amb un ritme limitat), ara també podeu configurar l'interval d'intents: quant de temps hauria d'esperar el connector després d'un intent de transmissió fallit. dades.
Els codis de resposta HTTP 201, 202, 203 i 204 ara també s'admeten pels connectors com a èxit (abans només 200).
Una nova eina per a transmisió de dades a sistemes externs: el connector Kafka per al servidor Zabbix /browse) - ara és disponible. El connector Kafka és un servidor lleuger escrit en Go, dissenyat per reenviar valors i esdeveniments d'elements des d'un servidor Zabbix a un corredor de Kafka.
Per obtindre plantilles noves i canvis a les existents, veieu Canvis a la plantilla.
Ara es pot emprar l'Autenticació multifactor (MFA) amb mot de pas únic basat en el temps (TOTP) o mètode d'autenticació Duo Universal Prompt per iniciar la sessió a Zabbix, proporcionant una capa addicional de seguretat més enllà d'un nom d'usuari i un mot de pas.
Les visualitzacions de data i hora a la interfície ara s'ajusten a la visualització de data i hora estàndard dels EUA quan s'empra l'idioma d'interfície predeterminat (en_US).
Abans | Ara |
---|---|
Anteriorment era possible Clonar i Clonar sencer equips, templates i mapes.
Ara s'ha esborrat l'opció Clonar i l'opció Clonar sencer s'ha canviat de nom a Clonar tot conservant tota la funcionalitat anterior de Clonar sencer.
Totes les icones de la interfície s'han canviat dels fulls d'imatges d'icones als tipus de lletra.
Ara s'obren diversos formularis d'interfície en finestres modals (emergents):
Les caselles de selecció Configuració avançada, responsables de mostrar les opcions de configuració avançades, s'han substituït per blocs plegables (veieu, per exemple, Configuració del connector, Configuració del servei, Clock widget configuration, etc.). Això millora l'experiència de l'usuari, ja que col·lapsar aquests blocs i desar la configuració ja no restablirà les opcions avançades configurades als seus valors predeterminats.
La secció de menú per visualitzar els triggers principals ara s'anomena Els 100 triggers principals. S'ha afegit la possibilitat de filtrar els triggers pel nom del problema i les etiquetes. A més, ara es mostra el nombre de problemes detectats en comptes del nombre de canvis d'estat per a cada trigger.
Camps d'URL
El límit de caràcters per a tots els camps d'URL és ara de 2048 caràcters. Ara inclou: URL del mosaic per a la configuració relacionada amb mapes geogràfics, URL de la portada per configurar diversos paràmetres de la portada, URL per a mapes de xarxa i elements del mapa de xarxa, URL A-C per als camps inventari d'amfitrió, i URL per al giny del tauler d'URL.
Camps d'autenticació
El límit de caràcters per als camps d'autenticació Nom d'usuari/usuari i Contrasenya és ara de 255 caràcters. Això s'aplica a la configuració de l'autenticació HTTP per a elements agent HTTP, escenaris web i connectors, així com configurar l'autenticació per a comprovacions simples, Monitoratge ODBC, Comprovacions SSH, Comprovacions de Telnet, i Monitoratge JMX.
Quan provem elements o provem passes de preprocessament, els valors recuperats d'un equip i els resultats de la prova es trunquen a la mida màxima de 512Ko quan s'envia a la interfície. Tingueu en compte que les dades de més de 512Ko encara es processen completament pel servidor Zabbix.
Tots els taulers de control de l'amfitrió per a l'equip triat es mostren ara com a pestanyes a la capçalera de la pàgina dels taulers d'equip, substituint el menú desplegable anterior a l'extrem superior dret. Això permet una transició fàcil entre diversos taulers d'equips i millora la navegació a través de les dades de monitoratge.
A Administració → Registre d'auditoria, ara podeu habilitar/desactivar el registre d'auditoria de les activitats de descoberta de baix nivell, descobriment de xarxa i registre automàtic realitzades pel servidor (System user).
El període predeterminat d'emmagatzematge dels registres d'auditoria abans que siguin esborrats per la neteja ha passat de 365 dies a 31 dies.
A Monitoratge → Dades recents, el subfiltre i les dades ja no es mostren de manera predeterminada si el filtre no és configurat.
Si actualitzeu des de versions anteriors de Zabbix, consulteu també: Notes d'actualització per a 7.0.0.
La versió mínima requerida de PHP ha pujat de la 7.4.0 a la 8.0.0.
S'ha afegit un nou connector per al monitoratge directe de Ember+ per part de l'agent Zabbix 2.
Per a més informació, consulteu:
Els [paquets d'instal·lació] (/manual/installation/install_from_packages/rhel) dedicats estan disponibles per a les versions 8 i 9 d'AlmaLinux, CentOS Stream, Oracle Linux i Rocky Linux. Abans, els paquets d'instal·lació eren únics per a les distribucions basades en RHEL i RHEL. Ara s'empren paquets separats per a RHEL i cadascun dels seus derivats esmentats anteriorment per evitar possibles problemes d'incompatibilitat binària.
Els paquets d'instal·lació ARM64/AArch64 ja són disponibles per a Debian, RHEL 8, 9 i els seus derivats, així com SLES/OpenSUSE Leap 15.