Centralized Logging

API7 Gateway produces several types of logs that are essential for debugging and operating the platform. For production environments, forward these logs to a centralized log management system such as Elasticsearch, Splunk, or AWS CloudWatch.

Log types and locations

Data plane logs

The data plane writes both an error log and an access log. With the official container images, both files live under /usr/local/apisix/logs/:

Log type	Description	Default path
Error log	Gateway startup events, plugin errors, upstream failures, and core errors.	/usr/local/apisix/logs/error.log
Access log	One line per request processed by the gateway.	/usr/local/apisix/logs/access.log

If you run the data plane outside the official images, the actual paths depend on your installation prefix. Both paths are configurable in config.yaml — see Configure log files below.

Control plane logs

The control plane (Dashboard and DP Manager) emits structured logs to standard output of the corresponding container. Use your container runtime to inspect them, for example:

docker logs <api7-ee-dashboard-container>
docker logs <api7-ee-dp-manager-container>

Administrative changes (configuration created/updated/deleted, login activity, role changes) are recorded separately in the audit log, which is viewable in the Dashboard.

Configure log files

The following keys in the data plane's config.yaml control where logs are written and how verbose the error log is:

conf/config.yaml

nginx_config:
  error_log: logs/error.log
  error_log_level: warn  # debug, info, notice, warn, error, crit, alert, emerg
  http:
    enable_access_log: true
    access_log: logs/access.log
    access_log_format: '$remote_addr - $remote_user [$time_local] $http_host "$request_line" $status $body_bytes_sent $request_time "$http_referer" "$http_user_agent" $upstream_addr $upstream_status $upstream_response_time "$apisix_request_id"'
    access_log_format_escape: default  # default or json

Relative paths are resolved against the gateway's installation prefix (/usr/local/apisix in the official images).

After changing any of these values, reload or restart the gateway for the new configuration to take effect.

Use a JSON access log format

For easier parsing by log shippers, set a JSON access log format and switch escaping to json:

conf/config.yaml

nginx_config:
  http:
    access_log_format: '{"time_local":"$time_local","remote_addr":"$remote_addr","status":"$status","request_time":"$request_time","upstream_status":"$upstream_status","request":"$request"}'
    access_log_format_escape: json

To include consumer labels in each access log line, see Log Consumer Labels in Access Log.

Forward logs to a centralized system

You have two complementary options:

• Ship the log files. Run a log forwarder such as Fluentd, Vector, Filebeat, or Logstash on each gateway host and tail /usr/local/apisix/logs/access.log and error.log. This works for any backend (Elasticsearch, Splunk, AWS CloudWatch, Loki, etc.) and decouples log delivery from the request path.
• Stream logs directly from a route. Use one of the gateway's logger plugins to send structured request logs over the network without writing them to disk first. Available logger plugins include http-logger, kafka-logger, syslog, splunk-hec-logging, google-cloud-logging, elasticsearch-logger, rocketmq-logger, and clickhouse-logger. For a full Splunk HEC walkthrough, see Splunk HEC Integration.

Next steps

• Log Consumer Labels in Access Log — include per-consumer metadata in every access log line.
• Splunk HEC Integration — stream logs to Splunk over HTTP.
• Configure Alerts — get notified when error rates breach a threshold.
• Audit Logs — track configuration changes made through the Dashboard or Admin API.