This article applies to:
- Trustwave MailMarshal (SEG)
- Server monitoring
Question:
- What are the items to include when monitoring MailMarshal (SEG) processing servers?
Information:
Health monitoring for SEG processing servers can be achieved using a third party product. Monitoring products typically provide features such as:
- an overview console
- configurable alert parameters from a variety of inputs
- alert notification by multiple methods such as email and SMS messages
- acknowledgement of alerts
One well-known monitoring product is Zabbix.
Trustwave suggests you include the following items when monitoring the status of SEG processing servers:
- SMTP connectivity: external service can connect to the SEG server and deliver a test message.
- Response time can also be checked
- DNS connectivity: DNS lookup from the SEG server is responsive.
- Note that the DNS server configured in SEG might not be the same one configured in Windows. Be sure to monitor the DNS used by SEG.
- Services running:
- The Controller, Engine, Receiver, and Sender must always be running.
- In some cases, committing a configuration change can automatically restart the processing services.
- Performance monitor counters: The following counters provided by SEG are the most basic.
- Receiver connections Total/Sec
- Engine Time Behind
- Engine messages total/sec
- Directory based queue lengths:
- Monitor the number of items (email messages/MML files) in the SEG queue folders: Incoming, ProcessedOK, and Sending.
- Use Powershell or WMI scripting to check the item counts
- The Sending queue rarely reaches zero due to retries and undeliverable items.
- Also monitor the Archiving queue if Trustwave Email Archiving is enabled
- Route checks (optional, advanced):
- The SEG REST API can be used to query the number of messages queued for delivery to specific routes or domains.
Notes:
For counters and queue lengths, sustained values above the average (or zero messages processed) should trigger an alert. Performance varies depending on hardware and the traffic profile of each installation.
Corrective actions
Ensure that services are set to auto-restart on failure.
Incoming queue too high
- Check the engine is running/not stalled – restart if required
- Check the engine is not at the limit of processing (CPU or Disk bottlenecks, memory swapping)
- Scale-up or scale-out to increase capacity
ProcessedOK too high
- Check the sender service is not stalled
- Check the sender service queue length is not at the maximum allowed level (50,000)
- Check and adjust thread settings for static route and DNS delivery
Sending queue too high
- Check errors in log files
- Check outbound SMTP connectivity
- Check DNS resolution
- For delays to inbound mail, check settings or issues at the internal server SEG delivers to