Managing syslog Growth in ServiceNow

[SachinG67648800]

Introduction

The syslog table is one of the most active tables in ServiceNow. It stores platform-level informational, warning, and error messages. Many customers face rapid growth of syslog data, which can impact system performance and storage.

This article outlines actionable steps to:

• Reduce excessive log generation.

• Adjust syslog table rotation for faster data truncation.

• Enforce coding guardrails around logging.

• Highlight why Data Management Policies do not apply to rotated tables like syslog.

---

Limitations of Data Management Policy and Reclamation Rules

• Data Management Policies (cleanup rules, retention, reclamation) cannot be applied to rotated tables such as syslog.

• Rotated tables are controlled by Table Rotation, which manages retention by truncating old shards.

• Attempting to configure cleanup rules for syslog will not take effect.

Official reference: Demystifying table rotation, extension, and table cleaner – ServiceNow Docs

---

System Properties – Logging Levels

⚠ Note: The list below is based on a specific customer instance configuration and enabled plugins.
In your case, start by filtering system properties where Name contains .log and review which are set to info or debug.
Always double-check with platform/operations teams before making changes, as reducing log levels may result in missing important troubleshooting information.

Set to warn from info

The following properties were previously set to info and have now been updated to warn to reduce syslog noise:

• com.snc.trigger_rules.log.level → set to warn from info

• glide.amb.log.level → set to warn from info

• com.glide.schedules.log.level → set to warn from info

• com.glide.document.log.level → set to warn from info

• cmdb.lifecycle.util.log.levels → set to warn from info

• x_dice_digicertone.logging.verbosity → set to warn from info

• sn_nxui_framework.logging.level → set to warn from info

Already safe / disabled

• sn_nxui_framework.logging.enabled → false (keep off unless required)

• sn_itom_pattern.log_gcp_event_job → false (keep off)

• sn_sb.logging (Service Bridge) → false (keep off)

• glide.sc.log.variable_actions → Recommendation: set to false unless detailed variable action logs are required

---

Table Rotation Policy for syslog

• Current configuration: 7 days per shard × 8 shards = 56 days retention.

• Recommended change: reduce to 3 days per shard.

  • With 8 shards, this results in 24 days of total retention.

Impact:

• Logs are truncated every 3 days instead of every 7.

• Overall syslog size is reduced, but you still retain 24 days of logs.

• Must be validated with audit/compliance stakeholders before implementation.

---

Guardrails for Logging in Custom Code

A. Current challenges

• Excessive use of gs.log() and gs.info() in scripts leads to unnecessary log entries.

• These methods are often used for debugging but left behind in production code.

B. Guardrail policies

1. New development:

   • Do not allow gs.info() or gs.log() in production-ready code.

   • Only use gs.warn() or gs.error() where absolutely necessary.

   • If informational logging is required, wrap it in a condition controlled by a system property (e.g., only enabled in sub-production).

2. Existing code cleanup initiative:

   • Identify and remove all occurrences of gs.info() and gs.log() in scripts, business rules, and scheduled jobs.

   • Replace with gs.warn() or gs.error() only where required for troubleshooting.

   • This is a one-time, tedious but necessary initiative to reduce syslog noise.

---

Recommendations Summary

1. System Properties:

   • Set logging levels to warn from info as listed above.

   • Disable variable action logging (glide.sc.log.variable_actions) unless strictly required.

   • Review all other .log properties in your instance and adjust carefully.

2. Table Rotation:

   • Reduce syslog retention from 7 days per shard (56 days total) to 3 days per shard (24 days total).

3. Logging Practices:

   • Enforce strict coding standards against gs.info() / gs.log().

   • Allow only gs.warn() and gs.error() in production.

   • Launch cleanup to remove existing gs.info/gs.log statements.

4. Data Management Policy Awareness:

   • Note that cleanup/reclamation rules cannot apply to syslog or other rotated tables.

   • Retention is managed only by table rotation.

---

Conclusion

By combining log-level tuning, rotation adjustments, and guardrails for logging practices, ServiceNow customers can control syslog growth, reduce storage usage, and maintain healthy platform performance — while still retaining a reasonable history of logs (24 days at 3-day shard rotation).