Revision as of 17:16, 22 January 2009

Feature Name

Systemtap Static Probes for userspace programs.

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

Name: Mark Wielaard

email: mjw@redhat.com

Current status

Targeted release: Fedora 11
Last updated: January 19 2009
Percentage of completion: 5%

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 (postgresql, java-1.6.0-openjdk, mysql, xorg-x11-server, ...)
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: Able to build something that works with current rpm. (upstream docs)
xorg-x11-server: Need tweaks to systemtap to gen proper header from .d file. (upstream docs)
java-1.6.0-openjdk: Probably likewise, has .d files in there. (upstream docs)
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.

To investigate:

Apache, Ruby, PHP, Sendmail, Python, others?

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.

Not required for this feature, but since systemtap uses debuginfo, this feature is enhanced by the Debug Info Revamp Feature.

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

FIXME: Should have some notes about the feature and which packages were enabled when finished.

Comments and Discussion

See Talk:Features/SystemtapStaticProbes

@@ Line 52: / Line 52: @@
 == How To Test ==
-<!-- This does not need to be a full-fledged document.  Describe the dimensions of tests that this feature is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
+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
-Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
+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.
-A good "how to test" should answer these four questions:
+'''Question''': Is there a convention/template for adding such test pages for test days?
-. What special hardware / data / etc. is needed (if any)?
-. How do I prepare my system to test this feature? What packages
-need to be installed, config files edited, etc.?
-. What specific actions do I perform to check that the feature is
-working like it's supposed to?
-. What are the expected results of those actions?
--->
-{{admon/important | Needs to be expanded |
-* Need a specific pacakage list.
-* For each package enabling probes a reference to the probe names.
-* And an simple example stap invocation listing markers that can be enabled.
-}}
 == User Experience ==

Search

Features/SystemtapStaticProbes: Difference between revisions