Server Logs

Use the WebAdmin Interface to examine the Server Logs. Open the Logs section in the Monitor realm. The Server page opens, it lists the stored Server Log files. The current Log is marked with the asterisk (*) symbol.

You should have the Can Monitor Server Access Right to view the Server Logs.

The options on the top of the page allow you to specify when the Server Logs files are created and deleted:

When the Log appears in your browser window, all Log records are displayed. Since Logs can have thousands of records, you may want to view only a portion of the Log. Interrupt the Log downloading process and specify the Log Level and the Time Interval options:

Only the records with time stamps in the specified interval are displayed.

If you are viewing the current Log and specify "*" in the second field, all records placed in the Log by this moment are displayed.

If you are viewing the current Log and specify some future time in the second field, the Server will keep the browser channel open, sending new Log records as they are placed in the Log. The channel is closed either at the end of the specified Time Interval, or when the Server starts a new Log.

The CommuniGate Pro Logs can be very big, reaching several hundred megabytes of data on a heavily loaded Server or on a Server with low-level logging enabled.
It is difficult to examine an entire Log of that size.

Level

Use this setting to suppress displaying records that are more detailed than the specified value (have a higher level marker).

Filter

Use this option to specify the Filter string. Only the records containing this string will be displayed.
The first part of log records (including a time stamp and a level marker) is not used for filtering operations.

RegEx

If this option is selected, the Filter string is interpreted as a regular expression.

Click the Display button to display only the records that contain the specified substring.

Example:

Some of your users complain that sometimes their mailer application cannot retrieve messages from your server properly and that they see error messages informing them about some protocol errors.

Since it does not occur often, you should run the IMAP module with its Log Level set to All-Info, though this will make your Logs very big. Finally, a user contacts you and says that the mailer has just displayed the same error.

You open the Log and set the Level to 3 (Problems). Now you may see all the problems with the IMAP module that occurred today. When you find the record that indicates the problem your user is talking about, you see that that record has the IMAP-437425 tag. So, you type IMAP-437425 into the Filter field, and change the Log Level to 5 (All Info). As a result, you see a clean log of that particular IMAP session.

00:06:23.261 4 IMAP-437425([64.173.55.175]) got connection on [64.173.55.169:143](mail.communigatepro.ru) fr
00:06:23.261 5 IMAP-437425([64.173.55.175]) out: * OK CommuniGate Pro IMAP Server 5.1.8 at mail.commun
00:06:23.261 5 IMAP-437425([64.173.55.175]) inp: 1 CAPABILITY
00:06:23.261 5 IMAP-437425([64.173.55.175]) out: * CAPABILITY IMAP4 IMAP4REV1 ACL NAMESPACE UIDPLUS ID
00:06:23.266 5 IMAP-437425([64.173.55.175]) inp: 2 AUTHENTICATE METHOD AAAAAAAAAAAAAAAAAAAAAA=
00:06:23.268 2 IMAP-437425([64.173.55.175]) 'user@domain.com' connected from [64.173.55.175:31358]
00:06:23.268 5 IMAP-437425([64.173.55.175]) out: 2 OK completed\r\n
00:06:23.269 5 IMAP-437425([64.173.55.175]) inp: 3 LIST "" "*"
00:06:23.269 5 IMAP-437425([64.173.55.175]) out: * LIST (\UnMarked) "/" Calendar\r\n* LIST (\Marked) "
00:06:23.279 5 IMAP-437425([64.173.55.175]) inp: 4 SELECT "Tasks"
00:06:23.270 5 IMAP-437425([64.173.55.175]) out: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $MD
00:06:23.272 5 IMAP-437425([64.173.55.175]) inp: 5 UID SEARCH NOT DELETED
00:06:23.272 5 IMAP-437425([64.173.55.175]) out: * SEARCH 32 49 76 84 94 96 98 100 101 102 113 116 117
00:06:23.275 5 IMAP-437425([64.173.55.175]) inp: 6 UID FETCH 193 (BODYSTRUCTURE FLAGS)
00:06:23.275 5 IMAP-437425([64.173.55.175]) out: * 35 FETCH (BODYSTRUCTURE (("text" "calendar" ("chars
00:06:23.278 5 IMAP-437425([64.173.55.175]) inp: 7 UID FETCH 193 (BODY.PEEK[HEADER])
00:06:23.278 5 IMAP-437425([64.173.55.175]) out: * 35 FETCH (BODY[HEADER] {722}\r\ncontent-class: urn:
00:06:23.280 5 IMAP-437425([64.173.55.175]) inp: 8 UID FETCH 193 (BODY.PEEK[1])
00:06:23.280 5 IMAP-437425([64.173.55.175]) out: * 35 FETCH (BODY[1] {539}\r\nBEGIN:VCALENDAR\r\nMETHO
00:06:23.281 5 IMAP-437425([64.173.55.175]) inp: 9 UID FETCH 191 (BODYSTRUCTURE FLAGS)
00:06:23.281 5 IMAP-437425([64.173.55.175]) out: * 34 FETCH (BODYSTRUCTURE (("text" "calendar" ("chars

The Keyed option instructs the Server to scan the Log twice. First, it scans the Log (within the specified Time Interval) and finds all records matching the filter string. These strings are not displayed, but their Prefix Keys are remembered. The Prefix Key is the first part of the record (not including the time stamp and the level marker) till the first space symbol. Up to 100 different Prefix Keys are remembered.

Then the Log is scanned again (within the specified Time Interval), and the Server displays all records that have Prefix Keys matching one of the remembered Prefix Keys.

Some protocols (such as SIP) do not use connections. A SIP session ("dialog") consists of several packets (each packet is recorded with its own SIPDATA-NNNNNN Prefix Key), but all packets contain the same Call-ID line. Use the

: Call-ID:caller-id

filter string with the Keyed option to display all SIP session packets:

00:54:10.312 2 SIPDATA-000502 out: req udp [10.0.0.1]:5060 REGISTER(680 bytes) sip:node6.communigatepro.ru
00:54:10.312 5 SIPDATA-000502 out: REGISTER sip:node6.communigatepro.ru SIP/2.0
00:54:10.312 5 SIPDATA-000502 out: Via: SIP/2.0/UDP 64.173.55.170:5060;branch=z9hG4bK234
00:54:10.312 5 SIPDATA-000502 out: Max-Forwards: 69
00:54:10.312 5 SIPDATA-000502 out: From: <sip:usrname@node6.communigatepro.ru>
00:54:10.312 5 SIPDATA-000502 out: Call-ID: 72D532E1CEB813B537E4E44058354C68-2494453@node9.communigatepro.ru
00:54:10.312 5 SIPDATA-000502 out: Contact: <sip:299@node9.communigatepro.ru;services=no>;expires=90
00:54:10.312 5 SIPDATA-000502 out: CSeq: 114249520 REGISTER
00:54:10.312 5 SIPDATA-000502 out: User-Agent: CommuniGatePro-gateway/5.1.4
00:54:10.312 5 SIPDATA-000502 out: Authorization: Digest realm="ns.communigatepro.ru",username="usrname",non
00:54:10.312 5 SIPDATA-000502 out: Expires: 90
00:54:10.312 5 SIPDATA-000502 out: Content-Length: 0
00:54:10.312 5 SIPDATA-000502 out: 
00:54:10.328 2 SIPDATA-000503 inp: rsp udp [64.173.55.167]:5060 200-REGISTER(566 bytes)
00:54:10.328 5 SIPDATA-000503 inp: SIP/2.0 200 OK
00:54:10.328 5 SIPDATA-000503 inp: Via: SIP/2.0/UDP 64.173.55.170:5060;branch=z9hG4bK234
00:54:10.328 5 SIPDATA-000503 inp: From: <sip:usrname@node6.communigatepro.ru>;tag=9B5A8DB531C3FD7A
00:54:10.328 5 SIPDATA-000503 inp: To: <sip:usrname@node6.communigatepro.ru>;tag=7FBB267A3903E5B0
00:54:10.328 5 SIPDATA-000503 inp: Call-ID: 72D532E1CEB813B537E4E44058354C68-2494453@node9.communigatepro.ru
00:54:10.328 5 SIPDATA-000503 inp: CSeq: 114249520 REGISTER
00:54:10.328 5 SIPDATA-000503 inp: Expires: 90
00:54:10.328 5 SIPDATA-000503 inp: Contact: <sip:299@node9.communigatepro.ru;services=no>;expires=90
00:54:10.328 5 SIPDATA-000503 inp: Event: registration
00:54:10.328 5 SIPDATA-000503 inp: Date: Mon, 16 Mar 2015 08:53:04 GMT
00:54:10.328 5 SIPDATA-000503 inp: Allow: PUBLISH,SUBSCRIBE
00:54:10.328 5 SIPDATA-000503 inp: Allow-Events: presence,message-summary,reg,keep-alive
00:54:10.328 5 SIPDATA-000503 inp: Supported: path
00:54:10.328 5 SIPDATA-000503 inp: Server: CommuniGatePro/5.1.4
00:54:10.328 5 SIPDATA-000503 inp: Content-Length: 0
00:54:10.328 5 SIPDATA-000503 inp: 
00:54:10.328 2 SIPDATA-000503 sent to SIPC-000234
00:55:25.328 2 SIPDATA-000507 out: req udp [10.0.0.1]:5060 REGISTER(680 bytes) sip:node6.communigatepro.ru
00:55:25.328 5 SIPDATA-000507 out: REGISTER sip:node6.communigatepro.ru SIP/2.0
00:55:25.328 5 SIPDATA-000507 out: Via: SIP/2.0/UDP 64.173.55.170:5060;branch=z9hG4bK236
00:55:25.328 5 SIPDATA-000507 out: Max-Forwards: 69
00:55:25.328 5 SIPDATA-000507 out: From: <sip:usrname@node6.communigatepro.ru>;tag=35270A39FB68F573
00:55:25.328 5 SIPDATA-000507 out: To: <sip:usrname@node6.communigatepro.ru>
00:55:25.328 5 SIPDATA-000507 out: Call-ID: 72D532E1CEB813B537E4E44058354C68-2494453@node9.communigatepro.ru
00:55:25.328 5 SIPDATA-000507 out: Contact: <sip:299@node9.communigatepro.ru;services=no>;expires=90
00:55:25.328 5 SIPDATA-000507 out: CSeq: 114249521 REGISTER
00:55:25.328 5 SIPDATA-000507 out: User-Agent: CommuniGatePro-gateway/5.1.4
00:55:25.328 5 SIPDATA-000507 out: Authorization: Digest realm="ns.communigatepro.ru",username="usrname",non
00:55:25.328 5 SIPDATA-000507 out: Expires: 90
00:55:25.328 5 SIPDATA-000507 out: Content-Length: 0
00:55:25.328 5 SIPDATA-000507 out: 
00:55:25.343 2 SIPDATA-000508 inp: rsp udp [64.173.55.167]:5060 200-REGISTER(566 bytes)
00:55:25.343 5 SIPDATA-000508 inp: SIP/2.0 200 OK
00:55:25.343 5 SIPDATA-000508 inp: Via: SIP/2.0/UDP 64.173.55.170:5060;branch=z9hG4bK236
00:55:25.343 5 SIPDATA-000508 inp: From: <sip:usrname@node6.communigatepro.ru>;tag=35270A39FB68F573
00:55:25.343 5 SIPDATA-000508 inp: To: <sip:usrname@node6.communigatepro.ru>;tag=7EF99B799DFD7632
00:55:25.343 5 SIPDATA-000508 inp: Call-ID: 72D532E1CEB813B537E4E44058354C68-2494453@node9.communigatepro.ru
00:55:25.343 5 SIPDATA-000508 inp: CSeq: 114249521 REGISTER
00:55:25.343 5 SIPDATA-000508 inp: Expires: 90
00:55:25.343 5 SIPDATA-000508 inp: Contact: <sip:299@node9.communigatepro.ru;services=no>;expires=90
00:55:25.343 5 SIPDATA-000508 inp: Event: registration
00:55:25.343 5 SIPDATA-000508 inp: Date: Mon, 16 Mar 2015 08:54:19 GMT
00:55:25.343 5 SIPDATA-000508 inp: Allow: PUBLISH,SUBSCRIBE
00:55:25.343 5 SIPDATA-000508 inp: Allow-Events: presence,message-summary,reg,keep-alive
00:55:25.343 5 SIPDATA-000508 inp: Supported: path
00:55:25.343 5 SIPDATA-000508 inp: Server: CommuniGatePro/5.1.4
00:55:25.343 5 SIPDATA-000508 inp: Content-Length: 0
00:55:25.343 5 SIPDATA-000508 inp: 
00:55:25.343 2 SIPDATA-000508 sent to SIPC-000236

Use your browser Find command to search for a string in the filtered portion of the CommuniGate Pro Log.

Use the Print command of your Web browser to print the filtered Log.

Each Log record has a time stamp indicating when the record was created. The time is displayed using the local time ("GMT shift") of the CommuniGate Pro Server used when the Log file was created.

If the Server OS uses the time zone with daylight saving time, the time stamps used in the Log will not change when the local time ("GMT shift") changes. The new local time will be used when the new Log file is created.

The CommuniGate Pro Log Manager is designed as high-speed engine capable of processing thousands records per second, without delaying the execution of the Server component that generated the Log records. When some component generates a huge amount of records, (most likely, due to the Log Level set for that component), even the Log Manager may be unable to store all those records in the Log file.

If a new record cannot be placed into the Log due to a Log Manager performance problem, the Log Manager stores a short Overflow Marker instead. The Overflow Marker is a line with three asterisk (***) symbols.

If you filter the Log, the displayed part of the Log will always contain the OverFlow Markers if they exist in the selected part of the Log. If several sequential Overflow Markers have to be displayed, only the first one is displayed.

Administrators can specify their individual Log Viewer Preferences.

Use the Preferences link to open the Monitor Preferences.

Open showing last

When you open the currently active Log file, this setting specifies the inital starting time of the Time Interval (see below), so you see only the recent Log records.
When you open an inactive Log file, the Time Interval is not initialized, and the Log is displayed from the beginning.

You may want to send CommuniGate Pro Log records to an external syslog server.
Usually these servers are not providing the CommuniGate Pro Log Manager performance, so you should send only a small part of the Log records to those servers.

Use the following settings to configure remote logging:

Records to send

Specify the level of Log Records to be sent to a remote syslog server. Records that are more detailed than the specified value (have a higher level marker) are not sent.

Server address

Specify the IP address of the remote syslog server. If you do not specify the port number, the standard port number 514 is used.

Facility Code

The remote syslog server can store log records in different locations based on this code value.

Source IP Address

Specify the local IP address and/or the port to send messages to the syslog server. If an address or a port is not specified explicitly, the server OS will assign them.

If the Log Manager fails to open a UDP socket or fails to send a datagram to the selected remote syslog server, the Log Manager suspends sending records to the remote syslog server till the end of the current second.

You may want to use a Trigger Handler to send notifications when a Crash-level record is added to the CommuniGate Pro Log.

Open the Statistics Elements page in the WebAdmin Interface, and specify a Trigger Handler for the logLastCrashRecord element. When a Crash-Level (0-Level) record is added to the Log, the selected Trigger Handler is invoked.

Note: the Trigger Handler is started once in 5-10 seconds. If more than one Crash-Level records were written to the CommuniGate Pro Log during this time period, the notification message contains only the last Crash-Level record.

Supplementary Logs are designed to store the most important events of a certain type only.

Supplementary Log records are stored as text file lines: one record is stored on one line. Each record/line starts with a timestamp prefix:
hh:mm:ss.ddd
where hh is the hour, mm is the minute, ss is the second, and ddd is the millisecond of the moment when the record was generated.

New supplementary Log Files are created daily.

Use the WebAdmin Interface to examine supplementary Logs. Open the Logs section in the Monitor realm. Click to select the supplementary Logs type. A page opens, it lists the stored supplementary Log files. The current Log is marked with the asterisk (*) symbol.

You should have the Can Monitor Server Access Right to view the supplementary Logs.

The supplementary Log files are created inside subdirectories of the SystemLogs subdirectory.

Setting Updates

These Log files contain a record for each Server module or component setting update.

The following record format is used:
component userName newSettings
Where:

component

the updated component name

userName

the name of the Administrator Account used to update the Settings.

newSettings

the updated settings object value (usually - a dictionary).

Call Detail Records (CDRs)

These Log files contain Call Detail Records in various formats. See the Real-Time Signals section for more details.

EMails

01

record format version

state

the message delivery result: RELAY (relayed), FINAL (delivered to the final destination), ERROR (a fatal error, resending will not help), TMPER (a temporary error condition, can be resent later).

returnPath

message envelope return-path

fromAddress

the message From: address

authAddress

if the message sender was authenticated, the authenticated Account name. Otherwise, an empty string

submitAddress

the name of the component submitted the message, followed by the Network Address associated with the message source.

localIP

the Server Local Network Address used to submit the message

queueID

the message internal Queue UID (numeric)

messageID

the message Message-Id header field value

messageSize

the message size in bytes

origRecipient

the delivery target, as originally specified in the submitted message

module(queueName)recipient

the actual delivery target: the deliver module name, the name of the Module queue (remote domain for the SMTP Module, Account name for the Local Delivery Module, etc.), optionally followed with the specific address (remote recipient for the SMTP Module, supplementary address for the Local Deliver module, etc.)

report

the report delivery string. As it can be a multi-line one, it is stored as the text presentation of the report String object

Login/Logout

Records are placed into these Log files when users log into their Accounts, and when they log out.

01

record format version

login, logout, verify, failure

operation. For session-based protocols (such as POP or XMPP), the login and logout records are created.
For session-less protocols (such as SIP), the verify records are created.
For authentication errors with existing accounts the failure records are created.

address, port

the IP address the user client has connected from

service

the name of the Service (protocol) associated with this operation.

method

the name of the Authentication Method used (for the login, verify and failure operations).

Statistics

These Log files contain values of all Statistics Elements. See the Statistics section for more details.