> ## Documentation Index
> Fetch the complete documentation index at: https://tyk.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Logging in Tyk
> Learn different types of logs in Tyk, how to configure them and how to integrate with third-party log management tools for effective API observability.
A log is a timestamped text record, either structured (recommended) or unstructured, with some metadata.
Tyk logs are written to `stderr` and `stdout`. In a typical installation, these will be handled by the service manager running the process.
## Types of Logs
Tyk generates three types of logs:
* **Application Logs:** Captures internal events of the system, such as health-checks, status, configuration changes, and errors, which are typically used for monitoring and debugging.
* **Access Logs:** Traditional server logs that record basic information about each request to your API Gateway. Gateway Only
* **404 Logs:** A configuration option in Tyk Gateway that enables logging of HTTP 404 (Not Found) errors. Gateway Only
Tyk Gateway also generates **API Traffic Logs**, which are written into Redis for detailed information about API traffic and analysis. For more information on API Traffic Logs, refer to this [documentation](/5.11/api-management/tyk-pump#api-traffic-logs).
## Configuring Logs
You can configure log verbosity and format for the following Tyk components:
### Log Verbosity
Tyk can generate application logs at four levels of verbosity:
* `error` is the most minimal level of logging, reporting only errors
* `warn` will log warnings and errors
* `info` logs errors, warnings and some additional information and is the default logging level
* `debug` generates a high volume of logs for maximum visibility of what Tyk is doing when you need to debug an issue
Debug log level generates a significant amount of data and is not recommended unless debugging.
You can set the logging verbosity for each Tyk Component using the appropriate `log_level` setting in its configuration file (or the equivalent environment variable).
| Tyk component | Config option | Environment variable | Default value if unset |
| :---------------------------------------------------------------------------------------------------------------- | :------------ | :------------------- | :--------------------- |
| Tyk Dashboard | Not Available | Not Available | `info` |
| [Tyk Gateway](/5.11/tyk-oss-gateway/configuration#log_level) | `log_level` | `TYK_GW_LOGLEVEL` | `info` |
| [Tyk Pump](/5.11/tyk-pump/tyk-pump-configuration/tyk-pump-environment-variables#log_level) | `log_level` | `TYK_PMP_LOGLEVEL` | `info` |
| [Tyk MDCB](/5.11/tyk-multi-data-centre/mdcb-configuration-options#log_level) | `log_level` | `TYK_MDCB_LOGLEVEL` | `info` |
| [Tyk Developer Portal](/5.11/product-stack/tyk-enterprise-developer-portal/deploy/configuration#portal_log_level) | `logLevel` | `PORTAL_LOG_LEVEL` | `info` |
### Log Format
You can configure the format in which logs will be generated; it can be either `text` (default) or `json` (recommended).
As a general performance tip, the `json` output format incurs less memory allocation overhead than the `text` format. For optimal performance, it's recommended to configure logging in the JSON format.
```
time="Sep 05 09:04:12" level=info msg="Tyk API Gateway v5.6.0" prefix=main
```
```json theme={null}
{"level":"info","msg":"Tyk API Gateway v5.6.0","prefix":"main","time":"2024-09-05T09:01:23-04:00"}
```
| Tyk component | Config option | Environment variable | Default value if unset |
| :-------------------------- | :------------ | :--------------------- | :------------------------ |
| Tyk Gateway (from `v5.6.0`) | log\_format | TYK\_GW\_LOGFORMAT | text |
| Tyk Pump | log\_format | TYK\_PMP\_LOG\_FORMAT | text |
| Tyk Dashboard (System) | log\_format | TYK\_DB\_LOGFORMAT | text |
| Tyk Dashboard (Audit) | audit.format | TYK\_DB\_AUDIT\_FORMAT | text |
| Tyk MDCB | Not Available | Not Available | text |
| Tyk Developer Portal | LogFormat | PORTAL\_LOG\_FORMAT | prod (equivalent to json) |
## Application Logs
Application logs capture internal events of the system, such as health-checks, status, configuration changes, and errors, which are typically used for monitoring and debugging.
**Example**
```
time="Feb 16 22:48:39" level=info msg="Using Policies from Dashboard Service" prefix=main
time="Feb 16 22:48:39" level=info msg="Calling dashboard service for policy list" prefix=policy
time="Feb 16 22:48:39" level=info msg="Processing policy list" prefix=policy
time="Feb 16 22:48:39" level=info msg="Policies found (5 total):" prefix=main
```
## Access Logs
Gateway Only Not available in Tyk Cloud
Access logs are simple, traditional server logs that record basic information about each request to your API Gateway and are written directly to stdout/stderr.
As of Tyk Gateway v5.8.0, you can configure the Gateway to log individual API requests. To enable this feature, set the `TYK_GW_ACCESSLOGS_ENABLED` environment variable to `true`.
You can also configure which fields are logged by configuring the `TYK_GW_ANALYTICSLOGS_TEMPLATE` environment variable. Below are the available values you can include:
### Configurable Fields
Obfuscated or hashed API key used in the request.
IP address of the client making the request.
Hostname of the request.
HTTP method used in the request (for example, GET or POST).
URL path of the request.
Protocol used in the request (for example, HTTP/1.1).
Remote address of the client.
Full upstream address, including scheme, host, and path.
Round-trip duration between the gateway sending the request to the upstream service and receiving the response.
Total time taken to process the request, including upstream latency and additional gateway processing.
User agent string provided by the client.
HTTP response status code.
#### Default Template Example
Configuration using `tyk.conf`
```json theme={null}
{
"access_logs": {
"enabled": true
}
}
```
Configuration using environment variables:
```
TYK_GW_ACCESSLOGS_ENABLED=true
```
Output:
```
time="Jan 29 08:27:09" level=info api_id=b1a41c9a89984ffd7bb7d4e3c6844ded api_key=00000000 api_name=httpbin client_ip="::1" host="localhost:8080" latency_total=62 method=GET org_id=678e6771247d80fd2c435bf3 path=/get prefix=access-log protocol=HTTP/1.1 remote_addr="[::1]:63251" status=200 upstream_addr="http://httpbin.org/get" upstream_latency=61 user_agent=PostmanRuntime/7.43.0
```
#### Custom Template Example
Configuration using `tyk.conf`
```json theme={null}
{
"access_logs": {
"enabled": true,
"template": [
"api_key",
"remote_addr",
"upstream_addr"
]
}
}
```
Configuration using environment variables:
```
TYK_GW_ACCESSLOGS_ENABLED=true
TYK_GW_ACCESSLOGS_TEMPLATE="api_key,remote_addr,upstream_addr"
```
Output:
```
time="Jan 29 08:27:48" level=info api_id=b1a41c9a89984ffd7bb7d4e3c6844ded api_key=00000000 api_name=httpbin org_id=678e6771247d80fd2c435bf3 prefix=access-log remote_addr="[::1]:63270" upstream_addr="http://httpbin.org/get"
```
#### Performance Considerations
Enabling access logs introduces some performance overhead:
* **Latency:** Increases consistently by approximately 4%–13%, depending on CPU allocation and configuration.
* **Memory Usage:** Memory consumption increases by approximately 6%–7%.
* **Allocations:** The number of memory allocations increases by approximately 5%–6%.
While the overhead of enabling access logs is noticeable, the impact is relatively modest. These findings suggest the performance trade-off may be acceptable depending on the criticality of logging to your application.
## track\_404\_logs
Gateway Only
The [track\_404\_logs](/5.11/tyk-oss-gateway/configuration#track_404_logs) is a configuration in Tyk Gateway. When you set it to `true`, the gateway will log all incoming HTTP requests that result in a 404 `Not Found` error because they don't match any of your configured API listen paths.
Currently, users can track 404 traffic through the gateway only using this method. Access logs and Tyk Pump’s API traffic logs do not include 404 traffic.
### Configuration
You can enable this feature by setting the [track\_404\_logs](/5.11/tyk-oss-gateway/configuration#track-404-logs) option to `true` in your `tyk.conf` file or by setting the [TYK\_GW\_TRACK404LOGS](/5.11/tyk-oss-gateway/configuration#track-404-logs) environment variable to `true`.
**Example**
```
time="2023-07-15T10:25:30Z" level=error msg="Not Found" prefix=gateway request="GET /nonexistent/path HTTP/1.1" origin=192.168.1.5:54321
```
## Register Custom Log Handlers
Gateway Only
[Custom logging event handlers](/5.11/api-management/gateway-events#logging-api-events) can be registered against **Gateway events** to customise the logs that are generated for those events.
## Exporting Logs
Gateway Only
Tyk Gateway can be configured to send log data to a range of 3rd party tools for aggregation and analysis.
To enable Sentry as a log aggregator, update these settings in both your `tyk.conf` and your `tyk_analytics.conf`:
* `use_sentry`: Set this to `true` to enable the Sentry logger, you must specify a Sentry DSN under `sentry_code`.
* `sentry_code`: The Sentry-assigned DSN (a kind of URL endpoint) that Tyk can send log data to.
To enable Logstash as a log aggregator, update these settings in your `tyk.conf`:
* `use_logstash`: Set this to `true` to enable the Logstash logger.
* `logstash_transport`: The Logstash transport to use, should be `"tcp"`.
* `logstash_network_addr`: Set to the Logstash client network address, should be in the form of `hostname:port`.
To enable Graylog as a log aggregator, update these settings in your `tyk.conf`:
* `use_graylog`: Set this to `true` to enable the Graylog logger.
* `graylog_network_addr`: The Graylog client address in the form of `:`.
To enable Syslog as a log aggregator, update these settings in your `tyk.conf`:
* `use_syslog`: Set this to `true` to enable the Syslog logger.
* `syslog_transport`: The Syslog transport to use, should be `"udp"` or empty.
* `syslog_network_addr`: Set to the Syslog client network address, should be in the form of `hostname:port`