Zimbra-Logger includes tools for syslog aggregation, reporting, and message tracing. Installing the Logger package is optional, but if you do not install Logger, Server Statistics and Server Status information is not captured and message tracing is not available.
In environments with more than one Zimbra server, Logger is enabled on only one mailbox server. This server is designated as the monitor host. The Zimbra monitor host is responsible for checking the status of all the other Zimbra servers and presenting this information on the Zimbra administration console. The information updates every 10 minutes.
The Server Status page lists all servers and services, their status, and when the server status was last checked. The servers include the MTA, LDAP, and mailbox server. The services include MTA, LDAP, Mailbox, SNMP, Anti-Spam, Anti-Virus, Spell checker, and Logger.
To start a server if it is not running, use the zmcontrol CLI command. You can stop and start services from the administration console,
Servers>
Services tab.
The Server Statistics page shows bar graphs of the Message Count, Message Volume, Anti-Spam, and Anti-Virus activity. The information is displayed for the last 48 hours, and 30, 60, and 365 days.
|
•
|
Message Count displays the number of messages sent and received per hour and per day.
|
|
•
|
Message Volume displays the aggregate size in bytes of messages sent and receive per hour and per day.
|
|
•
|
Anti-Spam/Anti-Virus Activity displays the number of messages that were checked for spam or viruses and the number of messages that were tagged as spam or deemed to contain a virus.
|
|
•
|
Disk displays the disk usage and the disk space available for individual servers. The information is displayed for the last hour, day, month and year.
|
Each email message includes a header that shows the path of an email from its origin to destination. This information is used to trace a message’s route when there is a problem with the message.
The CLI utility, zmmsgtrace is run to find email messages by the follow:
The following message trace example was looking for messages sent from sender, jdoe to recipient address, aol.com any time within the last 30 days. The details show that two messages were sent, and it shows to whom the messages were sent.
$ zmmsgtrace -s jdoe -r aol.com Tracing messages from jdoe to aol.com Message ID 17357409.1128717619728.JavaMail.companya@example.com jdoe@example.com --> kumsh@aol.com Recipient kumsh@aol.com 2005-01-07 13:40:19 - example.com (10.10.000.20) --> 2005-01-07 13:40:20 - example --> 000.0.0.1 (100.0.0.0) status sent 2005-01-07 13:40:20 Passed by amavisd on example (CLEAN) HITS: -5.773 in 539 ms 2005-01-07 13:40:20 - localhost.localdomain (100.0.0.1) --> example 2005-01-07 13:40:20 - example --> mta02.example.com (0.00.000.00) status sent Message ID 3836172.14011130514432170.JavaMail.root@example.com jdoe@example.com --> harma@aol.com lt@hotmail.com Recipient harma@aol.com 2005-01-28 08:47:13 - localhost.localdomain (000.0.0.1) --> example 2005-01-28 08:47:13 - example --> mta02.example.com ( 0.70.000.09) status sent 2 messages found
|
When the Logger package is installed, a daily mail report is automatically scheduled in the crontab. The Zimbra daily mail report includes the following information:
If you are having problems with mail delivery, you can view the mail queues from the administration console, Monitoring Mail Queues page to see if you can fix the mail delivery problem. When you open Mail Queues, the content of the Deferred, Incoming, Active, Hold, and Corrupt queues at that point in time can be viewed. You can view the number of messages and where they are coming from and going to. For description of these queues, see
"Zimbra MTA Message Queues” .
For each queue, the Summary pane shows a summary of messages by receiver domain, origin IP, sender domain, receiver address, sender address, and for the Deferred queue, by error type. You can select any of the summaries to see detailed envelope information by message in the Messages pane.
The Messages pane displays individual message envelope information for search filters selected from the Summary pane.
|
•
|
Hold to move all messages in the queue being viewed to the Hold queue. Messages stay in this queue until the administrator moves them.
|
|
•
|
Release to remove all message from the Hold queue. Messages are moved to the Deferred queue.
|
|
•
|
Requeue requeues all messages in the queue being viewed. Requeuing messages can be used to send messages that were deferred because of a configuration problem that has been fixed. Messages are re-evaluated and earlier penalties are forgotten.
|
|
•
|
Delete deletes all messages in the queue being viewed.
|
The Zimbra MTA, Postfix queue file IDs are reused. If you requeue or delete a message, note the message envelope information, not the queue ID. It is possible that when you refresh the mail queues, the queue ID could be used on a different message.
In addition to moving individual messages in a specific queue, you can flush the server. When you click the Flush button, delivery is immediately attempted for all messages in the Deferred, Incoming and Active queues.
You can view the mailbox quota for all accounts from the administration console in
Monitoring>Server Statistics>Mailbox Quota tab. The Mailbox Quota tab gives you an instant view of the following information for each account:
When an account quota is reached all mail messages are rejected. Users will need to delete mail off the server to get below their quota limit, or you can increase their quota.
The Zimbra Collaboration Suite logs its activities and errors to a combination of system logs through the syslog daemon as well as Zimbra specific logs on the local file system. The logs described below are the primary logs that are used for analysis and troubleshooting.
|
•
|
audit.log. This log contains authentication activity of users and administrators, as well as mail delivery, login failure, and Tomcat start/stop activities.
|
|
•
|
clamd.log. This log contains activity from the antivirus application clamd.
|
|
•
|
freshclam.log. This log contains log information related to the updating of the clamd virus definitions.
|
|
•
|
logger_myslow.log. This slow query log consists of all SQL statements that took more then long_query_time seconds to execute. Note: long_query_time is defined in /opt/zimbra/my.logger.cnf.
|
|
•
|
mailbox.log. This log is a Tomcat log4j server log containing the logs from the mailbox server. This includes the mailbox store, LMTP server, IMAP and POP servers, and Index server. (Note: prior to ZCS 4.5, this log was called /opt/zimbra/log/zimbra.log.)
|
|
•
|
myslow.log. This slow query log consists of all SQL statements from the mailbox server that took more then long_query_time seconds to execute. Note: long_query_time is defined in /opt/zimbra/my.cnf.
|
|
•
|
spamtrain.log. This log contains output from zmtrainsa during regularly scheduled executions from the cron.
|
|
•
|
sync.log. This log contains information about Zimbra mobile sync operations.
|
|
•
|
/var/log/zimbra.log. The Zimbra syslog details the activities of the ZCS MTA (Postfix, amavisd, antispam, antivirus), Logger, Authentication (cyrus-sasl), and Directory (OpenLDAP),
|
Syslog file is written by the operating system, and contains a subset of the messages written to the local logs. SNMP monitoring typically looks at the syslog file and generates traps for critical errors.
The Zimbra server uses log4j, a Java logging package as the log manager. By default, the Zimbra server has
log4j configured to log to the local file system. You can configure
log4j to direct output to another location. Go to the Log4j Website for information about using log4j.
The levels for Zimbra logging messages are shown below, along with which ones generate SNMP traps and where, by default, each message type is logged.
Zimbra includes an installer package with SNMP monitoring. This package should be run on every server (Zimbra, OpenLDAP, and Postfix) that is part of the Zimbra configuration.
The Zimbra error message generates SNMP traps when a service is stopped or is started. You can capture these messages using third-party SNMP monitoring software and direct selected messages to a pager or other alert system.
Beginning with 4.5.7, the MySQL database is automatically checked weekly to verify the health of the database. This check takes about an hour. If any errors are found, a report is sent to the administrator’s account. The report name that runs the MySQL check is zmbintegrityreport, and the crontab is automatically configured to run this report once a week.
Copyright © 2007 Zimbra Inc.