Ved å lage en løsning for en klient dukket det opp 2 oppgaver som jeg ønsket å løse vakkert og med vanlig Zabbix-funksjonalitet.
1 utfordring. Sporing av gjeldende fastvareversjon på Mikrotik-rutere.
Oppgaven løses enkelt – ved å legge til en agent i HTTP-malen. Agenten mottar den gjeldende versjonen fra Mikrotik-nettstedet, og utløseren sammenligner den gjeldende versjonen med den gjeldende og gir et varsel i tilfelle avvik.
Når man har 10 rutere er ikke en slik algoritme kritisk, men hva skal man gjøre med 3000 rutere? Sende 3000 forespørsler til serveren? Selvfølgelig vil en slik ordning fungere, men selve ideen om 3000 forespørsler passet ikke meg, jeg ønsket å finne en annen løsning. I tillegg var det fortsatt en ulempe med en slik algoritme: den andre siden kan telle så mange forespørsler fra én IP for et DoS-angrep, de kan ganske enkelt forby det.
2 utfordring. Bruke en autorisasjonsøkt i forskjellige HTTP-agenter.
Når en agent trenger å motta informasjon fra "lukkede" sider via HTTP, er det nødvendig med en autorisasjonsinformasjonskapsel. For å gjøre dette, er det vanligvis et standard autorisasjonsskjema med et "pålogging / passord"-par og innstilling av økt-ID i informasjonskapselen.
Men det er et problem, det er umulig å få tilgang til dataene til et annet element fra ett HTTP-agentelement for å erstatte denne verdien i overskriften.
Det er også et "Web script", det har en annen begrensning, det lar deg ikke få innhold for analyse og videre lagring. Du kan bare sjekke tilstedeværelsen av de nødvendige variablene på sidene eller sende tidligere innhentede variabler mellom webskripttrinn.
Etter å ha tenkt litt over disse oppgavene bestemte jeg meg for å bruke makroer som er perfekt synlige i alle deler av overvåkingssystemet: i maler, verter, utløsere eller elementer. Og du kan oppdatere makroer gjennom webgrensesnittets API.
Zabbix har god og detaljert API-dokumentasjon. For datautveksling via api brukes Json-dataformatet. Detaljer finner du i .
Sekvensen av handlinger for å skaffe dataene vi trenger og registrere dem i en makro er vist i diagrammet nedenfor.
Trinn 1
Det aller første trinnet kan bestå av en enkelt handling eller flere handlinger. All hovedlogikken legges i de første trinnene, og de siste 3 trinnene er de viktigste.
I mitt eksempel var det første trinnet å få autorisasjonsinformasjonskapsler på PBX for den første oppgaven. For den andre oppgaven fikk jeg nummeret til den gjeldende versjonen av Mikrotik-fastvaren.
URL til gjeldende versjoner av Mikrotik-fastvaren
- - URL-adresse til gjeldende stabile versjon
- — URL-adresse til gjeldende LTS-versjon
Disse adressene får tilgang til selve Mikrotik-utstyret når den siste tilgjengelige fastvareversjonen mottas.
Det første trinnet er helt individuelt for hvert tilfelle, og logikken i arbeidet kan være forskjellig. Alt avhenger av oppgaven din.
Når du jobber med webskripting, hold styr på hvilken responsmetode du trenger. Titler HTTP-svar eller selv тело svar uten overskrifter?
Hvis autorisasjonsinformasjonskapsler er nødvendig, angir du svarmetoden Titler som i tilfellet med Asterisk.Hvis du trenger data, som i tilfellet med mikrotik-serversvaret, sett kroppen svar uten overskrifter.
Trinn 2
La oss gå videre til det andre trinnet. Få en autorisasjonsøkt:
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc": "2.0",
"method": "user.login",
"params": {
"user": "Admin"
"password": "zabbix"
},
"id": 1,
"auth": null
}jsonrpc er versjonen av JSON-RPC-protokollen som brukes;
Zabbix implementerer JSON-RPC versjon 2.0;
- metode - metoden som kalles;
- params - parametere som sendes av metoden;
- id er en vilkårlig forespørselsidentifikator;
- auth - brukerautentiseringsnøkkel; siden vi ikke har det ennå, la oss sette det til null.
For å jobbe med APIen opprettet jeg en egen konto med begrensede rettigheter. For det første trenger du ikke gi tilgang til der du ikke trenger det. Og for det andre, før versjon 5.0, kunne passordet satt gjennom makroen leses. Følgelig, hvis du bruker Zabbix-administratorpassordet, er admin-kontoen lett å stjele.
Dette vil være spesielt sant når du arbeider med API gjennom tredjeparts skript og lagrer legitimasjon på siden.
Siden versjon 5.0 er det et alternativ for å skjule passordet som er lagret i makroen.
Når du oppretter en egen konto for oppdatering av data via API, må du sørge for å sjekke om dataene du trenger er tilgjengelige gjennom nettgrensesnittet og om det er mulig å oppdatere det. Jeg sjekket ikke, og da kunne jeg i lang tid ikke forstå hvorfor makroen jeg trengte ikke var synlig i API.
Etter at vi har mottatt autorisasjon i API, fortsetter vi for å få en liste over makroer.
Trinn 3
API-en tillater deg ikke å oppdatere en vertsmakro etter navn, du må først hente makro-ID. Dessuten, for å få en liste over makroer for en spesifikk vert, må du vite IDen til denne verten, og dette er en ekstra forespørsel. Bruk standard makro {HOST ID} i forespørselen er ikke tillatt. Jeg bestemte meg for å omgå begrensningen slik:
Jeg opprettet en lokal makro med denne vertens ID. Å finne ut verts-IDen er veldig enkelt fra nettgrensesnittet.
Et svar med en liste over alle makroer på en gitt vert kan filtreres etter et mønster:
regex:{"hostmacroid":"([0-9]+)"[A-z0-9,":]+"{$MIKROTIK_VERSION}"
Dermed får vi IDen til makroen vi trenger, hvor MIKROTIK_VERSJON er navnet på makroen vi leter etter. I mitt tilfelle blir makroen søkt MIKROTIK_VERSJONDen som ble tildelt verten.
Selve forespørselen ser slik ut:
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc":"2.0",
"method":"usermacro.get",
"params":{
"output":"extend",
"hostids":"{$HOST_ID}"
},
"auth":"{sid}",
"id":1
}
variabel {sid} oppnådd i det andre trinnet og vil bli brukt konstant, hvor du må jobbe med API-grensesnittet.
Siste 4 TRINN - oppdatering av makroen
Nå vet vi makro-ID-en som må oppdateres, autorisasjonsinformasjonskapselen eller fastvareversjonen til ruteren. Du kan oppdatere selve makroen.
POST http://company.com/zabbix/api_jsonrpc.php HTTP/1.1
Content-Type: application/json-rpc
{
"jsonrpc":"2.0",
"method":"usermacro.update",
"params":{
"hostmacroid":"{hostmacroid}",
"value":"{mikrotik_version}"
},
"auth":"{sid}",
"id":1
}
{mikrotik_version} er verdien oppnådd i det første trinnet. I mitt eksempel, versjonen av gjeldende mikrotik-firmware
{hostmacroid} - verdien ble oppnådd i det tredje trinnet - ID-en til makroen som vi oppdaterer.
Funn
Tilnærmingen til å løse problemet med standardfunksjonalitet er mye mer komplisert og lengre. Spesielt hvis du kan programmering og raskt kan legge til nødvendig logikk i scriptet.
Den åpenbare fordelen med denne tilnærmingen er "portabiliteten" av løsningen mellom forskjellige servere.
For meg personlig er det rart at HTTP-agenten ikke kan få tilgang til dataene til et annet element og erstatte dem i forespørselsteksten eller overskriftene [ ].
Den ferdige malen kan .
Kilde: www.habr.com