Process monitoring with okmeter

Okmeter снимает метрики не только про потреблении ресурсов сервера в целом, но и показывает какие процессы их утилизировали. Это позволяет не гадать, что происходило на вашем сервере в какой-то момент времени, а точно знать это.

На самом деле мы собираем метрики не про каждый процесс, а объединяем их в группы по общей части имени процесса, имени пользователя, который запустил этот процесс и названию контейнера. Каждая метрика помимо метки source_hostname с именем хоста имеет еще метки:

• process — имя процесса
• username — имя пользователя
• container — имя контейнера или “~host”, если процесс запущен вне контейнера

Про каждую группу процессов okagent собирает утилизированное процессорное время данной группой процессов:

process.cpu.user{process:”X”, username: “U”, container: “C”}

— время проведенное процессом в userspace.

process.cpu.system{process:”X”, username: “U”, container: “C”}

— ожидание выполнения системных вызовов.

По этим метрикам очень удобно следить за тем, какие процессы больше всего нагружают какой-то конкретный сервер:

или посмотреть суммарно по кластеру, какие контейнеры больше всего нагружают процессор:

process.mem.rss{process:”X”, username: “U”, container: “C”}

— размер резидентной памяти, используемой данной группой процессов.

Эта метрика позволяет выявить не только процессы, которые потребляют больше всего памяти, но и увидеть утечки памяти:

process.mem.swap{process:”X”, username: “U”, container: “C”}

— использование swap группой процессов.

Полезнее смотреть не на саму эту метрику, а на ее производную - скорость прироста/убывания swap для каждого процесса. Это позволяет увидеть процессы, которые активно работают со swap, при этом их быстродействие из-за этого может быть замедленно:

В okmeter также есть автоматический триггер уровня info (без уведомления), который сработает, если любой процесс на каком-либо сервере работает со swap на скорости более 1MB/s более двух минут. Это хорошо работает как подсказка в момент проблем в вашей инфраструктуре.

Остальные метрики по процессам:

process.proc_count{process:”X”, username: “U”, container: “C”}

— количество процессов в группе

process.thread_count{process:”X”, username: “U”, container: “C”}

— суммарное количество тредов в группе

process.disk.ops.read{process:”X”, username: “U”, container: “C”}

— количество операций чтения с диска, выполненные данной группой процессов

process.disk.ops.write{process:”X”, username: “U”, container: “C”}

— количество операций записи на диск группой процессов

process.disk.bytes.read{process:”X”, username: “U”, container: “C”}

— количество байт, считанных с диска группой процессов

process.disk.bytes.write{process:”X”, username: “U”, container: “C”}

— количество байт, записанных на диск группой процессов

process.open_files.count{process:”X”, username: “U”, container: “C”}

— количество файловых дескрипторов открытых группой процессов

process.open_files.max_usage_percent{process:”X”, username: “U”, container: “C”}

— процент использования открытых файловых дескрипторов относительно лимита ulimit -n для каждого процесса — берется максимальный процент из группы процессов.

Для этой метрики есть автоматический триггер, который сработает, если количество открытых дескрипторов приближается к лимиту. Если процесс достигнет этого лимита при попытке открыть файл или сетевой сокет процесс получит ошибку от ядра (too many open files), это может привести к отказу в обслуживании вашего сетевого сервиса, базы данных или других процессов.

process.max_cpu_percent_per_thread{process:”X”, username: “U”, container: “C”}

— процент использования процессора одним потоком процесса. Эта метрика позволяет отслеживать ситуацию, когда однопоточное приложение утилизирует одно процессорное ядро полностью, но при этом не может работать с несколькими ядрами. Например, для таких приложений как redis, pgbouncer, nginx worker - достижении этого лимита приведет к увеличению времени отклика.

process.uptime{process:”X”, username: “U”, container: “C”}

— максимальный uptime процессов в группе. По этой метрике можно отслеживать перезапуск процессов, например при изменении конфигурации или изменении версии.

Все этим метрики okmeter агент соберёт самостоятельно со всех процессов, без какой либо настройки. Такая детальность и степень покрытия позволяют иметь полную картину происходящего. Кроме того исторические данные позволяют разбираться с причинами уже прошедших проблем, а не гадать по поводу произошедшего.