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

в 11:56, , рубрики: linux, okmeter, Блог компании okmeter.io, Настройка Linux, системное администрирование

Простые метрики и способ сэкономить время при поиске проблем в инфраструктуре - 1 Не так давно в датацентре, в котором мы арендуем серверы случился очередной мини-инцидент. Никаких серьезных последствий для нашего сервиса в итоге не было, по имеющимся метрикам нам удалось понять что происходит буквально за минуту. А потом я представил, как пришлось бы ломать голову, если бы не хватало всего 2х простеньких метрики. Под катом коротенькая история в картинках.

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

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

Простые метрики и способ сэкономить время при поиске проблем в инфраструктуре - 3
Да, есть похожие всплески. Дальше смотрим, на потребление в разрезе сервисов на сервере:

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

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

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

CPU3: Core temperature above threshold, cpu clock throttled (total events = 88981)

Грубо говоря, у нас понижена частота из-за перегрева процессора. Смотрим на температуру:

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

теперь все понятно. Так как у нас подобное поведение наблюдалось сразу у 6 серверов, мы поняли, что проблема в ДЦ, причем не во всем, а только в определенных рядах стоек.

Но вернемся к метрикам. Мы потенциально хотим знать, если серверы будут перегреваться в будущем, но это же не повод добавлять график температуры процессоров на все дашборды и каждый раз это проверять.

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

Именно из-за сложности выбрать хороший порог для триггера, многие инженеры мечтают о детекторе аномалий, который без настроек сам найдет то, незнаю что :)

Первая мысль — поставить в качестве порога температуру, при которой у нашего сервиса начались проблемы. А если у вас ни разу не было перегрева? Вы конечно можете посмотреть, на мой график и решить для себя, что 95 °С это то, что вам нужно, но давайте еще немного подумаем.

Проблема же у нас не из-за градусов, а из-за того, что понизилась частота! Давайте будем отслеживать количество таких событий.
В linux это можно снять из sysfs:

/sys/devices/system/cpu/cpu*/thermal_throttle/package_throttle_count

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

Если честно, мы даже никуда не выводим эту метрику, у нас есть только автотриггер для всех клиентов, который срабатывает при достижениие порога "> 10 events/second". По нашей статистике при таком пороге ложных срабатываний практически нет.

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

Мы в okmeter.io большую часть времени как раз и занимаемся разработкой нашей базы автотриггеров, которые упрощают нашим клиентам поиск неизвестных для них проблем.

Автор: Николай Сивко

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js