What TBL should be checked when investigating a problem?

Go to solution
bonsai
Mega Sage

‎12-24-2024 11:56 PM

When an issue occurs with an instance, what else do you check besides the logs below?

I'd like to know best practices for investigating issues.

 

<Target table>
syslog_transaction
sysevent
syslog

 

I always check these three tables, but I don't know what's causing the problem.

0 Helpfuls
  • 671 Views
2 ACCEPTED SOLUTIONS

Go to solution
Community Alums
Not applicable

‎12-25-2024 04:13 AM

Hi @bonsai ,

When investigating issues in a ServiceNow instance, relying solely on logs such as syslog_transaction, sysevent, and syslog may not always pinpoint the root cause. While these logs are excellent starting points, it’s essential to expand the investigation to other key areas to uncover potential issues.

One critical area to explore is user sessions and activity. By reviewing the syslog_session and syslog_user tables, you can identify any unusual or unauthorized activity that might correlate with the problem. This can reveal conflicts caused by simultaneous updates or specific user actions.

Another vital aspect is examining scripts, business rules, and workflows. Errors in these can disrupt functionality. Logs like sysrule_script_error can help identify script failures, while workflow-related anomalies can be traced using the wf_context and wf_history tables. Often, scripting errors or logic flaws can cause cascading issues, so reviewing recent customizations is a good practice.

Integrations and API transactions also play a significant role in system health. Investigating REST API logs (sys_rest_message_trans) and message queues (ecc_queue) can uncover errors in external system communications. Issues like failed HTTP requests or incorrect endpoint configurations can often cause unexpected system behavior.

Performance and resource usage are other areas to consider. Tools such as the Transaction Log Viewer and System Diagnostics can provide insights into resource utilization, memory usage, and database response times. Monitoring these metrics can help identify whether performance bottlenecks are contributing to the issue.

Additionally, it’s crucial to assess data integrity. Corrupt or missing data in key tables or conflicting data policies can lead to erratic behavior. Running fix scripts or reviewing audit histories can help resolve inconsistencies. For recently deployed customizations, the sys_update_xml table can be invaluable for tracing changes that might have introduced problems.

Best practices for troubleshooting include defining the issue’s scope (e.g., user-specific or global), reproducing the issue in a test environment, and isolating potential causes by temporarily disabling non-critical customizations. Debugging tools like the Script Debugger and enabling Debug Business Rules can provide runtime information to identify errors. Lastly, leveraging ServiceNow’s Instance Scan or collaborating with ServiceNow Support can further enhance the troubleshooting process. By adopting a comprehensive and systematic approach, you can efficiently identify and resolve issues in your instance.

View solution in original post

2 REPLIES 2

Go to solution
Community Alums
Not applicable

‎12-25-2024 04:13 AM

Hi @bonsai ,

When investigating issues in a ServiceNow instance, relying solely on logs such as syslog_transaction, sysevent, and syslog may not always pinpoint the root cause. While these logs are excellent starting points, it’s essential to expand the investigation to other key areas to uncover potential issues.

One critical area to explore is user sessions and activity. By reviewing the syslog_session and syslog_user tables, you can identify any unusual or unauthorized activity that might correlate with the problem. This can reveal conflicts caused by simultaneous updates or specific user actions.

Another vital aspect is examining scripts, business rules, and workflows. Errors in these can disrupt functionality. Logs like sysrule_script_error can help identify script failures, while workflow-related anomalies can be traced using the wf_context and wf_history tables. Often, scripting errors or logic flaws can cause cascading issues, so reviewing recent customizations is a good practice.

Integrations and API transactions also play a significant role in system health. Investigating REST API logs (sys_rest_message_trans) and message queues (ecc_queue) can uncover errors in external system communications. Issues like failed HTTP requests or incorrect endpoint configurations can often cause unexpected system behavior.

Performance and resource usage are other areas to consider. Tools such as the Transaction Log Viewer and System Diagnostics can provide insights into resource utilization, memory usage, and database response times. Monitoring these metrics can help identify whether performance bottlenecks are contributing to the issue.

Additionally, it’s crucial to assess data integrity. Corrupt or missing data in key tables or conflicting data policies can lead to erratic behavior. Running fix scripts or reviewing audit histories can help resolve inconsistencies. For recently deployed customizations, the sys_update_xml table can be invaluable for tracing changes that might have introduced problems.

Best practices for troubleshooting include defining the issue’s scope (e.g., user-specific or global), reproducing the issue in a test environment, and isolating potential causes by temporarily disabling non-critical customizations. Debugging tools like the Script Debugger and enabling Debug Business Rules can provide runtime information to identify errors. Lastly, leveraging ServiceNow’s Instance Scan or collaborating with ServiceNow Support can further enhance the troubleshooting process. By adopting a comprehensive and systematic approach, you can efficiently identify and resolve issues in your instance.