[Nebula 19.10] New AP System Log Prefix for Easier Multi-Site Log Management

Zyxel_Lynn

Nebula 19.10 addresses a significant challenge faced by managed service providers (MSPs) and enterprises operating multiple Nebula sites with centralized syslog servers through the introduction of a new AP System Log Prefix feature.

The Challenge with Multi-Site Syslog

The core problem stems from the difficulty of identifying the origin of log messages when device names are duplicated across different sites, which is a common occurrence in large-scale deployments where multiple locations may have identically named devices such as “AP01” in both Site A and Site B. Without additional identifiers, administrators struggle to determine which site generated specific log entries, and the traditional solution of manually adding site names to every device hostname becomes time-consuming and impractical for extensive deployments.

The New AP System Log Prefix

The new AP System Log Prefix functionality provides an elegant solution by allowing administrators to add a custom unique identifier that applies to all APs within a site. This identifier is automatically incorporated into the Process ID field of every syslog message transmitted by those access points, enabling easy filtering and sorting of logs by site within syslog server environments. The prefix appears in the standard syslog message format where the ProcessID field contains the custom prefix, following the structure of Priority, Timestamp, Hostname, ProcessID, and Message components.

How to Configure

Configuration of this feature is straightforward and accessible through the Site Settings page under Site-Wide section in NCC. Within the Syslog Server section, administrators can locate the AP Syslog Prefix field and enter their desired identifier, which supports up to 31 characters including letters, numbers, and symbols, though spaces are not permitted. For example, entering "ZyCamp2025" as a prefix results in every AP in the site tagging its syslog messages with this identifier in the Process ID field, creating clear site-based identification.

Example Output

The practical implementation can be observed in network analysis tools like Wireshark, where a typical message might appear as "<134>2025-08-13T14:25:17Z AP01 ZyCamp2025: [log message here]", and in syslog servers where the components are clearly separated into Priority (<134>), Timestamp (2025-08-13T14:25:17Z), Hostname (AP01), Process ID (ZyCamp2025), and the actual log message content. This feature is specifically designed for cloud-managed APs and does not extend to standalone or controller-managed access points, making it particularly valuable for centralized syslog environments managing numerous sites.

In sum, the significance of this enhancement for MSPs and enterprise IT teams cannot be overstated, as it eliminates the guesswork traditionally associated with interpreting syslog data from multiple sites, enables rapid filtering by site within syslog analysis tools, and substantially reduces the manual configuration workload that previously required individual device hostname modifications. This improvement streamlines log management processes and enhances troubleshooting efficiency across complex multi-site network infrastructures.