Простые метрики и способ сэкономить время при поиске проблем в инфраструктуре

Не так давно в датацентре, в котором мы арендуем серверы случился очередной мини-инцидент. Никаких серьезных последствий для нашего сервиса в итоге не было, по имеющимся метрикам нам удалось понять что происходит буквально за минуту. А потом я представил, как пришлось бы ломать голову, если бы не хватало всего 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 большую часть времени как раз и занимаемся разработкой нашей базы автотриггеров, которые упрощают нашим клиентам поиск неизвестных для них проблем.

FavoriteLoadingДобавить в избранное
Posted in Без рубрики

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *