DTrace

Наконец-то нашёл время, и скачал PEAR модуль DTrace. Замечательная штука! Нашёл там одну маленькую проблему, и написал письмо товарщиу Фёрлонгу (Wez Furlong), который немедленно внёс изменения в исходник модуля, и теперь всё работает просто замечательно. Большущее спасибо, Wez! :)

Итак, самый первый скрипт для наблюдения за PHP: php-scripts-snoop.d



Качайте скрипт, ставьте ему chmod a+x, и после запуска его в терминале на вашем веб-сервере, можно запускать различные скрипты PHP с этого сервера, и скрипт будет докладывать, когда начинается или заканчивается выполнение того или иного PHP скрипта, и который из процессов Apache за это отвечает:



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

При написании скриптов DTrace, часто вам нужно передать скрипту какой-нибудь параметр в командной строке. Эта простая задача может быть неожиданно трудной, если не прочесть раздел docs.sun.com про написание скриптов на DTrace, особенно раздел про макросы параметров командной строки.

Как и в оболочках sh и bash, вы можете получить значения параметров командной строки с помощью макросов $0..$9. Но тут есть одно "но". Значения параметров должны попадать под определенный тип - число, имя идентификатора или строку. Если переданный параметр не попадает под одно из этих определений, будет выдана ошибка.

Давайте начнём с простенького скрипта.



Если передать этому скрипту число в качестве параметра, никакой ошибки не будет, и вы получити следующее сообщение:
Your parameter: 123

Но если попробовать передать строчку вместо числа, выйдет следующее:

bash-3.00# ./args.d a1b2c3
dtrace: failed to compile script ./args.d: line 9: failed to resolve a1b2c3: Unknown variable name

Это происходит потому, что DTrace пытается найти идентификатор "a1b2c3". Почему так происходит? Это из-за особенностей определения типа параметра. Значение не похоже на число, а из-за того, что мы передали строку без кавычек, DTrace считает, что это не строка. Единственный остающийся вариант - это идентификатор. Переменной с таким именем в скрипте нет, и потому мы получаем ошибку.

Чтобы проверить эту теорию, можно просто создать переменную с таким же именем в скрипте:


Пожалуйста - всё работает именно так, как я сказал:

Your parameter: 1979

И если параметр у вас - точно строчка, то нужно изменить скрипт (чтобы printf печатал строку %s, а не целое число %d, иначе и тут будет ошибка)...


... и передать строку, заключив её в кавычки, вот так:

bash-3.00# ./args.d '"a1b2c3"'
Your parameter: a1b2c3


Как вы видите, теперь мы действительно передаём и обрабатываем наш параметр как строку, а одноимённая переменная, специально оставленная в скрипте, больше не используется, иначе было бы выведено её значение.

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



И вот как можно будет передавать строки такому скрипту:

bash-3.00# ./args.d a1b2c3
Your parameter: a1b2c3

Ну вот и всё на сегодня... Удачи с вашими скриптами DTrace!

Вчера Bryan Cantrill (один из создателей DTrace) выложил презентацию с полезными советами и приёмами работы с DTrace, а также упоминанием подводных камней, на которые легко нарваться не только новичкам, но и тем, кто уже какое-то время активно использует DTrace.

Как и оговаривается в начале презентации, часть вещей довольно проста - советы, это по большей части то, что многие могли бы знать, если бы второй раз перечитали документацию, а вот приёмы работы - очень даже полезные. Узнал много нового, и потому советую всем интересующимся тоже прочитать эту презентацию. Ссылка на PDF файл.

При исследовании пользовательских процессов, часто нас интересует какой-то конкретный процесс. Поэтому мы используем переменную $target (я о ней уже рассказывал немного) или же просто номер процесса (pid) в предикатах наших проб, указывая таким образом DTrace наш особый интерес к тому или иному процессу.

Для начинающих работу с DTrace - это вполне приемлемая тактика. Но есть и более правильный способ: использование провайдера pid.

Как говорится в официальном руководстве, провайдер pid - это на самом деле не просто провайдер DTrace, а целый класс провайдеров. Как видно из названия, он предлагает нам пробы, относящиеся к конкретному процессу.

Скажем, провайдер pid737 предоставляет возможность следить за процессом с pid=737, и т.д. Более того - становится гораздо удобнее не только выделять интересующие нас пробы, но и понимать, на основе каких функций они создаются для каждого процесса.

Такой способ отладки конкретного процесса, в отличие от пробы с использованием предиката типа /pid == $target/, является более правильным. Вместо того, чтобы указанные пробы активизировались и предикат проверялся для каждого процесса, теперь DTrace и смотреть не станет на другие процессы - и лишь только для одного, нужного нам, и будут активированы указанные пробы. Переменную $target по-прежнему можно и даже нужно использовать при создании наших проб с использованием провайдера pid.

Мы уже знаем, как получить список проб, доступных DTrace. Я об этом уже рассказывал здесь. Так вот, стоит нам лишь один раз использовать провайдер pid для какого-то процесса, как dtrace -l начнёт нам показывать пробы, динамически созданные для него. Если процесс завершит работу, соответствующий провайдер исчезнет из списка доступных проб.

Ещё одно удобство провайдера pid - это то, что в качестве модулей провайдера выступают библиотеки, подключаемые при выполнении исследуемого процесса. Соответственно, можно создавать пробы для отслеживания только лишь функций, выполняемых какой-то конкретной библиотекой. Очень удобно.

Вот маленький примерчик. Берём самую обычную Hello, world! программку на C:



После того, как мы получили исполняемый файл, принимаемся за наш очередной DTrace-скрипт:



Сохраняем скрипт, делаем этот файл исполняемым, и запускаем его, указывая в параметре нашу hello:



Длинный список получится, почти 1000 строк - так что все показывать не буду, но идея, надеюсь, понятна. Видно, какие функции каждой библиотеки можно отследить средствами DTrace.

Очевидным будем из всего этого списка воспользоваться пробой, которая поймает наш printf:



Если запустить этот скрипт и передать ему нашу hello, как и в первом примере, то получится вот что:

Итак, открытие OpenSolaris.Org состоялось!

Но, как и ожидалось, исходники самой операционной системы пока недоступны. В то же время, чтобы доказать серьёзность намерений, разработчикам уже предоставили доступ к исходникам DTrace.

Bryan Cantrill сегодня добавил очень интересную запись в свой блог, советую почитать: Solaris 10 Revealed.