Forwarding events to a remote syslog server

Overview

VoIP Detective can forward its internal event log to a remote syslog server. This lets your operations team see VoIP Detective events alongside other infrastructure logs in whatever central log platform they already use — Splunk, Graylog, Datadog, Grafana Loki, rsyslog, syslog-ng, or any other RFC 3164 / RFC 5424 compatible receiver.

This article walks through the configuration, testing, and troubleshooting steps for enabling syslog forwarding. It is intended for VoIP Detective administrators who need to point VoIP Detective at a syslog server that someone else has already set up.

Who can configure this: Administrators (Group 2) only. The Syslog section appears on the Administration → Configuration page.

Required 

Before you change any settings, confirm these details with whoever operates the receiving syslog server:

• Hostname or IP address of the receiving server. Hostnames are preferred — they survive re-numbering.
• Port. Default is 514 for UDP and TCP, 6514 for TLS. Some modern platforms use 1514 or other custom ports.
• Transport protocol — UDP, TCP, or TLS.
• Message format — RFC 3164 (legacy) or RFC 5424 (modern). If unsure, start with RFC 3164; it is the most widely supported.
• Facility they want the messages tagged with. local0 through local7 (facility numbers 16–23) are the usual choices for application software. The VoIP Detective default is local0.
• Severity threshold. Whether they want only warnings and errors, or also notice-level audit events (configuration changes, scheduled job completions).

Configuring the syslog section

The syslog settings are on the Administration → Configuration page. Use the in-page dropdown navigation or scroll to the Syslog section.

Recommended workflow

1. Leave the master Enable Syslog Forwarding toggle at Disabled while you fill in the other fields. Changes to the other fields take effect immediately, but nothing is sent until forwarding is enabled.
2. Enter the Host, Port, Protocol, Format, Facility, and Minimum Severity values from the receiving team.
3. Review the Categories to Forward list and enable the subsystems you want. See the Categories section below for details on defaults.
4. Set the master Enable Syslog Forwarding toggle to Enabled.
5. Click the Test Syslog Server button in the Syslog section header.
6. Confirm with the receiving team that the test message arrived.

Settings reference

Categories to forward

Below the general settings is a list of checkboxes — one per VoIP Detective subsystem. Each subsystem can be independently enabled or disabled for syslog forwarding.

Understanding severity

Every syslog message carries a severity level from 0 (most urgent) to 7 (routine noise). The Minimum Severity setting is a cutoff: if you set it to 4 (Warning), only messages at severity 0, 1, 2, 3, or 4 are forwarded. Anything at severity 5, 6, or 7 is filtered locally and never sent.

Testing the configuration

The Syslog section header includes a Test Syslog Server button. Click it at any time to verify your settings. The test opens a modal showing exactly what was checked and what happened.

The test performs these checks in order:

• Confirms syslog forwarding is enabled (warning only — the test still runs if disabled).
• Confirms a host is configured.
• Resolves the hostname to an IP address (skipped if the host is already an IP).
• Opens a UDP, TCP, or TLS connection to the host and port.
• Sends a single test message in the configured format with the configured facility.
• Writes the complete test result to the local error log at severity Notice as an audit trail.

Reading the result

The modal always starts with a Configuration summary of the settings the test actually ran with. Check those first — a common mistake is running the test before saving a setting change.

Below the configuration summary, each check appears with a green check, yellow warning, or red X, followed by a summary banner at the bottom — green for all passed, yellow for passed with warnings, red for failures.

Troubleshooting

No messages are arriving

In order of likelihood:

1. The master toggle is disabled. Confirm Enable Syslog Forwarding is set to Enabled.
2. The relevant category is disabled. Confirm the subsystem you are expecting messages from is enabled. Remember that cron, report, and import are disabled by default.
3. The minimum severity filter is too strict. If it is set to 4 (Warning), routine notice-level events are filtered out. Temporarily set it to 6 (Informational) to see everything during testing.
4. Port or host is wrong. Run the Test Syslog Server button and carefully check the configuration summary at the top of the modal.
5. A firewall is dropping packets. Especially common with UDP — the sender never knows. Work with your network team to verify packets reach the receiver.
6. Format mismatch. If the receiver expects RFC 5424 and you are sending RFC 3164 (or vice versa), some receivers silently drop non-conforming packets. Confirm the expected format with the receiving team.

Fewer messages than expected

Most commonly this is a category or severity filter rather than a transport problem.

• Check the local log files. The files in Administration -> Logs receive every log event regardless of the syslog filter. If the local file is sparse, the application is simply quiet during the period you are looking at. If the local file is busy and only a fraction reaches syslog, a filter is the cause.
• Compare counts. If the local file has 200 entries in the last hour and syslog received 3, you are filtering out 98% — most likely by disabled category or too-strict severity.

Duplicate messages

VoIP Detective never sends the same message twice. If the receiving team sees duplicates, another sender is also shipping VoIP Detective's local log files — typically a file-based log agent running on the same server. Disable one of the two paths, typically the file-based agent, since VoIP Detective's direct syslog path carries more structured metadata.

Wrong timestamps

If timestamps appear off by hours, the cause is usually RFC 3164's lack of timezone information. Switch Message Format to RFC 5424, which includes full timezone data in every message. Alternatively, confirm the Vd Timezone setting on the Configuration page matches the system timezone of the application server.

Viewing the test audit trail

Every time you run the Test Syslog Server button, the complete result is written to the local error log at severity Notice. 

Tips & Frequently Asked Questions

What happens during a receiving server outage?

VoIP Detective does not buffer messages for later retry. Events that occur while the remote server is unreachable are written to the local log files but are not retroactively sent when the server comes back. If lossless delivery matters for compliance, have the receiving team ingest the local log files directly with a file-based collector running on the VoIP Detective server.

Do I need to restart anything after changing a setting?

No. All syslog settings take effect on the next log event. There is no restart needed and no risk of lost messages during a settings change.

Does enabling syslog forwarding slow down VoIP Detective?

No measurable impact. Syslog messages are sent asynchronously with short timeouts, and failures on the remote side are handled silently — they will never block application activity.

Can I use a hostname that only resolves via /etc/hosts?

Yes. The hostname is resolved at send time using the system resolver, so anything resolvable from the VoIP Detective server will work — DNS, /etc/hosts, or a combination.

Which format should I use — RFC 3164 or RFC 5424?

If the receiving platform is modern (built in the last 10 years: Splunk, Graylog, Datadog, Grafana Loki, etc.) use RFC 5424 — it includes year and timezone in every timestamp, which avoids several classes of problem. If the receiver is a legacy appliance or you are not sure, start with RFC 3164. You can switch at any time.

Can I forward to multiple syslog servers?

VoIP Detective supports one remote syslog server. If your operations team needs the same events to reach multiple destinations, the usual pattern is to forward to a local aggregator (such as rsyslog) on the VoIP Detective server, and have that aggregator fan out to multiple downstream servers.

What does the application name on the wire look like?

Messages appear with an application name of "voipdetective" plus the subsystem — for example "voipdetective-error", "voipdetective-cucm", "voipdetective-webex". This lets your operations team filter and route by subsystem without parsing the message body.

Quick-Start Checklist

1. Get Host, Port, Protocol, Format, Facility, and Severity threshold from the receiving team.
2. Confirm firewall rules permit traffic from the VoIP Detective server to the receiving server on the chosen port.
3. Go to Administration → Configuration → Syslog.
4. Enter all values from step 1 while Enable Syslog Forwarding is still Disabled.
5. In Categories to Forward, enable the subsystems you want — remember cron, report, and import are off by default.
6. Set Enable Syslog Forwarding to Enabled.
7. Click Test Syslog Server. Review the modal.
8. Confirm with the receiving team that the test message arrived (especially important for UDP).