In de IT is er een bijgeloof: 'Als het werkt, raak het dan niet aan'. Dit kan ook gezegd worden over ons monitorsysteem. Bij Southbridge gebruiken we Zabbix - toen we het kozen, was het echt geweldig. En in wezen waren er geen alternatieven.
In de loop der tijd is ons ecosysteem uitgebreid met handleidingen, extra omhulsels, en er is integratie met Redmine gekomen. Zabbix heeft een krachtige concurrent gekregen die op veel vlakken superieur was: werksnelheid, bijna out-of-the-box HA, mooie visualisatie en optimalisatie voor gebruik in een Kubernetes-omgeving.
Maar we haasten ons niet om over te stappen. We besloten een kijkje te nemen bij Zabbix en te vragen welke functies ze van plan zijn in de komende releases. We waren niet terughoudend en stelden ongemakkelijke vragen aan Sergey Sorokin, de directeur van Zabbix, en Vitaly Zhuravlev, Solution architect. Wat daaruit voortkwam, lees je verderop.
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 oprichter en eigenaar Alexey Vladyshev als databasebeheerder werkte bij een van de banken. Alexey vond het inefficiƫnt om databases te beheren zonder gegevens over historische waarden van verschillende parameters, zonder inzicht in de huidige en historische toestand van de omgeving.
De op dat moment beschikbare monitoringoplossingen op de markt waren erg kostbaar, log en vereisten veel middelen. Daarom begon Alexey verschillende scripts te schrijven die hem in staat stelden om efficiƫnt te monitoren over het hem toevertrouwde deel van de infrastructuur. Dit werd een hobby. Alexey wisselde van baan, maar zijn interesse in het project bleef bestaan. In 2000-2001 werd het project volledig herschreven en Alexey dacht na over hoe hij andere beheerders kon laten profiteren van de ontwikkelingen. Daarbij kwam de vraag op welke licentie de bestaande code moest worden vrijgegeven. Alexey besloot het onder de GPLv2-licentie uit te brengen. Het hulpmiddel werd onmiddellijk opgemerkt in de professionele omgeving. Na verloop van tijd kwamen er verzoeken bij Alexey voor ondersteuning, training en uitbreiding van de softwaremogelijkheden. Het aantal van dergelijke opdrachten groeide voortdurend. Zo kwam op natuurlijke wijze de beslissing om een bedrijf op te richten. Het bedrijf werd opgericht op 12 april 2005.
2. Welke belangrijke mijlpalen kunt u aanwijzen in de ontwikkeling van Zabbix?
Momenteel zijn er verschillende mijlpalen:
a. Het begin van Aleksejs werk aan scripts ā 1997.
b. Publicatie van de code onder de GPLv2-licentie ā 2001.
c. Oprichting van het bedrijf Zabbix ā 2005.
d. Aansluiting van de eerste partnerschappen, oprichting van het partnerprogramma ā 2007.
e. Oprichting van Zabbix Japan LLC ā 2012.
f. Oprichting van Zabbix LLC (USA) ā 2015.
g. Oprichting van LLC Zabbix ā 2018.
3. Hoeveel mensen werken er bij u?
Momenteel werken er iets meer dan 70 medewerkers in de Zabbix-groep: ontwikkelaars, testers, projectmanagers, ondersteuningsingenieurs, consultants, verkopers, marketingmedewerkers.
4. Hoe schrijft u de roadmap, verzamelt u feedback van gebruikers? Hoe bepaalt u de volgende stappen?
Bij het opstellen van de roadmap voor de volgende versie van Zabbix baseren we ons op de volgende belangrijke factoren, of beter gezegd, we verzamelen de roadmap op basis van de volgende categorieƫn:
a. Strategische verbeteringen van Zabbix. Dingen die Zabbix zelf als zeer belangrijk beschouwt. Bijvoorbeeld, de Zabbix-agent geschreven in Go.
b. Dingen die klanten en partners van Zabbix graag in Zabbix willen zien. En waarvoor ze bereid zijn te betalen.
c. Verzoeken/suggesties van de Zabbix-community.
d. Technische schulden. š Zaken die we in eerdere versies hebben uitgebracht, maar niet volledig functioneel hebben gemaakt, niet voldoende flexibel hebben gemaakt, en niet alle opties hebben aangeboden.
5. Kunt u Zabbix en Prometheus vergelijken? Wat is beter aan Zabbix en wat is slechter?
Het belangrijkste verschil, naar onze mening, is dat Prometheus een systeem is dat voornamelijk is gericht op het verzamelen van metrics ā en om een volledige monitoring op een onderneming te realiseren, moeten er veel andere componenten aan Prometheus worden toegevoegd, zoals Grafana voor visualisatie, een aparte long-term opslag, ergens apart problemen beheren, apart werken met logs...
Er zijn ook geen standaard monitoring templates in Prometheus; nadat u alle duizenden metrics van exporters heeft ontvangen, moet u zelf de probleemsignalering daarin vinden. De configuratie van Prometheus gebeurt met configuratiebestanden. Soms is dat handiger, soms niet.
Zabbix is een veelzijdig platform voor het creĆ«ren van monitoring 'van A tot Z', met onze eigen visualisatie, probleemcorrelatie en weergave, toegangsniveaus, actie-audits, tal van gegevensverzamelingsmogelijkheden via agent, proxy en verschillende protocollen, en de mogelijkheid om het systeem snel uit te breiden met plugins, scripts en modulesā¦
Je kunt ook gewoon gegevens verzamelen zoals ze zijn, bijvoorbeeld via het HTTP-protocol, en de antwoorden vervolgens omzetten in bruikbare metrics met functies voor pre-processing zoals JavaScript, JSONPath, XMLPath, CSV en dergelijke. Veel gebruikers waarderen Zabbix omdat ze de mogelijkheid hebben om het systeem te configureren en beheren via een webinterface, en om standaard configuraties voor monitoring te beschrijven in de vorm van sjablonen, die kunnen worden gedeeld en die niet alleen metrics bevatten, maar ook detectieregels, drempelwaarden, grafieken, beschrijvingen ā een complete set objecten voor monitoring van standaardobjecten.
Velen waarderen ook de mogelijkheid om beheer en configuratie te automatiseren via de Zabbix API. We willen eigenlijk geen religieuze strijd voeren. Wij denken dat beide systemen goed passen bij hun taken en elkaar kunnen aanvullen, bijvoorbeeld, Zabbix kan sinds versie 4.2 gegevens verzamelen van Prometheus-exporters of van zichzelf.
6. Hebben jullie nagedacht over het maken van Zabbix als SaaS?
We hebben eraan gedacht en zullen het in de toekomst doen, maar we willen dit zo gebruiksvriendelijk mogelijk maken voor klanten. In dat geval moet de standaard Zabbix worden aangeboden met communicatiehulpmiddelen, uitgebreide gegevensverzamelingsmiddelen, enzovoort.
7. Wanneer kunnen we Zabbix HA verwachten? En moeten we het verwachten?
Zabbix HA staat zeker op de planning. We hopen echt iets te zien in Zabbix 5.0 LTS, maar de situatie zal duidelijker worden in november 2019, wanneer de Roadmap voor Zabbix 5.0 volledig bevestigd is.
8. Waarom heeft het mediatype zo weinig keuze standaard? Plannen jullie om Slack, Telegram en dergelijke toe te voegen? Gebruikt iemand Jabber nog?
Jabber is verwijderd in versie Zabbix 4.4, maar we hebben wel Webhooks toegevoegd. Wat betreft mediatypes wil ik niet specifieke applicaties in het systeem maken, maar gewone communicatietools. Het is geen geheim dat veel van dergelijke chats of servicedesks een API via HTTP hebben ā daarom zal de situatie dit jaar veranderen met de release van 4.4.
Met het verschijnen van webhooks in Zabbix kunnen we binnenkort de meest gevraagde integraties direct beschikbaar verwachten. Deze integraties zullen bovendien tweeledig zijn in plaats van alleen eenvoudige meldingen in Ć©Ć©n richting. De media types die we niet bereiken, zullen door onze community worden gemaakt ā want nu kan een media type volledig worden geĆ«xporteerd naar een configuratiebestand, gedeeld op share.zabbix.com of GitHub. Andere gebruikers hoeven alleen het bestand te importeren om die integratie te kunnen gebruiken. Extra scripts installeren zal niet nodig zijn!
9. Waarom ontwikkelt de richting van Virtual machine discovery zich niet? Er is alleen vmware. Veel mensen wachten op integraties met ec2, openstack.
Nee, de richting ontwikkelt zich. In versie 4.4 is bijvoorbeeld de discovery van data storage geĆÆntroduceerd via de sleutel vm.datastore.discovery. Versie 4.4 heeft ook geweldige nieuwe sleutels zoals wmi.getall ā we verwachten dat we hiermee, samen met de sleutel perf_counter_en, goed toezicht kunnen houden op Hyper-V. Er zullen ook andere belangrijke wijzigingen in deze richting zijn in Zabbix 5.0.
10. Hebben jullie overwogen om af te stappen van sjablonen en het te doen zoals bij Prometheus, waarbij alles wordt verzameld wat beschikbaar is?
Prometheus haalt automatisch alle metrics op, dat is handig. Maar een sjabloon is meer dan alleen een set metrics; het is een 'container' die alle benodigde standaardmonitorconfiguratie voor dit type bron of dienst bevat. Het bevat een set belangrijke triggers, grafieken, en detectieregels, evenals beschrijvingen van metrics en drempelwaarden die de gebruiker helpen te begrijpen wat er wordt verzameld en welke drempels precies worden gecontroleerd en waarom. Bovendien kunnen sjablonen eenvoudig worden gedeeld met andere gebruikers, zodat zij goede monitoring van hun systeem krijgen, zelfs zonder dat ze experts zijn.
11. Waarom zijn er zo weinig metrics direct beschikbaar? Dit maakt de configuratie immers veel ingewikkelder vanuit operationeel perspectief.
Als je met 'direct beschikbaar' bedoelt kant-en-klare sjablonen, dan zijn we momenteel bezig met het uitbreiden en verbeteren van onze sjablonen. Zabbix 4.4 is uitgebracht met een nieuwe, verbeterde set en met betere mogelijkheden.
Voor Zabbix is er altijd een kant-en-klaar sjabloon te vinden op share.zabbix.com voor vrijwel elk systeem. Maar we hebben besloten dat we zelf basis-sjablonen moeten maken, zodat we een voorbeeld voor anderen kunnen tonen, en gebruikers kunnen ontlasten van het opnieuw schrijven van een sjabloon voor een MySQL. Daarom zullen er met elke nieuwe versie van Zabbix alleen maar meer officiƫle sjablonen komen.
12. Wanneer kunnen we triggers bouwen die niet aan hosts zijn gekoppeld, maar bijvoorbeeld op basis van labels zijn? Bijvoorbeeld, we monitoren een website vanuit n verschillende punten, en we willen een eenvoudige trigger die afgaat wanneer de website niet bereikbaar is vanuit 2 of meer punten.
In werkelijkheid bestaat deze functionaliteit al enkele jaren in Zabbix, ontwikkeld voor een van onze klanten. Klant ā ICANN. Ook soortgelijke controles kunnen bijvoorbeeld worden uitgevoerd via geaggregeerde items of met de Zabbix API. We werken momenteel actief aan het vereenvoudigen van het maken van dergelijke controles.
P.S.: Tijdens een van de Sloerms vroegen de Zabbix-ontwikkelaars ons wat we in het product wilden zien om Kubernetes-clusters te monitoren met behulp van Zabbix in plaats van Prometheus.
Het is geweldig wanneer ontwikkelaars luisteren naar hun klanten in plaats van alleen maar de dingen te doen. En nu verwelkomen we elke release met oprechte interesse ā het is geweldig dat steeds meer functies waarover we hebben gepraat, werkelijkheid worden.
Zolang ontwikkelaars niet in zichzelf opgesloten blijven, maar zich interesseren voor de behoeften van klanten, blijft het product leven en groeien. We zullen de nieuwe releases van Zabbix volgen.
P.P.S.: We zullen over een paar maanden een online cursus over monitoring lanceren. Voor degenen die geĆÆnteresseerd zijn, schrijf je in zodat je de aankondiging niet mist. Tot die tijd kun je onze .
Bron: habr.com
