Övervaka och säkra MongoDB med ClusterControl Advisors

Databasoperationshantering består till 80 % av att läsa och tolka dina övervakningssystem. Hundratals mätvärden kan tolkas och kombineras på olika sätt för att ge dig djupa insikter i dina databassystem och hur du kan optimera dem. När du kör flera databassystem kan övervakningen av dessa system bli ett jobbigt arbete. Om tolkningen och kombinationen av mätvärden tar mycket tid, skulle det inte vara bra om detta kunde automatiseras på något sätt?

Det är därför vi skapade databasrådgivare i ClusterControl:små skript som kan tolka och kombinera statistik åt dig och ge dig råd när det är tillämpligt. För MySQL har vi skapat ett omfattande bibliotek med de mest använda MySQL-övervakningskontrollerna. Men även för MongoDB har vi ett brett bibliotek av rådgivare till ditt förfogande. För det här blogginlägget har vi valt ut de nio viktigaste för dig. Vi kommer att beskriva var och en av dem i detalj.

De nio MongoDB-rådgivare som vi kommer att täcka i det här blogginlägget är:

• Kontrollera alternativ för diskmontering
• Numakontroll
• Procentandel för samlingslås (MMAP)
• Replikeringsfördröjning
• Replikeringsfönster
• Odelade databaser och samlingar (endast delade kluster)
• Autentiseringsaktiverad kontroll
• Kontroll av autentisering/auktorisering
• Felidentifiering (ny rådgivare)

Advisor för diskmonteringsalternativ

Det är väldigt viktigt att ha dina diskar monterade på det mest optimala sättet. Med ClusterControl diskmonteringsalternativ rådgivare tittar vi närmare på din datadisk på daglig basis. I den här rådgivaren undersöker vi vilket filsystem som används, monteringsalternativ och io-schemaläggarens inställningar för operativsystemet.

Vi kontrollerar om dina diskar har monterats med noatime och nodiratime. Om du ställer in dessa minskar diskarnas prestanda, eftersom åtkomsttiden för varje åtkomst till en fil eller katalog måste skrivas till disken. Eftersom detta sker kontinuerligt på databaser är detta en bra prestandainställning och ökar även hållbarheten på dina SSD:er.

För filsystem rekommenderar vi att du använder moderna filsystem som xfs, zfs, ext4 eller btrfs. Dessa filsystem är skapade med prestanda i åtanke. io-schemaläggaren rekommenderas att vara antingen på noop eller deadline. Deadline har varit standard för databaser i flera år, men tack vare snabbare lagring som SSD-enheter är noop Schemaläggaren är mer vettig nuförtiden.

Numa Check Advisor

För MongoDB aktiverar vi vår NUMA kolla rådgivare. Den här rådgivaren kontrollerar om NUMA (Non-Uniform Access Memory) har aktiverats på ditt system, och om så är fallet, för att stänga av det.

När Non-Uniform Access Memory har aktiverats kan serverns CPU bara adressera sitt eget minne direkt och inte de andra CPU:erna i maskinen. På så sätt kan processorn bara allokera minne från sitt eget minnesutrymme, och allokering av allt överskott kommer att resultera i swap-användning. Den här arkitekturen har en stark prestandafördel på applikationer med flera processorer som allokerar alla processorer, men eftersom MongoDB inte är en applikation med flera processorer kommer det att minska prestandan avsevärt och kan leda till enorm användning av utbyten.

Collection Lock Procent (MMAP)

Som MMAP är ett filbaserat lagringssystem, det stöder inte dokumentnivålåsningen som finns i WiredTiger och RocksDB. Istället den lägsta nivån av låsning för MMAP är samlingslåsen. Detta innebär att alla skrivningar till en samling (infoga, uppdatera eller ta bort) kommer att låsa hela samlingen. Om andelen låsningar blir för hög, indikerar detta att du har problem med konflikter på samlingen. När det inte åtgärdas på rätt sätt kan detta få din skrivkapacitet att stanna. Därför är det mycket användbart att ha en rådgivare som varnar dig i förväg.

MongoDB Replication Lag Advisor

Om du skalar ut MongoDB för läsningar via sekundärer är replikeringsfördröjningen mycket viktig att hålla ett öga på. MongoDB-klientdrivrutinerna kommer bara att använda sekundärer som inte ligger för långt efter, annars kan du riskera att servera inaktuella data.

Inuti MongoDB kommer primären att hålla reda på replikeringsstatusen för dess sekundärer. Rådgivaren hämtar replikeringsinformationen och skyddar replikeringsfördröjningen. Om fördröjningen blir för hög kommer den att skicka ut en varning eller ett kritiskt statusmeddelande.

MongoDB Replication Window Advisor

Utöver replikeringsfördröjningen är replikeringsfönstret ett viktigt mått att titta på. MongoDB-oploggen är en enda samling, som har begränsats i en (förinställd) storlek. När oploggen når slutet och en ny transaktion måste lagras, kommer den att vräka den äldsta transaktionen för att göra plats för den nya transaktionen. Replikeringsfönstret speglar antalet sekunder mellan den äldsta och senaste transaktionen i oploggen.

Detta mått är mycket viktigt eftersom du behöver veta hur länge du kan ta en sekundär ur replicaSet, innan den inte längre kommer att kunna komma ikapp mastern på grund av att den ligger för långt efter i replikeringen. Om en sekundär också börjar släpa efter, skulle det vara bra att veta hur länge vi kan tolerera detta innan sekundären inte längre kan komma ikapp.

I MongoDB-skalet finns en funktion tillgänglig för att beräkna replikeringsfönstret. Denna rådgivare i ClusterControl använder funktionen för att göra samma beräkning. Fördelen skulle vara att du nu kan bli varnad om ett för kort replikeringsfönster.

MongoDB Un-Sharded Databases and Collections Advisor

I ett shardt MongoDB-kluster tilldelas alla odelade databaser och samlingar till en standard primär shard av MongoDB-shardroutern. Denna primära shard kan variera mellan databaser och samlingar, men i allmänhet skulle detta vara den shard som har mest tillgängligt diskutrymme.

Att ha en odelad databas eller samling utgör inte omedelbart någon risk för ditt kluster. Men om en applikation eller användare börjar skriva stora mängder data till en av dessa, kan den primära skärvan fyllas snabbt och skapa ett avbrott på denna skärva. Eftersom databasen eller samlingen inte är delad kommer den inte att kunna använda andra skärvor.

Av denna anledning har vi skapat en rådgivare som kommer att förhindra att detta händer. Rådgivaren kommer att skanna alla databaser och samlingar och varna dig om den inte har klippts.

Kontroll av autentisering aktiverad

Utan att aktivera autentisering i MongoDB kommer alla användare som loggar in att behandlas som en admin. Detta är en allvarlig risk eftersom administratörsuppgifter, som att skapa användare eller göra säkerhetskopior, nu har blivit tillgängliga för alla. Detta i kombination med exponerade MongoDB-servrar, resulterade i de senaste MongoDB lösenhack, medan en enkel aktivering av autentisering skulle ha förhindrat de flesta av dessa fall.

Vi har implementerat en rådgivare som verifierar om dina MongoDB-servrar har autentisering aktiverad. Detta kan göras explicit genom att ställa in detta i konfigurationen, eller implicit genom att aktivera replikeringsnyckelfilen. Om den här rådgivaren inte kan upptäcka att autentiseringen har aktiverats bör du omedelbart agera på detta, eftersom din server är sårbar för att äventyras.

Autentiserings-/auktoriseringskontroll

Bredvid den autentiseringsaktiverade rådgivaren har vi också byggt en rådgivare som utför en förnuftskontroll för både autentisering och auktorisering i MongoDB.

I MongoDB är autentiseringen och auktoriseringen inte placerad på en central plats, utan utförs och lagras på databasnivå. Normalt kommer användare att ansluta till databasen och autentisera mot databasen de tänker använda. Men med rätt anslag är det också möjligt att autentisera mot andra (icke-relaterade) databaser och ändå använda en annan databas. Normalt är detta helt okej, såvida inte en användare har överdrivna rättigheter (som administratörsrollen) över en annan databas.

I den här rådgivaren verifierar vi om dessa överdrivna roller finns och om de kan utgöra ett hot. Vi kontrollerar också samtidigt efter svaga och lätta att gissa lösenord.

Felidentifiering (ny rådgivare)

I MongoDB kommer alla fel som uppstår att räknas eller loggas. Inom MongoDB finns det en stor variation av möjliga fel:användarpåståenden, vanliga påståenden, varningar och till och med interna serverundantag. Om det finns trender i dessa fel är det troligt att det antingen finns en felkonfiguration eller ett programproblem.

Denna rådgivare kommer att titta på statistiken över MongoDB-fel (påstår) och förstår detta. Vi tolkar trenderna som hittats och råd om hur man kan minska fel i din MongoDB-miljö!