Що сталося, коли ми втомилися дивитися на графіки 5 000 серверів в моніторингу (і коли серверів стало більше 10 000)



Ми в Однокласниках займаємося пошуком вузьких місць в інфраструктурі, що складається більш ніж з 10 тисяч серверів. Коли ми злегка задолбались моніторити 5000 серверів вручну, нам знадобилося автоматизоване рішення.

Точніше, не так. Колись у сиву давнину з'явився приблизно 20-ї сервер, стали використовувати Big Brother — найпростіший моніторинг, який просто збирає статистику і показує її у вигляді дрібних картинок. Все дуже просто. Ні наблизити, ввести діапазони допустимих змін не можна. Тільки дивитися картинки. Ось такі:


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

Тому ми зробили нову систему моніторингу — і зараз на роботу з 10 тисячами серверів витрачаємо по 1-2 години в тиждень на обробку алертів. Розповім, як це влаштовано.

Чому це треба
Інцидент-менеджмент у нас був поставлений задовго до початку робіт. В «залізниці» частини сервери працювали штатно і добре обслуговувалися. Були складнощі з передбаченням вузьких місць і виявленням типових помилок. У 2013 році збій в Однокласниках призвів до того, що сайт був недоступний протягом декількох днів, про що ми вже писали. Ми винесли з цього уроки, і приділили дуже багато уваги саме запобігання інцидентів.

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

Трохи статистики
На початку 2013 року інфраструктура Однокласників складалася з 5000 серверів і систем зберігання даних. Ось зростання за два з половиною роки:



Обсяг зовнішнього мережевого трафіку (2013-2016), Gbit/s:



Обсяг збережених даних (2013-2016), Tb:



Показники роботи додатків, обладнання та бізнес-метрик відслідковуються командою моніторингу в режимі 24/7. У зв'язку з тим, що і без того велика інфраструктура продовжує активно рости, вирішення проблем з вузькими місцями в ній може зайняти істотну час. Саме тому одного оперативного моніторингу недостатньо. Щоб розібратися з неприємностями максимально швидко, потрібно прогнозувати зростання навантаження. Це робиться наступним чином: команда моніторингу раз на тиждень запускає автоматичну перевірку операційних показників усіх серверів, масивів і мережевих пристроїв, за підсумками якої отримує список всіх можливих проблем з обладнанням. Список передається системним адміністраторам і мережним фахівцям.

Що моніториться
На всіх серверах та їх масивах ми перевіряємо наступні параметри:

  • загальне навантаження на процесор, а також навантаження на окремо взяте ядро;
  • утилізацію диска (I/O Utilization) і дискову чергу (I/O (Queue). Система автоматично визначає SSD/HDD, так як ліміти на них різні;
  • вільне місце на кожному дисковому розділі;
  • утилізацію пам'яті, так як різні сервіси використовують пам'ять по-різному. Є кілька формул, які вираховують використану/вільну пам'ять для кожної серверної групи, враховуючи специфіку завдань, які треба вирішувати на конкретній групі (формула по дефолту: Free + Buffers + Cached + SReclaimable — Shmem);
  • використання swap та tmpfs;
  • Load Average;
  • трафік на мережеві інтерфейси сервера;
  • GC Count, Full GC Count і GC Time (мова про Java Garbage Collection).
На центральних свитчах (core) і маршрутизаторах перевіряється використання пам'яті, навантаження на процесор і, природно, трафік. На комутаторах рівня доступу трафік access-портів не моніторимо, так як його ми перевіряємо безпосередньо на рівні мережевих інтерфейсів серверів.

Аналітика
Дані збираються з усіх хостів за допомогою SNMP і потім акумулюються у систему DWH (Data Warehouse). Про DWH ми розповідали на Хабре раніше — у статті BI в Однокласниках: збір даних та їх доставка до DWH. У кожному ЦОД стоять свої сервери для збору цієї статистики. Статистика з пристроїв збирається щохвилини. Дані вивантажуються в DWH кожні 90 хвилин. Кожен ЦОД генерує свій комплект даних, їх обсяг — 300-800 Mb за вивантаження, а це 300 Гб на тиждень. Дані апроксимуються, тому є можливість дізнатися точний час початку проблеми, що допомагає знайти її причину.

Всі сервери в залежності від своєї ролі в інфраструктурі розбиті на групи, на які навішуються thresholds (ліміти). Після перевищення ліміту пристрій потрапить у звіт. Угруповання всіх хостів відбувається у спеціально розробленій для цього системі Service Catalog. Так як ліміти навішуються на групу серверів, то нові сервери в групі автоматично починають моніторитися за таким же лімітам. Якщо адміністратор створив нову групу, тоді на неї автоматично навішуються жорсткі ліміти, і якщо сервери нової групи потрапляють на перевірку, то приймається рішення, нормально це чи ні. Якщо програмісти вважають, що це нормальна поведінка для групи серверів, ліміт піднімається. Для зручного керування лімітами створена панель управління, яка виглядає так:



У цій адмінці можна побачити всі унікальні групи серверів і їх ліміти. Наприклад, на скріншоті видно ліміти для групи achievements-cdb:

  • максимальне навантаження на процесор не повинна перевищувати 35 %;
  • формула для розрахунку навантаження на процесор 100 % — idle;
  • ліміт на дискову чергу для HDD-дисків — 2, для SSD — 10.
І так далі. Поправити який-небудь ліміт можна, лише посилаючись на задачу, у якій описані причини зміни. Вікно зміни ліміту:



На скріншоті перераховані всі поточні ліміти для групи серверів з можливістю їх зміни. Застосувати зміни можна тільки в тому випадку, якщо заповнене поле «Jira Ticket»; в нього записується завдання, в рамках якої вирішувалася проблема.

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

Що відбувається зі звітом
Звіт збирається по середах в один клік. Потім один з п'яти «денних» інженерів знімається з звичайного «патрулювання» ресурсу і роботи з управління тікетами, і починає читати звіт. Перевірка займає не більше півтора годин. У звіті — список всіх можливих проблем в інфраструктурі, як нових, так і старих, які ще не вирішені. Кожна проблема може стати алертом адміну, а сисадмін вже вирішує — відразу поправити або завести тікет.



На зображенні показано початкове вікно перевірки. Користувач може натиснути на відповідну кнопку і запустити автоматичну перевірку: «Servers» — всіх серверів, Nw CPU Mem» — використання пам'яті і процесора на мережевих пристроях, «Nw Traffic» — трафіку на центральних свитчах (core) і маршрутизаторах.

Система інтегрована з JIRA (система управління завданнями). Якщо проблема (перевищено ліміт) вже вирішується, навпроти неї знаходиться лінк на тікет, в рамках якого ведеться робота над проблемою або яким вона викликана зі статусом тікета. Так ми бачимо, в рамках якої задачі проблема вирішувалася раніше — тобто буде тікет зі статусом Resolve.



Все нові проблеми передаються старшим системним адміністраторам і старшим мережним фахівцям, які створюють тікети в JIRA для вирішення кожної проблеми окремо, потім ці тікети линкуются до відповідних проблем. У системного адміністратора є можливість запустити спеціальну перевірку по будь-якому параметру, достатньо вказати групу(-и) серверів, параметр ліміт, а система сама видасть всі сервери, які перевищили ліміт. Також можна подивитися графік по будь-якому параметру будь-якого сервера з лінією ліміту.

Приклад потрапляння сервера на радари:



Для самих великих груп серверів (web — front end, рівень бізнес-логіки і кеш даних користувачів) крім звичайної перевірки проводиться довгостроковий прогноз, так як для вирішення проблем з цими групами необхідні значні ресурси (обладнання, час).

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





На першій картинці ми бачимо використання CPU всіх груп web-серверів в окремо, на другий — загальне. Червоною лінією позначений ліміт. Жовта — прогноз.

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

Для кожної групи серверів з кроком в сім днів будуємо точки по наступній формулі (приклад для групи front end):

∑(n — max load — min, load)/(n — 2), де:

  • n — кількість серверів в групі;
  • max load — максимальне значення навантаження, яке протрималося більше 30 хвилин на кожному сервері окремо за весь тиждень. Складаємо всі значення навантажень по групі серверів;
  • min, load — мінімальне значення навантаження, обчислюється аналогічно максимального.
Для отримання більш точного прогнозу прибираємо один сервер з максимальною навантаженням і один з мінімальної. Цей алгоритм може здатися простим, однак він дуже близький до реалій, і саме тому винаходити складний аналіз не має сенсу. Таким чином для кожної групи серверів ми отримаємо щотижневі точки, за якими будується апроксимоване лінійна функція.

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



Система відкидає spare-диски (запасні диски в масиві), і вони не потрапляють в цю статистику.

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

  • розширити кластер photo;
  • збільшити диски в group1 і group2;
  • вирішити проблему з чергою на group3;
  • розібратися з GC на group4;
  • вирішити проблему з трафіком і навантаженням на server1 і server2;
  • вирішити проблему з swap на group5 і group6.
Всі ці завдання на момент їх постановки були не критичні, так як система виявила проблеми заздалегідь, що значно спростило роботу системним адміністраторам: їм не довелося кидати все, щоб вирішити проблеми за короткий відрізок часу.

Нові метрики
Іноді нам потрібні нові метрики. Це один-два нових показників на рік. Ми заводимо їх, найчастіше, за інцидентів, припускаючи, що якщо б чогось заздалегідь повідомило адміна, інциденту могло б і не бути. Однак іноді бувають потрібні свого роду милиці — наприклад, на кластері серверів з сховищем великих фотографій як-то було утилізовано простір на 80%. При розширенні ми не могли технічно перерозподілити фотографії, а моніторити хотіли на 70% заповнення. Утворилося дві групи — майже повні сервера, які генерували б алерт постійно, і нові, невинно чисті. Замість окремих правил довелося заводити віртуальну «фейковую» групу машин, яка поправила питання. Ще із прикладів — при масовому переході на SSD треба було правильно вибудувати моніторинг дискової черги, там дуже відрізняється типова поведінка від звичайних HDD.

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.