Хабрахабр

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

Не так давно в датацентре, в котором мы арендуем серверы случился очередной мини-инцидент. Никаких серьезных последствий для нашего сервиса в итоге не было, по имеющимся метрикам нам удалось понять что происходит буквально за минуту. А потом я представил, как пришлось бы ломать голову, если бы не хватало всего 2х простеньких метрики. Под катом коротенькая история в картинках.
Представим, что мы увидели аномалию на графике времени ответа некоторого сервиса. Для простоты возьмем хэндлер /ping, который не обращается ни в базы данных, ни в соседние сервисы, а просто отдает '200 OK' (он нужен для балансировщиков нагрузки и k8s для health check сервиса)

Правильно, сервису не хватает ресурсов, скорее всего CPU!
Какая мысль возникает первой? Смотрим, на потребление проца:

Дальше смотрим, на потребление в разрезе сервисов на сервере:
Да, есть похожие всплески.

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

В dmesg это выглядит примерно так: Я конечно как мог пытался сохранить интригу, но по началу статьи вы наверное уже догадались, что у сервера просто уменьшилось количество доступных cpu тактов.

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

Теги
Показать больше

Похожие статьи

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

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

Кнопка «Наверх»
Закрыть