Migration / Monitoring

Migrating PRTG Network Device Monitoring Definitions to
Zabbix Using Claude Code [Continued] #

Following the previous UPS edition, this time we migrated an environment with a mix of switches, routers, and wireless APs. Taking advantage of the consistency of all devices being from the same vendor, we proceeded with a safe approach: “register first, enable later.”

Claude Code PRTG Zabbix SNMP Python

Differences from Last Time (UPS Edition) #

Last time, all devices were APC UPS units in a uniform configuration, so applying a single template type was sufficient. This time, the target is a 2023 backup containing a mix of switches, routers, and wireless APs.

Last Time (UPS Edition)

All APC UPS #

One template type, immediate activation.
Completed in 30 minutes.

This Time (Network Device Edition)

3 Categories Mixed #

Classified into switches, routers, and APs.
Adopted a procedure to enable after SNMP connectivity verification.

The fact that all devices were from the same vendor was a strength this time. With a unified vendor, template selection was straightforward without confusion.

Migration Targets This Time #

After analyzing the 2023 PRTG backup (PRTG Configuration.dat), we identified the following 11 network devices for migration.

Switches (5 units)

Major Domestic Network Vendor #

1 core switch, 4 L2 switches.
All units were unified under the same vendor.

Routers (2 units)

Edge Routers × 2 #

Primary-secondary configuration.
Syslog sensors were also configured in PRTG.

Wireless APs (4 units)

Enterprise Wireless APs × 4 #

Distributed across each floor and location.
All units are the same model.

Sensor Configuration in PRTG

Mostly Ping Only #

44 sensors ÷ 28 units ≈ 1.5 per unit.
SNMP monitoring was not configured for many units.

Since the PRTG sensors were mostly Ping only, it was unclear whether SNMP connectivity would work. Therefore, we adopted this approach: “register in Zabbix first with monitoring disabled, then enable individually after SNMP connectivity verification.”

Preparation: Adding Static Routes to the Zabbix Server #

The target devices this time reside in a dedicated monitoring segment (hereafter referred to as x.x.x.0/24). Since there was no route from the Zabbix server to this segment, we added a static route before the migration work.

Key Point: Do not use nmcli connection up.
For adding static routes, use nmcli connection modify and ip route add together. Running nmcli connection up temporarily disconnects the interface, which should be avoided in production environments.

# Make permanent (survives reboot)
nmcli connection modify 'System eth1' +ipv4.routes 'x.x.x.0/24 x.x.x.1'

# Immediate effect (current session only)
ip route add x.x.x.0/24 via x.x.x.1 dev eth1

Instructions Given to Claude Code #

This time, learning from the UPS episode, I incorporated a step into the instructions that ensures a pause for template mapping confirmation. In the UPS episode, alerts falsely fired due to voltage threshold differences, but this time the aim is to prevent that issue through advance verification.

I need you to analyze the PRTG backup and migrate network devices to Zabbix.
This environment contains a mix of switches, routers, and APs.

STEP 1: Parse XML. Classify devices into switch / router / ap / other and output to CSV.
STEP 2: Retrieve template list with template.get, create a mapping table, and get confirmation.
        Do NOT proceed to STEP 3 until I respond with "OK".
STEP 3: Create host groups and register by category.
        ※ Register all devices as Disabled (monitoring disabled). Enable individually after SNMP connectivity check.
STEP 4: Output a differential verification report.

STEP 2 Mapping Confirmation #

Based on the template list retrieved via Zabbix API, Claude Code proposed the following mapping. Since all devices are from the same vendor, switches, routers, and APs could all use the same template without issue.

switch  → Network Generic Device by SNMP (templateid=10226)
router  → Network Generic Device by SNMP (templateid=10226)
ap      → Network Generic Device by SNMP (templateid=10226)

Interface: SNMP v2c / community=public / port=161
Registration status: Disabled (all devices · enable after connectivity verification)

Registration Results #

Devices Registered

All 11 Devices Successful #

Zero errors.
All devices registered in Disabled state.

Host Groups Created

3 Groups #

Migrated-NW-Switch
Migrated-NW-Router
Migrated-NW-AP

Registration Breakdown by Category #

Switches (5 devices)

1 core switch
4 L2 switches (PoE-enabled)

Routers (2 devices) · APs (4 devices)

2 edge routers (primary · secondary)
4 enterprise wireless APs (per site)

Comparison with UPS Episode: What Was Different #

✅ What Stayed the Same

Direct parsing of backup XML (no server required)
Claude Code automates from script generation to execution
Automatic application of host groups · templates
Output differential report after registration

📋 What Was Added This Time

Classify and register devices by category
Template mapping confirmation step (pause)
Register all devices as Disabled (enable after connectivity check)
Add static routes in advance

Key Points: Syslog Sensors and SNMP Connectivity #

Some routers had Syslog sensors configured in PRTG.
If you want to receive Syslog in Zabbix as well, separate Zabbix Syslog reception configuration will be required. This time, we only performed registration and postponed Syslog configuration as remaining work.

Disabled registration was the right choice.
The fact that PRTG sensors were mostly Ping-only suggests that SNMP configuration on the device side may be unconfirmed or not configured. Before enabling monitoring, we recommend checking snmp-server enable and verifying community string configuration on the device side.

Pre-Activation Checklist #

Is the SNMP agent enabled on the device side (snmp-server enable)?
Verify that the community string is configured (does it match with the Zabbix side)?
Can Zabbix server communicate with the target device on UDP/161?
Verify that snmpwalk from Zabbix actually returns a response

Current Status and Remaining Work #

Completed

Registration in Zabbix #

All 11 devices registered in Disabled state.
Host groups and templates also applied.

Remaining Work

SNMP Connectivity Check → Activation #

After confirming SNMP configuration on device side,
monitoring will be enabled individually for each device.

Improvements from the UPS Chapter #

Always confirm templates before applying them
In the UPS chapter, alerts falsely triggered due to voltage threshold differences. This time, we designed it to always pause at STEP 2 and have a human confirm the mapping table before proceeding.
Register devices without connectivity as Disabled
Looking at the PRTG sensor configuration, many devices did not have SNMP configured. The procedure of “registering first and confirming later” without immediate activation is safer.
Include pre-environment checks in the prompt
By writing necessary environment preparation such as adding static routes at the beginning of the prompt before running the migration script, Claude Code will suggest confirmation steps.
Clearly specify category classification rules
When inferring categories from device names, listing specific naming conventions (prefixes/suffixes) improves classification accuracy.

Next Steps #

Once SNMP connectivity checks for the registered 11 devices are complete, we will enable monitoring sequentially. We are also considering adding Syslog reception configuration for some routers.

Even for devices where PRTG sensors were mostly Ping-only, by utilizing Zabbix templates, we can monitor CPU usage, interface traffic, memory usage, and more at no additional cost. Migration is not the goal, but the starting line for improving monitoring quality.

We tried migrating PRTG network device monitoring definitions to Zabbix using Claude Code [Continued]