| Rotating logs more frequently than daily (on Unix only) |
| Categories: Audium Call Services 3.4.x and 3.5 |
| Article ID: | 30 |
| Last updated: | January 12, 2007 |
| User Opinions |
|
No users have voted.
|
|
Thank you for rating this answer.
|
SUMMARY
The desire is to have the Audium activity log split into multiple files based on a user-defined criteria rather than the default criteria of rotating on a daily basis. This article explains how this can be done without requiring any changes to the Audium system or major setup. Note that this article applies only to Unix operating systems (such as Linux or Solaris) and will not work on Windows.
SYMPTOMS
Under high load, an application's activity log file, with the logging level set to Complete, can become quite large (potentially in the gigabytes). This large file, while technically not a problem to create, may cause problems in it management. For example, compressing the file or moving the file offline can cause the CPU to spike, potentially aversely affecting calls running on the system. One option is to bring the logging level down, however this comes at the cost of recording less information that could be invaluable later for audit or tuning purposes.
RESOLUTION
The procedure is quite simple: rename the currently updated activity log file. It is important to rename the file rather than copy it. Copying the file would involve CPU overhead (the larger the file the larger the overhead). Renaming the file on Unix systems does not actually change the location of the file, just the public label, so the renaming process does not incur any overhead. When the log file is renamed, what will happen is that any process that would need to update the log will check to see if the file exists and since it does not, will recreate it with the same original name. All subsequent logging events will then log to the newly created file and the old file will no longer be updated. In this way, any process, whether it is manual or automatic, can rename the log files as often as required. Here are several examples of how this can be taken advantage of:
At any time, an administrator can manually run the Unix "mv" command on an activity log, naming it something like "activity_logYYYY-MM-DD-1.txt". They can then run this same command as often as desired, each time changing the name slightly.
A batch script that is repeatedly called by a crontab checks the size of all activity logs on the system and if greater than a user-defined amount, will rename them including the time in the new name (e.g. "activity-logYYYY-MM-DD-HH-MM-SS.txt"). Therefore, if the volume is low, the log would not be rotated arbitrarily.
A batch script is called by a crontab that activates on a regular basis (for example hourly) that will automatically rename all the log files in all applications by inserting the time in the new name (e.g. "activity-logYYYY-MM-DD-HH-MM-SS.txt"). Here are some notes concerning this process to remember:
- One would not have to worry about information on calls being split across log files rotated in this manner as long as the Audium logging cache is set to a large amount. When using a large cache, Call Services does not update a log for a call until the call ends or the logging cache is filled, so all information about a call would be contiguous in the log files. The only time there would be data about a single call split across logs would be if the log file were renamed exactly when Call Services was placing the contents of the cache to the log. Its not a problem in either case as the information from the log files can be combined later in a database or reporting system.
- Eventually, as the computer's free disk space is taken up by the log files, a process will have to occur to move the old log files off the system. Moving or copying files do incur CPU overhead, which could affect calls on the system. It is recommended to test this process under load to ensure that the added CPU overhead would not aversely affect the calls on the system. If the log rotation were performed frequently so that the log files would not become too large, these files could then be copied or archived faster without incurring too much overhead.
|
| Visitor Comments |
|
No visitor comments posted. Post a comment
|
| Related Questions |
|
No related questions were found.
|
| Attachments |
|
No attachments were found.
|
Search the Knowledgebase
Jump to ID
Browse by Category
Print this page
Post a comment