This section contains answers to common questions about the Logs and Queues.
When Iguana is restarted it will need time to scan the logs and rebuild the indexes. As a rough guide, assuming we have 365 days of logs at 1MB per day (365 MB total) it should only take a few minutes to rebuild the indexes on a basic PC with a single disk drive. On a machine with a fast disks (RAID, SAN etc) it will be much quicker. The manual page Log Age and Logging Performance indicates that the indexes (metafiles) for 20GB of data were rebuilt in 15 minutes on a test machine.
So why do you need to keep logs for so long? Probably for legal reasons, so you may not need to track everything in the logs. This FAQ suggests some archiving alternatives, For legal reasons we need to record 7 years of messages, how can I do this?
- Keep seven years of Iguana logs. Not recommended.
- Keep 60 days of logs and export and/or back them up regularly.
- Use the Translator to archive data to a database. Probably the best long term solution.
1. Keep seven years of Iguana logs
The Iguana logs are not designed for archiving. At the very least you need to copy or backup the logs also (see 2 below). Also keeping long term logs will slow down log index rebuilds, see I need to keep 365 days of logs, how will it affect Iguana? You can use Iguana to view and search the logs when you need to investigate.
2. Keep 60 days of Iguana logs and export and/or back them up regularly
Keeping a shorter period of logs and archiving them regularly makes much more sense.
Simply archive the logs by copying the <log directory>\log\<YYYMMDD>.log files to another location. When you need to do investigation you can use an Iguana server to view the archived logs. If you use backup software to “copy” the files you may need to restore the files before you can view them (we suggest restoring to an alternate location, rather than directly to the Iguana default log directory). An advantage of this approach is that it can easily be combined with your Iguana backup and restore routine.
3. Use the Translator to archive data to a database
The good news is that the code is going to be simpler than mapping your interfaces. Probably all you need to do is to save every message as a string in its original format. Because you are using the Translator you can customize the archive process to your own needs, filter messages, add timestamps/comments/etc, route messages from different channels to different databases and so on.
The technique is simple enough:
logDebug()statements in your code
- Enable Debug level logging to start debug logging
- Disable Debug level logging to stop debug logging
logDebug() function has very little overhead when debug logging is disabled, it is safe to use in production code. However it is advisable only to enable debug logging for short periods because of it writes a lot of extra data to the logs (which increases log size and reduces Iguana performance).
To track your SQL database performance, first set the logging level for your channel to Debug. When the logging level is set to Debug, the SQL statements that are sent to the database will show up as Debug entries in the Iguana log files.
Because each entry in the Iguana log files has a time stamp, you can determine the amount of time needed to execute an SQL statement. To do this, examine the time stamp for the statement and then examine the time stamp for the next SQL statement in the log. The difference between the two time stamps will give you an estimate of the time required for this particular SQL statement to execute.
Note: For information on using and viewing logs in Iguana, see the Logs section.
Locking Down Access
If you created the logs folder yourself, you may want to deny access to anyone but the owner (chmod 0700 path/to/logs). If you allowed Iguana to create this folder, this is already done for you. Use “ls -ld path/to/logs” to verify; you should see something like “drwx——” for the logs folder.
Granting Access to a Group
Typically in cases where you want to share files with other users, you collect those users into a group. To grant those users access to Iguana’s logs, you first change the group assigned to the logs folder (chgrp TheGroup path/to/logs), then you allow that group to enter but not modify the folder (chmod 0750 path/to/logs). You don’t have to change the group name attached to each .log file; once in the folder, any user can read the logs.
The above examples should work on most Linuxes; if they don’t work, your manual should be very helpful. E.g., “man 1 chmod” will tell you all about those magic numbers above, and give you alternatives like “chmod g+rx path/to/logs” for granting read/enter permission to the log folder’s group.
Another way to grant access to the log folder is with Access Control Lists, or ACLs. I never use them myself, but they are more flexible than the simpler, traditional Linux model describe above (ACLs are not universally supported).
You can prohibit Iguana or any Linux program from creating files with permissions you don’t like. The “umask” command (man 1 umask) can be told which permissions not to allow. Typically this is set to 022 (no write permission for group or other). E.g., if you change that to 026 before running Iguana, Iguana will also not create files that “other” users can read (users who don’t own the file, or who are not in the group assigned to the file). Use care with this as umask applies to every file Iguana creates, not just log files. See your Linux manual for details.