I_vod Aug 30 at 13:21

Я ломал свою платформу мониторинга. Первым сломалось не то, что я тестировал

Medium

11 min

10K

IT systems testing * System administration * DevOps *

Case

Comments 5

ITsuperiorRF Aug 30 at 13:33

Спасибо за статью. Интересно было почитать

vvolio Aug 30 at 16:06

Интересная статья, большое спасибо. Единственное, что немного огорчило:

У одного тенанта истекла подписка. Это тестовый тенант, его агент (vmagent + Vector) стоит на моём же тестовом сервере и пишет на прод.

Все же стоит отделять мух от котлет, я считаю. Не везде приветствуется пересечение сред эксплуатации даже на тривиальном уровне

I_vod Aug 31 at 06:47

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

otezvikentiy Sep 1 at 20:23

Тезис "первым ломается не то, что тестировал" узнаю по своему проекту (тоже пишу self-hosted observability в одиночку, тоже ClickHouse под капотом). У меня первым сломался не приём телеметрии, а сама база: при 543 КБ полезных данных ClickHouse занял 12 ГБ диска. Виноваты его собственные системные таблицы: trace_log (профайлер запросов включён по умолчанию, раз в секунду) набрал 26 млн строк и 404 МБ, а у trace_log, query_log и latency_log из коробки нет TTL вообще, растут навсегда. И это никаким k6 не ловится: нагрузки нет, а диск уходит.

Второй урок оттуда же, про который вы пишете в части про диагностику постфактум: я склеил два симптома в один. Разросшийся trace_log действительно давал мержи и I/O, но CPU грузило другое, и TRUNCATE это показал за минуту. Разбор с замерами: https://habr.com/ru/articles/1070270/

Интересно, у вас в трёх осях нагрузки где-то сидит "рост служебных данных самого хранилища" как отдельный сценарий, или он проходит по оси кардинальности?

I_vod Sep 2 at 05:40

Спасибо, отличный пример — и нет, ни в одну из трёх осей он не попадает. Все три описывают то, что приходит снаружи: объём, кардинальность и поведение клиента при отказе. Ваш случай — четвёртая ось: нагрузка, которую система создаёт сама себе, и она от трафика не зависит вообще.

У меня из той же категории два эпизода. Ретрай-шторм из статьи: 61 417 запросов от собственных агентов, снаружи при этом ни одного пользователя. И 4702 рестарта хранилища логов по memcg-OOM, копившиеся месяцами при почти нулевой нагрузке — их не поймал бы никакой нагрузочный сценарий, потому что ловить надо было не пик, а фон.

Практический вывод, который допишу в чек-лист после вашего комментария: тест с нулевой нагрузкой. Оставить стенд на сутки совсем без трафика и посмотреть дельту диска, число рестартов и рост системных таблиц. Ваши 12 ГБ на 543 КБ полезных данных ловятся ровно так.

Разбор пойду читать. TRUNCATE за минуту вместо часа профилирования — хороший приём.