ServiceNow Logs Structure - Knowledge Base Article - Support and Troubleshooting

ServiceNow Logs Structure - Knowledge Base Article Summary .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } This document provides brief information about the ServiceNow log structure, including field descriptions and their purposes.

Article Information Category: Platform Logging Subcategory: Node Logs / Localhost Logs Audience: Developers, System Administrators, Support Engineers Description ServiceNow node logs (also known as localhost logs) are local text files on ServiceNow instances that capture platform-level logging information. The logs are written as text entries where each LogEvent object is formatted and printed as a text line. When exported through Log Export Service (LES) or parsed by log aggregation tools, these text logs can be structured into JSON format with consistent fields that provide detailed context about system operations, transactions, and user activities.

Node Log File Pattern Raw Text Format Node logs are written as text entries in the localhost log files. Each LogEvent is printed as formatted text with timestamp, log level, logger name, and message.

Structured JSON Format (via LES/Log Aggregation) When node logs are exported through Log Export Service (LES) or processed by log aggregation tools, the text entries are parsed and structured into JSON format with the following fields:

Sample Structured Log Entry { "_timestamp": "2022-08-23T18:21:40.419351", "_source_type": "localhost_log", "_page_name": "xmlhttp.do", "_system_id": "192.168.1.44:glide_platformencore2", "_logged_in_user": "maint", "_user": "maint", "_is_impersonating": "false", "_txid": "0a244530b72111104cd7ccf78e11a906", "_session_id": "E54F30B4B72111104CD7CCF78E11A95C", "_message": "Ignoring configuration for sn_cs.auto_resolution reason[inactive ]", "_level": "INFO" } Field Descriptions Note: These fields represent the structured JSON format created when raw text logs are parsed and exported through Log Export Service or log aggregation tools. The raw localhost log files contain this information as formatted text entries.

_timestamp Type: String (ISO 8601 format) Example: "2022-08-23T18:21:40.419351" Description: The exact timestamp at which the log message was printed. This uses UTC time format with microsecond precision. Use Case: Correlating events, troubleshooting timing issues, performance analysis _source_type Type: String Example: "localhost_log" Description: Identifies the source of the log entry. For platform-level content from the Glide platform, this value remains constant as "localhost_log". Use Case: Filtering and categorizing log sources _page_name Type: String Example: "xmlhttp.do" , "sys_user.do" , "incident.do" Description: The page or endpoint that was invoked which triggered the current log message. This helps identify which UI page or API endpoint was being accessed. Use Case: Debugging page-specific issues, tracking user navigation patterns _system_id Type: String Example: "192.168.1.44:glide_platformencore2" Description: The actual application node from which this log message was printed. Format is typically : . Use Case: Identifying which node in a clustered environment generated the log, troubleshooting node-specific issues _logged_in_user Type: String Example: "maint" , "admin" , "john.doe" Description: The user who was logged into the system when this log message was printed. This represents the actual authenticated user. Use Case: User activity tracking, security auditing, troubleshooting user-specific issues _user Type: String Example: "maint" , "admin" , "john.doe" Description: The effective user context when the log was generated. This is the same as _logged_in_user if impersonation is not active. If impersonation is active, this field shows the impersonated user. Use Case: Understanding the effective security context, debugging permission issues _is_impersonating Type: String (Boolean) Example: "false" , "true" Description: Indicates whether user impersonation was in progress at the time of this transaction. When "true", the _logged_in_user and _user fields will differ. Use Case: Security auditing, troubleshooting impersonation-related issues _txid Type: String (System ID) Example: "0a244530b72111104cd7ccf78e11a906" Description: Transaction ID associated with this log statement. All log entries within the same transaction will share this ID. Use Case: Correlating multiple log entries for a single transaction, end-to-end transaction tracing _session_id Type: String (System ID) Example: "E54F30B4B72111104CD7CCF78E11A95C" Description: Session ID associated with this log statement. All log entries within the same user session will share this ID. Use Case: Tracking user session activity, debugging session-specific issues _message Type: String Example: "Ignoring configuration for sn_cs.auto_resolution reason[inactive ]" Description: The actual log message content that was printed. This contains the substantive information about what occurred in the system. Use Case: Understanding system behavior, debugging issues, monitoring system health _level Type: String (Enum) Possible Values: INFO , DEBUG , ERROR , WARN Example: "INFO" Description: The severity level of the log statement. Different levels indicate different types of messages: INFO: Informational messages about normal operations DEBUG: Detailed debugging information ERROR: Error conditions that need attention WARN: Warning messages about potential issues Use Case: Filtering logs by severity, alerting on errors, debugging with detailed logs Common Use Cases 1. Transaction Tracing Use the _txid field to follow all log entries for a specific transaction across multiple components and operations.

2. User Activity Monitoring Combine _logged_in_user , _user , and _is_impersonating fields to track user activities and understand the security context.

3. Performance Analysis Use _timestamp to analyze timing between operations and identify performance bottlenecks.

4. Node-Specific Debugging Filter by _system_id to isolate issues to specific nodes in a clustered environment.

5. Page-Level Troubleshooting Use _page_name to identify issues related to specific UI pages or API endpoints.

Important Notes General Characteristics of Localhost Node Logs File Format: Node logs are text-based files where LogEvent objects are printed as formatted text entries, not JSON. The JSON structure shown in this document represents how these logs are structured when exported via Log Export Service (LES) or parsed by log aggregation tools. File Location: Node logs are stored locally on each application node in the ServiceNow instance. They are not centralized by default and must be collected from individual nodes. Real-time Generation: Logs are written in real-time as events occur on the platform, providing immediate visibility into system operations. Multi-node Environments: In clustered environments, each node generates its own log file. Use the _system_id field (in structured format) to identify which node generated each log entry. Configuration and Management File Naming Convention: Log files typically follow the pattern localhost_log.YYYY-MM-DD.txt . Access Requirements: Accessing node logs typically requires: SSH/terminal access to the application node (for on-premise) Log Export Service (LES) configuration (for cloud instances) Appropriate administrative privileges Support Contact For questions or issues related to node logs:

Team: Dev-Platform Audit and Logging Escalation: Contact your ServiceNow Technical Account Manager Keywords node logs, localhost logs, log structure, log fields, transaction tracing, logging framework, platform logs, JSON logs, log analysis, debugging

Related Links .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0826291

https://www.servicenow.com/docs/bundle/zurich-platform-security/page/administer/system-logs/concept/system-logs.html