Reports and Logs

Introduction

KisoLabs provides full textual logs for CDN and Mail services. Logs for your services can be viewed and downloaded at the URL below:

https://www.kisolabs.com/account/reports/logs/services

Log files are generated starting at 4:00 AM UTC. Log generation takes a significant amount of time, and so logs for the previous day may not become available until late morning or early afternoon. In some circumstances it may take over 24 hours for your log data to be processed. If you are missing log data older than 48 hours, please let us know.

All dates and times within the logs are in UTC. (This page was loaded at 2024-04-24 17:18:09 UTC. Refresh the page to see the current UTC time).

Downloading Log Files

All downloadable log files are named in the following format:

kisolabs_[Service Type]_[Zone Name]_[Date].log.gz

Service Type - The type of service for which the log file was generated. This will be cdn_basic for our CDN Basic product, or mx for any of our mail products (e.g. Backup MX, Forwarder, or MX Front).

Zone Name - The name of your zone (domain) for which the log file was generated. (e.g. example.com).

Date - The UTC date for which the log file was generated in the format YYYYMMDD, where YYYY is the 4-digit year, MM is the two-digit month, and DD is the two-digit day. For example, 20120101 represents January 1, 2012 and 20121125 represents November 25, 2012.

Important: When log files are generated, they may be created with some data available for the current day, in addition to the full log for the previous day. You may see a log file for today's date, but it will only contain up to a few hours of data. It will be re-created with full data the following day.

Compression

Log files are compressed using gzip, and can be decompressed using gzip (or gunzip) which is included on most base Linux distributions. For Windows (and other operating systems), the gzip utility can be downloaded at www.gzip.org¹. Other popular archive software such as 7-Zip and WinRAR can also decompress gzip files.

Encoding

Log files are UTF-8 encoded text, with a single line feed (LF) character terminating each line.

Certain text editors, most notably Windows Notepad, do not display a new line when encountering a line feed (LF) without an accompanying carriage return (CR). To view or manipulate the logs properly, a more advanced text editor can be used, such as Notepad++¹.

¹ The third-party software referenced above is the intellectual property of its owner(s), and is not affiliated with KisoLabs. At the time of the release of this documentation, the software referenced is available at no cost (please see the licensing and/or terms of use accompanying the software for details).

CDN Basic

Log Format

Full text logs for your services are available here.

CDN Basic logs are formatted as space-delimited files with quotes enclosing any field that contains a space as content. The general format of the log is as follows:

Each of the fields is described below:

Field	Type	Description
Date	date	The UTC date and time of the request. The format is: yyyy-MM-dd HH:mm:ss yyyy is the 4-digit year. MM is the month (01-12) with leading zeroes. dd is the day of the month with leading zeroes. HH is the hour (00-23) with leading zeroes. mm is minutes ss is seconds
Host	string	The host that was requested. This corresponds to the entry in your Host Keys configuration. Your zone and the KisoLabs CDN zone are omitted from this value. For example, if a user requests an asset using the FQDN www.example.com.kisocdnb.net, the host field will contain www. If the root of your zone was requested, the host will be displayed as an at sign (@).
Host Key	string	The host key that was requested. This corresponds to the entry in your Host Keys configuration.
Host Key Requested?	boolean (integer)	This field indicates whether the asset was requested using the Host or Host Key listed in the previous two columns. 0 = Host name was used 1 = Host key was used
Cache Disposition	string	A two-letter code indicating how the request was handled by the CDN cache: CA (CAche) - The requested content was delivered from the CDN cache. OR (ORigin) - The requested content was not found in the CDN cache and was delivered as it was fetched from the origin server. ON (Origin file Not found) - The requested content was not found in the CDN cache and could not be obtained from the origin server. This indicates that the origin server did not provide the content requested, usually because it presented a 4XX or 5XX HTTP status code in response to the request made to it by the CDN. DL (DownLoading) - The requested content was already in the process of being downloaded from the origin server, and was delivered from the CDN cache as content became available from the origin download. OP (Origin Parital) - The requested content had already been partially downloaded from the origin server, but the original download had been interrupted. Part of the content was delivered from the CDN cache, and the remainder was delivered as it was fetched from the origin server. In cases where the origin server does not support byte ranges or the CDN determines that using a byte range would be inappropriate, the content will be downloaded from the origin server in full. Requests that did not result in any content being delivered begin with an "N" as follows: NC (No Configuration) - The configuration for the zone was not found. This usually occurs if an invalid host or host key was specified, or if traffic is directed to the CDN before a new service or changes to an existing service can propagate to all CDN servers. NT (No Timeout / No access level) - The configuration for the zone was found, but it was incomplete and did not include a valid cache timeout and/or access level. This usually occurs if traffic is directed to the CDN before a new service or changes to an existing service can propagate to all CDN servers. NF (No Favicon.ico permitted) - The file favicon.ico is not supported by the CDN. NM (Not a valid Mime type) - The extension of the file requested indicates that it is not a valid MIME type. See Supported MIME Types in the CDN Basic documentation for more information. NE (Not a valid Extension) - The CDN does not support files with the following extensions: .exe, .com, and .bat. NU (Not a valid URI) - No file extension found or request URI is empty. The CDN does not support default documents. ND (No Default documents) - No file extension found. The CDN does not support default documents. If there is no cache disposition for a request, the field will be deliniated with a single dash (-). This is usually the case when the request made by the client is invalid and did not match any of the conditions descibed above.
Client IP	IP (string)	The IP address of the client making the request.
Request Method	string	The HTTP method used to make the request (e.g. GET)
Requested Asset	string	The relative URL of the asset requested. For example, if the client requested http://s3qs2m92.kisocdnb.net/example.html, this field would contain /example.html
Status Code	integer	The HTTP status code generated by the CDN server in response to the request. Common status codes and their causes are: 200 = Asset found and passed to client. 403 = There was an error fetching the CDN configuration. 404 = Asset was not found on your server and could not be delivered.
Content Length	integer	The length of the content returned in bytes.
Referer	string	The URL of the resource that caused the asset to be requested. Usually this will be the web page that references the asset being requested.
User Agent	string	The user agent string that the client's browser passed to the CDN server.

Sample Log

For the sake of example, four log lines are shown below for the imaginary website located at http://www.example.com.

The meanings of each of the sample lines are discussed below:

Line 1

A request was made on March 15, 2012 at 11:01:18 PM UTC for the asset at the URL http://www.example.com.kisocdnb.net/pics/products/DSCN00049.jpg. The server responded with the status code 200 (success) and delivered 285,474 bytes of data from the CDN cache. The request was referred by http://www.example.com/products/super_widget.html, and the client made the request using Internet Explorer 9 running on Windows 7.

Line 2

A request was made on March 15, 2012 at 11:01:20 PM UTC for the asset at the URL http://pp778zr6.kisocdnb.net/pics/products/DSCN00667.jpg. The server responded with the status code 200 (success) and delivered 108,822 bytes of data from the origin via the CDN cache. The request was referred by http://www.example.com/products/amazing_wathcha.html, and the client made the request using FireFox 20 running on Windows 7.

Line 3

A request was made on March 15, 2012 at 11:01:23 PM UTC for the asset at the URL http://example.com.kisocdnb.net/graphics/home/logo_head.png. The server responded with the status code 200 (success) and delivered 45,020 bytes of data from the CDN cache as the content was being downloaded from the origin. The request was referred by http://www.example.com/index.html, and the client made the request using FireFox 17 running on a Linux distribution.

Line 4

A request was made on March 15, 2012 at 11:01:24 PM UTC for the asset at the URL http://www.example.com.kisocdnb.net/cgi-bin/incorrect_file.html. The server responded with the status code 404 (file not found) and delivered no data. The request had no referrer, and the client made the request using Google Chrome 26 running on Windows XP.

Mail Services

Log Format

Full text logs for your services are available here.

Mail logs are formatted as space-delimited files with quotes enclosing any field that contains a space as content. The general format of the log is as follows:

Each of the fields is described below:

Field	Type	Description
Date Queued	date	The UTC date and time that the message was queued. The format is: yyyy-MM-dd HH:mm:ss yyyy is the 4-digit year. MM is the month (01-12) with leading zeroes. dd is the day of the month with leading zeroes. HH is the hour (00-23) with leading zeroes. mm is minutes ss is seconds
Date Last Processed	date	The UTC date and time that the message was last processed. If delivery could not be made this date/time will be updated at every following delivery attempt. The format is: yyyy-MM-dd HH:mm:ss yyyy is the 4-digit year. MM is the month (01-12) with leading zeroes. dd is the day of the month with leading zeroes. HH is the hour (00-23) with leading zeroes. mm is minutes ss is seconds
Queue Id	hexadecimal (string)	The queue id assigned by the KisoLabs mail server. This value does not have any real meaning for the purposes of log analysis, but can be useful when working with KisoLabs' support team to resolve email delivery issues.
Message Size	integer	The size of the message in bytes.
Client IP	IP address (string)	The IP address of the SMTP client that relayed the message to the KisoLabs mail server.
Client Host	string	The host name of the SMTP client that relayed the message to the KisoLabs mail server. This is the host name reported by the client with the HELO (or EHLO) command, and does not necessarily represent the DNS entry that resolves to the Client IP field.
Message Id	string	The message identifier (this is usually generated by the first SMTP server to relay the message). The message identifier should be globally unique, and therefore may assist you in debugging mail delivery issues. The KisoLabs mail servers will not alter the message identifier, but in rare cases it may be modified in transit by an upstream or downstream server.
From Address	string	The email address of the sender of the message.
To Address	string	The email address to which the message will be delivered. For services that forward messages, such as Forwarder and Instance Mail, this field contains the ultimate destination address (in other words, the address to which the message was forwarded).
Original To Address	string	The email address to which the message was sent, if different than the To Address field. For services that forward messages, such as Forwarder and Instance Mail, this field contains the alias address defined in your service's configuration. For all other types of service, this field will contain a single dash (-) to indicate that it is unused.
Status Text	string	The textual description of the status code representing the delivery status of the message. This field may not be populated until the message is delivered to, rejected by, or a timeout is reached for the destination mail exchanger. If the field is unpopulated it will be represented by a single dash (-).
Status Code	integer	The status code representing the delivery status of the message. This field may not be populated until the message is delivered to, rejected by, or a timeout is reached for the destination mail exchanger. If the field is unpopulated it will be represented by a zero (0).
Spam (Virus) Status	string	The status reported by the spam and virus filter. If spam and virus filtering are disabled on your service, or if spam and virus filtering were not completed for a message, this field will not be populated. If the field is unpopulated it will be represented by a single dash (-).
Spam Hits	decimal	A number representing the strength of the assertion by the spam filter that the message is spam. The number is qualitative, so the general rule is that a higher number will indicate that the message is more likely to be spam.
Last Delivery IP	IP address (string)	The IP address of the host to which the message was last delivered. This will be the address of the next-hop SMTP server when delivery is successful. Important: If the address shown is 127.0.0.1 that indicates that it was not delivered externally, and was re-queued by the KisoLabs SMTP server. This is not an error condition, and will always occur when a message is blocked as spam, or blocked because it contains a virus. It may also occur when a message could not be delivered and is awaiting redelivery, however in that case this field may also contain a dash (-).

Mail Logs are Transactional

It is important to remember that the mail logs represent the transactional nature of the SMTP message workflow.

In other words, when a message is received by the KisoLabs MX servers, the receipt of that message is logged. The message is then (if your service is so configured) scanned by our spam and/or virus filters, which is also logged. When delivery is attempted, that attempt is logged (and may be logged multiple times). When delivery succeeds, that is logged as well.

The logs for your MX service are generated by aggregating all of those log messages into one line. As such, a log line (or log file) may be updated retroactively when a new event occurs. For example, the following may take place:

• 2012-03-15 23:11:42 - Your KisoLabs Backup MX service receives an email.
• 2012-03-15 23:11:42 - The KisoLabs MX server attempts to deliver that email to your SMTP server, but your SMTP server is down.
• 2012-03-15 23:21:42 through 2012-03-16 03:21:42 - The KisoLabs MX server re-attempts delivery numerous times.
• 2012-03-16 03:31:42 - Your SMTP server is up and running, and the email is delivered.

In that example, a log line will be written into your service's log file for 2012-03-15 showing that the email was received by KisoLabs' server, but will not show delivery having been made. Approximately 24 hours later, your services log file for 2012-03-16 will be generated, but that log file will contain no information about the email in the example. Instead, the log file for 2012-03-15 will have been retroactively updated to include the final delivery status.

For most KisoLabs MX services, email messages can be queued for up to 30 days. Therefore it is possible that a log file that is 30 days old may be updated with the status of a message.

In some cases, an ill-formatted email message will not be locatable across transactional steps. This is particularly common when the message is spam and does not contain a message id (or the message id is not unique, or is too short to be globally unique). In that case, the message may cause more than one line to appear in your service's logs.

Sample Log

For the sake of example, five log lines are shown below for the imaginary recipient domain example.com.

The meanings of each of the sample lines are discussed below:

Line 1

A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 10:56:28 PM UTC from bob@sample.com to matt@example.com. The message size was 1,292 bytes, and was relayed from 10.203.80.101 (having the host name of mx01.sample.com). It was relayed to 172.16.54.92 with status code 250 ("sent") on March 15, 2012 at 10:56:30 PM UTC. It passed spam filtering, and was not considered to be spam ("Passed" 0.2781).

Line 2

A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 10:58:14 PM UTC from fred@flintstones.org to barney@example.com. The message size was 2,173 bytes, and was relayed from 192.168.78.22 (with an unknown host name). It was relayed to 10.88.22.11 with status code 250 ("sent") on March 15, 2012 at 10:58:15 PM UTC. It passed spam filtering, but was considered to have some characteristics of a spam message ("Passed SPAMMY" 10.2032).

Line 3

A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 11:01:45 PM UTC from homer@evergreent.com to sales@example.com. The message size was 2,159 bytes, and was relayed from 172.16.250.33 (having the host name of mail.simpsons.net). It was relayed to 10.3.1.87 with status code 250 ("sent") on March 20, 2012 at 9:32:18 AM UTC. It passed spam filtering, but was considered to have some characteristics of a spam message ("Passed SPAMMY" 18.3999).

This line shows a case where a message could not be delivered to the next mail exchanger for almost 5 days (the difference between the Last Processed and Queued dates). This would usually represent an issue with your mail server where it was inaccessible when the KisoLabs mail exchanger attempted delivery.

Line 4

A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 11:02:25 PM UTC from wentworth@uwnto.de to gesundheit@example.com. The message size was 2,181 bytes, and was relayed from 10.58.244.148 (with an unknown host name). The next mail exchanger (e.g. your mail server) responded on March 15, 2012 at 11:02:25 PM UTC with the status code 550 ("rejected"), most likely because the recipient ("gesundheit@example.com") did not exist. It passed spam filtering, and was not considered to be spam ("Passed" 1.4420). Note that the last delivery IP address is shown as 127.0.0.1 because the message was not relayed.

Line 5

A message was receieved by the KisoLabs mail exchanger and queued on March 15, 2012 at 11:03:01 PM UTC from lannister@westeros.net to tyrion@example.com. The message size was 5,129 bytes, and was relayed from 10.105.99.152 (having the host name of www.somesite.org). The message has just entered the system, and so there is no delivery status nor spam status.