Сьогодні на нашому проекті крім монолітного коду функціонують десятки мікросервісів. Кожен із них вимагає того, щоб його моніторили. Робити це у таких обсягах силами DevOps-інженерів проблематично. Ми розробили систему моніторингу, яка працює як сервіс розробників. Вони можуть самостійно писати метрики в систему моніторингу, користуватися ними, будувати на їх основі дашборди, прикручувати до них алерти, які спрацьовуватимуть при досягненні порогових значень. З DevOps-інженерів — лише інфраструктура та документація.
Ця посада — розшифровка мого виступу з нашою на РІТ ++. Багато хто просив нас зробити текстові версії доповідей звідти. Якщо ви були на конференції або дивилися відео, то не знайдете нічого нового. А решті — ласкаво просимо під кат. Розкажу, як ми дійшли такої системи, як вона працює і як ми плануємо її оновлювати.
Минуле: схеми та плани
Як ми дійшли існуючої системи моніторингу? Для того, щоб відповісти на це питання, потрібно вирушити у 2015 рік. Ось як це виглядало тоді:
У нас існувало близько 24 вузлів, які відповідали за моніторинг. Тут є ціла пачка різних кронів, скриптів, демонів, які десь якимсь чином моніторять, відправляють повідомлення, виконують функції. Ми подумали, що що далі, то менш така система буде життєздатною. Розвивати її немає сенсу: надто громіздка.
Ми вирішили обрати ті елементи моніторингу, які ми залишимо і розвиватимемо, і ті, від яких відмовимося. Їх виявилося 19. Залишилися тільки графіти, агрегатори та Grafana як дашборд. Але як виглядатиме нова система? Ось так:
У нас є сховище метрик: це графіти, які базуватимуться на швидких SSD-дисках, це певні агрегатори для метрик. Далі - Grafana для виведення дашбордів і Moira як алертинг. Також ми хотіли розробити систему для пошуку аномалій.
Стандарт: Моніторинг 2.0
Так виглядали плани у 2015. Але нам треба було готувати не лише інфраструктуру та сам сервіс, а й документацію до нього. Ми розробили для себе корпоративний стандарт, який назвали моніторинг 2.0. Які вимоги були до системи?
- постійна доступність;
- інтервал зберігання метрик = 10 секунд;
- структуроване зберігання метрик та дашбордів;
- SLA > 99,99%
- збір івентових метрик за UDP (!).
Нам був необхідний UDP, тому що у нас великий потік трафіку та подій, які генерують метрики. Якщо їх все одразу писати у графіт, сховище ляже. Також ми вибрали префікси першого рівня для всіх метриків.
Кожен із префіксів носить якусь властивість. Є метрики по серверах, мережах, контейнерах, ресурсах, програмах і так далі. Реалізовано чітку, строгу, типізовану фільтрацію, де ми приймаємо метрики першого рівня, а решту просто дропаємо. Ось як ми планували цю систему у 2015 році. Що ж тепер?
Сьогодення: схема взаємодії компонентів моніторингу
Насамперед ми моніторимо аплікейшні: наш PHP-код, програми та мікросервіси — словом, усе, що пишуть наші розробники. Усі аплікейшні через UDP відправляють метрики в агрегатор Brubeck (statsd, переписаний на С). Він виявився найшвидшим за підсумками синтетичних тестів. І він відправляє вже агреговані метрики до Graphite через TCP.
Він має такий тип метрик, як таймери. Це дуже зручна річ. Наприклад, на кожне з'єднання користувача із сервісом ви відправляєте до Brubeck метрику з response time. Прийшов мільйон відповідей, а агрегатор видав лише 10 метрик. У вас є кількість людей, що прийшли, максимальний, мінімальний і середній час відгуку, медіана і 4 персентилі. Потім дані передаються в Graphite і ми бачимо їх наживо.
Також у нас є агрегація для метрик залізом, софтом, системними метриками та нашою старою системою моніторингу Munin (вона працювала у нас до 2015 року). Все це ми збираємо через C'ішний демон CollectD (в нього вшита ціла пачка різних плагінів, він вміє опитувати всі ресурси хостової системи, на якій він встановлений, просто вкажіть у конфігурації, куди писати дані) і пишемо через нього дані Graphite. Також він підтримує плагіни python і shell скрипти, так що ви можете писати свої кастомні рішення: CollectD буде збирати ці дані з локального або віддаленого хоста (припустимо, є Curl) і надсилати їх до Graphite.
Далі всі метрики, які ми зібрали, відправляємо до Carbon-c-relay. Це рішення Carbon Relay від Graphite, доопрацьоване на C. Це роутер, який збирає у собі всі метрики, які ми відправляємо з наших агрегаторів, і маршрутизує їх нодами. Також на стадії маршрутизації він перевіряє валідність метриків. Вони, по-перше, повинні відповідати схемі з префіксами, яку я показав раніше і, по-друге, валідні для графіту. Інакше вони тремтять.
Потім Carbon-c-relay відправляє метрики до кластера Graphite. Ми використовуємо як основне сховище метрик Carbon-cache, переписані на Go. Go-carbon внаслідок його багатопоточності набагато перевершує за продуктивністю Carbon-cache. Він приймає дані в себе і записує їх на диски за допомогою пакета whisper (стандартний, написаний на python). Для того, щоб прочитати дані з наших сховищ ми використовуємо Graphite API. Він працює набагато швидше, ніж стандартна Graphite WEB. Що відбувається з даними далі?
Вони ідуть до Grafana. Як основне джерело даних ми використовуємо наші кластери графітів, плюс у нас є Grafana як веб-інтерфейс для відображення метрик, побудови дешбордів. На кожен свій сервіс розробники заводять власний дешборд. Далі вони будують графіки, на яких відображаються метрики, які вони пишуть зі своїх додатків. Крім Grafana, у нас є ще SLAM. Це поживний демон, який вважає SLA на підставі даних з графіту. Як я вже казав, у нас є кілька десятків мікросервісів, кожен з яких має свої вимоги. За допомогою SLAM ми ходимо в документацію та порівнюємо її з тим, що є у Graphite та порівнюємо, наскільки вимоги відповідають доступності наших сервісів.
Ідемо далі: аллертинг. Він організований за допомогою сильної системи Moira. Вона незалежна тому, що в неї під капотом свій власний Graphite. Розроблена хлопцями із СКБ «Контур», написана на python та Go, повністю опенсорсна. Moira отримує весь той самий потік, що йде в графіти. Якщо з якоїсь причини у вас помре сховище, ваш аллертинг працюватиме.
Moira ми розгорнули в Kubernetes, як основну базу даних вона використовує кластер Redis-серверів. У результаті вийшла стійка до відмови система. Вона порівнює потік метрик зі списком тригерів: якщо в ньому немає згадок, то тремтить метрику. Так вона здатна перетравити гігабайти метрик за хвилину.
Ще ми до неї прикрутили корпоративний LDAP, за допомогою якого кожен користувач корпоративної системи може створювати для себе нотифікації щодо існуючих (або новостворених) тригерів. Оскільки Moira містить у собі Graphite, вона підтримує всі функції. Тому ви спочатку берете рядок і копіюєте його в Grafana. Дивіться, як відображаються дані на графіках. А потім берете цей рядок і копіюєте її в Moira. Обвішує її лімітами і отримуєте на виході алертинг. Щоб усе це робити, вам не потрібні специфічні знання. Moira вміє алертити по смс, email, у Jira, Slack… Також вона підтримує виконання кастомних скриптів. Коли у неї трапляється тригер, і вона підписана на кастомний скрипт або бінарник, вона його запускає, і віддає на stdin цього бінарника JSON. Відповідно, ваша програма має його розпарити. Що ви робитимете з цим JSONом — вирішуйте самі. Хочете - відправляйте в Telegram, хочете - відкривайте таски в Jira, робіть будь-що.
У нас для аллертингу використовується ще й власна розробка – Imagotag. Ми адаптували панель, яка зазвичай застосовується для електронних цінників у магазинах, під наші завдання. Ми вивели на неї тригери з Moira. Там зазначено, у якому вони стані, коли сталися. Частина хлопців із розробки відмовилися від повідомлень у Slack та на пошту на користь ось цієї панельки.
Ну і оскільки ми прогресивна компанія, то замоніторили в цій системі ще й Kubernetes. Включили його в систему за допомогою Heapster, який ми встановили в кластер, він збирає дані та відправляє їх у Graphite. У результаті схема виглядає так:
Компоненти моніторингу
Ось список посилань на ті компоненти, які ми використовували для цього завдання. Усі вони – опенсорсні.
Графіт:
- go-carbon:
- прошепотіти:
- graphite-api:
Carbon-c-relay:
Brubeck:
Зібрано:
Мойра:
Графана:
Heapster:
Статистика
І от трохи цифр про те, як система працює у нас.
Aggregator (brubeck)
Кількість метрик: ~300 000 / sec
Інтервал відправки метрик у Graphite: 30 sec
Використання ресурсів сервера: ~ 6% CPU (йдеться про повноцінні сервери); ~ 1Gb RAM; ~ 3 Mbps LAN
Graphite (go-carbon)
Кількість метрик: ~ 1 / min
Інтервал поновлення метрик: 30 sec
Схема зберігання метрик: 30sec 35d, 5min 90d, 10min 365d (дає розуміння, що відбувається з сервісом на тривалому етапі часу)
Використання ресурсів сервера: ~ 10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN
Гнучкість
Ми в Avito дуже цінуємо у нашому сервісі моніторингу гнучкість. Чому він власне вийшов таким? По-перше, його складові взаємозамінні: як самі компоненти, так і їх версії. По-друге – підтримуваність. Оскільки весь проект побудований на опенсорсі, ви можете правити код, вносити зміни, можете реалізовувати функції, недоступні з коробки. Використовуються досить поширені стеки, переважно, Go і Python, тому це робиться досить просто.
Ось приклад проблеми, що реально виникла. Метрика в Graphite – це файл. Він має назву. Назва файлу = ім'я метрики. І є шлях до нього. Назви файлів у Linux обмежені 255 символами. А у нас є (як "внутрішні замовники") хлопці з відділу баз даних. Вони нам кажуть: “Ми хочемо моніторити наші SQL-запити. А вони – не 255 символів, а 8 МБ кожен. Ми хочемо їх відображати в Grafana, бачити параметри за цим запитом, а ще краще, ми хочемо бачити топ таких запитів. Буде чудово, якщо він відображатиметься у реальному часі. А зовсім круто було б запхати їх у аллертинг”.
Приклад SQL-запиту взятий як приклад з
Ми піднімаємо сервер Redis та нашими Collectd-плагінами, які ходять у Postgres і беруть звідти всі дані, відправляємо метрики до Graphite. Але замінюємо ім'я метрики на хеші. Цей же хеш одночасно відправляємо в Redis як ключ, і весь SQL-запит як значення. Нам залишилося зробити так, щоб Grafana вміла ходити до Redis та брати цю інформацію. Ми відкриваємо Graphite API, т.к. це основний інтерфейс взаємодії всіх компонентів моніторингу з графітом, і вписуємо туди нову функцію, яка називається aliasByHash() — від Grafana отримуємо ім'я метрики, і використовуємо його у запиті до Redis як ключ, у відповідь отримуємо значення ключа, яким є наш SQL запит ”. Таким чином, ми вивели в Grafana відображення SQL-запиту, який, за ідеєю, відобразити там було ніяк не можна, разом зі статистикою по ньому (calls, rows, total_time, …).
Підсумки
Доступність. Наш сервіс моніторингу доступний 24 на 7 з будь-якого аплікейшну та будь-якого коду. Якщо ви маєте доступ до сховищ, ви можете писати в сервіс дані. Мова неважлива, рішення не важливі. Вам потрібно тільки знати, як відкрити сокет, закинути туди метрику і закрити сокет.
Надійність. Всі компоненти відмовостійкі та справляються з нашими навантаженнями добре.
Низький поріг входження. Для того, щоб користуватися цією системою, вам не потрібно вивчати мови програмування та запити у Grafana. Просто відкриваєте вашу програму, вписуєте в нього сокет, який відправлятиме метрики в Graphite, закриваєте його, відкриваєте Grafana, створюєте там дешборди і дивіться на поведінку ваших метрик, отримуючи повідомлення через Moira.
Самостійність. Все це можна робити самим, без допомоги DevOps-інженерів. І це оверфіча, тому що ви можете моніторити свій проект прямо зараз, нікого не треба просити ні для початку роботи, ні для змін.
Чого ми прагнемо?
Все перелічене нижче — це не просто абстрактні думки, а те, до чого зроблено хоча б перші кроки.
- Детектор аномалій. Хочемо запиляти в себе сервіс, який ходитиме в наші Graphite-сховища і кожну метрику перевірятиме за різними алгоритмами. Вже є алгоритми, які хочемо переглядати, є дані, ми вміємо з ними працювати.
- Метадані. У нас багато сервісів, згодом вони змінюються, як і люди, які з ними працюють. Постійно вести документацію вручну – не варіант. Тому зараз у наші мікросервіси вбудовуються метадані. Там прописано, хто його розробив, мови, з якими він взаємодіє, вимоги щодо SLA, куди та кому надсилати нотифікації. При депло сервісу всі дані сутності створюються самостійно. У результаті ви отримуєте два посилання - одне на тригери, інше - на дешборди в Grafana.
- Моніторинг у кожний будинок. Ми вважаємо, що такою системою мають користуватися всі розробники. У цьому випадку ви завжди розумієте, де ваш трафік, що з ним відбувається, де він падає, де має слабкі місця. Якщо, припустимо, прийде щось і завалить ваш сервіс, то ви дізнаєтеся про це не під час дзвінка від менеджера, а від алерту, і одразу зможете відкрити свіжі логи та подивитися, що там сталося.
- Висока продуктивність. Наш проект постійно зростає, і сьогодні в ньому обробляється близько 2 значень метрик за хвилину. Рік тому цей показник становив 000 000. А зростання продовжується, і це означає, що через якийсь час Graphite (whisper) почне дуже навантажувати дискову підсистему. Як я вже казав, ця система моніторингу досить універсальна за рахунок взаємозамінності компонентів. Хтось спеціально під Graphite обслуговує та постійно розширює свою інфраструктуру, але ми вирішили піти іншим шляхом: використовувати як сховище наших метрик. Цей перехід майже завершено, і дуже скоро я розповім детальніше, як це було зроблено: які були труднощі і як вони були подолані, як проходив процес міграції, опишу обрані як обв'язування компоненти та їх конфігурації.
Дякую за увагу! Задавайте свої питання на тему, постараюся відповісти тут або в наступних постах. Можливо, хтось має досвід побудови подібної системи моніторингу або переходу на Clickhouse у подібній ситуації — ділитесь ним у коментарях.
Джерело: habr.com