Я работаю в фирме с определенным количеством устаревших пакетных процессов.
Когда дело доходит до соединений с базой данных, кое-что из этого действительно нечеткое.
Strace - это не вариант, процессов слишком много, они слишком недолговечны, мне нужно проверять несколько ящиков.
IPtables не является вариантом, вы можете сопоставить путь процесса / пользователя, но вы не можете записать эту информацию (насколько мне известно)
Обычные инструменты, такие как lsof / netstat и т. Д., Содержат информацию только о активных процессах и о том, какие соединения они используют.
С другой стороны, эти пакетные задания уже мертвы, поэтому я не могу соотнести процесс с сокетом.
Так что сейчас самое время узнать о systemtap. Или напишите собственный модуль ядра. Но у меня нет опыта / времени, чтобы начать взламывать таблицу системных вызовов, и, кроме того, я хочу изучить systemtap, потому что это кажется очень полезным инструментом.
Моя конечная цель - написать зонд, который -
Но дьявол кроется в деталях ... Я не могу установить его на Debian (wheezy) (вообще), а на Ubuntu 12 (Precise) я получаю странные ошибки.
В Ubuntu простой зонд systemtap работает нормально (это простые примеры копирования и вставки).
#! /usr/bin/env stap
probe begin { println("hello world") exit () }
Это дает ожидаемый результат.
sudo stap -v stapinit.stp
Pass 1: parsed user script and 76 library script(s) using 22792virt/13512res/2224shr kb, in 90usr/0sys/93real ms.
Pass 2: analyzed script: 1 probe(s), 1 function(s), 0 embed(s), 0 global(s) using 23056virt/14000res/2304shr kb, in 10usr/0sys/2real ms.
Pass 3: translated to C into "/tmp/stap2ntfcM/stap_32acf6b6a3f643d9444c9c8339e390d8_687.c" using 23056virt/14332res/2584shr kb, in 0usr/0sys/0real ms.
Pass 4: compiled C into "stap_32acf6b6a3f643d9444c9c8339e390d8_687.ko" in 1290usr/390sys/1902real ms.
Pass 5: starting run.
hello world
Pass 5: run completed in 10usr/40sys/596real ms.
Но более сложный зонд просто умирает, например:
# Show sockets setting options
# Return enabled or disabled based on value of optval
function getstatus(optval)
{
if ( optval == 1 )
return "enabling"
else
return "disabling"
}
probe begin
{
print ("\nChecking for apps setting socket options\n")
}
# Set a socket option
probe tcp.setsockopt
{
status = getstatus(user_int($optval))
printf (" App '%s' (PID %d) is %s socket option %s... ", execname(), pid(), status, optstr)
}
# Check setting the socket option worked
probe tcp.setsockopt.return
{
if ( ret == 0 )
printf ("success")
else
printf ("failed")
printf ("\n")
}
probe end
{
print ("\nClosing down\n")
}
Производит -
Pass 1: parsed user script and 76 library script(s) using 22812virt/13660res/2224shr kb, in 90usr/10sys/120real ms.
semantic error: missing i386 kernel/module debuginfo under '/lib/modules/3.2.0-27-generic-pae/build' while resolving probe point kernel.function("tcp_setsockopt")
semantic error: no match while resolving probe point tcp.setsockopt
semantic error: missing i386 kernel/module debuginfo under '/lib/modules/3.2.0-27-generic-pae/build' while resolving probe point kernel.function("tcp_setsockopt").return
semantic error: no match while resolving probe point tcp.setsockopt.return
Pass 2: analyzed script: 2 probe(s), 1 function(s), 0 embed(s), 0 global(s) using 23136virt/14424res/2540shr kb, in 70usr/580sys/1255real ms.
Pass 2: analysis failed. Try again with another '--vp 01' option.
Кажется, мне не хватает зависимости, но я почти установил кухонную раковину.
sudo apt-get install elfutils
sudo apt-get install linux-headers-generic gcc libcap-dev
sudo apt-get install systemtap-sdt-dev
sudo apt-get install systemtap systemtap-doc linux-image linux-headers-generic-pae
Пакеты, предлагаемые apt-get install systemtap, могут вводить в заблуждение.
linux-headers-virtual, linux-image, linux-source и linux-tools - это виртуальные пакеты, поэтому они будут отслеживать, до какого ядра сейчас обновлено.
sudo apt-get install linux-headers-virtual linux-image linux-source linux-tools
Для удобства я также установил fdutils и пакет ядра.
sudo apt-get install fdutils kernel-package
Постараюсь это сделать и доложу.
Все еще не работает, та же ошибка, это фактически третья система, на которой я пытался ее установить.
Я также обнаружил следующую ошибку Ubuntu, возможно, пакет плохой?
https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/824105
Кажется, проблема Ubuntu в том, что они не создают пакет отладочных символов ядра или, по крайней мере, не распространяют его стандартным способом. Я пришел к выводу, что пакет systemtap не работает в Ubuntu, поскольку он не устанавливает важных зависимостей.
https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/106957
В моем ящике Debian у меня другая проблема, тестирование включено - таким образом, gcc обновлен до 4.6, а пакет linux-headers требует gcc 4.3
root@datasift:~# apt-get install systemtap linux-image-`uname -r`-dbg linux-headers-`uname -r`
Reading package lists... Done
Building dependency tree
Reading state information... Done
systemtap is already the newest version.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
linux-headers-2.6.32-5-amd64 : Depends: gcc-4.3 but it is not going to be installed
E: Broken packages
root@datasift:~# uname -a
Linux datasift.sentimentmetrics.com 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
Итак, в заключение - вполне возможно, что systemtap работает нормально в Debian, маловероятно, что он работает в Ubuntu, и у меня нет времени продолжать. Хотелось бы мне запустить BSD / Solaris или что-то еще со стандартным интерфейсом инструментов, но нравится вам это или нет, Linux - бог товаров.
Обновление 4
Тем временем мне удалось использовать Linux Auditing Framework, вдохновленный следующей публикацией:
как я могу определить, какой процесс делает UDP-трафик в Linux?
Моя команда auditd:
auditctl -a exit,always -F arch=b64 -F a0=2 -S socket
Создает сообщения журнала в следующем формате:
type=SYSCALL msg=audit(1344346149.672:1670): arch=c000003e syscall=41 success=yes exit=5 a0=2 a1=1 a2=6 a3=1999999999999999 items=0 ppid=1 pid=29674 auid=0 uid=1003 gid=1003 euid=1003 suid=1003 fsuid=1003 egid=1003 sgid=1003 fsgid=1003 tty=(none) ses=124 comm="php5" exe="/usr/bin/php5" key=(null)
Что приятно, но в конечном итоге бесполезно, так как не содержит аргументов программы.
Что мне действительно нужно (как минимум), так это то, что может фиксировать аргументы, например:
exe="/usr/bin/php5" args="/Administraitor/learn-to-code-hehe.php"
В идеале я хочу иметь возможность фильтровать по хосту и порту.
Мне удалось заставить его работать на Ubuntu, другое дело - Debian.
Я создал репозиторий со скриптами установки / мониторинга
https://bitbucket.org/sentimental/poc_stap
Скрипты также предоставляют программные аргументы, поэтому для непослушного PHP-скрипта теперь можно идентифицировать нарушителя.
Не столько ответ, сколько предупреждение: SystemTap может сбивать с толку, иногда даже просто глючить, а иногда не интуитивно. Тем не менее, это хороший инструмент, просто будьте осторожны с ним и проверяйте свои результаты с другими инструментами.
Эта запись в блоге Брендан Грегг дает очень глубокий анализ странного мира SystemTap. Конечно, поскольку автор блога обычно использует dtrace
, его точка зрения может быть необъективной. В любом случае, пост сделан очень хорошо и снова заставил меня задуматься о надежности SystemTap. В сообщении блога также есть несколько примеров кода, которые могут помочь вам решить вашу проблему (ы).
Вот цитата из сообщения в блоге:
Используя SystemTap, я вёл записи о том, что делал, в том числе о том, что работало, а что нет, и как я исправлял проблемы. Это оказалось полезным справочником.
В некоторых недавних обсуждениях DTrace люди спрашивали, как он соотносится с SystemTap, причем некоторые отмечали, что у них тоже не было времени на изучение. Меня поощряют публиковать сообщения о моем опыте, что легко сделать из моих заметок. Я мог (и, вероятно, должен) внести некоторые из них в базу данных ошибок SystemTap.
Я делюсь разнообразным опытом использования SystemTap, включая случаи, когда я делал ошибки, потому что не знал, что делал. Я начну с рассказа об отслеживании дискового ввода-вывода, который объединяет различные возможности. После этого он становится немного разрозненным, вырезанным из разных нот. Я постараюсь сохранить это техническое, позитивное и конструктивное. Возможно, это поможет самому проекту SystemTap увидеть, с чем борется пользователь (с сильным опытом динамической трассировки и разработки ядра).