The following table shows which information is written to which log files:
Log Output | Description | Filesnames |
Structured | All log output of an IAM application module in structured "JSON Lines" format. This format is ideal for machine interpretation, but should also be human-readable. | {MODULE}-structured.log |
Elasticsearch | IAM offers direct integration with Elasticsearch. See 7.4. Logging and reporting pipeline (Elasticsearch, Kibana). The structured log files are used as the basis of this Feature. | |
Main/Console | All log output of an IAM application module in traditional log format pattern. | {MODULE}.log |
User Trail | High-level information on user actions (e.g. login processes, password change, admin action on user). This log file is written by all Airlock IAM modules. | medusa-usertrail.log |
Audit Log | Technical information on all actions required for non-repudiation. Every log line can be digitally signed. The audit log format is proprietary. Audit log signing is disabled by default. See: 8.5. Logging configuration | medusa-audit.log |
Web Server Log | Web server log output; usually during start-up/shut-down. In some cases fatal errors can be found in this file, which is useful for troubleshooting. Because of technical limitations, web server log files are configured separately from the application log files and log rotation may behave differently. See: 8.5. Logging configuration | web-server.log |
Access Log | Records all incoming requests. By default, the common log format is used, which closely matches the standard log format of Apache web server. | access.log |
Parseable logs | Parseable logs are an internal format and use by the Adminapp to display log information. They may change without notice. | {MODULE}-parseable.log |
REST request logs from Exit Filter
Note that Airlock IAM logs a summary line on INFO level for all REST requests.
- The log lines contain the following information:
- ●Request URL (including REST resource path)
- ●HTTP response status
- ●Request processing time
- ●Standard log attributes (log level, session ID, request ID, etc.
Example logline of password check in the Loginapp:
Exiting GET https://auth.virtinc.com/auth-login/rest/public/authentication/password/check [status=200, elapsed=313ms] Level: INFO Session: 577211487140867760 Request: 494275672497342264 IP: 192.168.13.13
Further information an links
- ●For details on architecture and deployment of the logging infrastructure see: 7.4. Logging and reporting pipeline (Elasticsearch, Kibana)
- ●For detailed information on the configuration of the logging see: 8.5. Logging configuration.