Overvågning og sikring af MongoDB med ClusterControl Advisors

Database ops management består af 80% læsning og fortolkning af dine overvågningssystemer. Hundredvis af metrics kan fortolkes og kombineres på forskellige måder for at give dig dyb indsigt i dine databasesystemer og hvordan du optimerer dem. Når du kører flere databasesystemer, kan overvågningen af ​​disse systemer blive noget af en opgave. Hvis fortolkningen og kombinationen af ​​metrikker tager meget tid, ville det så ikke være fantastisk, hvis dette kunne automatiseres på en eller anden måde?

Det er derfor, vi har skabt databaserådgivere i ClusterControl:små scripts, der kan fortolke og kombinere metrics for dig og give dig råd, når det er relevant. Til MySQL har vi oprettet et omfattende bibliotek af de mest almindeligt anvendte MySQL-overvågningstjek. Men også for MongoDB har vi et bredt bibliotek af rådgivere til din rådighed. Til dette blogindlæg har vi udvalgt de ni vigtigste til dig. Vi vil beskrive hver og en af ​​dem i detaljer.

De ni MongoDB-rådgivere, vi vil dække i dette blogindlæg, er:

• Kontrol af muligheder for diskmontering
• Talkontrol
• Procent for samlingslås (MMAP)
• Replikeringsforsinkelse
• Replikeringsvindue
• U-sharded databaser og samlinger (kun sharded cluster)
• Autentificering aktiveret kontrol
• Tjek for godkendelse/godkendelse
• Fejlregistrering (ny rådgiver)

Disk Mount Options Advisor

Det er meget vigtigt at få monteret sine diske på den mest optimale måde. Med ClusterControl disk mount options advisor ser vi nærmere på din datadisk på daglig basis. I denne rådgiver undersøger vi det anvendte filsystem, monteringsmuligheder og io-planlægningsindstillingerne for operativsystemet.

Vi tjekker om dine diske er blevet monteret med noatime og nodiratime. Indstilling af disse vil reducere diskenes ydeevne, da adgangstiden skal skrives til disken ved hver adgang til en fil eller et bibliotek. Da dette sker kontinuerligt på databaser, er dette en god ydeevneindstilling og øger også holdbarheden af ​​dine SSD'er.

Til filsystemer anbefaler vi at bruge moderne filsystemer som xfs, zfs, ext4 eller btrfs. Disse filsystemer er skabt med ydeevne i tankerne. io-planlæggeren anbefales at være enten på noop eller deadline. Deadline har været standard for databaser i årevis, men takket være hurtigere lagring som SSD'er er noop Scheduler giver mere mening i dag.

Numa Check Advisor

For MongoDB aktiverer vi vores NUMA tjekke rådgiver. Denne rådgiver vil kontrollere, om NUMA (Non-Uniform Access Memory) er blevet aktiveret på dit system, og hvis dette er tilfældet, for at slukke det.

Når Non-Uniform Access Memory er blevet aktiveret, er serverens CPU kun i stand til at adressere sin egen hukommelse direkte og ikke de andre CPU'er i maskinen. På denne måde er CPU'en kun i stand til at allokere hukommelse fra sin egen hukommelsesplads, og allokering af alt overskydende vil resultere i swap-brug. Denne arkitektur har en stærk ydeevnefordel på multi-processor-applikationer, der allokerer alle CPU'er, men da MongoDB ikke er en multi-processor-applikation, vil det reducere ydeevnen betydeligt og kunne føre til enormt swap-brug.

Procentdel for samlingslås (MMAP)

Som MMAP er et filbaseret lagersystem, det understøtter ikke dokumentniveaulåsning som findes i WiredTiger og RocksDB. I stedet for det laveste niveau af låsning for MMAP er samlingen låse. Det betyder, at enhver skrivning til en samling (indsæt, opdatere eller slet) vil låse hele samlingen. Hvis procentdelen af ​​låse bliver for høj, indikerer dette, at du har problemer med stridigheder på samlingen. Når det ikke behandles korrekt, kan dette bringe din skrivegennemstrømning til at gå i stå. Derfor er det meget nyttigt at have en rådgiver, der advarer dig på forhånd.

MongoDB Replication Lag Advisor

Hvis du skalerer MongoDB ud til læsninger via sekundære, er replikeringsforsinkelsen meget vigtig at holde øje med. MongoDB-klientdriverne vil kun bruge sekundære, der ikke halter for langt bagud, ellers kan du risikere at udlevere forældede data.

Inde i MongoDB vil den primære holde styr på replikeringsstatussen for dens sekundære. Rådgiveren henter replikeringsoplysningerne og beskytter replikeringsforsinkelsen. Hvis forsinkelsen bliver for høj, vil den sende en advarsel eller en kritisk statusmeddelelse.

MongoDB Replication Window Advisor

Ved siden af ​​replikeringsforsinkelse er replikeringsvinduet en vigtig metrik at se. MongoDB-oploggen er en enkelt samling, der er blevet begrænset i en (forudindstillet) størrelse. Når oploggen når slutningen, og en ny transaktion skal gemmes, vil den fjerne den ældste transaktion for at give plads til den nye transaktion. Replikeringsvinduet afspejler antallet af sekunder mellem den ældste og nyeste transaktion i oploggen.

Denne metrik er meget vigtig, da du skal vide, hvor længe du kan tage en sekundær ud af replicaSet, før den ikke længere vil være i stand til at indhente masteren på grund af at være for langt bagud i replikering. Også hvis en sekundær begynder at halte bagud, ville det være godt at vide, hvor længe vi kan tolerere dette, før sekundæren ikke længere er i stand til at indhente det.

I MongoDB-skallen er en funktion tilgængelig til at beregne replikeringsvinduet. Denne rådgiver i ClusterControl bruger funktionen til at lave den samme beregning. Fordelen ville være, at du nu kan blive advaret om et for kort replikeringsvindue.

MongoDB Un-Sharded Database and Collections Advisor

I en sharded MongoDB-klynge tildeles alle un-sharded databaser og samlinger til en standard primær shard af MongoDB shard-routeren. Dette primære shard kan variere mellem databaserne og samlingerne, men generelt vil dette være det shard med mest tilgængelig diskplads.

At have en ikke-delt database eller samling udgør ikke umiddelbart en risiko for din klynge. Men hvis en applikation eller bruger begynder at skrive store mængder data til en af ​​disse, kan det primære shard hurtigt fyldes op og skabe et udfald på dette shard. Da databasen eller samlingen ikke er shardet, vil den ikke være i stand til at gøre brug af andre shards.

Af denne grund har vi oprettet en rådgiver, som vil forhindre dette i at ske. Rådgiveren scanner alle databaser og samlinger og advarer dig, hvis den ikke er blevet sønderdelt.

Tjek af godkendelsesaktiveret

Uden at aktivere godkendelse i MongoDB, vil enhver bruger, der logger på, blive behandlet som en admin. Dette er en alvorlig risiko, da administratoropgaver, som at oprette brugere eller lave sikkerhedskopier, nu er blevet tilgængelige for alle. Dette kombineret med afslørede MongoDB-servere resulterede i de seneste MongoDB-ransum-hack, mens en simpel aktivering af autentificering ville have forhindret de fleste af disse tilfælde.

Vi har implementeret en rådgiver, der verificerer, om dine MongoDB-servere har autentificering aktiveret. Dette kan gøres eksplicit ved at indstille dette i konfigurationen, eller implicit ved at aktivere replikeringsnøglefilen. Hvis denne rådgiver ikke opdager, at godkendelsen er blevet aktiveret, skal du straks reagere på dette, da din server er sårbar over for at blive kompromitteret.

Tjek for godkendelse/godkendelse

Ved siden af ​​den autentificeringsaktiverede rådgiver har vi også bygget en rådgiver, der udfører et sundhedstjek for både godkendelse og autorisation i MongoDB.

I MongoDB er godkendelsen og autorisationen ikke placeret centralt, men udføres og gemmes på databaseniveau. Normalt vil brugere oprette forbindelse til databasen og autentificere mod den database, de har til hensigt at bruge. Men med de korrekte bevillinger er det også muligt at autentificere mod andre (ikke-relaterede) databaser og stadig gøre brug af en anden database. Normalt er dette helt fint, medmindre en bruger har overdrevne rettigheder (som administratorrollen) over en anden database.

I denne rådgiver verificerer vi, om disse overdrevne roller er til stede, og om de kan udgøre en trussel. Vi tjekker også samtidig for svage og lette at gætte adgangskoder.

Fejlregistrering (ny rådgiver)

I MongoDB vil enhver stødt fejl blive talt eller logget. Inden for MongoDB er der en lang række mulige fejl:brugerpåstande, regelmæssige påstande, advarsler og endda interne serverundtagelser. Hvis der er tendenser i disse fejl, er det sandsynligt, at der enten er en fejlkonfiguration eller et programproblem.

Denne rådgiver vil se på statistikken over MongoDB-fejl (påstår) og giver mening i dette. Vi fortolker de fundne tendenser og råd om, hvordan du mindsker fejl i dit MongoDB-miljø!