DTrace - Wie geht das? Eine kurze Einführung!

[DukeNuke2]

Hallo ihr, die ihr den Funktionen aus den tiefen des Betriebssystems auf der Spur seid. Ich hatte in diesem Beitrag schon einiges über DTrace erzählt und auch eine kleine Einführung Online gestellt. auf wunsch in dem o.g. Thread stelle ich das "Tutorial" oder besser die kleine Einführung hier nochmal rein. Viel spaß beim tracen

DN2

--------------


Was ist DTrace?
DTrace ist ein umfassendes Framework für die dynamische Ablaufverfolgung im Betriebssystem Solaris und ab der Version 10.5 auch bei Mac OS X.
DTrace bietet eine leistungsfähige Infrastruktur, die es Administratoren, Entwicklern und Wartungspersonal ermöglicht, beliebige Fragen zum Verhalten des Betriebssystems und der Benutzerprogramme zu beantworten.

Was leistet DTrace?
- Sehr sicheres tracen von Informationen auf Live-Systemen
- Durch die Nutzung von DTrace können keine Abstürze verursacht werden
- Es können Kernel- und Userdaten getraced werden
- Sehr geringer Overhead während des tracing, kein Overhead wenn tracing nicht ausgelesen wird

Was kann "getraced" werden?
- Alle Argumente die an eine Funktion übergeben werden
- Jede globale Variable des Kernels
- Zeitstempel im Nanosekunden(!) Bereich
- Welcher Code hat welche Funktion aufgerufen
- Welche Prozesse liefen als die Funktion aufgerufen wurde
- Welcher Prozess hat die Funktion aufgerufen

Wie arbeitet DTrace?
Das dtrace Kommando benutzt die Libary libdtrace als Einstiegspunkt zu den verschieden “DTrace Providern” innerhalb des Kernels, von dem jeder unterschiedliche Daten aus dem Kernel liefert.
Alle DTrace Operationen werden durch das Dienstprogramm dtarce aufgerufen. Das Kommando kann direkt, mit Kommandline Optionen oder in einem “D” Script genutzt werden. D ist der Programmiersprache C sehr ähnlich und wird “on the fly” bei der Ausführung durch einen in den Kernel integrierten Code-Interpreter kompiliert. Der Code wird vor dem Ausführen im Kernel in einer “virtuellen Maschine” auf Sicherheit getestet. Wenn der Test bestanden wurde und ausreichende Rechte für die Ausführung vorhanden sind, wird der Code in den Kernel gepatcht und auf Kernelebene ausgeführt.


Prüfpunkte:
Der Prüfpunkt kann mit einem Messpunkt in der Technik verglichen werden. An diesen Punkten im Kernel können die Daten ausgelesen und den “Konsumenten” zur Verfügung gestellt werden. Jeder dieser Messpunkte hat zwei (2) eindeutige Kennzeichnungen.
- eine ID (z.B. 21223)
- einen Namen nach dem Modell provider:module:function:name

Provider:
Der Name des DTrace-Providers, der diesen Prüfpunkt veröffentlicht. Der Name des Providers stimmt bezeichnenderweise mit dem Namen des DTrace-Kernelmoduls überein, das die Instrumentation zur Aktivierung des Prüfpunkts durchführt.
Module:
Bei Prüfpunkten für eine bestimmte Programmposition der Name des Moduls, in dem sich der Prüfpunkt be?ndet. Dabei handelt es sich entweder um den Namen eines Kernelmoduls oder einer Benutzerbibliothek.
Function:
Bei Prüfpunkten für eine bestimmte Programmposition der Name der Programmfunktion, in der sich der Prüfpunkt be?ndet.
Name:
Der letzte Bestandteil des Prüfpunktnamens gibt, wie beispielsweise BEGIN oder END, in gewissem Maße Aufschluss über die semantische Bedeutung des Prüfpunkts.

Mit dem Befehl “dtrace –l” werden ALLE Messpunkte des Systems angezeigt. Die Anzahl der Punkte ist je nach Ausstattung (Hardware) und der Art der Installation (Software) für jedes System unterschiedlich.
Beim aufrufen eines Messpunktes werden bestimmte Daten übertragen (execname, pid, arg[], timestamp, probemod, probefunc) die angezeigt werden können und durch Argumente gezählt, summiert und quantisiert werden können.

Beispiele:

 # New processes with arguments
dtrace -n 'proc:::exec-success { trace(curpsinfo->pr_psargs); }'
 
# Files opened by process
dtrace -n 'syscall::open*:entry { printf("%s %s",execname,copyinstr(arg0)); }'
 
# Syscall count by program
dtrace -n 'syscall:::entry { @num[execname] = count(); }'
 
# Syscall count by syscall
dtrace -n 'syscall:::entry { @num[probefunc] = count(); }'
 
# Syscall count by process
dtrace -n 'syscall:::entry { @num[pid,execname] = count(); }'
 
# Read bytes by process
dtrace -n 'sysinfo:::readch { @bytes[execname] = sum(arg0); }'
 
# Write bytes by process
dtrace -n 'sysinfo:::writech { @bytes[execname] = sum(arg0); }'
 
# Read size distribution by process
dtrace -n 'sysinfo:::readch { @dist[execname] = quantize(arg0); }'
 
# Write size distribution by process
dtrace -n 'sysinfo:::writech { @dist[execname] = quantize(arg0); }'
 
# Disk size by process
dtrace -n 'io:::start { printf("%d %s %d",pid,execname,args[0]->b_bcount); }'

Links und Quellen:
http://www.sun.com/bigadmin/content/dtrace/
http://docs.sun.com/app/docs/doc/819-6956
http://www.sun.com/bigadmin/scripts/indexDtrace.html

[AgentSmith]

Wie schon im Ursprungsthread: Danke! Gut zusammengefasst, interessant zu lesen!

[DukeNuke2]

Wie schon im Ursprungsthread: Danke! Gut zusammengefasst, interessant zu lesen!

danke hab das ja auch nur aus dem alten thread übernommen. aber der antragsteller hat schon recht. in einem längeren thread kann sowas schnell überlesen werden und so kann man überflüssigen fragen gleich entgegenwirken

[Bier]

Es lebe Instruments...

[DukeNuke2]

Es lebe Instruments...

verwöhnte gui generation

[DukeNuke2]

Apple beschneidet die DTrace funktionalität:
http://www.c0t0d0s0.org/archives/401...proc-flag.html
http://blogs.sun.com/ahl/entry/mac_os_x_and_the

Da hat wohl jemand Angst das man per DTrace zu viele Geheimisse aus den tiefen des Betriebssystems zu Tage fördert

quelle: www.c0t0d0s0.org

[AgentSmith]

Sehr interessant - und bedenklich. Danke für die Links!

[DukeNuke2]

es wird ja schon an einer möglichkeit gearbeitet die beschränkungen zu umgehen aber stimmt schon, bedenklich ist das schon! wenn man nach einem problem sucht und dtrace wird einem als tool dafür angeboten und kann dann die ergebnisse NICHT liefern weil es beschnitten wurde... naja, ich bleib eh lieber bei solaris!