Чому без моніторингу MongoDB Atlas збій помічають пізно
Кластер MongoDB Atlas рідко відмовляє одномоментно — частіше він деградує поступово. Час відповіді на важких запитах зростає на десятки відсотків, частина операцій уже не вкладається у відведений час, а графіки завантаження залишаються у звичному коридорі.
Моніторинг MongoDB Atlas потрібен не для того, щоб зафіксувати вузол, що впав, а щоб зловити такий тренд за дні до відмови.
Сценаріїв прихованої деградації кластера зазвичай чотири. Кількість з'єднань зростає трохи швидше за трафік, і вичерпання пулу з'єднань проявляється різким сплеском помилок у пік навантаження, хоча передумови накопичувалися тиждень.
Відставання репліки на вторинних вузлах робить читання з них застарілим: звіти та списки показують дані, яких уже немає. Додайте поступове зростання пам'яті та запити без індексу — і кластер підходить до межі, не показавши жодного червоного індикатора.
Перший сигнал про проблему майже завжди надходить від користувачів: «не завантажується», «дані не ті», «зникло замовлення».
Далі починається ручний розбір за журналами, де причину вже не відрізнити від наслідку, а без історії метрик за кілька тижнів неможливо зрозуміти, коли почалася деградація і що її запустило.
Розбираємо, як це закривається: які показники знімати з кластера, які пороги вважати аварійними і як пов'язати оповіщення з регламентом дій.
Що дає безперервний моніторинг навантаження та реплікації
Моніторинг без вимірюваних критеріїв вироджується в набір графіків, на які ніхто не дивиться до першої відмови.
Чек-лист нижче — те, що перевіряється на живій інсталяції MongoDB Atlas і у зв'язці Prometheus із Grafana: кожен пункт відповідає на питання «що змінилося в цифрах», а не «скільки панелей намальовано».
- Час виявлення інциденту — хвилини, а не години. Сигнал про зростання відставання реплік, заповнення дискового журналу та провали в черзі на запис знімається з кожного вузла, тому деградація фіксується на вході, а не за фактом недоступності бази.
- Частка хибних спрацювань — менше десятої частини. Порогові оповіщення прив'язані до поведінки системи в цей самий час доби та до швидкості зміни метрики, а не до одного статичного числа, тому планове резервне копіювання більше не піднімає чергового вночі.
- Непомічених класів відмов не залишається: зміна ролі репліки, зростання затримки на читання з вторинних вузлів, відмова брокера оповіщень — кожна подія потрапляє в окреме правило з явним отримувачем.
- Зрозуміло, де вузьке місце: навантаження розкладене за операціями, колекціями та індексами, а саме оповіщення містить метрику, величину відхилення та вузол — розбір починається без листування й дзвінків.
Такий набір правил перевіряється на навчальному сценарії: вимикаємо вузол, навантажуємо колекцію, дивимося, чи прийшов сигнал і за скільки. Пункт, який не спрацював, доопрацьовується до приймання, а не відкладається.
Способи збору метрик: вбудовані засоби, зовнішній контур, гібрид
Метрики Atlas доступні одразу за трьома каналами: панелі та API самого сервісу, push-експорт метрик у власну кінцеву точку та опитування кластера зовнішнім експортером.
Вбудований контур дає готові алерти та графіки без інфраструктури, але історію тримає недовго й оперує фіксованим набором порогів.
Повноцінне спостереження починається там, де метрики потрапляють у загальне сховище — тоді їх можна зіставляти з навантаженням застосунку та станом мережі.
Вибір між схемами зводиться до трьох питань: як глибоко потрібно зберігати історію, наскільки складені умови потрібні в алертах і скільки підтримки готові виділити.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Вбудовані засоби Atlas | Один кластер, базовий контроль доступності та ресурсів, немає власної системи спостереження | Коротке вікно історії, пороги лише за готовими умовами, немає склейки з метриками застосунків |
| Зовнішній контур: експортер і Prometheus із Grafana | Кілька кластерів, єдині правила для всієї інфраструктури, тривале зберігання | Потрібні доступи до кластера та окрема інфраструктура спостереження, метрики надходять із затримкою опитування |
| Гібридна схема: експорт метрик у загальне сховище плюс вбудовані алерти | Критичні контури, де потрібен і швидкий сигнал, і розбір інцидентів за історією | Подвійне налаштування, ризик дубльованих повідомлень, потрібна синхронізація порогів |
На практиці вибір між зовнішнім контуром спостереження та гібридом упирається у трудозатрати на підтримку: експортер і скрейп дають гнучкість, але потребують стежити за доступом до реплік, іменами метрик і мітками.
У гібридній схемі окреме завдання — не дублювати алерти й не розводити пороги в двох місцях, інакше черговий отримує два повідомлення про один інцидент і перестає реагувати на обидва.
Ми зазвичай залишаємо вбудований контур для швидких сигналів про недоступність, а глибоку історію та складені умови виводимо в зовнішній.
Етапи налаштування: від аудиту схеми до передачі регламентів
Роботу починаємо не з увімкнення оповіщень, а з аудиту інсталяції: дивимося топологію реплік і шардів, розміри колекцій і профіль навантаження, кількість активних з'єднань, терміни зберігання логів і те, хто взагалі має доступ до кластера.
Без цієї карти будь-який набір порогів буде навмання — або мовчить на реальній деградації, або будить чергового вночі через плановий бекап. Налаштування моніторингу MongoDB Atlas будується так, щоб кожен сигнал мав власника та зрозумілу дію.
- Аудит інсталяції. Фіксуємо склад кластера, вузькі місця за індексами, ліміти з'єднань і поточні оповіщення з коробки — що вже налаштовано, а що дублюється.
- Схема метрик. Визначаємо показники здоров'я: затримка реплікації, черга операцій, частка повільних запитів, зростання дискових файлів, помилки автентифікації. Кожен показник прив'язуємо до бізнес-наслідку, щоб поріг було чим обґрунтувати.
- Підключення збору. Розгортаємо експортер метрик з окремим обліковим записом лише для читання, задаємо інтервал опитування та термін зберігання історії. Метрики стеку йдуть у загальне сховище — поруч із даними решти інфраструктури.
- Налаштування оповіщень. Розводимо рівні: попередження в робочий канал, критичне — на чергового. Пороги ставимо за відхиленням від базової лінії, а не за абсолютними значеннями, які застарівають при зростанні навантаження.
- Перевірка оповіщень. Проганяємо штучне навантаження та контрольовані відмови: вимикаємо вузол, заповнюємо диск, розриваємо реплікацію. Дивимося, що спрацювало, що промовчало, чи дійшло повідомлення до чергового і за який час.
- Регламент чергувань. Описуємо рівні критичності, порядок ескалації, вікна планових робіт і список типових дій за кожним сигналом.
- Передача команді. Віддаємо панелі спостереження, інструкції щодо типових інцидентів і розбір хибних спрацювань — ваші інженери ведуть систему без нас.
Що залишається в команди: конфігурації, панелі, регламенти
Ми не залишаємо моніторинг «сервісом на нашій стороні» — збираємо його всередині вашого контуру, щоб доступи, конфігурації та панелі залишалися у вашої команди. Нижче набір артефактів, з яким черговий працює без нас, а новий інженер розгортає збір у свіжому середовищі.
- Конфігурації збору — параметри агентів та інтеграції з API Atlas: період опитування, список баз і колекцій, винятки для службових просторів.
- Карта метрик — таблиця «показник → джерело → поріг → власник сервісу»: видно, звідки надходить цифра і кого будити при виході за межі.
- Панелі спостереження — огляди за рівнями: кластер і реплікація, вузли, з'єднання, черги операцій, профіль повільних запитів.
- Конфігурації оповіщень — правила з порогами, вікнами придушення, маршрутами повідомлень і ескалацією за рівнями чергувань.
- Інструкція чергового — порядок розбору: що дивитися першим, типові дії при збої, точка ескалації, фіксація інциденту.
- Правила доступу — ролі на панелі та оповіщення, окремі ключі з обмеженими правами й ротацією.
- Регламент ревізії — періодичність перегляду порогів, щоб оповіщення не перетворилися на шум, який перестають читати.
- Документація з розгортання — як підняти збір у новому кластері та що перевірити після підключення.
Усе це зберігається у вашому репозиторії та хмарному контурі: наша команда йде, працездатність моніторингу — ні.
Кейс: скоротили час виявлення збою, прибрали хибні спрацювання
До нас прийшов замовник із навантаженим кластером MongoDB Atlas: алерти стояли на процесор і середні значення метрик.
Поріг спрацьовував уже за фактом деградації, а половина нічних оповіщень виявлялася шумом — черговий піднімав розробника, і обидва дивилися на звичайний сплеск навантаження.
Що змінили в правилах
Алерти зібрали навколо сигналів, які передбачають відмову, а не фіксують її: відставання реплікації, вікно журналу операцій, частка повільних операцій, черга та утримувані курсори, зростання кількості підключень, помилки драйвера.
Пороги прив'язали до відхилення від стійкої норми на довгому вікні, коротке залишили лише для жорстких відмов — недоступності вузла або зміни первинного. Кожне правило отримало свій маршрут і коротку інструкцію, що перевірити першим ділом.
Метрики до і після
Час виявлення скоротився з десятків хвилин до двох-трьох: проблему бачить черговий, а не користувач. Частка хибних оповіщень упала з більшості нічних спрацювань до менше десятої частини — шум відсікли вікна та похідні метрики замість миттєвих порогів.
Частка інцидентів, які черговий закриває без розробника, зросла з чверті до більшості: на руках дашборд і порядок дій за кожним правилом. Нічні підйоми стали поодинокими — для команди це головний ефект.
Окремо пішов клас відмов, який раніше ловили за скаргами: вичерпання вікна журналу операцій на тлі відставання репліки. Тепер зростання відставання видно задовго до того, як вторинні вузли почнуть віддавати застарілі дані, — залишається запас часу, щоб втрутитися за регламентом.
Чим вбудовані оповіщення відрізняються від зовнішнього контуру
Вбудовані оповіщення Atlas — перший контур, який вмикають при виведенні кластера в роботу. Вони стежать за проєктними метриками: завантаження процесора та накопичувача, кількість активних з'єднань, відставання реплікації, обсяг операцій читання й запису, доступність вузла.
Поріг виставляється в інтерфейсі, повідомлення надходить на пошту, у месенджер або за зовнішньою адресою — цього достатньо, щоб зловити відмову вузла, вичерпання місця або розрослий трафік.
Далі починаються обмеження. Пороги статичні й живуть окремо від навантаження застосунку, вікно усереднення задає платформа, а глибина історії метрик обмежена її ж терміном зберігання.
Зіставити зростання навантаження з релізом тижневої давності або з перебудовою індексів уже не вийде — даних у потрібному вікні просто немає.
Зовнішній контур знімає ті самі метрики самостійно та складає їх у власну базу часових рядів. Глибину історії визначаємо ми: місяць для оперативних розборів, рік і більше для трендів і планування ємності.
Гнучкість порогів — наслідок: правила описуються запитами мовою Prometheus, комбінуються між собою, розрізняють «вузол недоступний» і «вузол не віддає метрики», спираються на швидкість зміни, а не лише на абсолютне значення.
На панелях кластер опиняється поруч із сервером застосунку, балансувальником і чергою. Інцидент видно повністю: сплеск часу відповіді, зростання кількості з'єднань і відставання репліки читаються за одним графіком, а не збираються з трьох інтерфейсів вручну.
Розбираємо, як це закривається: які метрики знімати в першу чергу, де ставити пороги і як пов'язати зовнішній контур із вбудованими оповіщеннями, щоб сигнали не дублювалися.
Часті технічні питання перед початком робіт
Перед стартом замовники перевіряють три речі: чи не доведеться чіпати код застосунків, чи витримає кластер підключення спостереження без зупинки і чи не потоне чергова зміна в алертах. Відповідаємо за кожним пунктом — це знімає більшу частину сумнівів ще до оцінки.
Моніторинг MongoDB Atlas збирається з двох потоків: службова телеметрія кластера та метрики з боку застосунків. Перший показує стан вузлів, реплікації, черг і дискового вводу-виводу, другий — як навантаження переживає конкретний сервіс. Нижче — технічні деталі, які найчастіше уточнюють на цьому етапі.
Чи доведеться змінювати код застосунків?
Для базового контуру — ні. Достатньо увімкнути збір метрик на боці кластера та підняти експортер, який віддає їх у систему спостереження.
Інструментування в код додаємо лише там, де потрібні метрики драйвера: стан пулу з'єднань, тривалість окремих операцій, частка повільних запитів. Це невеликий ізольований набір, він викочується у звичайному релізі та не змінює логіку роботи сервісу.
Кластер працює під навантаженням — як підключаєте спостереження?
Спостереження підключається на працюючому кластері та не потребує його зупинки. Агент читає службову статистику й не втручається в обробку запитів; споживання ресурсів під збір обмежуємо, щоб він не конкурував з робочим навантаженням. Ролинг-перезапуск і зміна топології на цьому етапі не потрібні.
Як відсікти шум від планових навантажень?
Пороги будуємо на відхиленні від базової лінії, а не на абсолютних значеннях: нічна реіндексація та резервне копіювання не повинні виглядати як інцидент. Вікна планових робіт і масових вивантажень позначаємо як очікувані — алерти за ними придушуються. У чергування потрапляє лише те, що потребує дії.
Де і як довго зберігаються метрики?
Збір іде в Prometheus, візуалізація та дашборди — в Grafana. Свіжі детальні дані тримаємо в оперативному сховищі, старі згортаємо в агрегати, тому обсяг зростає передбачувано, а не лінійно.
Терміни зберігання задаємо, виходячи з того, наскільки глибоко потрібно розбирати інциденти й порівнювати навантаження між сезонами.
Після цих відповідей зазвичай залишається узгодити склад алертів і регламент чергування — це вже предмет окремого розбору. Опишіть задачу: повернемося з оцінкою та планом робіт.Обговоримо задачу: надішліть схему — повернемося з планом
Щоб оцінка була предметною, а не «на око», до розмови достатньо додати кілька вхідних — ми розбираємо їх до дзвінка, тому зустріч іде по суті: уточнюємо прогалини й одразу переходимо до плану налаштування.
- топологію кластера: набір реплік або шардування, кількість вузлів, регіони розміщення, режим відмовостійкості;
- метрики, за якими ухвалюються рішення: затримка запитів, зростання колекцій, промахи кешу, кількість з'єднань, відставання реплік;
- що вже працює в оповіщеннях Atlas: пороги, отримувачі, канали доставки та хто розбирає спрацювання;
- доступи — на читання метрик, на зміну правил оповіщення, на рівні проєкту та організації;
- контур збору та візуалізації: залишаємося всередині Atlas або зводимо дані в єдиний збирач метрик із дашбордами;
- режим чергування та порядок ескалації: хто відповідає на нічне спрацювання і за яким правилом.
Окремо фіксуємо, що вважається нормою в пікові години навантаження — без цієї опорної лінії будь-який поріг буде довільним, а алерти почнуть або мовчати, або будити чергового без приводу.
Повернемося з планом налаштування: перелік правил та їхні пріоритети, спосіб перевірки кожного оповіщення на реальному збої, оцінку робіт за етапами та регламент передачі спостереження — щоб чергова зміна підтримувала систему без нас. Опишіть задачу у вільній формі, цього достатньо для старту.
