Centralize Linux logs by forwarding selected messages from each source server with rsyslog to a Telegraf syslog listener on one VPS. Telegraf parses the stream and writes records to InfluxDB, while Grafana connects to InfluxDB and displays timestamped log rows, filters and dashboards. The practical pipeline is rsyslog → Telegraf syslog input → InfluxDB → Grafana.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
This design is a good fit when you already operate Telegraf and InfluxDB for metrics and your log volume is modest. It supports UDP, TCP, TLS and Unix-socket ingestion, but TCP or TLS is usually the safer choice for logs crossing a network. Keep Grafana and InfluxDB administration interfaces private, expose only the collector port required by your source hosts, and model fields carefully so high-cardinality message text does not make the database expensive to query.
As an Amazon Associate I earn from qualifying purchases.
What the centralized logging stack does
Every Linux machine writes local events through its syslog facility. Rsyslog can select those events by facility and severity, format them as RFC5424 messages, and forward them to the VPS. Telegraf receives the stream through its inputs.syslog plugin, extracts fields such as the timestamp, hostname, application name, facility, severity, message ID and message text, and sends the resulting records through an InfluxDB output plugin.
Grafana does not read the source servers directly. It queries the InfluxDB measurement that contains the log records. A result with a timestamp column and a message column can be rendered as a Logs view; level, host and application columns provide context for each row.
#1 Best Overall
Linux host A ─┐
Linux host B ─┼─ rsyslog ── TCP or TLS ── Telegraf ── InfluxDB ── Grafana
Linux host C ─┘Grafana’s published syslog dashboard pattern uses classic syslog reception on UDP/514 and forwards RFC5424-formatted messages to Telegraf on TCP/6514. You do not need to reproduce that exact topology if each source host can forward directly to the Telegraf listener. Telegraf’s syslog service supports Unix-domain sockets, UDP, TCP and TLS; when no port is specified, its documented TCP default is 6514.
Plan the VPS before installing anything
Choose the collector’s network boundary
Give the VPS a private address reachable from the source machines whenever possible. If sources are on separate networks, publish only the syslog listener through a firewall or VPN. Do not expose Grafana’s web interface or InfluxDB’s API to the entire internet merely because the collector must be reachable.
Recommended Free Tools
- Allow the chosen syslog port only from the known source IP ranges.
- Allow Grafana administration from your management network, VPN or a reverse proxy with authentication.
- Bind InfluxDB’s management and query interface to a private address unless remote access is explicitly required.
- Use TLS for forwarding over an untrusted network; plain UDP and plain TCP provide no confidentiality.
Estimate storage from your workload
Exact CPU, RAM, disk and retention values depend on message rate, average message size, indexes, dashboard queries and the retention period. There is no universal VPS size that is correct for every installation. Start with a known observation period, measure the resulting disk growth, and set retention to match the capacity you can actually monitor and back up.
Decide which InfluxDB API you will use
InfluxDB 2.x configurations normally use a URL, organization, bucket and token. InfluxDB 1.x-style configurations use a database and often a username and password. Telegraf supports the corresponding output plugins; select the one that matches the server you installed and do not accidentally point a 1.x configuration at a 2.x bucket endpoint.
Install and lock down the three services
Install InfluxDB, Telegraf and Grafana using the packages and service instructions for your Linux distribution and the versions you have selected. Avoid mixing repositories intended for a different distribution release. After installation, verify that each daemon starts under systemd and that the host firewall is enabled before opening the collector port.
- Initialize InfluxDB and create the organization and bucket, or create the database and credentials if you are using the 1.x API.
- Create a Telegraf service account or token with permission to write to the selected destination. Give it no broader permissions than necessary.
- Install Grafana and keep its listening address restricted to your administration network or protected proxy.
- Open the Telegraf syslog port only after the listener configuration has been tested locally.
Telegraf requires both sides of the pipeline: its configuration must enable at least one input plugin to collect data and one output plugin to write data. A collector with only inputs.syslog will accept messages but cannot persist them; a collector with only an InfluxDB output has nothing to send.
Configure Telegraf as the central syslog listener
Create the input and output
Place the following pattern in a Telegraf configuration file, adapting the URL, organization, bucket and secret names to your deployment. The example uses TCP with octet-counting framing, which is appropriate when the sender is configured for RFC5424 over a stream connection.
[[inputs.syslog]]
server = "tcp://:6514"
framing = "octet-counting"
[[outputs.influxdb_v2]]
urls = ["http://127.0.0.1:8086"]
token = "${INFLUX_TOKEN}"
organization = "example-org"
bucket = "system-logs"If your InfluxDB installation uses the older database API, use the matching output block instead:
[[outputs.influxdb]]
urls = ["http://127.0.0.1:8086"]
database = "syslog"
username = "${INFLUX_USERNAME}"
password = "${INFLUX_PASSWORD}"Do not enable both output blocks unless you intentionally want every event written twice. The exact measurement name and field set are determined by the Telegraf syslog parser and your configuration. Inspect a sample write before building Grafana queries instead of assuming a schema.
Use environment variables or a secret store
Keep tokens and passwords out of a world-readable configuration file. Telegraf’s guidance recommends environment variables or a secret store. A systemd environment file can provide INFLUX_TOKEN, INFLUX_USERNAME and INFLUX_PASSWORD with restrictive permissions; the service configuration then references those variables. Ensure the service manager actually imports the file, and restart Telegraf after changing a secret.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchEnable TLS when required
Telegraf’s syslog input supports TLS. Configure a TLS listener with a certificate and private key, and configure rsyslog’s forwarding action to validate the collector certificate. Use a private certificate authority or a publicly trusted certificate appropriate to the network. Test certificate hostname matching, trust-chain availability and expiration monitoring before switching production senders.
Validate the configuration and service
- Run Telegraf’s configuration test using the distribution’s Telegraf binary and confirm that both the syslog input and InfluxDB output load without errors.
- Start or restart the service with systemd.
- Review the service journal for bind failures, authentication errors, TLS errors and rejected writes.
- Confirm that the listener is bound to the intended address and port, not accidentally exposed on every interface.
A successful socket bind proves only that Telegraf is listening. It does not prove that messages parse correctly or that InfluxDB accepts the writes, so continue with an end-to-end test from a source host.
Forward Linux messages with rsyslog
Start with a narrow rule
Forward only the facilities and severities you need. Sending every debug message from every daemon can overwhelm a small VPS and make important events harder to find. A typical first pass includes authentication, kernel, daemon, user and system messages at informational severity or higher, while excluding noisy facilities that you already collect elsewhere.
Use rsyslog’s TCP forwarding action and the RFC5424 template expected by the collector. A representative action block is:
action(
type="omfwd"
target="LOG_VPS_ADDRESS"
port="6514"
protocol="tcp"
template="RSYSLOG_SyslogProtocol23Format"
queue.type="linkedList"
action.resumeRetryCount="-1"
)Attach the action to the selectors you chose in the host’s rsyslog configuration. The target value above is an example name, not a literal hostname; replace it with the collector’s resolvable address. If you use UDP, change the transport deliberately and accept that packets can be lost or reordered. For logs crossing an untrusted network, use rsyslog’s TLS forwarding support and match its framing and certificate settings to Telegraf.
Preserve delivery during outages
The linked-list queue in the example lets rsyslog queue messages while the collector is temporarily unavailable. Set queue limits that fit the source host’s disk and outage tolerance. A queue that is unlimited in practice can consume the source server’s filesystem during a prolonged outage, while a queue that is too small silently discards older messages when full.
Reload safely and generate a test event
- Check the rsyslog configuration with the validation command supplied by your distribution before reloading it.
- Reload or restart rsyslog only after the syntax check succeeds.
- Generate a distinctive test message with the host’s local logger utility, using a facility and severity included by your rule.
- Watch the Telegraf journal and query InfluxDB for that message during the current time range.
Once one source works, add additional hosts incrementally. Keep a record of each source IP so the VPS firewall and Grafana filters remain understandable.
Design an InfluxDB schema that stays queryable
Keep event data in fields
Store the message body, message ID and other values that can vary on every event as fields. Turning unique message text into a tag creates an unbounded tag set, increases index work and makes retention more expensive. Preserve the original timestamp as the event time rather than replacing it with ingestion time.
Use stable dimensions as tags
Host, severity, facility and application name are generally useful dimensions because their value sets are relatively small and support filtering. Decide whether an attribute is stable enough to be a tag before deployment; a user ID, request ID, URL or stack trace usually is not.
| Attribute | Recommended role | Reason |
|---|---|---|
| Event timestamp | Time column | Required for time-range queries and log ordering. |
| Message text | Field | Often unique or high-cardinality; keep it out of the tag index. |
| Host | Tag or indexed dimension | Useful for selecting one machine or a group. |
| Severity | Tag or indexed dimension | Supports filtering for errors, warnings and informational events. |
| Facility | Tag or indexed dimension | Separates kernel, auth, daemon and other syslog sources. |
| Application name | Tag when bounded | Useful when the set of services is controlled. |
| Message ID | Field unless tightly bounded | Preserve it for diagnosis without creating unnecessary series. |
The parser’s exact field names can vary with its version and input options. Use an actual record to confirm capitalization and names before writing permanent dashboards.
Connect Grafana and render log rows
Add InfluxDB as a data source
- Sign in to Grafana with an administrator account.
- Open Connections, choose Data sources, and select Add new data source.
- Choose the InfluxDB data source plugin.
- Enter the private InfluxDB URL and select the query language that matches your server and bucket or database configuration.
- Provide the organization, bucket and token for an InfluxDB 2.x endpoint, or the database and credentials for a 1.x-style endpoint.
- Save and test the data source, then correct URL, network, authentication or TLS errors before creating panels.
Build the first query in Explore
Open Explore, select the new InfluxDB source and restrict the time picker to a period in which you generated a test message. The query must return a timestamp and a message column for Grafana’s log renderer. Include host, severity, facility and application columns when they exist.
For an InfluxQL-style source, the logical shape is:
SELECT "message", "severity", "host", "facility"
FROM "syslog"
WHERE time > now() - 1hFor a Flux-style source, select the bucket, measurement and time range, then keep the event time and message fields in the returned table. Replace the measurement and field names after inspecting your first Telegraf write; do not assume that every installation calls the measurement syslog.
Format the result as logs
In the query editor or visualization settings, choose the Logs result format when available. Grafana identifies the timestamp and message columns and uses the other returned columns as context. If rows appear as a table instead, verify that the timestamp is a real time value, the message column contains strings, and the query is not aggregating events into a single numeric result.
Best Value
Create useful filters
- Use a dashboard variable for host when operators regularly switch between machines.
- Add severity and facility filters for incident triage.
- Keep the default time range short enough that a broad query does not scan the entire retention period.
- Add a panel showing ingestion or write errors separately from the log rows, so a quiet dashboard is not mistaken for a healthy system.
Operate the collector after the first successful query
Monitor all three failure points
There are three independent stages to observe: rsyslog delivery, Telegraf parsing and output, and InfluxDB storage or Grafana querying. A source can report successful local logging while its forwarding queue is blocked. Telegraf can accept a connection while rejecting malformed messages. InfluxDB can contain records while Grafana uses the wrong bucket, measurement or time zone.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute- Review rsyslog queue depth, connection retries and discarded-message counters on source hosts.
- Review Telegraf input, parser and output errors in its systemd journal.
- Monitor InfluxDB write failures, disk usage and retention activity.
- Check Grafana data-source health and test a known host and time range after upgrades.
Set retention intentionally
Choose retention from the questions you need to answer: short operational troubleshooting, multi-week incident review or long-term audit. Apply the policy at the InfluxDB bucket or database level and verify that expired records are actually removed. Keep a separate export or archive only if your compliance requirements demand it; do not assume that a long live-retention period is a backup.
Protect time and identity information
Synchronize clocks on source hosts and the VPS. Log rows ordered by inconsistent clocks can make an incident appear to happen in the wrong sequence. Preserve the original host and application identity so an event remains attributable after it leaves the source machine. Restrict Grafana users to the data sources and dashboards they need, and rotate tokens and certificates on a schedule.
Back up configuration, not just data
Keep versioned copies of rsyslog rules, Telegraf configuration, Grafana provisioning and dashboard definitions. Store secrets outside that repository. A database backup without the parser and forwarding configuration may restore records but leave you unable to ingest new events or interpret their fields.
Troubleshoot the common failure modes
| Symptom | Likely cause | Checks and fix |
|---|---|---|
| No records from any host | Firewall, wrong bind address or stopped listener | Check the Telegraf service, listening socket and VPS firewall. Test connectivity from an allowed source IP. |
| One host is missing | Rsyslog selector, DNS, route or source firewall | Generate a local test event, inspect the rsyslog queue and verify that the host reaches the collector address and port. |
| TCP connects but records are rejected | Framing or syslog-format mismatch | Make rsyslog’s RFC5424 template and Telegraf’s framing setting agree. Review parser errors in the Telegraf journal. |
| TLS handshake fails | Untrusted CA, expired certificate or hostname mismatch | Check certificate validity, trust-chain installation, server name and the TLS settings on both ends. |
| Grafana says no data | Wrong bucket, database, measurement, time range or credentials | Test the data source, query a period containing a known message and inspect the actual measurement and field names. |
| Rows have no usable message text | Message field omitted or mapped differently | Inspect a raw Telegraf record and adjust the query to the parser’s actual message column. |
| Queries become slow as hosts grow | High-cardinality tags or overly broad time ranges | Move unique values such as full message text and request IDs to fields, then constrain queries by time and stable tags. |
| Source disk fills during an outage | Forwarding queue retained too many events | Set bounded queue behavior, alert on queue depth and decide which events may be dropped during an extended outage. |
InfluxDB or Loki for centralized logs?
InfluxDB is reasonable when the VPS already uses Telegraf and InfluxDB for metrics, the event volume is modest and operators benefit from one query and retention system. Loki is a log-focused alternative when label-based log storage and querying matter more than reusing an existing metrics database.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →| Decision axis | InfluxDB with Telegraf | Loki-based stack |
|---|---|---|
| Existing platform | Extends a Telegraf and InfluxDB metrics installation. | Introduces a dedicated log storage and query path. |
| Collection and transport | Telegraf accepts Unix sockets, UDP, TCP and TLS syslog input. | A collector such as Alloy gathers logs and sends them to Loki. |
| Data model | Fields and stable tags must be designed to control cardinality. | Labels identify streams; the system does not index full log contents like a traditional full-text engine. |
| Best query fit | Structured, time-bounded queries that combine logs with existing InfluxDB data. | Log exploration centered on labels and log-specific workflows. |
| Operational complexity | Lower if InfluxDB, Telegraf and Grafana are already maintained. | Additional log-specific components and retention policies to operate. |
| Primary trade-off | Convenient reuse, but schema and cardinality choices affect cost and speed. | Purpose-built log workflow, but it is a separate storage system to learn and maintain. |
Choose based on expected volume, retention, search behavior, label cardinality, transport and security requirements, and the tools your team already knows. Do not choose solely because one product has a familiar dashboard: the collector, storage policy and query model determine the operational result.
Quick Recap
A production-readiness checklist
- Every source forwards only the facilities and severities that are useful for the stated retention period.
- The VPS firewall allows the collector only from approved source addresses.
- TLS protects logs whenever they traverse an untrusted network.
- Grafana and InfluxDB administration endpoints are private or strongly access-controlled.
- Telegraf has at least one working input and one working InfluxDB output.
- Credentials come from environment variables or a secret store, not plain shared configuration.
- Timestamp, message, host, severity, facility and application fields are preserved where available.
- Unique message text and request identifiers are not used as unbounded tags.
- A known test event can be traced from rsyslog to Telegraf, InfluxDB and Grafana.
- Retention, disk growth, queue depth, parser errors and write failures have alerts or routine checks.
- Configuration and dashboard definitions are backed up, while secrets are stored separately.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
