From: Philippe Proulx Date: Fri, 4 Sep 2015 03:12:40 +0000 (-0400) Subject: nuts-and-bolts: split and update contents X-Git-Url: https://git.lttng.org./?a=commitdiff_plain;h=6b7fb0d382c439cb3b977b77cedc993fcfd1b755;p=lttng-docs.git nuts-and-bolts: split and update contents Signed-off-by: Philippe Proulx --- diff --git a/contents/nuts-and-bolts/intro.md b/contents/nuts-and-bolts/intro.md index ba77f89..0347a62 100644 --- a/contents/nuts-and-bolts/intro.md +++ b/contents/nuts-and-bolts/intro.md @@ -6,93 +6,3 @@ What is LTTng? As its name suggests, the _Linux Trace Toolkit: next generation_ is a modern toolkit for tracing Linux systems and applications. So your first question might rather be: **what is tracing?** - -As the history of software engineering progressed and led to what -we now take for granted—complex, numerous and -interdependent software applications running in parallel on -sophisticated operating systems like Linux—the authors of such -components, or software developers, began feeling a natural -urge of having tools to ensure the robustness and good performance -of their masterpieces. - -One major achievement in this field is, inarguably, the -GNU debugger -(GDB), which is an essential tool for developers to find and fix -bugs. But even the best debugger won't help make your software run -faster, and nowadays, faster software means either more work done by -the same hardware, or cheaper hardware for the same work. - -A _profiler_ is often the tool of choice to identify performance -bottlenecks. Profiling is suitable to identify _where_ performance is -lost in a given software; the profiler outputs a profile, a -statistical summary of observed events, which you may use to know -which functions took the most time to execute. However, a profiler -won't report _why_ some identified functions are the bottleneck. -Also, bottlenecks might only occur when specific conditions are met. -For a thorough investigation of software performance issues, a history -of execution, with historical values of chosen variables, is -essential. This is where tracing comes in handy. - -_Tracing_ is a technique used to understand what goes on in a running -software system. The software used for tracing is called a _tracer_, -which is conceptually similar to a tape recorder. When recording, -specific points placed in the software source code generate events -that are saved on a giant tape: a _trace_ file. Both user applications -and the operating system may be traced at the same time, opening the -possibility of resolving a wide range of problems that are otherwise -extremely challenging. - -Tracing is often compared to _logging_. However, tracers and loggers -are two different types of tools, serving two different purposes. Tracers are -designed to record much lower-level events that occur much more -frequently than log messages, often in the thousands per second range, -with very little execution overhead. Logging is more appropriate for -very high-level analysis of less frequent events: user accesses, -exceptional conditions (errors and warnings, for example), database -transactions, instant messaging communications, etc. More formally, -logging is one of several use cases that can be accomplished with -tracing. - -The list of recorded events inside a trace file may be read manually -like a log file for the maximum level of detail, but it is generally -much more interesting to perform application-specific analyses to -produce reduced statistics and graphs that are useful to resolve a -given problem. Trace viewers and analysers are specialized tools which -achieve this. - -So, in the end, this is what LTTng is: a powerful, open source set of -tools to trace the Linux kernel and user applications. LTTng is -composed of several components actively maintained and developed by -its community. - -Excluding proprietary solutions, a few competing software tracers -exist for Linux. -ftrace -is the de facto function tracer of the Linux kernel. -strace -is able to record all system calls made by a user process. -SystemTap -is a Linux kernel and user space tracer which uses custom user scripts -to produce plain text traces. -sysdig -also uses scripts, written in Lua, to trace and analyze the Linux -kernel. - -The main distinctive features of LTTng is that it produces correlated -kernel and user space traces, as well as doing so with the lowest -overhead amongst other solutions. It produces trace files in the -CTF -format, an optimized file format for production and analyses of -multi-gigabyte data. LTTng is the result of close to 10 years of -active development by a community of passionate developers. It is -currently available on all major desktop, server, and embedded Linux -distributions. - -The main interface for tracing control is a single command line tool -named `lttng`. The latter can create several tracing sessions, -enable/disable events on the fly, filter them efficiently with custom -user expressions, start/stop tracing and do much more. Traces can be -recorded on disk or sent over the network, kept totally or partially, -and viewed once tracing is inactive or in real-time. - -[Install LTTng now](#doc-installing-lttng) and start tracing! diff --git a/contents/nuts-and-bolts/lttng-alternatives.md b/contents/nuts-and-bolts/lttng-alternatives.md new file mode 100644 index 0000000..6b827d8 --- /dev/null +++ b/contents/nuts-and-bolts/lttng-alternatives.md @@ -0,0 +1,52 @@ +--- +id: lttng-alternatives +--- + +Excluding proprietary solutions, a few competing software tracers +exist for Linux: + + * ftrace + is the de facto function tracer of the Linux kernel. Its user + interface is a set of special files in sysfs. + * perf is + a performance analyzing tool for Linux which supports hardware + performance counters, tracepoints, as well as other counters and + types of probes. perf's controlling utility is the `perf` command + line/curses tool. + * strace + is a command line utility which records system calls made by a + user process, as well as signal deliveries and changes of process + state. strace makes use of + ptrace + to fulfill its function. + * SystemTap + is a Linux kernel and user space tracer which uses custom user scripts + to produce plain text traces. Scripts are converted to the C language, + then compiled as Linux kernel modules which are loaded to produce + trace data. SystemTap's primary user interface is the `stap` + command line tool. + * sysdig, like + SystemTap, uses scripts to analyze Linux kernel events. Scripts, + or _chisels_ in sysdig's jargon, are written in Lua and executed + while the system is being traced, or afterwards. sysdig's interface + is the `sysdig` command line tool as well as the curses-based + `csysdig` tool. + +The main distinctive features of LTTng is that it produces correlated +kernel and user space traces, as well as doing so with the lowest +overhead amongst other solutions. It produces trace files in the +CTF +format, an optimized file format for production and analyses of +multi-gigabyte data. LTTng is the result of close to 10 years of +active development by a community of passionate developers. It is +currently available on all major desktop, server, and embedded Linux +distributions. + +The main interface for tracing control is a single command line tool +named `lttng`. The latter can create several tracing sessions, +enable/disable events on the fly, filter them efficiently with custom +user expressions, start/stop tracing, and do much more. Traces can be +recorded on disk or sent over the network, kept totally or partially, +and viewed once tracing becomes inactive or in real-time. + +[Install LTTng now](#doc-installing-lttng) and start tracing! diff --git a/contents/nuts-and-bolts/what-is-tracing.md b/contents/nuts-and-bolts/what-is-tracing.md new file mode 100644 index 0000000..e419a56 --- /dev/null +++ b/contents/nuts-and-bolts/what-is-tracing.md @@ -0,0 +1,63 @@ +--- +id: what-is-tracing +--- + +As the history of software engineering progressed and led to what +we now take for granted—complex, numerous and +interdependent software applications running in parallel on +sophisticated operating systems like Linux—the authors of such +components, or software developers, began feeling a natural +urge of having tools to ensure the robustness and good performance +of their masterpieces. + +One major achievement in this field is, inarguably, the +GNU debugger +(GDB), which is an essential tool for developers to find and fix +bugs. But even the best debugger won't help make your software run +faster, and nowadays, faster software means either more work done by +the same hardware, or cheaper hardware for the same work. + +A _profiler_ is often the tool of choice to identify performance +bottlenecks. Profiling is suitable to identify _where_ performance is +lost in a given software; the profiler outputs a profile, a +statistical summary of observed events, which you may use to discover +which functions took the most time to execute. However, a profiler +won't report _why_ some identified functions are the bottleneck. +Bottlenecks might only occur when specific conditions are met, sometimes +almost impossible to capture by a statistical profiler, or impossible to +reproduce with an application altered by the overhead of an event-based +profiler. For a thorough investigation of software performance issues, +a history of execution, with the recorded values of chosen variables +and context, is essential. This is where tracing comes in handy. + +_Tracing_ is a technique used to understand what goes on in a running +software system. The software used for tracing is called a _tracer_, +which is conceptually similar to a tape recorder. When recording, +specific probes placed in the software source code generate events +that are saved on a giant tape: a _trace_ file. Both user applications +and the operating system may be traced at the same time, opening the +possibility of resolving a wide range of problems that are otherwise +extremely challenging. + +Tracing is often compared to _logging_. However, tracers and loggers +are two different tools, serving two different purposes. Tracers are +designed to record much lower-level events that occur much more +frequently than log messages, often in the thousands per second range, +with very little execution overhead. Logging is more appropriate for +very high-level analysis of less frequent events: user accesses, +exceptional conditions (errors and warnings, for example), database +transactions, instant messaging communications, etc. More formally, +logging is one of several use cases that can be accomplished with +tracing. + +The list of recorded events inside a trace file may be read manually +like a log file for the maximum level of detail, but it is generally +much more interesting to perform application-specific analyses to +produce reduced statistics and graphs that are useful to resolve a +given problem. Trace viewers and analysers are specialized tools +designed to do this. + +So, in the end, this is what LTTng is: a powerful, open source set of +tools to trace the Linux kernel and user applications at the same time. +LTTng is composed of several components actively maintained and +developed by its community. diff --git a/toc/docs.yml b/toc/docs.yml index fe9e3f4..dbb8ade 100644 --- a/toc/docs.yml +++ b/toc/docs.yml @@ -4,6 +4,11 @@ cats: title: What's new in LTTng 2.6? - id: nuts-and-bolts title: Nuts and bolts + cats: + - id: what-is-tracing + title: What is tracing? + - id: lttng-alternatives + title: Alternatives to LTTng - id: installing-lttng title: Installing LTTng cats: