Er heerst een bijgeloof in de IT: “Als het werkt, raak het dan niet aan.” Dit kan gezegd worden over ons monitoringsysteem. Bij Southbridge gebruiken we Zabbix - toen we ervoor kozen, was het erg cool. En feitelijk had hij geen alternatieven.
In de loop van de tijd heeft ons ecosysteem instructies en extra bindingen gekregen en is er integratie met redmine verschenen. Zabbix had een krachtige concurrent die in veel opzichten superieur was: snelheid, HA bijna out-of-the-box, prachtige visualisatie, optimalisatie van het werk in een Kubernethes-omgeving.
Maar we hebben geen haast om verder te gaan. We besloten Zabbix te bekijken en te vragen welke functies ze van plan zijn te maken in de komende releases. We waren niet aanwezig bij de ceremonie en stelden ongemakkelijke vragen aan Sergey Sorokin, ontwikkelingsdirecteur van Zabbix, en Vitaly Zhuravlev, oplossingsarchitect. Lees verder om erachter te komen wat ervan is gekomen.
1. Vertel ons over de geschiedenis van het bedrijf. Hoe is het idee voor het product ontstaan?
De geschiedenis van het bedrijf begon in 1997, toen de oprichter en eigenaar van het bedrijf, Alexey Vladyshev, als databasebeheerder bij een van de banken werkte. Het leek Alexey dat het niet effectief zou zijn om databases te beheren zonder gegevens over de historische waarden van een grote verscheidenheid aan parameters, zonder inzicht in de huidige en historische toestand van de omgeving.
Tegelijkertijd zijn de monitoringoplossingen die momenteel op de markt zijn erg duur, omslachtig en vereisen ze grote middelen. Daarom begint Alexey verschillende scripts te schrijven waarmee hij effectief toezicht kan houden op het deel van de infrastructuur dat hem is toevertrouwd. Het begint een hobby te worden. Alexey verandert van baan, maar de interesse in het project blijft bestaan. In 2000-2001 werd het project helemaal opnieuw geschreven - en Alexey dacht erover om andere beheerders de kans te geven de ontwikkelingen te gebruiken. Tegelijkertijd rees de vraag onder welke licentie de bestaande code zou worden vrijgegeven. Alexey besloot het uit te brengen onder de GPLv2-licentie. De tool werd meteen opgemerkt in een professionele omgeving. Na verloop van tijd begon Alexey verzoeken te ontvangen voor ondersteuning, training en uitbreiding van de mogelijkheden van de software. Het aantal van dergelijke bestellingen groeide voortdurend. Dus natuurlijk kwam de beslissing om een bedrijf op te richten. Het bedrijf werd opgericht op 12 april 2005
2. Welke belangrijke punten kun je benadrukken in de geschiedenis van de ontwikkeling van Zabbix?
Er zijn momenteel verschillende van dergelijke punten:
A. Alexey begon in 1997 aan scripts te werken.
B. Publicatie van de code onder de GPLv2-licentie - 2001.
V. Zabbix werd opgericht in 2005.
d) Sluiting van de eerste partnerschapsovereenkomsten, oprichting van een partnerprogramma - 2007.
d. Oprichting van Zabbix Japan LLC - 2012.
e. Oprichting van Zabbix LLC (VS) - 2015
En. Oprichting van Zabbix LLC - 2018
3. Hoeveel mensen heeft u in dienst?
Op dit moment heeft de Zabbix-bedrijvengroep iets meer dan 70 medewerkers in dienst: ontwikkelaars, testers, projectmanagers, support engineers, consultants, verkopers en marketingmedewerkers.
4. Hoe schrijf je een roadmap, verzamel je feedback van gebruikers? Hoe bepaal je waar je verder naartoe gaat?
Bij het maken van een Roadmap voor de volgende versie van Zabbix concentreren we ons op de volgende belangrijke factoren, meer bepaald verzamelen we Roadmaps volgens de volgende categorieën:
A. Strategische verbeteringen van Zabbix. Iets wat Zabbix zelf erg belangrijk vindt. Bijvoorbeeld de Zabbix-agent geschreven in Go.
B. Dingen die klanten en partners van Zabbix willen zien in Zabbix. En waarvoor ze bereid zijn te betalen.
V. Wensen/suggesties van de Zabbix-gemeenschap.
d)Technische schulden. 🙂 Dingen die we in eerdere versies uitbrachten, maar niet de volledige functionaliteit boden, ze niet flexibel genoeg maakten, niet alle opties boden.
5. Kun je Zabbix en Prometheus vergelijken? Wat is beter en wat is slechter in Zabbix?
Het belangrijkste verschil is naar onze mening dat Prometheus in de eerste plaats een systeem is voor het verzamelen van statistieken - en om volwaardige monitoring in een onderneming te verzamelen, is het noodzakelijk om veel andere componenten aan Prometheus toe te voegen, zoals grafana voor visualisatie, een aparte lange termijn opslag, en apart beheer ergens problemen, apart werken met logs...
Er zullen geen standaard monitoringsjablonen zijn in Prometheus; nadat je alle duizenden statistieken van exporteurs hebt ontvangen, zul je er zelfstandig problematische signalen in moeten vinden. Prometheus instellen - configuratiebestanden. Op sommige plaatsen is het handiger, op andere niet.
Zabbix is een universeel platform voor het creëren van monitoring “van en naar”, we hebben onze eigen visualisatie, correlatie van problemen en hun weergave, distributie van toegangsrechten tot het systeem, audit van acties, veel opties voor het verzamelen van gegevens via een agent, proxy, gebruik makend van totaal verschillende protocollen, de mogelijkheid om het systeem snel uit te breiden met plugins, scripts, modules...
Of u kunt de gegevens eenvoudigweg verzamelen zoals ze zijn, bijvoorbeeld via het HTTP-protocol, en de antwoorden vervolgens omzetten in nuttige statistieken met behulp van voorverwerkingsfuncties zoals JavaScript, JSONPath, XMLPath, CSV en dergelijke. Veel gebruikers waarderen Zabbix vanwege de mogelijkheid om het systeem via een webinterface te configureren en te beheren, vanwege de mogelijkheid om typische monitoringconfiguraties te beschrijven in de vorm van sjablonen die met elkaar kunnen worden gedeeld en die niet alleen statistieken bevatten, maar ook detectieregels. drempelwaarden, grafieken, beschrijvingen - een complete set objecten voor het bewaken van typische objecten.
Veel mensen houden ook van de mogelijkheid om het beheer en de configuratie te automatiseren via de Zabbix API. Over het algemeen wil ik geen holivar organiseren. Het lijkt ons dat beide systemen goed geschikt zijn voor hun taken en elkaar harmonieus kunnen aanvullen. Zabbix kan vanaf versie 4.2 bijvoorbeeld gegevens verzamelen van Prometheus-exporteurs of van zichzelf.
6. Heb je erover nagedacht om zabbix saas te maken?
We hebben erover nagedacht en zullen het in de toekomst doen, maar we willen deze oplossing zo gemakkelijk mogelijk maken voor klanten. In dit geval moet standaard Zabbix worden aangeboden, samen met communicatiemiddelen, geavanceerde hulpmiddelen voor gegevensverzameling, enzovoort.
7. Wanneer kan ik zabbix ha verwachten? Zal ik wachten?
Zabbix HA is zeker een wachttijd. We hopen echt iets te zien in Zabbix 5.0 LTS, maar de situatie zal duidelijker worden in november 2019 wanneer de Zabbix 5.0 Roadmap volledig wordt bevestigd.
8. Waarom heeft het mediatype standaard zo'n slechte selectie? Ben je van plan om Slack, Telegram, etc. toe te voegen? Gebruikt iemand anders Jabber?
Jabber is verwijderd in Zabbix 4.4, maar Webhooks zijn toegevoegd. Wat de mediatypen betreft, zou ik geen specifieke toepassingen van het systeem willen maken, maar standaard berichtentools. Het is geen geheim dat veel soortgelijke chats of bureaudiensten een API via HTTP hebben - dus dit jaar met de release van 4.4 zal de situatie veranderen.
Met de komst van webhooks in Zabbix kun je in de nabije toekomst alle populairste integraties out-of-the-box verwachten. In dit geval zal de integratie tweerichtingsverkeer zijn, en niet slechts eenvoudige eenrichtingsmeldingen. En de mediatypen waar we niet bij kunnen komen, zullen door onze gemeenschap worden gedaan - omdat nu het hele mediatype naar een configuratiebestand kan worden geëxporteerd en op share.zabbix.com of github kan worden geplaatst. En andere gebruikers hoeven het bestand alleen maar te importeren om deze integratie te kunnen gebruiken. In dit geval hoeft u geen extra scripts te installeren!
9. Waarom ontwikkelt de richting voor het ontdekken van virtuele machines zich niet? Er is alleen vmware. Velen wachten op integratie met ec2, openstack.
Nee, de richting ontwikkelt zich. In 4.4 verscheen de detectie van datastores bijvoorbeeld via de sleutel vm.datastore.discovery. In 4.4 verschenen ook hele coole wmi.getall-sleutels - we verwachten dat het hierdoor, samen met de perf_counter_en-sleutel, mogelijk zal zijn om goede Hyper-V-monitoring uit te voeren. Welnu, er zullen nog andere belangrijke veranderingen in deze richting plaatsvinden in Zabbix 5.0.
10. Heb je erover nagedacht om de sjablonen achterwege te laten en het te doen zoals prometeus, wanneer alles wat gegeven is, wordt weggenomen?
Prometheus neemt automatisch alle statistieken over, dit is handig. En een sjabloon is meer dan alleen een set statistieken; het is een ‘container’ die alle noodzakelijke typische configuraties bevat voor het monitoren van een bepaald type bron of dienst. Het beschikt al over een reeks belangrijke triggers, grafieken en detectieregels, het bevat beschrijvingen van statistieken en drempels die de gebruiker helpen begrijpen wat er wordt verzameld, welke drempels worden gecontroleerd en waarom. Tegelijkertijd zijn sjablonen gemakkelijk te delen met andere gebruikers - en krijgen ze een goede monitoring van hun systeem, zelfs zonder er noodzakelijkerwijs een expert in te zijn.
11. Waarom zijn er zo weinig kant-en-klare statistieken? Dit bemoeilijkt ook de installatie aanzienlijk vanuit het oogpunt van de bediening.
Als je kant-en-klare sjablonen bedoelt, dan werken we momenteel aan het uitbreiden en verbeteren van onze sjablonen. Zabbix 4.4 wordt geleverd met een nieuwe, verbeterde set en betere functies.
Voor Zabbix kun je op share.zabbix.com altijd een kant-en-klaar template vinden voor vrijwel elk systeem. Maar we besloten dat we zelf basissjablonen moesten maken, een voorbeeld moesten stellen voor anderen, en gebruikers ook moesten bevrijden van het opnieuw schrijven van een sjabloon voor een of andere MySQL. Daarom zullen er nu in Zabbix bij elke versie alleen maar meer officiële sjablonen zijn.
12. Wanneer wordt het mogelijk om triggers te bouwen die niet gebonden zijn aan hosts, maar bijvoorbeeld op basis van labels. We monitoren bijvoorbeeld een site vanaf n verschillende punten, en we willen een eenvoudige trigger die wordt geactiveerd wanneer de site niet toegankelijk is vanaf 2 of meer punten.
Dergelijke functionaliteit is zelfs al enkele jaren beschikbaar in Zabbix, geschreven voor een van de klanten. Klant - ICANN. Soortgelijke controles kunnen ook worden uitgevoerd, bijvoorbeeld via geaggregeerde items of met behulp van de Zabbix API. We werken er nu actief aan om het creëren van dergelijke controles te vereenvoudigen.
PS: Bij een van de Slurms vroegen Zabbix-ontwikkelaars ons wat we in het product wilden zien om Kubernetes-clusters te monitoren met Zabbix, en niet met Prometheus.
Het is geweldig als ontwikkelaars klanten halverwege ontmoeten en niets voor zichzelf blijven. En nu begroeten we elke release met oprechte belangstelling - het goede nieuws is dat steeds meer functies waar we het over hadden van vlees en bloed worden.
Zolang de ontwikkelaars zich niet in zichzelf terugtrekken, maar geïnteresseerd zijn in de behoeften van klanten, leeft en ontwikkelt het product. We houden nieuwe releases van Zabbix in de gaten.
PPS: Over een paar maanden lanceren we een online monitoringcursus. Bent u geïnteresseerd, schrijf u dan in om de aankondiging niet te missen. In de tussentijd kunt u onze .
Bron: www.habr.com