.png?sv=2022-11-02&spr=https&st=2024-11-23T00%3A46%3A02Z&se=2024-11-23T00%3A56%3A02Z&sr=c&sp=r&sig=QTXyJ%2FLxfobwKAA1RkNdI%2F%2Bi5DLWlmYWyrej60mzo98%3D){kind=logo}
Logging
- 10 Jul 2024
-
DarkLight
-
PDF
Logging
- Updated on 10 Jul 2024
-
DarkLight
-
PDF
Article summary
Did you find this summary helpful?
Thank you for your feedback
Logging provides useful data to evaluate system health, more easily debug errors, and capture events that happen during runtime.
-
Check the application logs or journal logs to verify if the application is up and working correctly, or to determine if an app or adapter is down or has no connection in Admin Essentials.
- Application logs are commonly found at
/var/log/pronghorn. - To view journal logs use the journalctl command
journalctl -fu pronghorn.
- Application logs are commonly found at
-
From Admin Essentials, navigate to Applications → AGManager → loggerProps. Three log types can be viewed: application, console, syslog.
Figure 1: Logger Props
| Log Type | Subject of Logging |
|---|---|
| Application | Pertains to AG Manager and log files for the application. |
| Console | Pertains to log files showing everything under IAP Standard-out (STD_OUT). |
| Syslog | Pertains to system logs that can be produced in any specified host or localhost. |
To configure Syslog, go to the Configuration guide.
To configure alarmProps for more logging options, see the IAP Profiles guide.
To configure alarmProps using various SNMP Traps, see SNMP Notification Types.
Log Levels
Log levels are defined in the loggerProps and each log level has a severity associated with it. The most important log level is defined as an error.
| Log Level | Description |
|---|---|
| Error | Errors or failures that impact functionality. |
| Warn | Issues or unexpected behavior which does not impact functionality. |
| Info | Successful status change; should be limited to one message per successful action. |
| Debug | Major events such as successful data retrieval from an external system or the completion of a function. |
| Trace | Minor events within functions. These are "breadcrumbs" within a function. |
| Spam | Collect or output excessive or repetitive messages, large text files, large quantities of data such as search results; information which though relevant would clutter up the log file and render it unusable. |
Figure 2: Log Settings
Production environments should have the log_level set to warn or info. Debug, trace, and spam log levels will generate a large amount of log data and additional server load. Only configure production servers in debug mode when tracing logs are necessary to the operations.
For systemd operating systems, the system journal manages console logging. The system journal may also contain application life cycle error messages that cannot be saved to the IAP file logs.
Systemd logs will show IAP starting up and the deployment log files.
Additional systemd logging information is stored in the systemd journal or at /var/log/messages on System V (“System Five”) hosts.
Monitor the system journal for errors and warnings using the shell command journalctl -f.
Filter log messages to show only IAP logs using the shell command journalctl -f -u pronghorn.service.
Monitor IAP logs with a tail follow shell command, such as tail -F /var/log/pronghorn/pronghorn.log.
Apart from the IAP logs it is essential to capture logs for dependencies like MongoDB, RabbitMQ, and Redis. The configuration files for each dependency will contain the location of their respective log files. If an ISD ticket is opened, the service desk may or may not request a copy of these logs.
For more information, see Event Logs & Logging.
Was this article helpful?
