Мене звуть Антон Бадерін. Я працюю в Центрі Високих Технологій та займаюся системним адмініструванням. Місяць тому завершилася наша корпоративна конференція, де ми ділилися накопиченим досвідом із IT-спільнотою нашого міста. Я розповідав про моніторинг веб-додатків. Матеріал призначався для рівня junior або middle, які не вибудовували цей процес із нуля.
Наріжний камінь, що лежить в основі будь-якої системи моніторингу, — вирішення завдань бізнесу. Моніторинг заради моніторингу нікому не цікавий. А що хоче бізнес? Щоб усе працювало швидко та без помилок. Бізнес хоче проактивності, щоб ми самі виявляли проблеми у роботі сервісу та максимально швидко їх усували. Це, по суті, і є завданням, які я вирішував весь минулий рік на проекті одного з наших замовників.
Про проект
Проект — одна із найбільших у країні програм лояльності. Ми допомагаємо роздрібним мережам збільшувати частоту продажів за рахунок різних маркетингових інструментів на кшталт бонусних карток. Загалом у проект входять 14 програм, які працюють на десяти серверах.
У процесі ведення співбесід я неодноразово зауважував, що адміни далеко не завжди правильно підходять до моніторингу веб-додатків: досі багато хто зупиняється на метриках операційної системи, зрідка моніторять сервіси.
У моєму випадку раніше в основі системи моніторингу замовника лежала Icinga. Вона не вирішувала зазначені вище завдання. Часто клієнт сам повідомляв про проблеми і не рідше нам просто не вистачало даних, щоб докопатися до причини.
Крім того, було чітке розуміння безперспективності її подальшого розвитку. Я думаю, ті хто знайомий з Icinga мене зрозуміють. Отже, ми вирішили повністю переробити систему моніторингу веб-застосунків на проекті.
Прометей
Ми вибрали Prometheus, виходячи з трьох основних показників:
- Величезна кількість доступних метрик. У нашому випадку їх 60 тисяч. Звичайно, варто зазначити, що переважну більшість з них ми не використовуємо (напевно, близько 95%). З іншого боку, вони відносно дешеві. Для нас ця інша крайність, в порівнянні з Icinga, що раніше використовувалася. У ній додавання метрик доставляло особливий біль: наявні діставалися дорого (достатньо подивитися на вихідники будь-якого плагіна). Будь-який плагін був скриптом на Bash або Python, запуск яких недешевий з точки зору споживаних ресурсів.
- Ця система споживає відносно невелику кількість ресурсів. На всі наші метрики вистачає 600 Мб оперативної пам'яті, 15% одного ядра та кілька десятків IOPS. Звичайно, доводиться запускати експортери метрик, але всі вони написані на Go і теж не відрізняються ненажерливістю. Не думаю, що у сучасних реаліях це проблема.
- Дає можливість переходу до Kubernetes. З огляду на плани замовника – вибір очевидний.
ELK
Раніше ми логи не збирали та не обробляли. Недоліки зрозумілі всім. Ми обрали ELK, оскільки досвід роботи із цією системою у нас уже був. Зберігаємо там лише логи додатків. Основними критеріями вибору стали повнотекстовий пошук та його швидкість.
Сlickhouse
Спочатку вибір припав на InfluxDB. Ми усвідомлювали необхідність збирання логів Nginx, статистики з pg_stat_statements, зберігання історичних даних Prometheus. Influx нам не сподобався, тому що він періодично починав споживати велику кількість пам'яті та падав. Крім того, хотілося групувати запити по remote_addr, а угрупування в цій СУБД тільки за тегами. Теги дороги (пам'ять), їх кількість умовно обмежена.
Ми розпочали пошуки заново. Потрібна була аналітична база з мінімальним споживанням ресурсів, бажано зі стиском даних на диску.
Clickhouse відповідає всім цим критеріям, і про вибір ми жодного разу не пошкодували. Ми не пишемо до нього якихось видатних обсягів даних (кількість вставок лише близько п'яти тисяч за хвилину).
NewRelic
NewRelic історично був із нами, оскільки це був вибір замовника. У нас він використовується як APM.
Zabbix
Ми використовуємо Zabbix виключно для моніторингу Black Box різних API.
Визначення підходу до моніторингу
Нам хотілося декомпозувати завдання і цим систематизувати підхід до моніторингу.
Для цього я розділив нашу систему на такі рівні:
- «залізо» та VMS;
- операційна система;
- системні послуги, стек ПЗ;
- додаток;
- бізнес-логіки.
Чим зручний такий підхід:
- ми знаємо, хто відповідальний за роботу кожного з рівнів і, виходячи з цього, можемо надсилати алертів;
- ми можемо використовувати структуру при придушенні алертів — було б дивно посилати алерт про недоступність бази даних, коли віртуальна машина в цілому недоступна.
Так як наше завдання виявляти порушення в роботі системи, ми повинні на кожному рівні виділити набір метрик, на які варто звертати увагу при написанні правил аллертингу. Далі пройдемося за рівнями «VMS», «Операційна система» та «Системні сервіси, стек ПЗ».
Віртуальні машини
Хостинг виділяє нам процесор, диск, пам'ять та мережу. І з першими двома ми мали проблеми. Отже, метрики:
CPU stolen time - коли ви купуєте віртуалку на Amazon (t2.micro, наприклад), слід розуміти, що вам виділяється не ціле ядро процесора, а лише квота його часу. І коли ви вичерпаєте її, процесор у вас почнуть забирати.
Ця метрика дозволяє відстежувати такі моменти та приймати рішення. Наприклад, чи потрібно взяти тариф пожирніше або рознести обробку фонових завдань та запитів в API на різні сервери.
IOPS + CPU iowait time — чомусь багато хмарних хостингів грішать тим, що недодають IOPS. Більше того, графік із низькими IOPS для них не аргумент. Тому варто збирати і CPU iowait. З цією парою графіків — з низькими IOPS і високим очікуванням на введення-виведення — вже можна розмовляти з хостингом і вирішувати проблему.
Операційна система
Метрики операційної системи:
- кількість доступної пам'яті %;
- активність використання swap: vmstat swapin, swapout;
- кількість доступних inode та вільного місця на файловій системі в %
- середнє завантаження;
- кількість з'єднань у стані tw;
- заповненість таблиці conntrack;
- якість роботи мережі можна моніторити за допомогою утиліти ss, пакетом iproute2 - отримувати з її виведення показник RTT-з'єднань та групувати за dest-портом.
Також на рівні операційної системи у нас виникає така сутність, як процеси. Важливо виділити у системі набір процесів, які грають значної ролі у роботі. Якщо, наприклад, у вас є кілька pgpool, необхідно збирати інформацію по кожному з них.
Набір метрик наступний:
- ЦП;
- пам'ять - насамперед, резидентна;
- IO - бажано в IOPS;
- FileFd - відкриті та ліміт;
- суттєві відмови сторінки - так ви зможете зрозуміти, який процес свапа.
Весь моніторинг у нас розгорнуто в Docker, для збору даних метрик ми використовуємо Сadvisor. На решті машин застосовуємо process-exporter.
Системні сервіси, стек ПЗ
Кожна програма має свою специфіку, і складно виділити якийсь набір метрик.
Універсальним набором є:
- рейт запитів;
- кількість помилок;
- латентність;
- насичення.
Найбільш яскраві приклади моніторингу даного рівня у нас – Nginx та PostgreSQL.
Найнавантаженіший сервіс у нашій системі — база даних. Раніше у нас досить часто виникали проблеми, щоб з'ясувати, чим займається база даних.
Ми бачили високе навантаження на диски, але слоулоги нічого до ладу не показували. Цю проблему ми вирішили за допомогою pg_stat_statements, уявлення, в якому збирається статистика на запити.
Це все, що потрібне адміну.
Будуємо графіки активності запитів на читання та запис:
Все просто і зрозуміло, кожному запиту свій колір.
Не менш яскравий приклад – Nginx-логи. Не дивно, що мало хто їх парсить чи згадує у списку обов'язкових. Стандартний формат не дуже інформативний, і його потрібно розширювати.
Особисто я додав request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Будуємо графіки часу відповіді та кількості помилок:
Будуємо графіки часу відповіді та кількості помилок. Пам'ятаєте? я говорив про завдання бізнесу? Щоб швидко та без помилок? Ми вже двома графіками ці питання закрили. І ними вже можна дзвонити черговим адмінам.
Але залишилася ще одна проблема – забезпечити швидке усунення причин інциденту.
Усунення інцидентів
Весь процес від виявлення до вирішення проблеми можна розбити на низку кроків:
- виявлення проблеми;
- повідомлення чергового адміністратора;
- реакція на інцидент;
- усунення причин.
Важливо, що ми маємо це робити максимально швидко. І якщо на етапах виявлення проблеми та надсилання повідомлення ми особливо часу виграти не можемо — дві хвилини на них підуть у будь-якому випадку, то наступні — просто неоране поле для покращення.
Давайте просто уявімо, що у чергового задзвонив телефон. Що він робитиме? Шукати відповіді на запитання: що зламалося, де зламалося, як реагувати? Ось яким чином ми відповідаємо на ці запитання:
Ми просто включаємо всю цю інформацію в текст повідомлення, даємо в ньому посилання на сторінку вікі, де описано, як на цю проблему реагувати, як її вирішувати та ескалувати.
Я досі нічого не сказав про рівень застосування та бізнес логіки. На жаль, у наших додатках поки що не реалізовано збір метрик. Єдине джерело будь-якої інформації з цих рівнів – логи.
Пара моментів.
По-перше, пишіть структуровані логи. Не потрібно включати контекст у текст повідомлення. Це ускладнює їхнє угруповання та аналіз. Logstash вимагає багато часу, щоб усе це нормалізувати.
По-друге, правильно використовуйте severity-рівні. Кожна мова має свій стандарт. Особисто я виділяю чотири рівні:
- помилки немає;
- помилка за клієнта;
- помилка нашому боці, не втрачаємо грошей, не несемо ризики;
- помилка на нашому боці, втрачаємо гроші.
Резюмую. Потрібно намагатись вибудовувати моніторинг саме від бізнес-логіки. Намагатися замоніторити саму програму і оперувати вже такими метриками, як кількість продажів, кількість нових реєстрацій користувачів, кількість активних на даний момент користувачів і так далі.
Якщо весь ваш бізнес — одна кнопка в браузері, необхідно моніторити, чи вона протискається, чи працює належним чином. Все інше не важливо.
Якщо у вас цього немає, ви можете спробувати це надолужити в логах програми, Nginx-логах тощо, як це зробили ми. Ви повинні бути якомога ближче до програми.
Метрики операційної системи звичайно важливі, але бізнесу вони не цікаві, нам платять не за них.
Джерело: habr.com