Twee jaar geleden plaatste ik al een bericht over . Nu is er enige ontwikkeling van het project, en ik heb ook gepubliceerd onder , daarom besloot ik deze korte recensie op Habr te schrijven.
[ ]
Voor wie het interessant kan zijn
Dit kan interessant voor je zijn als je in een klein team of alleen werkt. Je hebt geen monitoring en je weet niet zeker of je die echt nodig hebt. Of je hebt een populaire, serieuze monitoring geprobeerd ‘voor de grote jongens’, maar op de een of andere manier ‘sloeg het niet’ voor je, of het werkt in een bijna standaardconfiguratie en heeft je leven niet veel veranderd. En ook - als u zeker niet van plan bent een hele medewerker (of zelfs een afdeling) toe te wijzen om het monitoringdashboard minstens een paar uur per dag te monitoren of te configureren.
Waarom okerr ongebruikelijk is
Vervolgens zal ik interessante kenmerken van de okerra laten zien die hem onderscheiden van sommige andere monitoringsystemen.
Okerr is een hybride monitoring
Tijdens de interne monitoring draait er een “agent” op de bewaakte machines, die gegevens naar de monitoringserver verzendt (bijvoorbeeld vrije schijfruimte). Indien extern, voert de server controles uit via het netwerk (bijvoorbeeld ping of websitebeschikbaarheid). Elke benadering heeft zijn beperkingen. Okerr gebruikt beide opties. Controles binnen servers worden uitgevoerd door een zeer lichte (30Kb) agent of uw eigen scripts en applicaties, en netwerkcontroles worden uitgevoerd via okerr-sensoren in verschillende landen.
okerr is niet alleen software, maar ook een dienst
Het servergedeelte van elke monitoring is groot en complex, moeilijk te installeren en configureren, en vereist middelen. Met okerr kunt u uw eigen monitoringserver installeren (deze is gratis en opensource), of u kunt eenvoudigweg alleen het clientgedeelte gebruiken en de service van onze server gebruiken. Ook gratis.
Als je met monitoring het gebrek aan betrouwbaarheid van servers en applicaties kunt compenseren en verdoezelen, rijst er een filosofische vraag: wie is de bewaker? Hoe zal monitoring ons iets vertellen over een probleem als het om de een of andere reden zelf “dood” is, afzonderlijk of samen met uw andere bronnen (het kanaal naar het datacenter viel bijvoorbeeld weg)? Wanneer u de externe service okerr gebruikt - dit probleem is opgelost - ontvangt u een waarschuwing, zelfs als het hele datacenter met uw servers zonder stroom zit of wordt aangevallen door zombies.
Natuurlijk bestaat het risico dat de okerr-server zelf niet beschikbaar zal zijn, dit is waar (zoals u weet wordt 90% van de betrouwbaarheid altijd eenvoudig en “gratis” verkregen, 99% met een minimum aan inspanning, en elke volgende negen is exponentieel moeilijker). Maar ten eerste is de kans dat dit gebeurt kleiner, en ten tweede kan het probleem alleen onopgemerkt blijven als het samenvalt met problemen op onze servers. Als wij een betrouwbaarheid van 99.9% hebben, en jij 99.9% (niet al te hoge cijfers), dan is de kans op een onopgemerkte storing 0.1% van 0.1% = 0.0001%. Bijna moeiteloos en zonder kosten drie negens toevoegen aan uw betrouwbaarheid is erg goed!
Een ander voordeel van monitoring as a service is dat een hostingprovider of webstudio een okerr-server kan installeren en klanten als betaalde of gratis extra service toegang kan verlenen. Jouw concurrenten hebben alleen hosting en websites, maar jij beschikt over betrouwbare hosting met monitoring.
Okerr gaat over indicatoren
De indicator is een “gloeilamp”. Het heeft twee hoofdstatussen: groen (OK) of rood (ERR). Het project bevat veel gegroepeerde (bijvoorbeeld per server) indicatoren. Op de hoofdpagina van het project zie je meteen dat alles groen is (en je kunt het sluiten), of dat er iets rood oplicht en gecorrigeerd moet worden. Bij het overschakelen tussen deze statussen wordt een waarschuwing verzonden. Eenmaal per dag wordt tijdens het instellen een samenvatting van het project verzonden.
Elke okerr-indicator heeft ingebouwde voorwaarden waardoor deze van status verandert (in Zabbix wordt dit een trigger genoemd). Het belastinggemiddelde mag bijvoorbeeld niet meer dan 2 zijn (dit is uiteraard configureerbaar). En voor elke interne controle (laadgemiddelde, schijf vrij, ...) is er een waakhond. Als we om wat voor reden dan ook geen succesvolle bevestiging ontvangen op het afgesproken tijdstip, wordt er een fout geregistreerd en wordt er een waarschuwing verzonden.
Ons gebruikelijke werkpatroon is om 's ochtends e-mails te controleren en de samenvatting tussen andere brieven te bekijken (we plannen deze bij aanvang van het werk). Als alles daarin in orde is, doen we andere belangrijke dingen (maar voor de zekerheid kunnen we snel naar het okerra-dashboard kijken en ervoor zorgen dat alles op dit moment groen is). Als er een waarschuwing binnenkomt, reageren wij.
Natuurlijk is het mogelijk om eenvoudigweg “informatieve” indicatoren te behouden (om het beeld van het netwerk te zien van monitoring), maar er wordt alles aan gedaan om eenvoudig, gemakkelijk en snel indicatoren te creëren specifiek voor automatische monitoring en het verzenden van waarschuwingen.
Het doel waarvoor je okerr instelt is het genereren van waarschuwingen, zodat je binnen een minuut een indicator kunt maken, deze een jaar kan ‘slapen’, gewoon updates accepteert, en als er een jaar later iets kapot gaat, licht hij op en verzendt een waarschuwing. De minuut die u ooit besteedde aan het maken van een indicator heeft zijn vruchten afgeworpen; u leerde het probleem onmiddellijk kennen, als eerste. Het is mogelijk dat ze het probleem hebben opgelost voordat iemand het merkte. Iets dat snel wordt opgeheven, wordt niet als gevallen beschouwd!
veiligheid
Het zou zonde zijn als je monitoring instelt om de betrouwbaarheid te vergroten, maar als gevolg daarvan word je via het netwerk aangevallen en zijn er nogal wat netwerkkwetsbaarheden in verschillende monitoringtools (, ).
Agent (okerrmod uit pakket ) die op het systeem draait, is geen netwerkserver, maar een client. Daarom zijn er geen extra open poorten op de bewaakte server, werkt de client gemakkelijk achter een firewall of NAT en is het erg moeilijk (ik zou zeggen “onmogelijk”) om via het netwerk te hacken, omdat hij in principe niet naar het netwerk luistert stopcontact.
Volledige monitoringdekking
Nu is onze regel dat we van okerr over alle technische problemen leren. Als de regel plotseling wordt overtreden (okerr heeft niet gewaarschuwd voor het op handen zijnde optreden ervan (als dit mogelijk is) of dat dit al heeft plaatsgevonden) - voegen we controles toe aan okerr.
Externe controles
Een typisch setje:
- ping
- http-status
- het controleren van de geldigheid en versheid van het SSL-certificaat (waarschuwt als het bijna verloopt)
- open de TCP-poort en banner erop
- http grep (de pagina [mag niet] specifieke tekst bevatten)
- sha1-hash om paginawijzigingen op te vangen.
- DNS (DNS-record moet een specifieke waarde hebben)
- WHOIS (waarschuwt als het domein op het punt staat slecht te worden)
- Antispam DNSBL (hostcontrole op meer dan 50 antispam-blacklists tegelijk)
Interne controles
Verder een redelijk standaard set (maar makkelijk uit te breiden).
- df (vrije schijfruimte)
- gemiddelde belasting
- opentcp (open TCP-luistersockets - geeft een melding als er iets is gestart of gecrasht)
- uptime - alleen uptime op de server. Zal het melden als het is uitgeschakeld (dat wil zeggen dat de server overbelast is)
- klant_ip
- dirsize - we gebruiken het om bij te houden wanneer de rootfs van onze virtuele machines de toegestane grootte overschrijden, zonder strikte beperkingen te introduceren, en om de grootte van de thuismappen van gebruikers te meten
- leeg en niet-leeg - controleer bestanden die leeg moeten zijn (of niet leeg). Het foutenlogboek van de okerr-server zelf zou bijvoorbeeld leeg moeten zijn, en als er zelfs maar een regel in staat, ontvang ik een melding en controleer ik deze. Maar mail.log op de mailserver mag NIET leeg zijn (N minuten na rotatie). En soms was het voor ons leeg na een systeemupdate, toen logrotate rsyslog niet correct kon herstarten.
- linecount - aantal regels in het bestand (zoals wc -l). We gebruiken het als een zachtere vervanging voor leeg, wanneer het foutenlogboek nog steeds kan groeien, maar slechts langzaam (Googlebot bezoekt bijvoorbeeld enkele gesloten pagina's). Er is een limiet van 2 lijnen in 20 minuten. Als deze hoger is, volgt er een waarschuwing
Interessante interne controles
Als je tot nu toe “diagonaal” hebt gelezen, zal het nu interessanter zijn om zorgvuldiger te lezen.
backups
Bewaakt back-ups in de directory. Onze back-upbestanden hebben namen als “ServerName-20200530.tar.gz”. Voor elke server in okerr wordt de indicator ServerName-DATE.tar.gz aangemaakt (de werkelijke datum verandert in de regel “DATE”). De aanwezigheid van een nieuwe back-up en de grootte ervan worden ook gecontroleerd (deze mag bijvoorbeeld niet minder zijn dan 90% van de vorige back-up).
Wat moet er gebeuren om ervoor te zorgen dat een nieuwe back-up wordt bijgehouden nadat we zijn begonnen met het maken ervan en het in deze map plaatsen? Niets! Dit is een erg handige aanpak als u “niets” hoeft te doen, omdat:
- ‘Niets’ doen gaat behoorlijk snel, het bespaart tijd
- Het is moeilijk om te vergeten ‘niets’ te doen
- Het is moeilijk om ‘niets’ verkeerd te doen, met een fout. Niets is de meest betrouwbare methode
Als er plotseling geen nieuwe back-upbestanden meer verschijnen, volgt er een waarschuwing. Als u bijvoorbeeld een van de servers heeft uitgeschakeld en er geen back-ups meer zouden moeten zijn, moet u de indicator verwijderen (via de webinterface of vanuit de shell via de API).
maxfilesz
Houdt de grootte van de grootste bestanden bij (meestal: /var/log/*). Hierdoor kunt u onvoorspelbare problemen opsporen, bijvoorbeeld brute force-wachtwoorden of het verzenden van spam via de server.
runstatus/runlijn
Dit zijn twee belangrijke proxymodules voor het uitvoeren van andere programma's op de server. Runstatus rapporteert de programma-exitcode aan de indicator. Okerr heeft bijvoorbeeld geen module nodig om te controleren of systemd-services actief zijn. Dit gebeurt via runstatus (zie hieronder). Runline - rapporteert aan de server de lijn die het programma produceert. Bijvoorbeeld, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" in de Runline-configuratie op onze server wordt een indicator servernaam:temp gemaakt met de processortemperatuur.
sql
Voert een numerieke query uit naar MySQL en rapporteert het resultaat aan de indicator. In een eenvoudig geval kunt u bijvoorbeeld "SELECT 1" doen - hiermee wordt gecontroleerd of het DBMS als geheel werkt.
Maar een veel interessantere toepassing is bijvoorbeeld het bijhouden van het aantal bestellingen in een webwinkel. Als u weet dat u 100 of meer bestellingen per uur heeft, kunt u de minimumlimiet instellen op 100 of 80. Als uw omzet dan plotseling daalt, ontvangt u een waarschuwing en kunt u daar achter komen.
Merk op dat het niet uitmaakt om welke onvoorspelbare reden dit gebeurde:
- De server is eenvoudigweg niet beschikbaar (stroomloos of zonder netwerk), en de waarschuwing kwam voort uit het feit dat de indicator “rot” was.
- De server is ergens mee overbelast, hij werkt traag of er gaan pakketten verloren, het is lastig voor gebruikers en ze vertrekken zonder aankopen te doen
- De server is opgenomen in de spamlijsten en e-mail ervan wordt niet geaccepteerd, gebruikers kunnen zich niet registreren
- Het budget voor de reclamecampagne is op, de banners draaien niet.
Er kunnen allerlei redenen zijn, maar deze kunnen niet allemaal van tevoren worden voorzien en zijn technisch moeilijk te achterhalen. Maar u kunt gemakkelijk de laatste parameter (orders) volgen en daaruit opmaken dat de situatie verdacht is en moet worden aangepakt.
Logische indicatoren
Maakt het gebruik van Booleaanse expressies (Python-syntaxis) mogelijk via een module (). Gegevens van het project en de indicatoren ervan zijn beschikbaar voor expressie. In het hoofdstuk over SQL-controle hierboven heeft u misschien een zwak punt opgemerkt: overdag kunnen we 100 verkopen per uur hebben, maar 's nachts 20, en dit is gebruikelijk en geen probleem. Wat moet ik doen? De indicator zal 's nachts voortdurend in paniek raken.
U kunt twee indicatoren maken, dag en nacht. Maak beide “stil” (ze sturen geen waarschuwingen). En creëer een logische indicator die vereist dat de dagindicator vóór 20 uur in orde is, en na 00 uur is het voldoende dat de nachtindicator in orde is.
Een ander voorbeeld van het gebruik van een logische indicator is escalatie. Een projectmanager meldt zich bijvoorbeeld af voor waarschuwingen (hij hoeft dit niet te doen, beheerders moeten reageren op normale problemen), maar abonneert zich op een logische indicator die rood wordt als een indicator in het project niet binnen de toegewezen tijd wordt gecorrigeerd.
Ook is het mogelijk om de toegestane werktijd in te stellen, bijvoorbeeld van 3 tot 5 uur 's ochtends. Het maakt ons niet uit als servers en sites gedurende deze tijd crashen. Maar om vijf uur moeten ze werken. Als ze op een ander moment niet werken: waarschuw dan. Met de logische indicator kunt u ook rekening houden met serverredundantie. Als u vijf webservers heeft, kunnen beheerders op elk moment één tot twee servers uitschakelen. Maar als er minder dan 5 van de 00 servers in de strijd zijn, zal er een waarschuwing zijn.
De bovenstaande voorbeelden zijn geen betere functies, en niet enkele functies die moeten worden geactiveerd en geconfigureerd. Okerra heeft niet al deze functies, maar er is een logische module waarmee je deze functionaliteit kunt implementeren (ongeveer zoals in een programmeertaal - als we rekenkundige operatoren hebben, hebben we geen speciale functie nodig voor het berekenen van 20% BTW vanuit de taal, je kunt het altijd zelf doen en het naar jouw wensen aanpassen).
Logic Indicator is waarschijnlijk een van de weinige relatief complexe onderwerpen in okerr, maar het goede nieuws is dat je het pas onder de knie hoeft te krijgen als het nodig is. Maar tegelijkertijd breiden ze de mogelijkheden enorm uit, terwijl ze het systeem zelf vrij eenvoudig houden.
Uw eigen cheques toevoegen
Ik zou heel graag het idee willen overbrengen dat okerr niet een reeks van duizenden kant-en-klare cheques voor alle gelegenheden is, maar integendeel - in de eerste plaats - een eenvoudige engine met de eenvoudige mogelijkheid om uw eigen cheques te maken. Het maken van je eigen controles in okerr is geen taak voor hackers, mede-ontwikkelaars van systemen of op zijn minst gevorderde okerr-gebruikers, maar een haalbare taak voor elke beheerder die Linux een maand geleden voor de eerste keer heeft geïnstalleerd.
Controles op het minimumloon worden gedaan via de module :
Deze regel in de config zal u op de hoogte stellen als /bin/true plotseling niet start of iets anders retourneert dan 0.
true_OK=/bin/trueSlechts één regel - en hier zijn we al een beetje uitgebreid functionaliteit oker.
Zelfs zo'n controle heeft al zijn waarde: als uw server plotseling crasht, wordt de overeenkomstige indicator op de okerr-server niet tijdig bijgewerkt en verschijnt er na het verstrijken van de tijd een waarschuwing.
Deze controle geeft aan dat de apache2-server is gecrasht (nou ja, je weet maar nooit...):
apache_OK="systemctl is-active --quiet apache2"Dus als u een programmeertaal spreekt en in ieder geval shell-scripts kunt schrijven, kunt u al uw eigen controles toevoegen.
Moeilijker: je kunt (in elke taal) je eigen module voor okerrmod schrijven. In het eenvoudigste geval ziet het er als volgt uit:
#!/usr/bin/python3
print("STATUS: OK")Is het niet heel moeilijk? De module moet de controle zelf uitvoeren en de resultaten naar STDOUT uitvoeren. Een complexere module geeft bijvoorbeeld dit:
$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52
NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32Het werkt meerdere indicatoren tegelijk bij (gescheiden door een lege regel), creëert ze indien nodig, geeft verificatiedetails aan en een tag waarmee het gemakkelijk is om de benodigde indicatoren in het dashboard te vinden.
Telegram
Er is een Telegram-bot . Je hoeft je telefoon niet vol te proppen met afzonderlijke applicaties (ik vind het niet leuk dat je voor Pyaterochka één applicatie met een kaart nodig hebt, voor Lenta een andere, voor MTS een derde, enzovoort voor iedereen, allemaal, allemaal). Eén telegram is genoeg. Via telegram kunt u onmiddellijk waarschuwingen ontvangen, de status van het project controleren en een opdracht geven om alle problematische indicatoren opnieuw te controleren. We verlieten het theater/vliegtuig, hielden twee uur lang de vinger niet aan de pols, zetten de telefoon aan, drukten op één knop in de chatbot en zorgden ervoor dat alles in orde was.
Statuspagina's
Tegenwoordig zijn statuspagina's bijna een must-have voor elk bedrijf dat over IT beschikt, een verantwoordelijke houding ten opzichte van betrouwbaarheid heeft en zijn klanten/gebruikers met respect behandelt.
Stel je een situatie voor: een gebruiker wil iets doen, informatie bekijken of een bestelling plaatsen, en iets werkt niet. Hij weet niet wat er aan de hand is, aan wiens kant het probleem ligt en wanneer het opgelost zal zijn. Misschien heeft uw bedrijf gewoon een niet-functionele website? Of is het zes maanden geleden kapot gegaan en wordt het over twee jaar gerepareerd? Maar je moet nu een koelkast kopen, die zit al in de winkelwagen... En het is een heel andere zaak als iemand ziet dat er iets mis is met je (het is tenminste duidelijk dat het probleem niet aan zijn kant ligt), dat de probleem is ontdekt, dat u er al aan werkt, en misschien zelfs de geschatte tijd voor correctie hebt opgeschreven. De gebruiker kan zich abonneren en een e-mailmelding ontvangen wanneer het probleem is opgelost en hij kan doen wat hij wil (een koelkast kopen).
Problemen en downtime overkomen iedereen. Maar gebruikers en partners vertrouwen meer op degenen die transparanter en verantwoordelijker zijn in hun aanpak hiervan.
Hier . Hier zijn voorbeelden van hoe deze projectpagina's eruit zien и . .
Failover
Om dit artikel niet nog langer te maken, verwijs ik nogmaals naar mijn vorige artikel - . Als u een dubbele server kunt maken en failover gebruikt, heeft u in principe geen lange downtime: zodra er een probleem wordt gedetecteerd, worden gebruikers automatisch doorgestuurd naar een werkende back-upserver. En het lijkt mij dat dit een zeer interessante, heldere functie is die zelden ergens beschikbaar is.
Lage systeemvereisten
Voor okerr-servers gebruiken we machines met RAM vanaf 2Gb. Voor netwerksensoren is zelfs 512 MB voldoende. Het cliëntdeel is over het algemeen vrijwel nul. (Plastieken zak weegt 26 Kb, maar vereist Python3 en standaardbibliotheken). De client draait vanuit een cron-script en heeft dus geen persistent geheugenverbruik. Onder de machines die we hebben gemonitord, bevinden zich sensoren (supergoedkope VPS met 512 MB RAM) en een Raspberry Pi. Het is zelfs mogelijk zonder het klantgedeelte ! (zie hieronder)
Hiermee rekening houdend - oké, waarschijnlijk meest gratis monitoringsysteem van de beschikbare, want zelfs als je een ander gratis open-sourcesysteem zoals Zabbix of Nagios wilt gebruiken, moet je er bronnen (server) aan toewijzen, en dit is al geld. Daarnaast is er nog enig serveronderhoud nodig. Met okerr kan dit onderdeel worden verwijderd. Of je hoeft het niet te verwijderen en je eigen server te gebruiken, afhankelijk van wat je het leukst vindt.
API en integratie in eigen software
Eenvoudige en open architectuur. okerr heeft een vrij eenvoudige , waarmee gemakkelijk te werken is. Moet u 1000 indicatoren maken? Eén shellscript van 3-4 regels zal dit doen. Moet u 1000 indicatoren opnieuw configureren? Het is ook heel gemakkelijk. We willen bijvoorbeeld al onze HTTPS-certificaten van een Russische sensor dubbel controleren:
#!/bin/sh
for indicator in `okerrclient --api-filter sslcert`
do
echo set location for $indicator
okerrclient --api-set location=ru retest=1 --name $indicator
doneU kunt de indicator bijwerken met behulp van onze clientmodule, zelfs zonder, gewoon via curl.
# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK
# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/U kunt indicatoren rechtstreeks vanuit uw programma bijwerken. Het verzenden van bijvoorbeeld hartslagsignalen zodat okerr weet dat het apparaat actief is en een alarm genereert als het crasht of vastloopt. Trouwens, okerr-componenten doen precies dat: okerr controleert zichzelf, en problemen in vrijwel elke module zullen worden gedetecteerd en een waarschuwing over het probleem genereren. (En in het geval dat dit “bijna” is, worden ze gecontroleerd vanaf een andere server)
Hier is de code (vereenvoudigd) in onze telegrambot:
from okerrupdate import OkerrProject, OkerrExc
op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
os.getpid(), dhms(uptime), commands_cnt))Er is een bibliotheek voor het bijwerken van indicatoren uit Python-programma's Voor andere talen zijn er geen bibliotheken, maar u kunt het okerrupdate-script aanroepen of een HTTP-verzoek indienen bij de okerr-server.
Hoe okerr ons helpt
Okerr heeft ons leven veranderd. Inderdaad. Misschien zou een ander monitoringsysteem hetzelfde kunnen doen, maar werken met okerr is voor ons gemakkelijk en eenvoudig en het heeft alle functies die we nodig hadden (we hebben toegevoegd wat het niet had). Trouwens, als er enkele functies ontbreken, vraag het dan en ik zal ze toevoegen (ik beloof het niet, maar ik wil dat okerr het beste monitoringsysteem is voor kleine tot middelgrote projecten). Of beter nog: voeg het zelf toe: het is heel eenvoudig.
We zijn erin geslaagd te leven volgens het principe ‘leer over alle problemen van de kerra’. Als er plotseling een probleem optreedt waar we niets van hebben vernomen, voegen we een controle toe aan okerr. (in dit geval bedoel ik met “wij” ons als gebruikers van het systeem, niet als mede-ontwikkelaars). In het begin was dit gebruikelijk, maar nu is het zeer zeldzaam geworden.
controle
Via okerr monitoren we de loggroottes op alle servers. Het is natuurlijk onmogelijk om elke regel van het logboek aandachtig met je ogen te lezen, maar het simpelweg monitoren van de groeisnelheid levert al veel op. Hierdoor ontdekten we spammailing en brute force-zoekopdrachten naar wachtwoorden, en als sommige applicaties “gek worden”, lukt er iets niet voor hen en herhalen ze het keer op keer (elke keer voegen ze een paar regels toe aan het logbestand). ).
SSL-certificaten. Vrijwel onmiddellijk na de lancering onze klant begon zijn klanten (ongeveer duizend) gratis SSL-certificaten te verstrekken. En het bleek een hel voor de administratie! Feit is dat sites 'live' zijn, klanten vragen hen periodiek om iets te doen, programmeurs doen het. Ze kunnen de site geheel vrij overzetten naar bijvoorbeeld een andere DocumentRoot. Of voeg een onvoorwaardelijke herschrijving toe aan de virtualhost-configuratie. Uiteraard vervalt hierna de automatische verlenging van certificaten. Nu hebben we alle SSL-hosts automatisch aan okerr toegevoegd via een van onze handige hulpprogramma's uit het pakket . Laten we gewoon lanceren a2okerr.py — en als er meerdere nieuwe sites op de server verschijnen, verschijnen ze automatisch in okerr. Als het certificaat om wat voor reden dan ook plotseling niet wordt verlengd, drie weken voordat het certificaat verloopt, zijn we op de hoogte en zullen we uitzoeken waarom het niet is bijgewerkt, zo'n hond. a2certbot.py uit hetzelfde pakket - het helpt hier veel bij (het controleert onmiddellijk de meest waarschijnlijke problemen - en schrijft goed wat er is gecontroleerd, en waar er hoogstwaarschijnlijk een probleem is).
Wij monitoren de vervaldatum van al onze domeinen. En al onze mailservers die mail versturen worden ook gecontroleerd aan de hand van meer dan 50 verschillende zwarte lijsten. (En soms vallen ze erin). Wist u trouwens dat de mailservers van Google ook op de zwarte lijst staan? Voor zelftesten hebben we mail-wr1-f54.google.com toegevoegd aan de bewaakte servers, en deze staat nog steeds op de SORBS-zwarte lijst! (Dit gaat over de waarde van “anti-spammers”)
Back-ups - Ik schreef hierboven al hoe gemakkelijk het is om ze te monitoren met okerr. Maar we monitoren zowel de nieuwste back-ups op onze server als (met behulp van een apart hulpprogramma dat okerr gebruikt) de back-ups die we uploaden naar Amazon Glacier. En ja, er gebeuren af en toe problemen. Geen wonder dat ze keken.
Wij gebruiken de escalatie-indicator. Het laat zien of een probleem al lange tijd niet is opgelost. En ikzelf, als ik sommige problemen oplos, kan ik ze soms vergeten. Escalatie is een goede herinnering, zelfs als u uzelf in de gaten houdt.
Over het geheel genomen ben ik van mening dat de kwaliteit van ons werk met een orde van grootte is toegenomen. Er is vrijwel geen sprake van downtime (of de opdrachtgever heeft geen tijd om het op te merken. Sst maar!), terwijl de hoeveelheid werk kleiner is geworden en de werkomstandigheden rustiger zijn geworden. We zijn overgegaan van noodwerk waarbij gaten worden gedicht met tape naar rustig en afgemeten werk, waarbij veel problemen vooraf worden voorspeld en er tijd is om ze te voorkomen. Zelfs problemen die zich hebben voorgedaan, zijn ook gemakkelijker op te lossen: ten eerste komen we erachter voordat klanten in paniek raken, en ten tweede komt het vaak voor dat het probleem verband houdt met recent werk (terwijl ik het ene deed, brak ik het andere) - dus het is heet. Het is gemakkelijker voor sporen om er mee om te gaan.
Maar er was nog een geval...
Wist u dat in het populaire Debian 9 (Stretch) zo'n populair pakket als phpmyadmin nog (vele maanden!) in de kwetsbare status verkeert? (). Toen de kwetsbaarheid naar voren kwam, hebben we deze snel op verschillende manieren afgedekt. Maar ik heb monitoring van de security-tracker-pagina in okerr ingesteld om te weten wanneer er een “mooie” oplossing uitkomt (via de SHA1-som van de inhoud). De indicator trilde me verschillende keren, de pagina veranderde, maar zoals je kunt zien, geeft dit nog steeds (sinds januari 2019!) Aan dat het probleem is opgelost. Misschien weet iemand trouwens wat het probleem is dat zo'n belangrijk pakket nog ruim een jaar kwetsbaar is?
Een andere keer in een soortgelijke situatie: na een kwetsbaarheid in SSH was het nodig om alle servers te updaten. En wanneer u een taak instelt, moet u de uitvoering ervan controleren. (Ondergeschikten hebben de neiging om het verkeerd te begrijpen, te vergeten, in de war te raken en fouten te maken). Daarom hebben we eerst een SSH-versiecontrole toegevoegd aan okerr op alle servers, en via okerr hebben we ervoor gezorgd dat updates op alle servers werden uitgerold. (Handig! Ik heb voor dit type indicator gekozen, dan zie je meteen welke server welke versie heeft). Toen we er zeker van waren dat de taak op alle servers was voltooid, hebben we de indicatoren verwijderd.
Een paar keer was er een situatie waarin een bepaald probleem zich voordeed en vervolgens vanzelf verdween. (waarschijnlijk bekend bij iedereen?). Tegen de tijd dat je het merkt, tegen de tijd dat je het controleert – en er valt niets meer te controleren – werkt alles al goed. Maar dan breekt het weer. Dit gebeurde bijvoorbeeld met producten die we uploadden naar Amazon Marketplace (MWS). Op een gegeven moment was de geladen inventaris onjuist (verkeerde hoeveelheden goederen en verkeerde prijzen). Wij zijn er achter gekomen. Maar om erachter te komen, was het belangrijk om meteen het probleem te achterhalen. Helaas is MWS, net als alle Amazon-services, een beetje traag, dus er was altijd een vertraging, maar toch konden we in ieder geval grofweg het verband begrijpen tussen het probleem en de scripts die het veroorzaakten (we hebben een controle uitgevoerd en zijn vastgelopen naar de okerr en controleerde het onmiddellijk en kreeg een waarschuwing).
Onlangs is er een interessante case aan de collectie toegevoegd door een grote en dure Europese hoster, waar onze klant gebruik van maakt. Plots verdwenen AL onze servers van de radar! Ten eerste merkte de klant zelf (sneller dan okerra!) dat de site waarmee hij werkte niet openging en maakte er een ticket over. Maar niet slechts één site ging offline, maar allemaal! (Natasha, we hebben alles laten vallen!). Hier begon Okerr lange voetbandages te sturen met alle indicatoren die voor hem oplichtten. Paniek, paniek, we rennen in cirkels (wat kunnen we nog meer doen?). Toen steeg alles. Er blijkt sprake te zijn van routineonderhoud in het datacenter (eens in de zoveel jaar) en uiteraard hadden we gewaarschuwd moeten worden. Maar er gebeurde iets met hen en ze waarschuwden ons niet. Nou ja, meer hartaanvallen, minder hartaanvallen. Maar nadat alles is hersteld, moet je alles nog eens controleren! Ik kan me niet voorstellen hoe ik het met mijn handen zou doen. Okerr testte alles in een paar minuten. Het bleek dat de meeste servers simpelweg tijdelijk niet beschikbaar waren, maar ze werkten. Sommigen waren overbelast, maar stonden ook op zoals het hoort. Van alle verliezen zijn we twee backups kwijtgeraakt, die volgens de kroon gemaakt en geladen hadden moeten worden terwijl deze volle banaan aan de gang was. Ik nam niet eens de moeite om ze te maken, slechts een dag later kwamen er waarschuwingen dat alles in orde was en dat er back-ups waren verschenen. Ik vind dit voorbeeld erg leuk omdat okerr erg handig bleek te zijn in een situatie waar we van tevoren niet eens over hadden nagedacht, maar dat is het doel van monitoring: weerstand bieden aan het onvoorspelbare.
Voor Okerr-sensoren maken we gebruik van de goedkoopst mogelijke hosting (waar kwaliteit en betrouwbaarheid niet belangrijk zijn, ze verzekeren elkaar). We hebben dus onlangs een zeer goede hosting gevonden en supergoedkoop, de benchmarks zijn geweldig. Maar... soms blijkt dat uitgaande verbindingen vanaf de virtuele machine vanaf een ander (naburig) IP-adres worden gemaakt. Wonderen. Client_ip-module met krijgt het verkeerde IP-adres. En uit de serverlogboeken van de indicator is het duidelijk dat de update ook van dit naburige IP kwam. Laten we nu de steun afhandelen. Het is goed dat we dit in vredestijd hebben opgemerkt. Maar het komt bijvoorbeeld vaak voor dat de toegang wordt geregistreerd volgens de IP-whitelist - en als de server soms even zo knippert - kun je heel lang proberen dit probleem op te vangen.
Nog één ding – aangezien we het over VPS-hosting hebben – gebruiken we altijd goedkope (hetzner, ovh, scaleway). Ik vind het erg leuk, zowel qua benchmarks als qua stabiliteit. Ook voor andere projecten gebruiken we de veel duurdere Amazon EC2. Dankzij okerr hebben we dus onze eigen geïnformeerde mening. Ze vallen allebei. En ik zou niet zeggen dat goedkope hostings zoals hetzner over de lange periode van onze observaties merkbaar minder stabiel bleken te zijn dan EC2. Waarom zou u dus meer betalen als u niet gebonden bent aan andere Amazon-functies? 🙂
Wat is het volgende?
Als ik je in dit stadium nog niet heb weggejaagd van Okerr, probeer het dan! U kunt rechtstreeks naar deze link gaan (Klik nu!) Maar houd er rekening mee dat er voor iedereen maar één demo-account is, dus als u iets doet, kan iemand anders in hetzelfde account zich tegelijkertijd met u bemoeien. Of (beter) schrijf je in via de link naar - alles is eenvoudig, zonder sms. Als je je echte e-mail niet wilt gebruiken, kun je een wegwerp-e-mail gebruiken, zoals mailinator (ik raad aan ). Dergelijke accounts kunnen na verloop van tijd worden verwijderd, maar kunnen prima worden getest.
Na inschrijving wordt u gevraagd een training te volgen (het uitvoeren van enkele niet al te moeilijke trainingstaken). De initiële limieten zijn erg klein, maar voor training of één server zijn ze voldoende. Na voltooiing van de training worden de limieten (bijvoorbeeld het maximale aantal indicatoren) verhoogd.
Uit de documentatie - allereerst aan de serverzijde en aan de clientzijde (). Maar als er iets onduidelijk is, schrijf dan naar support (at) okerr.com of laat een ticket achter - we zullen proberen alles snel op te lossen.
Als je het serieus gebruikt en deze verhoogde limieten zijn niet genoeg, schrijf dan naar support en we zullen het (gratis) verhogen.
Wilt u de okerr-server op uw server installeren? Hier . Wij raden aan om op een schone virtuele machine te installeren, dan kunt u dit eenvoudig doen met een installatiescript. Op uw virtuele machine - geen beperkingen :-). Nogmaals, als er iets gebeurt, zullen we altijd proberen te helpen.
Wij willen dat dit project een vlucht neemt, zodat de wereld dankzij ons betrouwbaarder wordt. Dankzij vrije software en diensten is de wereld vriendelijker geworden en ontwikkelt zich dynamischer. Bronnen kunnen worden opgeslagen in gratis github, voor mail kun je gratis gmail gebruiken. Wij gebruiken gratis Voor ondersteuning. Voor dit alles hoeft u niet voor servers te betalen, hoeft u niet te downloaden en te configureren en hoeft u geen verschillende operationele problemen op te lossen. Elk nieuw project, elk team beschikt onmiddellijk over mail, repositories en CRM. En dit alles is van zeer hoge kwaliteit en gratis en onmiddellijk. We willen dat dit hetzelfde is voor monitoring: kleine bedrijven en projecten kunnen okerr gratis gebruiken en zelfs in de fase van geboorte en groei hebben ze de betrouwbaarheid van serieuze volwassen projecten.
Bron: www.habr.com