Налаштування Yandex Monitoring і Cloud Logging під ключ

Налаштування Yandex Monitoring: чому сповіщення надходять пізно

Метрики збираються, дашборди відкриваються, правила оповіщення заведені — а першим про відмову повідомляє користувач.

Так виглядає типова картина, коли налаштування Yandex Monitoring зроблено формально: збір метрик працює, але шлях від початку деградації до сигналу вимірюється десятками хвилин, і весь цей час збій накопичується в черзі, у незавершених операціях і у відмовах, які вже отримали клієнти.

Пізні сповіщення про відмову — наслідок не збору даних, а правила. Вікно усереднення в кілька хвилин згладжує сплеск, період обчислення додає ще стільки ж, а поріг виставлено на абсолютному значенні, без базової лінії та добової сезонності конкретного сервісу.

Звідси два ефекти одразу: сигнал надходить, коли лічильник уже пройшов критичну позначку, а частина коливань дає хибні спрацювання — і канал повідомлень поступово починають ігнорувати.

Далі — класи відмов, які не видно взагалі. Пропущені відмови сервісів зазвичай виглядають як «зелена» метрика за реальної деградації: зростає черга фонових завдань, падає частка успішних відповідей на окремому маршруті, зависає обробник, відповідає один екземпляр із кількох.

Друга причина — метрики та журнали живуть незв’язано: зростання кількості помилок видно в записах, але не виведено в лічильник, і за журналом не можна відрізнити системний збій від поодиноких повідомлень.

Розбираємо нижче, як це закривається: зв’язкою метрик, записів журналу та правил із коректним вікном, розміткою за сервісами й середовищами, а також ескалацією, яка не залишає нічну відмову без адресата.

Що змінюється після впровадження: виявлення, розбір, чергування

До впровадження відмову помічає користувач: він пише в підтримку, підтримка шукає чергового, черговий відкриває консоль — час до виявлення вимірюється десятками хвилин і залежить від того, хто першим помітив.

Після впровадження метрики знімаються з застосунків, вузлів і балансувальника, правила порівнюють їх із базовою лінією, і сигнал про деградацію надходить черговому за хвилини — до того, як посипалися запити.

Другий ефект — шум. Пороги рахуються за перцентилями, а не за середніми, правило вимагає стійкого відхилення в кількох вікнах поспіль, а дублі одного збою склеюються в один інцидент.

Частка хибних спрацювань падає з половини до одиниць відсотків, і канал чергування перестає ігноруватися.

Спостережуваність сервісів зводиться в один контур: метрики, журнали й трасування зв’язуються спільним ідентифікатором запиту, у кожного сервісу — панель із залежностями та затримками.

У Yandex Monitoring лежать метрики й правила, поруч — журнали застосунків і вузлів, тому шлях від спрацьованого правила до конкретного запиту займає хвилини.

Розбір інциденту за логами перестає бути археологією: записи структуровані, пошук іде за полями — код відповіді, маршрут, ідентифікатор запиту, тривалість. Частка інцидентів, де контекст готовий у момент спрацювання, зростає з третини до більшості.

Чергування стає передбачуваним: замість потоку шуму інженер отримує опис проблеми, графік і посилання на логи, а після закриття інциденту правило доопрацьовується — наступна така сама відмова ловиться раніше.

Варіанти збору телеметрії: що підійде вашому контуру

Спосіб збору телеметрії обирають не за зручністю, а за тим, звідки дані фізично можна забрати. У Yandex Monitoring і Cloud Logging вони потрапляють чотирма шляхами: агент з вузла, програмний інтерфейс провайдера, публікація із самого застосунку та комбінація цих способів.

В одному контурі способи зазвичай поєднуються, тому обирати «один на все» не потрібно — важливіше розуміти обмеження кожного. Нижче порівняння за умовами застосовності.

Етапи впровадження: від аудиту джерел до передачі в експлуатацію

Моніторинг не починається зі встановлення агента — він починається з інвентаризації того, що взагалі можна знімати, і з відповіді на питання, які сигнали справді означають деградацію сервісу, а які просто шумлять. Порядок робіт ми тримаємо однаковим, змінюється лише набір джерел і режими знімання.

1. Аудит джерел телеметрії. Обходимо сервіси, бази, черги, балансувальники, контейнери та віртуальні машини; фіксуємо, де метрики й логи вже віддаються штатно, де потрібен експортер, а де доведеться додати точки знімання в код.
2. Схема збору метрик і логів. Розводимо, що знімаємо опитуванням, а що відправкою із застосунку, які мітки потрібні для розбивки за сервісом, середовищем і роллю вузла, задаємо строки зберігання та агрегацію лічильників.
3. Розгортання збору та маршрутів. Піднімаємо агенти, приймачі логів і правила маршрутизації: гарячий пошук окремо від довгого зберігання, налагоджувальні потоки відсікаються на вході, щоб обсяг не зростав безкінечно.
4. Налаштування порогів сповіщень. Пороги рахуємо від звичайного профілю навантаження, а не «на око»: помилки, затримка, насичення диска й пам’яті, недоступність. Далі — маршрути чергувань, групування та придушення повторів, щоб черговий отримував один дзвінок за інцидентом.
5. Зв’язка метрик із логами та панелі. З графіка переходимо в конкретне вікно логів за часом і мітками — розбір іде без ручного зіставлення вивантажень із різних систем.
6. Перевірка на аварійних сценаріях. Вимикаємо вузол, переповнюємо диск, виводимо з ладу залежність, вносимо затримку. Дивимося, чи спрацював сигнал, чи дійшов до потрібного чергового і чи вистачило даних, щоб зрозуміти причину.
7. Передача в експлуатацію. Інструкції на типові спрацювання, регламент чергувань, правила перегляду порогів і навчання команди.

Після передачі контур живе без нас: команда замовника додає нові сервіси в схему збору самостійно, за описаними правилами розмітки та маршрутизації.

Що залишається у вашому контурі: артефакти й регламенти

Розгортання закінчується не зеленими галочками в інтерфейсі, а тим, що команда замовника може сама підняти контур, пояснити інженеру на чергуванні, чому спрацювало оповіщення, і додати новий сервіс у спостереження без нашої участі.

Тому все, що ми налаштовуємо, віддаємо у вигляді файлів і текстів у вашому репозиторії та базі знань — з історією змін і зрозумілим власником у кожного артефакту.

• Конфігурації збору. Опис джерел метрик і логів, правила розбору рядків, строк зберігання та ротація, прив’язка сервісів до проєктів і середовищ — у вигляді файлів, які лежать поряд із кодом і проходять рев’ю як звичайна зміна.
• Конфігурації оповіщень. Пороги, вікна усереднення, групування пов’язаних сигналів, маршрутизація за каналами та правила придушення повторів: зрозуміло, яку умову вважаємо інцидентом, а яку — фоном.
• Політики доступу до логів. Ролі за проєктами й командами, розмежування чутливих полів, маскування персональних даних на вході та строк їх зберігання — з обґрунтуванням, чому обрано саме таку межу видимості.
• Схема потоків телеметрії. Від точки знімання до панелі та отримувача оповіщення, з позначеними вузькими місцями й поведінкою за недоступності проміжної ланки.
• Панелі за сервісами. Набори графіків із порогами, прив’язані до власників: черговий бачить стан сервісу на одному екрані, а не збирає картину з десяти запитів.
• Регламент чергування. Графік, зони відповідальності, порядок ескалації, час реакції за класами подій і правило, за яким сигнал іде далі першої лінії.
• Інструкція з розбору інцидентів. Покроковий порядок дій, типові сценарії з готовими запитами до метрик і логів, місця фіксації висновку та розбір після закриття.
• Передача в експлуатацію. Доступи з розподілом прав, приймальні перевірки на відмову вузла, коротке навчання чергової зміни та перелік завдань, які залишаються на вашій стороні.

Усе перелічене — не додаток до звіту, а робочий контур: його можна передати новій зміні, перевірити на навчаннях і розширювати в міру зростання сервісів. Опишіть задачу — повернемося з оцінкою та планом, у якому порядку це розгортається на вашій інфраструктурі.

Кейс: як скоротили час до виявлення відмови

До: відмову виявляли за скаргами

У клієнта — сервіс із постійним потоком запитів, але сплеск помилок помічали не чергові, а користувачі.

Інженер відкривав логи за часом скарги й вручну зіставляв записи кількох сервісів: час до виявлення сягав 40–50 хвилин, а причина часто залишалася неясною, бо метрик не збиралося взагалі. Довгі відновлення та повторні відмови з тієї самої причини були нормою.

Що зібрали

Налаштували збір метрик застосунку та вузлів у Yandex Monitoring, а логи звели в Cloud Logging з єдиними полями запиту й трасування.

Вийшла одна панель спостереження: частка помилкових відповідей, затримка на повільних викликах, глибина черг, збої зовнішніх залежностей — поряд із графіком релізів і навантаженням.

Оповіщення повісили на симптоми, а не на кожен нездоровий вузол, щоб черговий бачив один сигнал замість лавини.

Метрики до та після

Виявлення — 3–5 хвилин замість 40: сигнал надходить із системи, а не з підтримки. Частка інцидентів, знайдених до звернень користувачів, зросла приблизно до 9 із 10. Розбір причини скоротився з годин до хвилин — за трасуванням видно, який виклик і який реліз дав просідання.

Повторні відмови майже зникли: після першого сигналу поріг і правило оповіщення уточнюються, і та сама ситуація ловиться раніше.

Чим відрізняється оповіщення від панелі спостереження і що впроваджувати першим

Панель спостереження й оповіщення — різні інструменти, і плутати їх дорого. Панель відповідає на питання «що відбувається і чому», оповіщення — на питання «хто і коли має втрутитися». Панель пасивна: вона чекає, поки на неї подивляться, а вночі дивитися на неї нікому.

Тому порядок впровадження спостережуваності та збір телеметрії починаються не з графіків. Спочатку метрики й логи — без них нема чого порівнювати.

Потім 3–5 правил на найпомітніший для користувача симптом: зростання частки помилок, падіння доступності, час відповіді вищий за звичайний. І лише після цього — панелі, які роблять розбір інциденту швидким.

Оповіщення будується на симптом, а не на причину. Користувач помічає зростання часу відповіді, а не заповнений диск, — отже, правило ставиться на затримку й частку помилок, із вікном підтвердження, щоб одиничний сплеск не піднімав чергового дарма.

Логи тримаємо поряд із метриками, в одному контурі Yandex Monitoring: за сигналом одразу видно, який вузол або реліз став джерелом. Причини розбирають уже за панеллю.

Небезпечні обидві крайнощі. Панелі без оповіщень створюють відчуття контролю: графіки гарні, але дізнаєтеся ви про збій від клієнта. Оповіщення без панелей дають зворотний ефект — черговий отримує сигнал, але шукає джерело навмання, і відновлення затягується.

Критерій готовності контуру простий: на кожен критичний сценарій є і правило, і панель, а перевірка — навчальний збій, який приводить до повідомлення потрібної людини. Починати варто з одного сервісу й розширювати контур у міру того, як попередній перестає шуміти.

Технічні сумніви перед стартом: відповідаємо по суті

Перед стартом випливають ті самі питання — від відповідей залежить обсяг робіт і те, як система поводитиметься через пів року. Нижче — короткі відповіді по суті.

У нас уже развёрнут сторонний сбор. Всё переписывать?

Ні. Працюючий контур залишається джерелом, ми підключаємо його до Yandex Monitoring і поступово переносимо правила перевірок. Попередній збір не чіпаємо до моменту виведення — відкат до нього займає хвилини.

Где и сколько хранить логи?

Строк задається політикою зберігання за типами подій: операційні зберігаються коротше, аудит і події доступу — довше. Ротація, стиснення та вивантаження в холодне сховище налаштовуються одразу, щоб обсяг не зростав безконтрольно.

Как убрать шум в оповещениях?

Поріг рахуємо за відхиленням від базової лінії, а не статичний, пов’язані спрацювання групуємо в одне повідомлення та розводимо за критичністю. Черговий отримує одиниці повідомлень за зміну замість сотень.

Кто сопровождает систему после передачи?

Передаємо конфігурації, схеми та регламент чергування; правила описані як код і версіонуються. Далі їх веде ваша команда — або ми залишаємося на супроводі за узгодженим режимом.

Обговоримо задачу — повернемося з оцінкою та планом робіт

Щоб розмова зайняла один захід і одразу дала оцінку, а не серію уточнювальних питань, варто підготувати ввідні щодо інфраструктури. Нижче — чек-ліст перед стартом: він покриває те, що реально впливає на обсяг робіт із налаштування Yandex Monitoring і Cloud Logging.

• Перелік сервісів і контурів, за якими потрібен контроль: продуктив, передпродуктивне середовище, ізольовані сегменти.
• Що вже збирається: джерела метрик і логів, куди вони пишуться, чим знімаються — самописні агенти чи штатні засоби платформи.
• Критичні сценарії: які відмови мають піднімати чергового раніше, ніж про них напише користувач, і за якими ознаками їх ловити.
• Доступи й ролі: сервісні облікові записи, хто з команди що бачить, чи потрібна ізоляція між підрозділами.
• Вимоги до зберігання: строк життя логів і метрик, чи потрібно тримати дані всередині контуру.
• Поточна практика чергувань: як надходять оповіщення і куди — пошта, месенджер, телефон чергового.

Далі порядок простий. Обговорюємо задачу спостережуваності: які сигнали важливі, що вже налаштовано, де вузькі місця. Повертаємося з оцінкою та планом робіт — за етапами, зі складом панелей моніторингу, правил оповіщення та зрозумілими строками.

Після узгодження обсягу стартуємо: спочатку базовий збір метрик і логів, потім оповіщення та розбір хибних спрацювань.