(assuming that you kept the FUP default; refer to files.c to be certain).
The version of FUP that needs to be used for the logging system HAS to be higher than version 1.8.1 although we will assume that version 1.9 is installed. Make sure that you read the section about FUP when installing! There is one property to add for @getupdate() to work correctly, which is not cited in the FUP README as it concerns Aloha specifically.
There are actually two form of logs. We call them:
Static method
Controlled by Aloha_Log.static which has to be set to 1. If so, there are two properties that handle the file name and its location: Aloha_log.log_file and Aloha_Log.log_dir. Those two properties are STRING. This method will therefore save the log into a file that you designate and it will always be the same unless you change them. The drawback of this method is that log files *might* get big, and if you do not write your own cron file to archive them regularly, it may take quite a while to search what you are looking for. Of course, grep is always here to help us out, but to solve that problem, the dynamic method can be used.
Dynamic method
Controlled by Aloha_Log.dynamic which has to be set to 1. In this case, Aloha_Log.log_dir STILL has to be set, but Aloha_log.log_file is no longer needed. It is up to you now to decide the period of time the same file name should be used.
The choice that you will make obviously (or may be not) depends on the amount of traffic that you expect. To make that choice taken in effect, check Aloha_log_.dwm and use: "day", "week", or "month".
There is nothing to prevent you to use more than one method (I always use the three of them). So, several examples of this settings would be:
;Aloha_log_.dwm={"day"}
;Aloha_log_.dwm={"day", "month"}
The order of the STR arguments does not matter.
You could decide to use a file name for each day.
For instance, if today is January 1, 2003 then Aloha_log_01012003.log is going to be used as the file name and all logs will be saved for that day on that file. The next day and new file will be created: Aloha_log_01022003.log and so on. This option will allow you to trouble shoot logs faster if you know when the problem was and will allow you to delete them easily as well. For example, if you decide to erase all logs for January, rm -rf 01*.log will do the job cleanly.
You could decide to use a file name for every week.
Again, similar thing will happen and Aloha_log_startstop_2003.log is going to be used with startstop being the length of seven days. So it will look something like: Aloha_log_0101_0107_2003.log. Please note that the above example has log from January first (00:00) until January 7 included (midnight) and I would not see how you would want to modify it (but you do whatever you want :).
Now, really, you ought to give the system a starting date, otherwise it will not know from which day to start counting: this is handled by Aloha_log.weekinit This property is of the format of time(). You definitely want to choose a number that correspond to a date that is synchronized to 00:00, otherwise everything will be shifted as the number of seconds to cover a full week will be used. So, if you REALLY want to change that by hand, a cheap by cumbersome way to find the time you need is to use something like: ;ctime(number_here) where number_here is obtained from ;time() and modified according to your needs.
By default, Aloha_log.weekinit is set to 1041415200, which correspond to Wed Jan 1 00:00:00 2003 HST.
You could decide to use a file name for every month.
Same idea here as above, except that now Aloha_log_Jan2003.log will be used as a file name and so on.
Side note: Technically, there is nothing that prevents you to use both Static and dynamic methods (although using both might be overdoing it, especially if you already combine methods of logging through Aloha_log_.dwm).
Last thing: you really have to make sure that the directory EXISTS as the log script will not create it for you (I would rather leave that to you rather than letting the script creating directories on the system...).
Of course, the package FUP has to be installed. So, refer to the section concerning FUP. Once installed, $kahuna.modules should have a new entry: { "FUP", 
} (assuming that is the object number used for FUP on your system) if you executed the @test script accordingly.
IT is strongly suggested that while testing if the log works, you enable Direct logging, so that when checking if the FUP method is working, you will be able to see what kind of errors the system is running into IF it bumps into one... (The errors are listed in this document).