Написать пост

Хэллоуинский спецвыпуск Tproger Changelog: какие факапы мы словили за этот месяц

Аватар Александр Ланский
для
Логотип компании Tproger
Tproger

В предпраздничном выпуске ченжлога расскажем, с какими проблемами и неудачами нам пришлось столкнуться за этот месяц.

В этом выпуске ченжлога собрали для вас проблемы и факапы, с которыми столкнулись за последнее время.

Алексей рассказывает, из-за чего в начале месяца упал наш сайт и как пришлось его воскрешать, а Антон делится взломом нашего сервера reports и необходимостью оптимизации ClickHouse.

В ночь с четверга на пятницу, 2 октября, у нас падал сайт. Примерно с трёх ночи до десяти утра многие страницы не открывались вообще.

Причина оказалась простой: мы с Никитой тестировали новые рассылки в боте. Для этого нужно подключаться к продакшен базе и получать свежие посты. Бот не закрывал MySQL-соединение, и мы быстро достигли лимита в 255 открытых дескрипторов (ограничение managed MySQL от DO). Я закрыл подключение для бота, и минут через 15 база данных разрешила к себе подключаться.

Хэллоуинский спецвыпуск Tproger Changelog: какие факапы мы словили за этот месяц 1

Выводы — настраивайте больше алертов на неочевидные метрики. Количество подключений не приводит к перегрузке по памяти или ЦП, и мы не смогли отловить состояние текущим мониторингом достаточно заранее для принятия превентивных действий.

Вот такая вот история восстания сайта из своей могилы.

Хэллоуинский спецвыпуск Tproger Changelog: какие факапы мы словили за этот месяц 2

По рабочей необходимости мне потребовалось открыть порт для доступа к Docker API на одной из наших виртуальных машинок, развернутых в Digital Ocean. Открыл порт, воспользовался по назначению, а затем заметил, что ресурсы машины закончились. Нечто забило всю память, а потребление CPU выросло до 100%:

Хэллоуинский спецвыпуск Tproger Changelog: какие факапы мы словили за этот месяц 3

Я не очень опытный пользователь Docker, поэтому сначала решил, что это реально я создал такую нагрузку, и потому запросил дополнительный бюджет на эту машинку, чтобы поднять её ресурсы.

А ещё на сервере иногда запускался подозрительный контейнер с ubuntu. Я тоже подумал на себя и просто удалял его. А он опять появлялся. Ну а я опять удалял. А потом я пошёл спать.

На следующий день от Digital Ocean пришло письмо: мол, ребят, у вас на сервере запущено что-то, что сканирует порты других хостов. Если это не вы, сделайте что-нибудь.

Хэллоуинский спецвыпуск Tproger Changelog: какие факапы мы словили за этот месяц 4

И тут у меня сошлась картинка: открыл порт, на машинке появился незваный гость. А дело всё в том, что на машинках Digital Ocean по умолчанию нет никакого фаерволла: как только открываешь любой порт, он становится доступен всем в интернете. Это спорное решение, но упрощает задачу новичкам и злоумышленникам. Вот мне в открытый порт Docker и заслали какую-то ubuntu.

Я быстренько закрыл порты, удалил вредоносный контейнер в последний раз и всё стало хорошо.

Вот так мы не дали злоумышленнику погубить один из наших серверов.

Хэллоуинский спецвыпуск Tproger Changelog: какие факапы мы словили за этот месяц 5

Правда ненадолго: на следующий день вредоносная активность возобновилась, причем подозрительные процессы через ps aux не обнаруживались. Сервис пришлось перенести на другой сервер, а машинку загасить. Подскажите: как бы вы искали вредоносный процесс на своей виртуалке? Ресурсы были забиты под 100%, но в списке запущенных процессов ни один не вызвал подозрений. Сторонних контейнеров в Docker тоже запущено не было.

А вот еще история. Пишет мне наш шеф-редактор: зашла, мол, в DataLens (почитайте про наш трекер событий), собрала пару графиков, и всё сломалось. Смотрю, а ClickHouse, из которого графики читают данные, прилёг под нагрузкой. Кто виноват? Конечно же юзер! Поругался, урезал доступ к данным. Короче, молодец: если продуктом никто не пользуется — значит его никто не сломает.

Но как-то не по себе: от чего бы ClickHouse падать из-за такого простого запроса? Оказалось, почти вся оперативная память занята. Ну я и решил, всё верно: трекер работает уже несколько месяцев, мы накопили данных — значит, подросли. Значит, пора ресурсы увеличить. Согласовал небольшое увеличение бюджета. Уже знакомый способ решения проблемы, не правда ли? ?

И как-то обидно мне так стало за ClickHouse: что ж он всю оперативку занимает, даже когда запросы не выполняет? Причём потребление памяти постоянно росло:

Хэллоуинский спецвыпуск Tproger Changelog: какие факапы мы словили за этот месяц 6

Были у меня под подозрением словари, которые реплицируют данные с продакшн базы Tproger. В них хранятся соответствия идентификаторов постов и их заголовков, рубрик, тегов и т.п. Такое решение было реализовано из-за невозможности создать базу данных с движком MySQL в managed версии ClickHouse.

И хранятся словари как раз в памяти. Причём статистика в системной таблице system.dictionaries по ним показывает, мол, занимают в памяти мегабайт 10 от силы (а по графикам занято уже больше 7 гигов). Короче, не поверил, поменял схему обращения к проду Tproger, и вот как изменилось потребление памяти:

Хэллоуинский спецвыпуск Tproger Changelog: какие факапы мы словили за этот месяц 7

Оказалось, что словари действительно занимали почти всю свободную память. Теперь же данные с прода мы в ClickHouse не храним, а читаем налету. А получилось сделать так благодаря тому, что я случайно наткнулся на нужный раздел в документации ClickHouse ?

С точки зрения производительности и влияния на пользователя, негативного эффекта нет: наша продовая БД работает довольно шустро, а чтения со стороны ClickHouse из неё довольно редкие, ведь пользователей у DataLens пока немного.

В результате удалось вернуть ClickHouse в самую дешёвую конфигурацию и продолжить им комфортно пользоваться.

А как вы строите BI решения для небольших данных?

Tproger Changelog
1968