This material is copyright and is licensed for the sole use by Kliwon Klimis on 28th October 2008 425 cilce, , frood, grradt, 525254

Keeping an Eye on Zimbra

Working with Mail Queues

Email servers handle virtually thousands of email messages per day, and in most cases messages are sent and received to the proper users seamlessly. However, there are times when messages get bottlenecked or held up in a queue, and as administrators, it is important we keep an eye on that queue and handle "problem" messages, before they become an even bigger problem for our entire server.

The Mail Queue application is designed to give administrators visibility to messages coming in and delivering out of the server. Each message is scanned, for viruses and spam, and then delivered to the appropriate party. While a message is in the queue, administrators may view messages that are deferred (messages that have not been able to be sent for some reason and will eventually expire unless some action is taken), a message may be placed on hold (messages the system is unable to process), incoming (all messages come in to this queue before they are delivered to the appropriate user, and active (messages being prepared to be sent). Also, using the Mail Queue application, an administrator may "flush" the queue and attempt to deliver all messages in hold, deferred, and the active queues. This is usually done when a bottleneck is created from the server experiencing too many errors sending

out too many messages and therefore no messages are being sent out from the server.

Each queue displays the Receivers domain, origin IP of the sender, sender's domain, and receiver's address. When a message is in queue, it may be placed on hold, deleted, or re-queued for delivery at a later time. In the upper-right-hand corner of the Mail Queue application is the Flush button for flushing all the queues when and if it becomes necessary.

[ 200 ]

This material is copyright and is licensed for the sole use by Kliwon Klimis on 28th October 2008 425 cilce, , frood, grradt, 525254

Chapter 11

Monitoring Log Files

There are times when the information provided in the Administration Console GUI are just not enough to help troubleshoot an issue with the server, or to have a complete picture of the overall health and activity of the server. So besides using

the tools described earlier in this chapter, it is also very important that the systems administrator is aware of at least three log files that are key to monitoring your Zimbra implementation.

The first log file is the zimbra.log file, located at /var/log/zimbra.log on the Linux server. This log is used to record and display system messages from the Zimbra server. For example, when services are started or stopped. If we noticed a server

is stopped and we would like to find out if there are any messages in the log file regarding this to help explain why the server stopped, we could search the log file for all instances of the word stopped, by issuing the command:

cat /var/log/zimbra.log | grep Stopped

Or if you would just like to view system messages about a specific service you could issue a similar command and replace the keyword Stopped, with the name of the service.

cat /var/log/zimbra.log | grep logger

The second log file is the audit.log file located at /opt/log/zimbra/audit.log. This file is used to look at security authentication and is useful in viewing which users are successfully, and unsuccessfully, logging in to the Zimbra server.

Finally, for detailed information on mailbox activity, you will definitely want to use the mailbox.log file, located at /opt/zimbra/log/mailbox.log. This is a great file for troubleshooting mail delivery and receipt problems. This log records all activity for the mailboxes on the server, so that you could see if the mailbox is even attempting to send a message before you get lost in trying to find out why delivery was unsuccessful. So for example, let's say I want to see a list of all messages that were sent to a particular email address, I could use my favourite grep command and seach the entire mailbox.log for all instances of the address by typing in:

cat /opt/zimbra/log/mailbox.log | grep [e-mail]

There are many more log files that Zimbra, and the operating system offer, to help monitor and troubleshoot issues with you email system, however, the three

discussed previously (mailbox.log, audit.log, and zimbra.log) are probably the ones you will end up using most frequently. Also, due to the overwhelming size of the files and the amount of information contained in each file, it may be a good idea to look at a third-party log management solution to not only make it easier to view and search the logs, but also to write information to a database for further analysis.

[ 201 ]

This material is copyright and is licensed for the sole use by Kliwon Klimis on 28th October 2008 425 cilce, , frood, grradt, 525254

Keeping an Eye on Zimbra

Summary

The goal of this chapter was to remind system administrators that their jobs does not stop after implementation, configuration, and backing-up the system. It is critical that we, as effective systems administrators, remain proactive when it comes to the availability, scalability, and security of our servers.

Specifically, this chapter discussed: the need for monitoring, and a looked at a few built-in tools that Zimbra provides. We also talked about working with,

and monitoring, mail queues and viewing three key log files for additional troubleshooting information.

The messaging system of any organization is a critical piece of the infrastructure. Users rely on this system to maintain communication with vendors, customers, and fellow employees. E-mail has become a key component to every organization, and our responsibility to make sure that our system is effective and efficient is our number one priority.

[ 202 ]