This is easy. There is a global trace() function, which you can call from anywhere. The output from trace calls only appears when the flash applikation in run on either the debugger version of the flash player or the debugger version of the standalone player.
There are two options for getting at the output: Either through the flex debugger or by having it go into a file. Of the two, I have found the latter the most useful.
Flex trace into a file
In your home directory, you put a file called mm.cfg, which contains the following three lines:
ErrorReportingEnable=1And when you run your flash application on a debug player, the flash runtime will open and write to a file at this path: "$HOME/.macromedia/Flash_Player/Logs/flashlog.txt". You can then "tail -f" this file and see all the trace.
Flex trace through debugger
Well, you start the fdb debugger binary and type run. After this, you start your flash application in a debugger version of a player and connects to the debugger through the dialog that opens. You then switch back to the fdb console and type continue (twice). Trace will then flow out on the fdb console.
Only problem is, that on linux, the fdb console disconnects at random intervals (or, most often, just before you reach the trace information you are interested in).
Flex trace in the FlashTracer firefox plugin
Firefox has a nice plugin called FlashTracer, which can show the contents of the trace file enabled with the mm.cfg file. This is really nice, as you need not tail the file and can view the output along the application.
If you are running linux, you need a special built version. Alessandro Crugnola has a nice blog entry about how to install the linux built version of FlashTracer.
While you use tracing mostly for debugging purposes, logging can be done on several levels and hence be used for more sophisticated purposes. There is a complete mx.logging package in flex2, which provides the main logging functionality of flex.
Two central abstractions here are ILogger which abstracts something that you can log to and ILoggingTarget, which abstracts something that can accept logs and do something with them. When logging to an ILogger, you can do it as debug, info, warn, error or fatal. In addition, an ILogger has a category, which is a hierarchic name. A log target can have filters on which categories they "let through", and a level setting, that specifies which of the five debug, info, warn, error and fatal levels that it "let through".
In the mx.logging.targets package, there are two (very) simple logging targets implemented. One which goes to trace output, and one old, deprecated minidebug-based one, which should never have been in the public flex2 api.
Good thing is, that you can implement your own log targets. I have written an example on how to send logs to the server from a flex application using a log target implementation, which might be helpful.