# ZTP Event Tracker

The **ZTP Event Tracker** provides a centralized view for monitoring and tracking **ZTP-related syslogs received from DHCP servers**. It helps administrators follow the complete lifecycle of a Zero Touch Provisioning (ZTP) event—from the moment a syslog is received through discovery, configuration download, and the creation of an upload job.

This module acts as a **traceability and troubleshooting layer** for ZTP, enabling users to identify where a syslog currently resides in the processing pipeline and quickly detect failures or duplicate events.

The ZTP Event Tracker is available only when:

* The **ZERO\_TOUCH\_PROVISIONING** license is enabled, and
* The **Infraon\_NCCM** feature flag is active.

## **How It Works**

1. A DHCP server sends a **ZTP-related syslog** to the Infraon Data Collector.
2. Syslog messages are ingested into **Kafka** and assigned a unique **Track ID**.
3. The syslog progresses through multiple internal processing stages:

* Event ingestion
* Trigger processing
* Discovery creation
* Download job handling
* Upload job creation

4. Each stage updates the **Status** of the syslog in real time.
5. If a failure occurs at any stage, the error is captured and displayed in the tracker.
6. On successful completion, the tracker confirms whether:

* A discovery job was completed, and
* A download/upload job was created or already existed.

This visibility allows administrators to **validate ZTP behavior**, **diagnose failures**, and **confirm automation outcomes** without switching across modules.

### **ZTP Processing Status**

As a syslog moves through the ZTP pipeline, the **Status** field is updated sequentially to reflect its current processing stage. Common statuses include:

ZTP Event **| State | Status**

<table><thead><tr><th width="183.4000244140625">Status</th><th width="133.20001220703125">State</th><th>Description</th></tr></thead><tbody><tr><td><strong>Received in Kafka</strong></td><td>Not Started</td><td>The ZTP syslog message is received from the DHCP server and successfully ingested into Kafka via the data collector. This is the initial state of ZTP event tracking.</td></tr><tr><td><strong>Sent To Event</strong></td><td>Not Started</td><td>The syslog event is forwarded from Kafka to the event consumer for further ZTP processing.</td></tr><tr><td><strong>Received In Trigger</strong></td><td>Not Started</td><td>The event consumer passes the syslog to the trigger service, where ZTP workflow validation begins.</td></tr><tr><td><strong>Sent To Discovery Celery</strong></td><td>Not Started</td><td>The trigger service sends the ZTP event to the discovery celery worker for device discovery processing.</td></tr><tr><td><strong>Processing Discovery Request</strong></td><td>In Progress</td><td>The discovery celery worker is actively processing the ZTP request to identify the device and validate discovery prerequisites.</td></tr><tr><td><strong>Discovery Configuration Added</strong></td><td>In Progress</td><td>The discovery configuration for the identified device is created or mapped during the ZTP workflow.</td></tr><tr><td><strong>Discovery Job Added</strong></td><td>In Progress</td><td>A discovery job is created and queued for execution on the agent for the detected device.</td></tr><tr><td><strong>Discovery Completed</strong></td><td>Completed</td><td>The discovery job execution is completed successfully, and the device is discovered as part of the ZTP process.</td></tr><tr><td><strong>Download Job Already Exist</strong></td><td>In Progress</td><td>A configuration or image download job already exists for the detected device, so no new job is created.</td></tr><tr><td><strong>Download Job Created</strong></td><td>In Progress</td><td>A new download job is created for the device during ZTP onboarding.</td></tr><tr><td><strong>Added Download Job To Agent</strong></td><td>In Progress</td><td>The download job is successfully assigned to the agent for execution on the device.</td></tr><tr><td><strong>Adding Upload Job</strong></td><td>In Progress</td><td>The system is creating an upload job to collect configuration or operational data from the device after discovery.</td></tr><tr><td><strong>Upload Job Created</strong></td><td>Completed</td><td>The upload job is successfully created and linked to the ZTP workflow.</td></tr><tr><td><strong>Upload Job Created</strong></td><td>Completed</td><td>The ZTP workflow completes after a successful upload job is created.</td></tr><tr><td><strong>Error (Hover Details)</strong></td><td>Error</td><td>If an error occurs at any stage of the ZTP workflow, an error icon is displayed. Hovering over the icon shows the available error details.</td></tr></tbody></table>

## **What You See on the Screen**

The **ZTP Event Tracker** page provides a single consolidated view to monitor, track, and control the lifecycle of ZTP syslog events received from DHCP servers.\*\*Syslog Events |\*\*Basic Details

<table><thead><tr><th width="149">Label</th><th width="86.20001220703125">Action</th><th>Description / Example</th></tr></thead><tbody><tr><td><strong>Search</strong></td><td>Filter</td><td>Allows users to filter ZTP events based on selected columns and conditions (in, not in, equal, not equal, contains).<strong>Fields:</strong> Track ID, Syslog, DHCP Server ID, Status, Device IP Address, Reference Key, and State.</td></tr><tr><td><strong>Track ID</strong></td><td>View</td><td>Unique identifier generated for each ZTP syslog event. Used to trace the full ZTP workflow across stages.<br><br><strong>Example:</strong> 257ea3f5b77c49b...</td></tr><tr><td><strong>Syslog</strong></td><td>View</td><td>Displays the raw syslog message received from the DHCP server, including DHCPACK details.<br><br><strong>Example:</strong> DHCPACK on 192.168.50.14 to bd:f8:f2:0d:c5:cf via 10.0.4.1</td></tr><tr><td><strong>Received Time</strong></td><td>View</td><td>Timestamp indicating when the syslog was received by the data collector.<br><br><strong>Example:</strong> Oct 30, 2025 03:42 PM</td></tr><tr><td><strong>DHCP Server IP</strong></td><td>View</td><td>IP address of the DHCP server from which the syslog was received.<br><br><strong>Example:</strong> 10.0.4.88</td></tr><tr><td><strong>Data Collector</strong></td><td>View</td><td>Shows the data collector (agent) that ingested the syslog event.<br><br><strong>Example:</strong> Test – 10.0.4.88</td></tr><tr><td><strong>State</strong></td><td>View</td><td>Represents the high-level execution state of the ZTP process.<br><br><strong>Example:</strong> Not Started, Completed</td></tr><tr><td><strong>Status</strong></td><td>View</td><td>Indicates the current processing stage of the ZTP workflow.<br><br><strong>Example:</strong> Sent To Event, Upload Job Created, Discovery Completed</td></tr><tr><td><strong>Device IP Address</strong></td><td>View</td><td>IP address assigned to the device through ZTP DHCP process.<br><br><strong>Example:</strong> 192.168.50.14</td></tr><tr><td>Reference Key</td><td>View</td><td>Device identifier (typically MAC address) used to correlate the ZTP event.<br><br><strong>Example:</strong> bd:f8:f2:0d:c5:cf</td></tr><tr><td>Last Update Time</td><td>View</td><td>Timestamp of the most recent status update for the ZTP event.<br><br><strong>Example:</strong> Oct 30, 2025 03:42 PM</td></tr><tr><td>Export</td><td>Action</td><td>Exports the ZTP Event Tracker data to an XLSX file for analysis or audit purposes.</td></tr><tr><td>Re-Initiate</td><td>Action</td><td>Re-triggers the ZTP process from the beginning for the selected event, subject to permissions and status conditions.<br><br><strong>Example:</strong> Restart ZTP when the process stops due to an error or exceeds the configured delta time.</td></tr></tbody></table>

### **ZTP Syslog Re-Trigger**

The **Re-Initiate** action allows authorized users to manually restart the ZTP workflow for a selected syslog event when reprocessing is required.

**Availability**

* Visible only to users with **Edit permission** for the ZTP license.
* Not available when the status is **Upload Job Created** or **Download Job Already Exist**.

**When It Is Enabled**

* The ZTP process stopped due to an error.
* The **Last Update Time** exceeds the configured delta interval (ZTP\_RE\_TRIGGER\_DELTA\_INTERVAL).
* The event is in an intermediate or failed state.

**Execution**

* Clicking **Re-Initiate** opens a confirmation dialog.
* On confirmation, the ZTP process restarts from the beginning.
* Each action is captured in the audit log.

#### **How It Works**

When a ZTP-related syslog is received, the system tracks its progress through each processing stage. If the workflow fails or becomes inactive beyond the configured threshold, the **Re-Initiate** option becomes available.

Triggering this action re-queues the event and restarts the ZTP process from the initial stage, enabling recovery without waiting for a new syslog.