Мониторинг и защита на MongoDB с ClusterControl Advisors

Управлението на операциите на базата данни се състои от 80% четене и тълкуване на вашите системи за наблюдение. Стотици показатели могат да бъдат интерпретирани и комбинирани по различни начини, за да ви дадат задълбочена представа за вашите системи за бази данни и как да ги оптимизирате. Когато работите с множество системи за бази данни, наблюдението на тези системи може да се превърне в доста скучна работа. Ако тълкуването и комбинацията от показатели отнемат много време, няма ли да е чудесно, ако това може да бъде автоматизирано по някакъв начин?

Ето защо създадохме съветници за база данни в ClusterControl:малки скриптове, които могат да интерпретират и комбинират показатели вместо вас и да ви дават съвети, когато е приложимо. За MySQL създадохме обширна библиотека от най-често използваните проверки за мониторинг на MySQL. Но също така и за MongoDB имаме на ваше разположение широка библиотека от съветници. За тази публикация в блога сме избрали деветте най-важни за вас. Ще опишем подробно всеки един от тях.

Деветте MongoDB съветника, които ще разгледаме в тази публикация в блога, са:

• Проверка на опциите за монтиране на диск
• Numa check
• Процент на заключване на събиране (MMAP)
• Закъснение при репликация
• Прозорец за репликация
• Неразчленени бази данни и колекции (само разчленени клъстери)
• Проверка за активирано удостоверяване
• Проверка на автентичност/упълномощаване
• Откриване на грешки (нов съветник)

Съветник за опции за монтиране на диск

Много е важно вашите дискове да са монтирани по най-оптималния начин. Със съветника за опции за монтиране на диск ClusterControl ние разглеждаме по-отблизо вашия диск с данни всеки ден. В този съветник ние изследваме използваната файлова система, опциите за монтиране и настройките на io планировчика на операционната система.

Проверяваме дали вашите дискове са монтирани с noatime и nodiratime. Задаването им ще намали производителността на дисковете, тъй като при всеки достъп до файл или директория времето за достъп трябва да бъде записано на диска. Тъй като това се случва непрекъснато в бази данни, това е добра настройка за производителност и също така увеличава издръжливостта на вашите SSD дискове.

За файлови системи препоръчваме да използвате съвременни файлови системи като xfs, zfs, ext4 или btrfs. Тези файлови системи са създадени с мисъл за производителността. Препоръчва се ио планировчикът да е на noop или краен срок Краен срок е по подразбиране за бази данни от години, но благодарение на по-бързото съхранение като SSD дисковете noop Планировчикът има повече смисъл в днешно време.

Numa Check Advisor

За MongoDB активираме нашия NUMA проверете съветник. Този съветник ще провери дали NUMA (Памет за неравномерен достъп) е активирана във вашата система и ако случаят е такъв, да я изключите.

Когато паметта за неравномерен достъп е активирана, процесорът на сървъра може да адресира директно собствената си памет, но не и другите процесори в машината. По този начин процесорът може да разпределя памет само от собственото си пространство в паметта и разпределянето на нещо в излишък ще доведе до използване на суап. Тази архитектура има силно предимство в производителността на многопроцесорни приложения, които разпределят всички процесори, но тъй като MongoDB не е многопроцесорно приложение, това значително ще намали производителността и може да доведе до огромно използване на суап.

Процент на заключване на събиране (MMAP)

Като MMAP е файлова система за съхранение, тя не поддържа заключването на ниво документ, както се намира в WiredTiger и RocksDB. Вместо това най-ниското ниво на заключване за MMAP е колекцията брави. Това означава, че всяко записване в колекция (вмъкване, актуализиране или изтриване) ще заключи цялата колекция. Ако процентът на заключване става твърде висок, това показва, че имате проблеми със споровете в колекцията. Когато не се адресира правилно, това може да доведе до спиране на пропускателната способност на запис. Ето защо да ви предупреди съветник е много полезно.

Съветник за забавяне на репликацията на MongoDB

Ако мащабирате MongoDB за четене чрез вторични елементи, забавянето на репликацията е много важно, за да следите. Клиентските драйвери на MongoDB ще използват само вторични, които не изостават твърде много, в противен случай може да рискувате да обслужвате остарели данни.

Вътре в MongoDB основният ще следи състоянието на репликация на своите вторични. Съветникът ще извлече информацията за репликация и ще пази забавянето на репликацията. Ако изоставането стане твърде голямо, това ще изпрати предупреждение или съобщение за критично състояние.

Съветник за прозорец за репликация на MongoDB

Освен забавянето на репликацията, прозорецът за репликация е важен показател за наблюдение. MongoDB oplog е единична колекция, която е ограничена в (предварително зададен) размер. След като oplog достигне края и трябва да се съхрани нова транзакция, той ще изхвърли най-старата транзакция, за да освободи място за новата транзакция. Прозорецът за репликация отразява броя секунди между най-старата и най-новата транзакция в oplog.

Този показател е много важен, тъй като трябва да знаете за колко време можете да извадите вторичен набор от replicaSet, преди той вече да не може да настигне главния поради твърде много изоставане в репликацията. Освен това, ако вторичният започне да изостава, би било добре да знаем колко дълго можем да търпим това, преди второстепенният вече да не може да наваксва.

В обвивката на MongoDB е налична функция за изчисляване на прозореца за репликация. Този съветник в ClusterControl използва функцията, за да направи същото изчисление. Предимството би било, че сега можете да бъдете предупредени за твърде кратък прозорец за репликация.

Съветник за неразчленени бази данни и колекции на MongoDB

В разчленен MongoDB клъстер всички неразчленени бази данни и колекции се присвояват на първичен шард по подразбиране от рутера за шард MongoDB. Този първичен фрагмент може да варира между базите данни и колекциите, но като цяло това би бил сегментът с най-много налично дисково пространство.

Наличието на неразделена база данни или колекция не представлява веднага риск за вашия клъстер. Ако обаче приложение или потребител започнат да записват големи обеми данни в едно от тях, основният шард може да се запълни бързо и да създаде прекъсване на този сегмент. Тъй като базата данни или колекцията не са разделени, тя няма да може да използва други фрагменти.

Поради тази причина създадохме съветник, който ще предотврати това да се случи. Съветникът ще сканира всички бази данни и колекции и ще ви предупреди, ако не е разделен.

Проверка за активирано удостоверяване

Без да активирате удостоверяване в MongoDB, всеки потребител, който влиза, ще се третира като администратор. Това е сериозен риск, тъй като обикновено администраторските задачи, като създаване на потребители или създаване на резервни копия, вече са достъпни за всеки. Това, съчетано с открити MongoDB сървъри, доведе до скорошните хакове за откуп на MongoDB, докато простото активиране на удостоверяване би предотвратило повечето от тези случаи.

Внедрихме съветник, който проверява дали вашите MongoDB сървъри имат активирана автентификация. Това може да стане изрично, като зададете това в конфигурацията, или неявно чрез активиране на ключовия файл за репликация. Ако този съветник не успее да открие, че удостоверяването е активирано, трябва незабавно да действате по този начин, тъй като сървърът ви е уязвим, за да бъде компрометиран.

Проверка за автентичност/упълномощаване

До съветника с активирана автентификация, ние също така изградихме съветник, който извършва проверка за здравина както за удостоверяване, така и за оторизация в MongoDB.

В MongoDB удостоверяването и оторизацията не се поставят на централно място, а се извършват и съхраняват на ниво база данни. Обикновено потребителите ще се свързват с базата данни, удостоверявайки се спрямо базата данни, която възнамеряват да използват. Въпреки това, с правилните разрешения е възможно също да се удостоверите срещу други (несвързани) бази данни и все пак да използвате друга база данни. Обикновено това е напълно добре, освен ако потребителят няма прекомерни права (като ролята на администратор) върху друга база данни.

В този съветник проверяваме дали тези прекомерни роли присъстват и дали могат да представляват заплаха. Ние също така проверяваме в същото време за слаби и лесни за отгатване пароли.

Откриване на грешки (нов съветник)

В MongoDB всяка възникнала грешка ще бъде отчетена или регистрирана. В MongoDB има голямо разнообразие от възможни грешки:потребителски асерти, редовни асерти, предупреждения и дори вътрешни изключения на сървъра. Ако има тенденции в тези грешки, вероятно има или неправилна конфигурация, или проблем с приложението.

Този съветник ще разгледа статистиката на грешките в MongoDB (твърди) и ще разбере това. Ние интерпретираме откритите тенденции и съветваме как да намалите грешките във вашата среда MongoDB!