Как использовать strace для диагностики linux серверов. strace показывает все сигналы и системные вызовы (syscall) для выбранного процесса. Он не покажет вам логику выполняемого кода, но по системным вызовам всё же можно понять многое, что происходит внутри. Стандартный способ использования strace -ttyfkp 123. Не пугаемся от обилия флагов, тут всё просто. Флаги -tt добавляют к выводу timestamp (так проще ориентироваться в большом потоке сообщений), -y показывает человекочитаемые названия файловых дескрипторов вместо чисел. Флаг -f означает, что собирать инфомрацию будем в том числе со всех дочерних процессов (удобно подключиться к родительскому и собирать сразу всё), а -k покажет stacktrace каждого вызова (его можно можно не включать без необходимости). И в последнем параметре -p 123 указываем PID нужного нам процесса (в данном случае 123). Для чего это может пригодиться: ▪️ Узнать, чем занят зависший или потребляющий много ресурсов процесс. Например, может быть read/write или wait какого-то сокета к БД или внешнему сервису. Также часто бывает спам каких-нибудь mmap (выделение памяти), что намекает на какое-то большое количество создаваемых объектов или бесконечный цикл и тп. ▪️ Убедиться, что процесс получает ваш запрос. Например, в большой распределенной системе довольно сложно понять, пришёл ли запрос на нужный нам веб сервер или другой софт. Можно конечно идти по следам запроса от начала и до конца, проходя через десяток слоев абстракций и сервисов, но гораздо быстрее сразу подключиться к финальной точке назначения и просто посмотреть пришло что-то или нет. ▪️ Посмотреть текст входящего запроса/ответа или логи. Помимо того, чтобы просто понять пришёл запрос или нет, мы сразу можем увидеть текст запроса и текст ответа. Также часто бывают ситуации, когда проще прямо в strace увидеть, что какой-то софт пишет что-то в лог и где этот лог находится. На более менее крупных и нагруженных серверах у нас с десяток мест, куда пишут логи разные сервисы и системы. Например, логи могут идти в стандартный /var/log, либо в домашнюю директорию сервиса, либо в stdout docker контейнера, либо могут даже сохраняться внутри docker контейнера в файл. А еще могут уходить в syslog или в journal или даже в /dev/null. В общем, в реальной жизни в /var/log логи оказываются реже всего. В такой ситуации strace — отличная отправная точка. ▪️ Найти причину, почему процесс/запрос падает фаталом. Иногда сталкиваюсь с ситуациями, когда даже какой-нибудь nginx (!) не отдает ответ на запрос и ничего не пишет в лог. Здесь сразу на помощь приходит strace — можно посмотреть, что предшествовало ошибке и как вообще ошибка выглядела глазами syscall. Во всех кейсах речь конечно про диагностику на prod серверах, когда проблема уже возникла и нужно очень быстро найти ее причины. #linux #devops #strace