From Fedora Project Wiki
mNo edit summary
(→‎Scope: Add who is working on which package. Explain troublesome packages.)
Line 42: Line 42:
Currently identified packages:
Currently identified packages:


* postgresql: Able to build something that works with current rpm. ([http://www.postgresql.org/docs/8.2/interactive/dynamic-trace.html upstream docs])
* postgresql: Already able to build something that works with current rpm. ([http://www.postgresql.org/docs/8.2/interactive/dynamic-trace.html upstream docs], [http://gnu.wildebeest.org/diary/2009/02/24/systemtap-09-markers-everywhere/ example trace]) - stan
* xorg-x11-server: Need tweaks to systemtap to gen proper header from .d file. ([http://people.freedesktop.org/~alanc/dtrace/ upstream docs])
* xorg-x11-server: Need tweaks to systemtap to gen proper header from .d file. ([http://people.freedesktop.org/~alanc/dtrace/ upstream docs]) - stan and/or rajan
* java-1.6.0-openjdk: Probably likewise, has .d files in there. ([http://java.sun.com/javase/6/docs/technotes/guides/vm/dtrace.html upstream docs])
* java-1.6.0-openjdk: Probably likewise, has .d files in there. ([http://java.sun.com/javase/6/docs/technotes/guides/vm/dtrace.html upstream docs]) - stan and/or mjw
* mysql 6.0.8. Really new alpha version from mysql.com has probes. However, the version in fedora 5.0.67 doesn't it built in. A backport would be required.
* tcl-8.4.16+: Has a single generic/tclDTrace.d file. ([http://wiki.tcl.tk/19923 upstream docs]) - stan
* tcl-8.4.16+: Has a single generic/tclDTrace.d file. ([http://wiki.tcl.tk/19923 upstream docs])
* firefox-3.1-0.6 ([https://wiki.mozilla.org/Performance/Optimizing_JavaScript_with_DTrace upstream docs]) - rajan


To investigate:
Packages without probes or currently not possible:


* Apache, Ruby, PHP, Sendmail, Python, others?
* mysql 6.0.8. Really new alpha version from mysql.com has probes. However, the version in fedora 5.0.67 doesn't. A backport would be required. Won't be in next fedora.
* apachetop-0.12.6
* perl-5.10.0
* Python-2.6     
* php-5.2.8 
* ruby-1.8.6-p287
 
It seems as if several of these were dtrace-instrumented in code that was never merged into the upstream versions of the package, but instead represented as run-time add-ons or private patches for solaris distributions.  Disappointing, but perhaps we can do better and engage the respective upstream teams.  This will of course take time and panache.
 
At least the patches tend to be very small so we have some freedom to choose between approaches (adding STAP_PROBE/whatever hooks directly to the core upstream code; or fedora local patches; or add-on shared libraries like for php/httpd).
 
Another approach worth considering is adding tapsets that map process.mark() events to process.function/statement() to approximate
the dtrace out-of-tree patches.
 
For php, it was implemented as an add-on module (shared library listed in /etc/php.ini) that intercepts internal php interpreter function pointers and wraps those calls with markers. Same for httpd. Ruby is similar but richer & far more complicated.
 
For perl, it was implemented as an out-of-tree patch to the core. Same for python.


== How To Test ==
== How To Test ==

Revision as of 11:04, 2 March 2009


Systemtap Static Probes

Summary

Systemtap allows event tracing of programs when they have static probes inserted. This allows for tracing specifics of an application on a higher level that is meaningful to the application user so they don't have to know the exact source code details for tracing what is happening.

Owner

  • email: mjw@redhat.com

Current status

  • Targeted release: Fedora 11
  • Last updated: February 23 2009
  • Percentage of completion: 20%
  • systemtap-sdt-devel 0.9-1.fc11 is now available in rawhide.

Detailed Description

By packaging a new version of systemtap, that enables programs that already have static dtrace probe markers in their sources and by making those packages build depend on the new systemtap-sdt-devel package and recompiling them with probe points enabled, users of those packages will be able to trace any high level events that these packages provide.

Benefit to Fedora

It will be easier for developers and users to observe what is really happening on their system on a higher (application) level.

Scope

  • Work with upstream to identify any issues with the new capabilities while we activate probes in packages.
  • Package new version of Systemtap (including new subpackage systemtap-sdt-devel).
  • Identify packages that already include static user probes (see below)
  • Work with package maintainer to enable them in the Fedora build spec file.
  • Add documentation on enabled probes and how to use them with a systemtap tapset.

Currently identified packages:

  • postgresql: Already able to build something that works with current rpm. (upstream docs, example trace) - stan
  • xorg-x11-server: Need tweaks to systemtap to gen proper header from .d file. (upstream docs) - stan and/or rajan
  • java-1.6.0-openjdk: Probably likewise, has .d files in there. (upstream docs) - stan and/or mjw
  • tcl-8.4.16+: Has a single generic/tclDTrace.d file. (upstream docs) - stan
  • firefox-3.1-0.6 (upstream docs) - rajan

Packages without probes or currently not possible:

  • mysql 6.0.8. Really new alpha version from mysql.com has probes. However, the version in fedora 5.0.67 doesn't. A backport would be required. Won't be in next fedora.
  • apachetop-0.12.6
  • perl-5.10.0
  • Python-2.6
  • php-5.2.8
  • ruby-1.8.6-p287

It seems as if several of these were dtrace-instrumented in code that was never merged into the upstream versions of the package, but instead represented as run-time add-ons or private patches for solaris distributions. Disappointing, but perhaps we can do better and engage the respective upstream teams. This will of course take time and panache.

At least the patches tend to be very small so we have some freedom to choose between approaches (adding STAP_PROBE/whatever hooks directly to the core upstream code; or fedora local patches; or add-on shared libraries like for php/httpd).

Another approach worth considering is adding tapsets that map process.mark() events to process.function/statement() to approximate the dtrace out-of-tree patches.

For php, it was implemented as an add-on module (shared library listed in /etc/php.ini) that intercepts internal php interpreter function pointers and wraps those calls with markers. Same for httpd. Ruby is similar but richer & far more complicated.

For perl, it was implemented as an out-of-tree patch to the core. Same for python.

How To Test

Whether systemtap and static markers are working in general can be tested by installing systemtap, kernel-debuginfo and the systemtap-testsuite. Running sudo make installcheck in /usr/share/systemtap/testsuite

When applications get static markers enabled we should add them to a testing page listing:

  • Package install instructions.
  • Setup and sample run of the application
  • A reference to the probe names.
  • And an simple example stap invocation listing markers that can be enabled.

Question: Is there a convention/template for adding such test pages for test days?

User Experience

For packages that have static probes enabled users will be able to trace high-level events, like for example database transactions, through stap.

Dependencies

  • A new version of systemtap with the systemtap-sdt-devel subpackage.
  • Any package wishing to expose existing probes in its (upstream) sources depending on systemtap-sdt-devel and adding an --enable-dtrace or equivalent to its spec file.

Contingency Plan

Even if all the tracing will not work, packages that are converted to provide static probes will not be impacted since the probe points have (near) zero overhead, so in the worse case some packages were recompiled to enable the feature, but users will still not be able to use it.

Documentation

The upstream wiki is the best description for now http://sourceware.org/systemtap/wiki/UsingStaticUserMarkers the systemtap list has an example on converting a package http://sourceware.org/ml/systemtap/2009-q1/msg00140.html

While working on this feature this section will be expanded to list packages that have probe points enabled and pointers to (upstream) package documentation on the probe names and semantics like for postgresql http://www.postgresql.org/docs/8.2/static/dynamic-trace.html

Release Notes

Systemtap has been extended to support user space tracing, and in particular to support static (dtrace compatible) markers enabled in various programs in Fedora 11. This enables users, developers and administrators a high level overview of what is going on with their system or deep down in a specific program or subsystem.

Systemtap comes with a tutorial, a language reference manual, a tapsets reference and an examples directory under /usr/share/doc/systemtap-?.?/

  • TODO: Should have a list of which packages were enabled with markers when finished.

Comments and Discussion