LogZilla

ServiceNow Integration Overview

LogZilla integrates with ServiceNow to automate incident creation, enrichment, and routing. The integration requires specific prerequisites, a clear configuration sequence, and ongoing monitoring practices for reliable operations.

Architecture Overview

At a high level, LogZilla evaluates incoming events against Triggers. For matching events, an Execute Script action posts a JSON payload to the ServiceNow Incident Table API. The script has access to event context via EVENT_* variables and can implement idempotent logic using correlation_id. Throttling (e.g., EXEC_SCRIPT_PERIOD) and dedup windows can reduce outbound volume. See citations in frontmatter for LogZilla triggers, deduplication, and ServiceNow REST.

Use Triggers with Execute Script to call external REST APIs; scripts receive EVENT_* environment variables for payload construction.

Dedup windows and trigger throttling (e.g., EXEC_SCRIPT_PERIOD) control outbound volume.

Minimal Implementation Examples

ServiceNow Table API supports POST, GET, and PATCH for incident records.

Create Incident payload (example-only)

json
{
  "short_description": "[${SEV_TEXT}] ${EVENT_HOST}: ${EVENT_MESSAGE}",
  "description": "Host: ${EVENT_HOST}\nProgram: ${EVENT_PROGRAM}\nSeverity: ${SEV_TEXT} (${EVENT_SEVERITY})\nMessage: ${EVENT_MESSAGE}\nEventID: ${EVENT_ID}",
  "correlation_id": "${CORRID}"
}

Optional instance-specific fields you may add as needed:

"category": "network"
"subcategory": "router"
"priority": "2"
"assignment_group": "Network Operations"
"caller_id": "logzilla_integration"
"cmdb_ci": "router-nyc-01"

Incident table includes correlation_id and fields such as category, subcategory, priority, assignment_group, caller_id, and cmdb_ci.

Note: Official docs demonstrate a minimal POST-only example. The idempotent GET-by-correlation_id + PATCH/POST pattern below is a recommended enhancement. Requirement: the PATCH and POST examples below use jq to build JSON safely. Install jq via your Linux package manager (for example, apt-get install -y jq, yum install -y jq, or dnf install -y jq).

bash
# Derive severity text from EVENT_SEVERITY (docs pattern)
case "${EVENT_SEVERITY}" in
  0) SEV_TEXT="EMERGENCY" ;;
  1) SEV_TEXT="ALERT" ;;
  2) SEV_TEXT="CRITICAL" ;;
  3) SEV_TEXT="ERROR" ;;
  4) SEV_TEXT="WARNING" ;;
  5) SEV_TEXT="NOTICE" ;;
  6) SEV_TEXT="INFO" ;;
  7) SEV_TEXT="DEBUG" ;;
  *) SEV_TEXT="UNKNOWN" ;;
esac

# Generate stable correlation id from key event fields (SHA-256)
if command -v sha256sum >/dev/null 2>&1; then
  CORRID=$(printf '%s' "${EVENT_HOST}|${EVENT_PROGRAM}|${EVENT_ID}" | sha256sum | awk '{print $1}')
else
  # Fallback to OpenSSL if sha256sum is unavailable
  CORRID=$(printf '%s' "${EVENT_HOST}|${EVENT_PROGRAM}|${EVENT_ID}" | openssl dgst -sha256 | awk '{print $2}')
fi

Idempotent update-or-create flow (example-only)

bash
# Assumes ServiceNow API key in $SN_API_KEY and instance in $SN_INSTANCE

# 1) Try to find an existing incident by correlation_id
FOUND=$(curl -s -H "x-sn-apikey: $SN_API_KEY" \
  -H "Accept: application/json" \
  "https://$SN_INSTANCE/api/now/table/incident?sysparm_query=correlation_id=${CORRID}&sysparm_limit=1")

SYS_ID=$(printf '%s' "$FOUND" | jq -r '.result[0].sys_id // empty')

if [ -n "$SYS_ID" ]; then
  # 2) Update existing incident (e.g., add work_notes and refresh summary)
  PATCH_PAYLOAD=$(jq -n \
    --arg sev "$SEV_TEXT" \
    --arg host "$EVENT_HOST" \
    --arg msg "$EVENT_MESSAGE" \
    '{
      work_notes: "Repeated event observed; count updated",
      short_description: ("[" + $sev + "] " + $host + ": " + $msg)
    }')

  curl -s -X PATCH \
    -H "x-sn-apikey: $SN_API_KEY" \
    -H "Content-Type: application/json" \
    -d "$PATCH_PAYLOAD" \
    "https://$SN_INSTANCE/api/now/table/incident/$SYS_ID" > /dev/null
else
  # 3) Create a new incident (build payload safely with jq)
PAYLOAD=$(jq -n \
  --arg sev "$SEV_TEXT" \
  --arg host "$EVENT_HOST" \
  --arg msg "$EVENT_MESSAGE" \
  --arg program "$EVENT_PROGRAM" \
  --arg sevnum "$EVENT_SEVERITY" \
  --arg id "$EVENT_ID" \
  --arg corr "$CORRID" \
  '
  {
    short_description: ("[" + $sev + "] " + $host + ": " + $msg),
    description:
      ("Host: " + $host + "\n" +
       "Program: " + $program + "\n" +
       "Severity: " + $sev + " (" + $sevnum + ")\n" +
       "Message: " + $msg + "\n" +
       "EventID: " + $id),
    correlation_id: $corr
  }
  ')

curl -s -X POST \
  -H "x-sn-apikey: $SN_API_KEY" \
  -H "Content-Type: application/json" \
  -d "$PAYLOAD" \
  "https://$SN_INSTANCE/api/now/table/incident" > /dev/null
fi

Notes:
Use a ServiceNow API Key via the x-sn-apikey header. Limit scope to only the endpoints required for incident operations. LogZilla’s UI/API authentication is separate and unrelated to the ServiceNow API call.
Do not hardcode secrets in scripts. Prefer environment variables or a root-readable configuration file with least privilege.

Prerequisites

ServiceNow instance with API access (appropriate roles for incident creation)
ServiceNow API Key and corresponding authentication profile
API keys are supported via header-based authentication.
Network access between LogZilla and ServiceNow endpoints
Defined incident fields (assignment groups, categories, priorities)

Configuration Step-by-Step

ServiceNow integration covers script deployment and UI trigger setup.

Phase 1: ServiceNow instance preparation and API setup

Generate an API Key and configure an authentication profile to accept the x-sn-apikey header.
Verify API table permissions (for example, incident table access).
Capture endpoint URLs for REST API and authentication.

Phase 2: LogZilla connector configuration

Configure forwarding rules to call ServiceNow endpoints via webhook or API.
Include authentication headers and payload templates.
Test connectivity with a non-production incident or sandbox.

Phase 3: Field mapping and data transformation

Map syslog fields to incident fields (source host, category, severity).
Add enrichment fields (location, device role, dedup count, tags).
Normalize timestamps and ensure consistent encoding.

Phase 4: Workflow automation and business rules

Define when to create, update, or close incidents.
Set routing rules by category, severity, or device type.
Add escalation rules and on-call schedules where applicable.

Advanced Automation Scenarios

Scenario 1: Automatic incident creation from critical alerts with enrichment.
Scenario 2: Correlate repeat events and update existing tickets with counts.
Scenario 3: Trigger ServiceNow workflows for change approvals on configuration events.
Scenario 4: Bi-directional updates (optional): add comments or status updates from ServiceNow back to LogZilla dashboards.

Monitoring and Troubleshooting

Track success versus error rates for API calls and retries.
Log request/response bodies for non-sensitive failures.
Alert on authentication failures and rate limits.
Periodically validate field mappings as schemas evolve.

ROI and Business Impact

Reduced mean time to resolution through automated triage and routing.
Lower manual workload for NOC/SOC teams with standardized incident creation.
Improved auditability with consistent enrichment and field mapping.

Walkthrough Highlights (screenshots)

Below are a few high-signal steps illustrated with screenshots. For complete setup instructions, see the LogZilla Triggers documentation and Administration guides.

ServiceNow API key creation
interface Create a dedicated API credential in ServiceNow.

Add new trigger modal in LogZilla with 'Execute script' action
available Enable the Execute Script action when creating a new trigger.

Trigger filter using User Tags
menu Filter by tags to control when to raise incidents.

Execute script action with script selection
dropdown Use Execute Script to run the ServiceNow integration script.

Micro-FAQ

Which authentication method should be used?

Use a ServiceNow API Key with the x-sn-apikey header. Limit scope to only the endpoints required for incident operations. LogZilla's UI/API authentication remains token-based and is unrelated to the ServiceNow API call.

How should duplicate events be handled?

Apply ingest-time deduplication to suppress noisy repeats and update a single incident with cumulative counts at intervals.

Next Steps

Validate the integration in a test environment with a small set of sources. Monitor volumes, error rates, and ticket quality. Iterate on routing and field mappings before rolling out to production.

For detailed configuration steps, explore the Creating Triggers documentation and Administration guides.

Complete Guide to ServiceNow Integration for Automated Incident Response