Vi er glade for å dele nyheten om at det har blitt lansert et gratis overvåkningssystem med åpen kildekode. Zabbix 4.2!

Er versjon 4.2 svaret på det viktigste spørsmålet om livet, universet og overvåkning generelt? La oss ta en titt!

La oss huske at Zabbix er et allsidig system for overvåking av ytelsen og tilgjengeligheten til servere, ingeniør- og nettverksutstyr, applikasjoner, databaser, virtualisering, containere, IT-tjenester og nettjenester.

Zabbix implementerer hele syklusen fra datainnsamling, bearbeiding og transformering, analyse av mottatte data, til lagring, visualisering og sending av varsler med bruk av eskaleringsregler. Systemet gir også fleksible muligheter for å utvide metoder for datainnsamling og varsling, samt muligheter for automatisering via API. Ett enkelt webgrensesnitt gir sentralisert administrasjon av overvåkningskonfigurasjoner og fordeling av tilgangsrettigheter til ulike brukergrupper. Koden til prosjektet distribueres fritt under lisens GPLv2.

Zabbix 4.2 er en ny versjon som ikke er LTS, med kortere offisiell støtte. Vi anbefaler LTS-versjoner som 3.0 og 4.0 for brukere som satser på en lang produktlivssyklus.

Så, la oss snakke om nyhetene og de viktigste forbedringene i versjon 4.2:

Flere offisielle plattformer

I tillegg til de allerede eksisterende offisielle pakkene, tilbyr vi også nye distribusjoner for:

RaspberryPi, Mac OS/X, SUSE Enterprise Linux Server 12
MSI for Windows-agent
Docker-bilder

Innebygd støtte for Prometheus for overvåking av applikasjoner

Zabbix kan samle data på forskjellige måter (push/pull) fra ulike datakilder. Dette inkluderer JMX, SNMP, WMI, HTTP/HTTPS, RestAPI, XML Soap, SSH, Telnet, agenter og skript og andre kilder. Og nå, møt støtte for Prometheus!

Strengt tatt har datainnsamling fra Prometheus-eksportører vært mulig tidligere takket være typen datainnsamlingsmetoder HTTP/HTTPS og regulære uttrykk.

Imidlertid lar den nye versjonen deg jobbe med Prometheus så effektivt som mulig takket være innebygd støtte for spørringsspråket PromQL. Bruken av avhengige målinger gjør at data kan samles og bearbeides mest effektivt: først henter vi dataene, og deretter organiserer vi dem etter de nødvendige målingene.

Hent verdien av en spesifikk måling

Det er viktig å merke seg at nå lavnivådeteksjon kan bruke innsamlede data for automatisk å lage målinger. I så fall konverterer Zabbix de mottatte dataene til JSON-format, som er veldig praktisk å jobbe med.

Vi finner målinger ved hjelp av filter på PromQL-spørrespråket

For øyeblikket finnes det mer enn 300 integrasjoner og oppskrifter for overvåking av tredjeparts tjenester og applikasjoner ved hjelp av Zabbix. Støtte for Prometheus vil muliggjøre å legge til en hel rekke applikasjoner som har offisielle eller fellesskapsstøttede Prometheus-eksportører. Dette overvåker populære tjenester, containere og skytjenester.

Effektiv høyfrekvent overvåking

Vil vi oppdage problemer så raskt som mulig? Selvfølgelig, ingen tvil! Oftest fører en slik tilnærming til at vi må spørre enhetene for ofte og samle data, noe som fører til større belastning på overvåkingssystemet. Hvordan kan vi unngå dette?

Vi har implementert en mekanisme for throttling i preprocessing-reglene. Throttling gir oss i hovedsak muligheten til å overse like verdier.

La oss anta at vi overvåker tilstanden til en kritisk applikasjon. Hver sekund sjekker vi om applikasjonen vår fungerer eller ikke. I Zabbix kommer det en kontinuerlig strøm av data som representerer 1 (fungerer) og 0 (fungerer ikke). For eksempel: 1111111111110001111111111111...

Når applikasjonen vår er i orden, kommer det bare 1-ere til Zabbix. Må vi behandle dem? Egentlig ikke, for vi er bare interessert i endringen av applikasjonens tilstand, vi ønsker ikke å samle og lagre så mye data. Så throttling gjør det mulig å overse verdien hvis den er lik den forrige. Til slutt vil vi bare få data om endringer i tilstanden, for eksempel 01010101... Det er mer enn nok informasjon for å oppdage problemer!

Zabbix ignorerer rett og slett de glemte verdiene, de registreres ikke i historikken og påvirker ikke utløserne. Fra Zabbix' synspunkt eksisterer det ingen glemte verdier.

Ignorerer gjentatte verdier

Flott! Nå kan vi spørre enhetene veldig ofte, samtidig som vi umiddelbart oppdager problemer uten å lagre unødvendig informasjon i databasen.

Hva med grafene? De vil jo være tomme på grunn av mangel på data! Og hvordan kan man forstå om Zabbix samler inn data når de fleste av dataene vil bli utelatt?

Vi har tenkt på dette også! Zabbix tilbyr en annen type throttling, throttling med hjerteminutt (throttling with heartbeat).

Vi sjekker hvert minutt om målingen lever.

I dette tilfellet vil Zabbix, til tross for en gjentatt strøm av data, lagre minst én verdi innen den angitte tidsperioden. Hvis dataene samles inn hvert sekund, og tidsintervallet er satt til ett minutt, vil Zabbix konvertere den sekundære strømmen av ett-tall til en minutts strømming. Det er ikke vanskelig å se at dette fører til en 60 ganger komprimering av innsamlede data.

Nå kan vi være sikre på at dataene samles inn, nodata()-triggeren fungerer, og grafene er i orden!

Validering av innsamlede data og feilbehandling.

Ingen av oss ønsker å samle feilaktige eller unøyaktige data. For eksempel vet vi at temperatursensoren skal returnere data i området 0°C til 100°C, og enhver annen verdi skal betraktes som feilaktig og/eller ignoreres.

Dette er nå mulig med innebygde preprosessregler for datavalidering i samsvar med eller mangel på samsvar med regulære uttrykk, verdier, JSONPath og XMLPath.

Nå kan vi styre reaksjonen på feil. Hvis temperaturen er utenfor området, kan vi bare ignorere denne verdien, sette en standardverdi (for eksempel 0°C), eller definere vår egen feilmelding, som «Sensoren er skadet» eller «Bytt batteri».

Temperaturen bør være mellom 0 og 100, øvrig ignoreres.

Et godt eksempel på å bruke validering er muligheten til å sjekke inngangsdata for tilstedeværelsen av en feilmelding og sette denne feilen for hele målingen. Dette er en svært nyttig funksjonalitet når man henter data fra eksterne API-er.

Enhver datatransformasjon med JavaScript.

Hvis vi ikke er fornøyde med de innebygde preprosessreglene, tilbyr vi nå full frihet med bruk av vilkårlige skripter i JavaScript!

Bare én linje med kode for å konvertere grader Fahrenheit til grader Celsius.

Dette åpner opp for ubegrensede muligheter for behandling av innkommende data. Den praktiske nytten av denne funksjonaliteten er at vi ikke lenger trenger eksterne skript som vi tidligere brukte for enhver form for databehandling. Nå kan alt dette gjøres med JavaScript.

Nå er datatransformasjon, aggregering, filtrering, aritmetiske og logiske operasjoner og mye mer mulig!

Vi henter ut nyttig informasjon fra Apache mod_status!

Vi tester forbehandling

Nå trenger vi ikke lenger å gjette hvordan våre komplekse forbehandlingsscenarier fungerer. Det er blitt en praktisk sjekk av korrektheten ved forbehandling direkte fra grensesnittet!

Vi behandler millioner av metrikker i sekundet!

Før Zabbix 4.2 ble forbehandlingen utelukkende håndtert av Zabbix-serveren, noe som begrenset mulighetene for bruk av proxyer for lastfordeling.

Fra og med Zabbix 4.2 får vi utrolig effektiv lastskalaering ved å støtte forbehandling på proxiesiden. Nå håndterer proxyene dette!

I kombinasjon med throttling gjør denne tilnærmingen det mulig å utføre høyfrekvent storskalamonitorering og utføre millioner av sjekker i sekundet, uten å overbelaste den sentrale Zabbix-serveren. Proxyene behandler enorme datamengder, og det som når Zabbix-serveren er bare en liten del, på en til to ordener mindre, takket være throttlingen.

Mer enkel lavnivådeteksjon

La oss minne om at lavnivådeteksjon (LLD) er en svært kraftig mekanisme for automatisk oppdagelse av alle typer ressurser for overvåking (filsystemer, prosesser, applikasjoner, tjenester, osv.) og automatisk oppretting av dataverdier, triggere, nettverksnoder og andre objekter basert på dem. Dette sparer utrolig mye tid, forenkler konfigurasjonen og gjør det mulig å bruke én mal for nettverksnoder med ulike overvåkingsressurser.

Lavnivådeteksjon krevde spesialformatert JSON som input. Slik er det ikke lenger!

Zabbix 4.2 lar låg-nivå oppdagelse (LLD) bruke vilkårlig utformede data i JSON-format. Hvorfor er dette viktig? Det gjør det mulig å kommunisere med for eksempel eksterne API uten å måtte ty til skripter og bruke informasjonen som blir hentet for automatisk å opprette nettverksnoder, datakomponenter og triggere.

I kombinasjon med støtte for JavaScript skaper dette fantastiske muligheter for å lage maler for arbeid med ulike datakilder, som for eksempel sky-API-er, applikasjons-API-er, data i XML-, CSV- og andre formater.

Kobler JSON med prosessinformasjon via LLD

Mulighetene er virkelig uendelige!

Støtte for TimescaleDB

Hva er TimescaleDB? Det er vanlig PostgreSQL pluss en utvidelsesmodul fra TimescaleDB-teamet. TimescaleDB lover bedre ytelse ved hjelp av mer effektive algoritmer og datainfrastrukturer.

I tillegg er en annen fordel med TimescaleDB automatisk partisjonering av historikk-tabeller. TimescaleDB gir fart og enkel vedlikehold! Selv om jeg må påpeke at teamet vårt ennå ikke har gjennomført en grundig sammenligning av ytelse med vanlig PostgreSQL.

Per nå er TimescaleDB et ganske ungt og raskt voksende produkt. Bruk med forsiktighet!

Enkel styring av etiketter

Tidligere kunne etiketter kun styres på nivået av triggere, men nå er styringen av etiketter mye mer fleksibel. Zabbix støtter etiketter for maler og nettverksnoder!

Alle oppdagede problemer får etiketter fra både triggeren og nettverksnode, samt malene til denne nettverksnoden.

Definerer etiketter for nettverksnoden

Mer fleksibel automatisk registrering

Zabbix 4.2 lar deg filtrere nettverksnoder etter navn ved hjelp av regulære uttrykk. Dette gir muligheten til å lage forskjellige oppdagelsesscenarier for ulike grupper av nettverksnoder. Spesielt nyttig når vi bruker komplekse navngivingsregler for enheter.

Mer fleksibel nettverksoppdagelse

En annen forbedring er knyttet til navngivning av nettverksnoder. Det har blitt mulig å styre enhetsnavn ved nettverksoppdagelse og å hente enhetsnavn fra verdien av en metrikk.

Dette er en svært nyttig funksjonalitet, spesielt ved nettverksoppdagelse med SNMP og Zabbix-agent.

Automatisk tilordne et lokalt navn til nettverksnoden som det synlige navnet

Sjekk om varslingsmetodene fungerer

Nå kan du sende deg selv en testmelding direkte fra nettgrensesnittet og sjekke om varslingsmetoden fungerer. Denne funksjonaliteten er spesielt nyttig for å teste Zabbix-skripter med ulike varslingssystemer, oppgavehåndteringssystemer og andre eksterne programmer og API-er.

Fjernovervåking av Zabbix-infrastrukturkomponenter

Det er nå mulig med fjernovervåking av interne mål på Zabbix-serveren og proxyene (ytelses- og driftsstatusmål for Zabbix-komponenter).

Hvorfor er dette nødvendig? Funksjonaliteten gjør det mulig å overvåke interne mål på servere og proxyer fra utsiden, og lar deg raskt oppdage og varsle om problemer selv om selve komponentene er overbelastet eller, for eksempel, hvis det er en stor mengde usendte data på proxyen.

Støtte for HTML-format i e-postmeldinger

Nå er vi ikke begrenset til vanlig tekst og kan lage flotte e-postmeldinger takket være støtten for HTML-format. Det er på tide å lære HTML + CSS!

Meldinger er lettere å oppfatte, selv med minimal bruk av HTML

Tilgang til eksterne systemer fra nettverkskart

Støtten for en hel rekke nye makroer i brukerdefinerte URL-er har kommet for bedre integrering av kart med eksterne systemer. Dette gjør det mulig å åpne en oppgave i oppgavehåndteringssystemet med ett eller to klikk på nettverksnoden.

Åpne en oppgave i Jira med ett klikk

Oppdagelsesregler kan være avhengige datakomponenter

Hvorfor er dette nødvendig, spør du kanskje. Dette gjør det mulig å bruke data fra hovedmålet både til oppdagelse og direkte datainnsamling. For eksempel, når man samler inn data fra Prometheus-eksportøren, vil Zabbix utføre en HTTP-forespørsel én gang og umiddelbart bruke den innhentede informasjonen for alle avhengige datakomponenter: målverdier og regler for lavnivåoppdagelse.

Ny måte å visualisere problemer på kartene

Støtten for animerte GIF-bilder på kartene er nå tilgjengelig for bedre visualisering av problemer.

Problematisk utstyr har blitt mer synlig

Hent data fra HTTP-headere i Web-overvåking

Web-overvåkingen har fått muligheten til å velge data fra mottatt HTTP-header.

Dette gjør det mulig å lage flertrinns web-overvåking eller overvåking av tredjeparts API-er, ved å bruke en autoriseringstoken oppnådd i et av trinnene.

Vi henter AuthID fra HTTP-headere

Zabbix Sender bruker alle IP-adresser

Zabbix Sender sender nå data til alle IP-adresser fra parameteren ServerActive i agentens konfigurasjonsfil.

Praktisk ny filter i konfigurasjonen av triggere

Siden for konfigurasjon av triggere har fått et utvidet filter for rask og enkel seleksjon av triggere i henhold til gitte kriterier.

Vi velger triggere relatert til K8S-tjenesten

Vi viser nøyaktig tid

Her er det enkelt, nå viser Zabbix nøyaktig tid når du holder musen over grafen.

Andre nyheter

Implementert en mer forutsigbar algoritme for å endre rekkefølgen på widgetene i dashbordet.
Mulighet for masseendring av prototypeparametere for datakomponenter
Støtte for IPv6 for DNS-sjekker: «net.dns» og «new.dns.record»
En ny parameter «skip» lagt til for sjekkene «vmware.eventlog»
Feil ved preprocesseringstrinn inkluderer trinnnummer

Hvordan oppdatere?

For å gå over fra tidligere versjoner er det bare nødvendig å installere de nye binærfilene (servere og proxy) og det nye grensesnittet. Zabbix vil automatisk utføre oppdateringsprosedyren for databasen. Ingen ny agentinstallasjon vil være nødvendig.

Vi holder gratis webinarer for de som ønsker å lære mer om Zabbix 4.2 og få mulighet til å stille spørsmål til Zabbix-teamet. Meld deg på!

Ikke glem den populære Telegram-kanalen til Zabbix-fellesskapet, hvor du alltid kan få råd og svar på spørsmål på russisk fra mer erfarne kolleger, og hvis du er heldig, fra selve Zabbix-utviklerne. For nybegynnere anbefaler vi gruppa for nybegynnere.