Не так давно в датацентре, в котором мы арендуем серверы случился очередной мини-инцидент. Никаких серьезных последствий для нашего сервиса в итоге не было, по имеющимся метрикам нам удалось понять что происходит буквально за минуту. А потом я представил, как пришлось бы ломать голову, если бы не хватало всего 2х простеньких метрики. Под катом коротенькая история в картинках.
Представим, что мы увидели аномалию на графике времени ответа некоторого сервиса. Для простоты возьмем хэндлер /ping, который не обращается ни в базы данных, ни в соседние сервисы, а просто отдает '200 OK' (он нужен для балансировщиков нагрузки и k8s для health check сервиса)
Какая мысль возникает первой? Правильно, сервису не хватает ресурсов, скорее всего CPU! Смотрим, на потребление проца:
Да, есть похожие всплески. Дальше смотрим, на потребление в разрезе сервисов на сервере:
Видим, что потребление проца выросло по всем сервисам пропорционально. Дальше однозначно ничего сказать нельзя: можно идти и смотреть, изменился ли профиль нагрузки (так как все компоненты связаны и увеличение запросов на входе может реально вызвать пропорциональное повышение потребления ресурсов) или разбираться, что стало с ресурсами сервера.
Я конечно как мог пытался сохранить интригу, но по началу статьи вы наверное уже догадались, что у сервера просто уменьшилось количество доступных cpu тактов. В dmesg это выглядит примерно так:
CPU3: Core temperature above threshold, cpu clock throttled (total events = 88981)
Грубо говоря, у нас понижена частота из-за перегрева процессора. Смотрим на температуру:
теперь все понятно. Так как у нас подобное поведение наблюдалось сразу у 6 серверов, мы поняли, что проблема в ДЦ, причем не во всем, а только в определенных рядах стоек.
Но вернемся к метрикам. Мы потенциально хотим знать, если серверы будут перегреваться в будущем, но это же не повод добавлять график температуры процессоров на все дашборды и каждый раз это проверять.
Обычно для оптимизации процесса слежение за какими-то метриками используют триггеры. Но какой порог выбрать для триггера по температуре процессора?
Именно из-за сложности выбрать хороший порог для триггера, многие инженеры мечтают о детекторе аномалий, который без настроек сам найдет то, незнаю что :)
Первая мысль — поставить в качестве порога температуру, при которой у нашего сервиса начались проблемы. А если у вас ни разу не было перегрева? Вы конечно можете посмотреть, на мой график и решить для себя, что 95 °С это то, что вам нужно, но давайте еще немного подумаем.
Проблема же у нас не из-за градусов, а из-за того, что понизилась частота! Давайте будем отслеживать количество таких событий.
В linux это можно снять из sysfs:
/sys/devices/system/cpu/cpu*/thermal_throttle/package_throttle_count
Если честно, мы даже никуда не выводим эту метрику, у нас есть только автотриггер для всех клиентов, который срабатывает при достижениие порога "> 10 events/second". По нашей статистике при таком пороге ложных срабатываний практически нет.
Да, этот триггер очень редко срабатывает, но когда подобное случается, он очень облегчает жизнь!
Мы в okmeter.io большую часть времени как раз и занимаемся разработкой нашей базы автотриггеров, которые упрощают нашим клиентам поиск неизвестных для них проблем.
Автор: Николай Сивко
