# Application Logs

This is a support document to provide information on the application logs implemented in Aviva-SRM application.

##### Table of Content

- [Logging Mechanism](#Logging-Mechanism)
    - [Log levels](#Logging-Mechanism)
    - [Log file location](#Log-file-location)
    - [log Structure](#Log-file-Structure)
- [Application logs Tiers](#Application-log-Tiers)
    - [Internal (Application) Error logs](#Application-Error-logs)
    - [Internal (Aviva) Logs](#Internal-Aviva-Requests)
    - [External (Third-part) Logs](#Third-party-Requests)
- [Log Rotation/Archiving](#Log-Rotation)
- [Key Environment variables.](#Key-Environment-variables)

### Logging Mechanism
The application logs in SRM backend is of three levels logs:

- Debug
- Info
- Error

    #### Debug
    Logs all inbound and out bound requests. to enable debug logs sent ``NODE_ENV`` value to ``DEBUG``.

    #### INFO
    These logs are used to log inbound, outbound and responses of API requests. These logs are logged on to the ``app-info***.log`` file.

    ##### Error
    These logs are used to log the various errors that occur on the system. These logs are logged on to the ``app***.log`` file.

#### Log file location
The application logs are stored in the <strong>log</strong> folder in the application root folder.
```
.
+-- logs   <---  folder where logs are stored
+-- controller
    +-- index.js
    +-- auth.controller.js
+-- lakkin.js
+-- app.js
+-- server.js
```
the file naming convention is:

- error: ``app-SRM_%DATE%.log``
- info: ``app-info-SRM_%DATE%.log``
#### Log file Structure
The template/structure the logs follow is as follows:

- error : ``${timestamp} - ${level} - ${layer} - ${method} - ${message} - ${payload} - ${url}``
- info : ``${timestamp} - ${level} - ${layer} - ${req_method} - ${req_url} - ${message} - ${payload}``

the description of all the keys are:

- timestamp - the time the log entry was made.(``2019-09-19T12:00:03.278Z``)
- level - the type of log thats being printed.(``error|debug|warn|info``)
- layer - layer defines where in the application flow did the log get triggered.
- method - method is used to trace back the exact location of the log trigger point.
- message - custom or error message text that needs to be logged.
- payload - the request/response payload.
- url - the url that was triggered to initiate the application flow.
- req_url - the request/response URL.
- req_method - the request/response method.(``GET|POST|PUT|DELETE``)


### Application-log Tiers

While logging errors or information in SRM-backend application, the logging is divided into different tiers based on the destination and sensitivity of the data.

- ##### Application Error logs
    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``.

    the content that is logged in these requests are usually the error response or the error code that was recieved while execution.
- ##### Internal-Aviva Requests
    Internal-Aviva requests are API calls that are made to Aviva services. The main API's called are:
    1) login services.
    2) policy services.
    3) notification services.
    4) user(AOL) services.

    SSO request are also logged to track inbound requests.

    In all the API-calls that are made we log the key attributes:
    - url.
    - method.
    - success.(only message).
    - failure.(message and response body.)

    if the ``NODE_ENV`` is set to ``debug`` then the request/response body is logged into <i>info-logs</i>.

- ##### Third-party Requests
    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:
    - URL.
    - method.
    - request and response body.
    - headers.

    There are transaction_id added to the logs to trace the request to the corresponding response.

### Log Rotation
Log 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.

In SRM log files are rotated based on the following:
- ##### file size.
    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.
    ```
    +-- logs
        +-- app-SRM_22-09-2019.log.gz
        +-- app-SRM_22-09-2019.log.1
        ...
        ...
        ...
        +-- app-info-SRM_22-09-2019.log
    +-- controller
    ```
- ##### Daily.
    when a particular day ends the files are archived. on the same trigger we move the files from the ``/logs`` to the ``/archived`` folder.
    ```
    +-- logs
        +-- app-SRM_22-09-2019.log.gz
        +-- app-SRM_23-09-2019.log
        ...
        ...
        ...
        +-- app-info-SRM_22-09-2019.log.gz
        +-- app-info-SRM_23-09-2019.log
    +-- controller
    +-- archived
        +-- app-SRM_21-09-2019.log.gz
        +-- app-SRM_20-09-2019.log.gz
        +-- app-info-SRM_21-09-2019.log.gz
        +-- app-info-SRM_20-09-2019.log.gz
    ```
- ##### Week.
    In 7 days from when the zip was added into the archived folder the zips are deleted from the ``/archived`` folder.

### Key Environment variables
- ``NODE_ENV`` - when set to debug the application prints the debug level logs.