SmartMonitoring — моніторинг бізнес-логіки в Однокласниках



Зараз у нас в Однокласниках є чотири географічно розподілених дата-центру, 11 тис. серверів, більше 1 тис. мережевих пристроїв, 180 сервісів. Під сервісами ми розуміємо фото, відео, музику, стрічку і т. д. Щодня сайт відвідують десятки мільйонів унікальних користувачів. І за всім цим господарством необхідно стежити, чим і займаються:

  • команда інженерів, яка встановлює обладнання, змінює диски, вирішує hardware-інциденти;
  • команда моніторингу, яка якраз шукає ці інциденти і віддає в роботу іншим командам;
  • мережеві адміністратори, вони працюють з мережею, налаштовують обладнання;
  • системні адміністратори, вони адмініструють і налаштовують портал;
  • розробники.
Ми самі встановлюємо і налаштовуємо наші сервери, але так як їх дуже багато, то неминуче, що кожен день щось ламається. І наша найголовніша задача в такому випадку — побачити поломку швидше користувачів. Тому за роботу всього порталу відповідає ціла команда моніторингу. Вони переглядають графіки, шукають у них аномалії, заводять інциденти, розподіляють «автоинциденты», які створюються за допомогою зв'язки Zabbix + JIRA. Ми не просто моніторимо бізнес-логіку, але і автоматично її аналізуємо. Детальніше про це я розповім далі.

Зупинимося на перегляді графіків і пошуку аномалій. Які у нас графіки, що таке аномалія, що таке інцидент?



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



Екскурс у минуле
Раніше, коли портал за всіма показниками був сильно менше, ми робили дашборды з графіками, яких було небагато — всього десь 100-200 штук. Але Однокласники росли і розвивалися, з'являлися все нові сервіси, графіків ставало все більше і більше.

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

В годину команда моніторингу обробляла 650 графіків, розбитих на чотири дашборда, кожен з яких хлопці з команди переглядали з певним інтервалом. Інтервал перегляду кожного дашборда свій (від 15 хвилин до години). За восьмигодинну зміну через чергового проходило в середньому 7 тис. графіків, іноді більше. Багато. З цим потрібно було щось зробити. Адже доводилося не тільки моніторити тисячі графіків, але і розслідувати інциденти. Це дійсно складно і довго, тому що до вирішення проблем (а у величезній системі рівня Однокласників якісь проблеми з залізом або софтом виникають постійно, це аксіома великих систем) підключалися і підключаються ще і розробники, і адміни. До того ж при ручному моніторингу волею-неволею завжди щось пропускалося.

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

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

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



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



Але є одна маленька проблема: у нас 11 тисяч серверів. Такий граф вийшов би величезним, побудувати і наочно промалювати його складно. Рішення напрошується. Кожен сервер грає якусь роль в інфраструктурі, тобто у нього є свій (мікро-)сервіс, всього їх 280 штук: стрічка новин, особисті повідомлення, соціальний граф (наприклад, граф дружб) та ін. і щоб зменшити граф зв'язків серверної інфраструктури, ми вирішили згрупувати фізичні сервери по функціональності, фактично виділивши кластери, які обслуговують ту чи іншу підсистему в Однокласниках. Великі микросервисы типу веб-серверів, кешей і серверів бізнес-логіки ми розділили по дата-центрам.

В результаті такої угруповання по кластерах граф сильно зменшився: залишилося близько 300 вершин і 2,5 тис. ребер між ними. Це допомогло побудувати граф того, як насправді працює портал Однокласники:



По колу розташовані микросервисы. Лінії — це взаємозв'язки. На даній картинці виділений один микросервис (вгорі праворуч). Зелені лінії — куди ходить цей микросервис, а коричневі — хто ходить до нього. Ми намагалися по-різному розташувати вершини графа на площині, тому що без гарної візуалізації граф топології було складно якось використовувати. Думали зробити його динамічним та підсвічувати проблемні зв'язку, тобто ті, на графіках яких є аномалії, але це не працює: граф дуже великий.

Але навіщо показувати весь граф завжди? Ми вирішили повернутися до вихідної задачі і подивитися на нього в момент реального інциденту. І через кілька днів такий випадок представився — виникла аномалія в системі особистих повідомлень: користувач хотів написати повідомлення, але у нього дуже довго подгружалась історія листування. Відмінний кейс! Ми вирішили перебудувати граф, залишивши тільки ті зв'язки, в яких є аномалія. Ось що у нас вийшло:



Синім кольором показане час між двома микросервисами (в кожному микросервисе різну кількість серверів), жовтий колір — кількість запитів, а фіолетовий — помилки. Швидко стало зрозуміло, що це не просто нова в'юшка для графа. Граф реально вказував на проблему. Проблему стало видно! Якщо говорити мовою сухих цифр, тривалість запитів мобільних веб-серверів серверів сервісу повідомлень в момент описуваного інциденту збільшилася десь на 0,5 мс. Час відгуку серверів бізнес-логіки до messaging proxy — на 10 мс. І найголовніше, середня latency запитів до сховища даних збільшилася на 40 мс. З'явилися помилки, викликів до бази стало менше: ймовірно, не всі користувачі чекали кінця завантаження історії повідомлень, вони закривали вікно листування. З цього графу відразу стало видно, куди копати — кластер messaging-conversation-cdb, який зберігає історію листування. Іншими словами, причина очевидна: остання ланка графа, як раз там і зростання часу найбільш значний.

Протестувавши цей підхід ще кілька разів, ми зрозуміли, що він працює. Нам дуже сподобалася ідея з побудовою графа проблемних взаємозв'язків, і ми вирішили розвивати систему далі, не зупиняючись тільки на статистиці взаємодії серверів. Ми також стали аналізувати статистику віддачі контенту з веб-серверів: час, помилки, запити, трафік. Додали моніторинг платежів (грошей) — часто ми дізнаємося про проблеми у наших платіжних агрегаторів швидше, ніж вони самі, про що і повідомляємо їм, відправляючи «листи щастя». Крім того, ми почали моніторити логіни по країнам як в мобільному, так і в веб-версії і додали різні технічні графіки. У результаті зараз ми в режимі реального часу моніторимо 100 тис. графіків. Це дійсно багато!

Архітектура системи

Всі логи пишуться в Data Warehouse. Це централізована система сховища статистики, побудована на Druid'о. За добу туди потрапляє 3 трильйони подій, які після агрегації поміщаються в 3 мільярди записів, або близько 600 Гб. Сервіс Data Collector, написаний .NET, забирає необхідні для системи дані (ми моніторимо не всі графіки, деякі створені для інших цілей) і кладе їх у Storage — базу на MSSQL, сховище підготовлених для аналізу даних. Anomaly Detector забирає дані і аналізує, допомагаючи шукати аномалії в числових послідовностей. Якщо він бачить аномалію, позначає і кладе результат назад в Storage. Application Server (також написаний .NET) ходить до Storage за даними про знайдені аномалії і до додаткових сервісів (типу нашої JIRA, системи управління порталом, LiveInternet — там ми дивимося активність по всьому рунету), готує всю інформацію і передає веб-клієнта.

Самий цікавий модуль тут — Anomaly Detector — являє собою написаний .NET сервіс. Ось як він працює.



Вхідні дані — те, що ми повинні давати системі для навчання.



Це значення, які були в такій же момент часу 7, 14, ..., 42 дні тому, ми беремо шість тижнів (тобто якщо сьогодні понеділок, то в навчальну вибірку йдуть всі понеділки). Беремо значення в той момент часу, який аналізується зараз, плюс два сусідніх значення — як зліва, так і справа. Це робиться для нормального розподілу вибірки. Якщо в той момент система зазначила якісь значення як аномальні, то вони не включаються до вибірки.

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



З графіка випливає, що аномалія виникла в 6:30 ранку. А ось так це бачить наша система на базі тесту Граббса:



Зліва значення, які були раніше в цей же проміжок часу, плюс-мінус два значення ліворуч і праворуч. Знизу поточне значення. Тест Граббса каже, що це аномалія, виявлено викид. Далі ми робимо фільтрацію. Фільтрація — це боротьба з помилковими спрацьовуваннями, тому що тест Граббса знаходить все, але для нас це не завжди аномалії. Ось які бувають «помилкові аномалії».

Незначне відхилення від тренду


На графіку показано середнє час запитів однією з зв'язку микросервисов. Червона лінія (розглянутий день) йде трохи вище решти днів. Тут дійсно є відхилення, і тест Граббса його знайде, але для нас він некритичний. Ситуація двояка: нам важливо виявити аномалію, але без помилкових спрацьовувань. Досвідченим шляхом ми прийшли до того, що для нас некритично відхилення на 20 % і на 15 % за запитами. Правда, не на всіх зв'язках, а лише на основних. Тому в даному випадку зв'язок не буде відзначена як аномалія. Але повторюся, якщо б це був графік важливою зв'язку, такий як час від веб-серверів до серверів бізнес-логіки, вона була б відзначена як аномалія, так як, швидше за все, ефект для користувачів незначний; потрібно розбиратися, поки він не став помітний.

Сильно зашумлені графіки


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

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



Робота з мережею
При роботі з мережею частенько відбувається unicast storm, який засмічує мережу, і тому час взаємодії двох микросервисов майже завжди ненадовго, але значно зростає. Тому ми відстежуємо виникнення unicast storm в дата-центрах (було надіслано відразу багато пакетів?). Якщо виявляється шторм, то ми показуємо дата-центр, в якому він відбувся, а чергові з'ясовують причини.

Сезонне коливання активності


Це картинка за 30 квітня: перед великими святами люди роз'їхалися на відпочинок, і червона лінія з 8:00 пішла трохи нижче. І таке по всіх сервісів. Ми розуміємо, що це вплив сезонності і треба перебудовувати алгоритм. Тоді включаємо інший алгоритм, який знає приблизні відхилення користувацької активності; він дивиться на онлайны та інші метрики, переосмислює їх і не відображає подібні спрацювання.

Як працює система?
Члену команди моніторингу приходить граф, або просто зв'язок, і він може зробити з нею чотири речі:

  • Позначити як певну аномалію, щоб вона пішла на час. Припустимо, користувач знає, чому вона сталася. Якийсь програміст сказав: «Я зараз включу якийсь функціонал, тут час зросте, і я його через дві години вимкну». Користувач зі спокійною душею описує все в потрібних полях, і ця подія тимчасово його не турбує.
  • Створити інцидент. Він заводиться в самій системі і автоматично з'являється в JIRA (створюється JIRA ticket, куди передається вся необхідна інформація про інцидент).
  • додати новий тренд. Припустимо, програміст чимось доповнює свій сервіс і очікує збільшення тривалості запиту. З цього моменту потрібно інакше аналізувати графік, і користувач вказує, що почався новий тренд.
  • Нічого не зробити, якщо, припустимо, з'явилося якесь помилкове спрацьовування.
Можливості системи, полегшують роботу з нею:

  • Якщо з якихось графом вже виникали проблеми, то система підкаже, чим це було викликано. Ми зберігаємо всі позначки користувачів, якими вони маркують графи.
  • Зв'язок з JIRA. Інциденти створюються в системі моніторингу і автоматично з'являються в JIRA. Система перевіряє статуси інцидентів: буває, що користувач створив інцидент і забуває його оновлювати, а якщо на зв'язку є інцидент без часу завершення, то такі зв'язки не показуються. Якщо в цей момент проблема посилюється, тоді система скаже про це. Те ж саме і з уже відомою аномалією. Якщо черговий ненадовго сховав аномалію як відому, але вона посилилася, то система підкаже, що треба подивитися ось ці графіки.
  • Зв'язок із системою конфігурації. У нас є система конфігурації порталу, за допомогою якої програмісти вносять зміни до порталу. Користувач бачить якийсь граф і може подивитися, які зміни на порталі були в цей момент. Це дозволяє зрозуміти, який саме програміст доклав руку до проблеми, а значить, і допоможе з рішенням.
  • Якщо якому-небудь адміну або програмісту цікаво, що відбувалося з його (мікро-)сервісом, то він може подивитися, наприклад, які аномалії виникали вночі або за весь тиждень.
  • Система дозволяє працювати віддалено і спільно: якщо один користувач зазначає якийсь зв'язок відому як аномалію, то інший відразу ж бачить, хто і чому зазначив викид як аномалію і що саме сталося.
  • Графічний інтерфейс. Я відношу його до фічами.


    Картинка кликабельна

    Зліва таблиця, праворуч граф, зверху шапка. Таблиці та граф дублюються за змістом. Над графом відображається активність по всьому рунету і Однокласникам. Це потрібно для відстеження відхилень активності. Зліва вгорі — користувач бачить, скільки зараз на ньому відкритих інцидентів. Також там знаходяться вкладки за «автоинцидентам»; вони, як уже писалося вище, створюються за допомогою зв'язки Zabbix + JIRA, на яких спалахує кількість нових інцидентів, створених системою: HardWare, SoftWare, Network. Праворуч — вкладки, куди потрапляють оброблені зв'язку: Known Anomalies, Incidents, New Trends. На них же баблами з'являється кількість усугубилися проблем.
Результат роботи системи
Тепер ми моніторимо 100 тис. графіків, не пропускаємо інциденти, витрачаємо значно менше часу на розслідування. Всі нові сервіси автоматично ставляться на моніторинг. Зросла продуктивність команди. Будь адмін або програміст може зайти в систему і подивитися, що зараз відбувається, є якісь проблеми, великі або не дуже. Це допомагає і адмінам, і програмістам радіти життю.

Якщо хто-то з вас буде створювати таку систему, ми зробили список статей, які вам допоможуть. Ви знайдете їх за посилання.
Джерело: Хабрахабр

0 коментарів

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