Reading the log file
After each report generation attempt, a log file, called output.log, is stored in the same folder as the report. This log file contains information about whether the generation of the report was successful, and an error message when something went wrong during report generation.
Let's look at some examples. A log file of a succesfully generated report can look like this:
[2024-03-08 05:59:24,316] INFO [INFO_0001] Report generation has started.
[2024-03-08 05:59:58,856] INFO [INFO_0004] Report generation done.
[2024-03-08 05:59:59,234] INFO [INFO_0002] Storing report.json for 01HRE8FA3JT12HXBEX7840CXAF at client storage started.
[2024-03-08 06:00:01,726] INFO [INFO_0003] Storing report.json for 01HRE8FA3JT12HXBEX7840CXAF at client storage ended successfully.
[2024-03-08 06:00:02,502] INFO [INFO_0002] Storing output.log for 01HRE8FA3JT12HXBEX7840CXAF at client storage started.
[2024-03-08 06:00:02,938] INFO [INFO_0003] Storing output.log for 01HRE8FA3JT12HXBEX7840CXAF at client storage ended successfully.
When generating a report fails, a log file could look like this:
[2024-02-08 13:19:47,635] INFO [INFO_0001] Report generation has started.
[2024-02-08 13:20:15,161] CRITICAL [SERVER_ERROR_0004] Missing contribution data for the following instruments and dates: {'AT0000641352': ['2023-12-01', '2023-12-04', '2023-12-05']}.
[2024-02-08 13:20:23,635] INFO [INFO_0002] Storing output.log for 01HP4DZE6VV7ZS4RW9B806QH97 at client storage started.
[2024-02-08 13:20:24,474] INFO [INFO_0003] Storing output.log for 01HP4DZE6VV7ZS4RW9B806QH97 at client storage ended successfully.
Structure of the log file¶
Each line of the log file follows the same structure:
[<timestamp>] <message type> [<ID>] <message>
containing a timestamp, message type, ID, and message. You can use the message type and ID to parse and build logic upon if desired.
| Field | Format | Explanation |
|---|---|---|
timestamp |
yyyy-mm-dd hh:mm:ss,sss |
Timestamp of the log message |
message type |
one of INFO, CRITICAL |
The type of the message. INFO for informational messages, CRITICAL when an error resulted in failure to generate the report. |
ID |
fixed string | Identification code for the subtype of the message. |
message |
free string | A log message. |
Info logs¶
Regardless of whether your report fails or generates, there will always be informational messages in your log file. See the table below for possible informational log message types.
| Trigger for log message | ID | Explanation |
|---|---|---|
| Start report generation | INFO_0001 |
Rerport generation has started. |
| Start storage trasfer | INFO_0002 |
Transfer of a file to client storage has started. |
| Succesful storage transfer | INFO_0003 |
Transfer of a file to client storage has ended succesfully. |
| Successful report generation | INFO_0004 |
Report generation has ended succesfully. |
Critical error logs¶
When a report fails to generate, a critical error message will be logged.
SERVER_ERROR versus CLIENT_ERROR
You will notice that ID codes of critical errors have either SERVER_ERROR or CLIENT_ERROR in the name. This is done to keep track for billing purposes. When a report fails to generate because of a bug in StoryTeller, the ID code of the error will start with SERVER_ERROR. When it's the client's responsibility, for example because a client uploads faulty custom data, the ID code will start with CLIENT_ERROR.
| Trigger for log message | ID | Explanation |
|---|---|---|
| General error | SERVER_ERROR_0001 |
Something went wrong because of an uncaught bug. |
| Financial data error | SERVER_ERROR_0002 |
Something went wrong while trying to fetch financial data. |
| Text database error | SERVER_ERROR_0003 |
Something went wrong while parsing the text database. |
| Missing contribution data | CLIENT_ERROR_0001 |
When StoryTeller does not calculate contribution data, but uses the contribution data of the client, and contribution data is missing for at least one holding on at least one day within the reporting period. Holdings and dates for which contribution data is missing are specified in error message. |
| Missing reference data | SERVER_ERROR_0002 or CLIENT_ERROR_0002 |
Reference data is missing for at least one holding. Holdings for which reference data is missing are specified in error message. |
| Missing price data | SERVER_ERROR_0002 or CLIENT_ERROR_0003 |
Price data is missing for at least one holding, on at least one date. Holdings for which reference data is missing are specified in error message. |
| Missing composition data | SERVER_ERROR_0002 or CLIENT_ERROR_0004 |
Composition data is missing for at least one holding for which it is required, on at least one date. Holdings and dates for which composition data is required and missing are specified in the error message. |
| Missing fund NAV data | SERVER_ERROR_0002 or CLIENT_ERROR_0005 |
Fund NAV data is missing for at least one holdings for which it is required, for at least one date. Holdings and dates for which NAV data is required and missing are specified in the error message. |
| Reporting period starts before fund's launch date | CLIENT_ERROR_0006 |
The start date of the reporting period is before the launch date of the fund, for a fund factsheet. |
| Incorrect NAV timeseries data | SERVER_ERROR_0002 or CLIENT_ERROR_0007 |
The NAV timeseries contains zero values. |