· 6 years ago · Oct 10, 2019, 03:20 PM
1# Application Logs
2
3This is a support document to provide information on the application logs implemented in Aviva-SRM application.
4
5##### Table of Content
6
7- [Logging Mechanism](#Logging-Mechanism)
8 - [Log levels](#Logging-Mechanism)
9 - [Log file location](#Log-file-location)
10 - [log Structure](#Log-file-Structure)
11- [Application logs Tiers](#Application-log-Tiers)
12 - [Internal (Application) Error logs](#Application-Error-logs)
13 - [Internal (Aviva) Logs](#Internal-Aviva-Requests)
14 - [External (Third-part) Logs](#Third-party-Requests)
15- [Log Rotation/Archiving](#Log-Rotation)
16- [Key Environment variables.](#Key-Environment-variables)
17
18### Logging Mechanism
19The application logs in SRM backend is of three levels logs:
20
21- Debug
22- Info
23- Error
24
25 #### Debug
26 Logs all inbound and out bound requests. to enable debug logs sent ``NODE_ENV`` value to ``DEBUG``.
27
28 #### INFO
29 These logs are used to log inbound, outbound and responses of API requests. These logs are logged on to the ``app-info***.log`` file.
30
31 ##### Error
32 These logs are used to log the various errors that occur on the system. These logs are logged on to the ``app***.log`` file.
33
34#### Log file location
35The application logs are stored in the <strong>log</strong> folder in the application root folder.
36```
37.
38+-- logs <--- folder where logs are stored
39+-- controller
40 +-- index.js
41 +-- auth.controller.js
42+-- lakkin.js
43+-- app.js
44+-- server.js
45```
46the file naming convention is:
47
48- error: ``app-SRM_%DATE%.log``
49- info: ``app-info-SRM_%DATE%.log``
50#### Log file Structure
51The template/structure the logs follow is as follows:
52
53- error : ``${timestamp} - ${level} - ${layer} - ${method} - ${message} - ${payload} - ${url}``
54- info : ``${timestamp} - ${level} - ${layer} - ${req_method} - ${req_url} - ${message} - ${payload}``
55
56the description of all the keys are:
57
58- timestamp - the time the log entry was made.(``2019-09-19T12:00:03.278Z``)
59- level - the type of log thats being printed.(``error|debug|warn|info``)
60- layer - layer defines where in the application flow did the log get triggered.
61- method - method is used to trace back the exact location of the log trigger point.
62- message - custom or error message text that needs to be logged.
63- payload - the request/response payload.
64- url - the url that was triggered to initiate the application flow.
65- req_url - the request/response URL.
66- req_method - the request/response method.(``GET|POST|PUT|DELETE``)
67
68
69### Application-log Tiers
70
71While logging errors or information in SRM-backend application, the logging is divided into different tiers based on the destination and sensitivity of the data.
72
73- ##### Application Error logs
74 Application error logs, are logs that are triggered on an event of failure or error response. These error logs are primarily internal with respect to the application. The logs help in identifying the point/s of failure to derive the root cause of a business logic failure. These logs are logged in the ``app-SRM_%DATE%.log``.
75
76 the content that is logged in these requests are usually the error response or the error code that was recieved while execution.
77- ##### Internal-Aviva Requests
78 Internal-Aviva requests are API calls that are made to Aviva services. The main API's called are:
79 1) login services.
80 2) policy services.
81 3) notification services.
82 4) user(AOL) services.
83
84 SSO request are also logged to track inbound requests.
85
86 In all the API-calls that are made we log the key attributes:
87 - url.
88 - method.
89 - success.(only message).
90 - failure.(message and response body.)
91
92 if the ``NODE_ENV`` is set to ``debug`` then the request/response body is logged into <i>info-logs</i>.
93
94- ##### Third-party Requests
95 We classify requests that are made outside of Aviva's environment as Third-party requests. The SRM application calls Nexmo service which are global services which are not hosted in aviva's network. while logging request for third party services we log the all the key attributes:
96 - URL.
97 - method.
98 - request and response body.
99 - headers.
100
101 There are transaction_id added to the logs to trace the request to the corresponding response.
102
103### Log Rotation
104Log Rotation, by definition is the mechanism of archiving the logs of an application by different frequencies of hours/days/weeks/.. . In the SRM's log archiving we handle both, error and application logs, with same frequency.
105
106In SRM log files are rotated based on the following:
107- ##### file size.
108 there's max size for a single log file, which is 20mb. When a log-file's size exceeds 20mb the file is rotated and zipped into a ``.gz`` file. a new file is created with tha same name with an incremented value.
109 ```
110 +-- logs
111 +-- app-SRM_22-09-2019.log.gz
112 +-- app-SRM_22-09-2019.log.1
113 ...
114 ...
115 ...
116 +-- app-info-SRM_22-09-2019.log
117 +-- controller
118 ```
119- ##### Daily.
120 when a particular day ends the files are archived. on the same trigger we move the files from the ``/logs`` to the ``/archived`` folder.
121 ```
122 +-- logs
123 +-- app-SRM_22-09-2019.log.gz
124 +-- app-SRM_23-09-2019.log
125 ...
126 ...
127 ...
128 +-- app-info-SRM_22-09-2019.log.gz
129 +-- app-info-SRM_23-09-2019.log
130 +-- controller
131 +-- archived
132 +-- app-SRM_21-09-2019.log.gz
133 +-- app-SRM_20-09-2019.log.gz
134 +-- app-info-SRM_21-09-2019.log.gz
135 +-- app-info-SRM_20-09-2019.log.gz
136 ```
137- ##### Week.
138 In 7 days from when the zip was added into the archived folder the zips are deleted from the ``/archived`` folder.
139
140### Key Environment variables
141- ``NODE_ENV`` - when set to debug the application prints the debug level logs.