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:
- Start New File
- A new file is created automatically every day (at midnight), or more
often, according to this setting value.
- if Larger than
- A new Log file is also created if the current Log file size exceeds the specified limit.
The Log files are created in the SystemLogs subdirectory of the Server base directory.
- Delete Old Files
- Shortly after a new Log file is created, the Server checks all files in the SystemLogs
subdirectory, and removes all files that are older than the time period specified with this setting.
- Time Precision
- This setting specifies how many digits should be used in log record time stamps to specify fractions of a second.
- External Logger
- Please see the Sending to Remote Servers section.
You should have the CanTuneLoggerSettings Monitor Access Right to modify the Logs Engine settings.
You can select one or several Logs in the list and then remove them using
the Delete Marked Logs button. The active (current) Log file cannot be deleted.
You should have the CanDeleteLogs Monitor Access Right to delete Logs.
If there are too many Log files on the Server, you can enter a string
in the Filter field and click the Display button: only the Logs with names
matching the Filter string will be displayed:
Click the Log file name to open it.
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.communigate.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.communigate.ru
00:54:10.312 5 SIPDATA-000502 out: REGISTER sip:node6.communigate.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.communigate.ru>
00:54:10.312 5 SIPDATA-000502 out: Call-ID: 72D532E1CEB813B537E4E44058354C68-2494453@node9.communigate.ru
00:54:10.312 5 SIPDATA-000502 out: Contact: <sip:299@node9.communigate.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.communigate.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.communigate.ru>;tag=9B5A8DB531C3FD7A
00:54:10.328 5 SIPDATA-000503 inp: To: <sip:usrname@node6.communigate.ru>;tag=7FBB267A3903E5B0
00:54:10.328 5 SIPDATA-000503 inp: Call-ID: 72D532E1CEB813B537E4E44058354C68-2494453@node9.communigate.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.communigate.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.communigate.ru
00:55:25.328 5 SIPDATA-000507 out: REGISTER sip:node6.communigate.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.communigate.ru>;tag=35270A39FB68F573
00:55:25.328 5 SIPDATA-000507 out: To: <sip:usrname@node6.communigate.ru>
00:55:25.328 5 SIPDATA-000507 out: Call-ID: 72D532E1CEB813B537E4E44058354C68-2494453@node9.communigate.ru
00:55:25.328 5 SIPDATA-000507 out: Contact: <sip:299@node9.communigate.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.communigate.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.communigate.ru>;tag=35270A39FB68F573
00:55:25.343 5 SIPDATA-000508 inp: To: <sip:usrname@node6.communigate.ru>;tag=7EF99B799DFD7632
00:55:25.343 5 SIPDATA-000508 inp: Call-ID: 72D532E1CEB813B537E4E44058354C68-2494453@node9.communigate.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.communigate.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.
The CommuniGate Pro Server maintains supplementary Logs in addition to the main Server Log described above.
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.
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).
These Log files contain Call Detail Records in various formats.
See the Real-Time Signals section for more details.
The E-mail Transfer Dequeuer component generates a record
for every E-mail delivery event. The following record format is used (the tabulation symbol is used as the field separator):
01 state returnPath fromAddress authAddress submitAddress localIP
queueID messageID messageSize
origRecipient module(queueName)recipient
report
Where:
- 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
Records are placed into these Log files when users log into their Accounts, and when they log out.
The following record formats are used (the tabulation symbol is used as the field separator):
01 login accountName [address]:port service method
01 logout accountName [address]:port service
01 verify accountName [address]:port service method
01 failure accountName [address]:port service method
Where:
- 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).
These Log files contain values of all Statistics Elements.
See the Statistics section for more details.
|