To monitor CPU and memory for a nonstop YouTube stream on Hetzner Cloud, collect metrics inside the Linux server with Node Exporter, scrape them with Prometheus, and view current values and trends in Grafana. Hetzner’s Prometheus/Grafana app image can reduce setup work, but its components need to be activated after boot.
The useful question is not whether CPU or memory has crossed a universal “safe” percentage. There is no single threshold that proves a stream is healthy; instead, establish what is normal for your stream, spot sustained changes, and check those changes against the streaming service and YouTube ingest status.
What CPU and memory monitoring can reveal
Hetzner Cloud’s provider-level graphs and metrics collected inside your guest operating system answer different questions. Guest-level monitoring shows how the operating system and processes are using resources. That matters when you need to know whether an encoder, relay, playlist process, or another workload is consuming CPU or memory while the stream runs.
Node Exporter exposes hardware and kernel metrics from the host. Prometheus periodically requests those metrics over HTTP and stores samples; Grafana queries that stored data to display it. Together, these components let you look beyond a momentary screenshot and ask whether resource use changed just before a service restarted or a stream stalled. See the Prometheus guide to monitoring Linux host metrics with Node Exporter for the documented collection model and examples.
CPU metrics need interpretation over time. A value such as node_cpu_seconds_total is a cumulative counter of CPU time, not a current utilisation reading. Prometheus’s guide demonstrates using a rate(...) expression over a recent window to calculate a rate of change. This gives you a more useful graph than plotting the raw counter, which normally keeps increasing while the machine runs.
Memory is similarly more informative as a trend than as a single number. Observe available memory and, where the relevant collectors and metrics are present, swap use. A gradual decline during a long-running stream may be worth investigating; a brief variation on its own does not identify a fault. The operating system, workload, and other processes all affect what a reading means.
These system metrics cannot prove that YouTube is receiving a healthy live feed. A stream can have spare CPU and memory while its ingest connection, encoder output, or scheduled content has failed. Pair resource graphs with the status and logs of your own streaming process, and check the live event in YouTube Studio when diagnosing an interruption. If you are still choosing the way to run a loop, the practical considerations in choosing a 24/7 YouTube streaming service for a regional-language channel in India can help frame that separate decision.
Choose guest-level monitoring components
For a small setup, the baseline is one Node Exporter on the stream server, one Prometheus scraper, and Grafana for dashboards. You can put all three on a single server to minimise initial moving parts. Or you can run Prometheus and Grafana elsewhere and scrape the stream server over a private network. A separate monitoring host takes more configuration, but its graphs may remain available when the stream server itself is down.
| Approach | Setup considerations | Where to view the metrics | Suitable when |
|---|---|---|---|
| Hetzner Prometheus/Grafana app image | Packaged components reduce installation work, but require a post-boot activation step | On the app-image server by default | You want a starting point for one server and are comfortable managing the stack there |
| Install and configure components independently | You choose placement, configuration, and how monitoring covers other machines | On the host where you run Grafana; Prometheus can scrape remote targets | You already have monitoring or want to separate the scraper from the stream server |
The choice is about operational fit, not stream quality. A packaged single-server setup can be easier to get running, but if that server is unreachable, the monitoring interface on it may be unreachable too. Independent placement adds network and firewall work. It can be worthwhile if you already monitor several hosts or need an outside view of stream-server failure.
Node Exporter is intended to expose host metrics. If you run it in a container without suitable access to the host’s namespaces and filesystems, it may show the container’s view rather than the complete server. Decide whether the stream runs directly on Linux or in a container before interpreting the graphs. Do not assume a host-level dashboard describes an isolated container’s resource limits, or vice versa.
Deploy Node Exporter on the streaming server
First identify the distribution and how the stream process is launched. Commands and service management differ between operating systems, and package details can change. Follow the current Node Exporter installation guidance and your distribution’s package documentation rather than copying an old command blindly. The aim is to run the exporter as a managed service that starts again after a server reboot.
After installation, check that the exporter is running locally. Prometheus’s guide demonstrates checking the metrics endpoint; on a server where it listens on the local default address, a local request looks like this:
curl http://localhost:9100/metrics
A successful response should contain lines with metric names prefixed by node_. If the request fails, check service status and logs first, then confirm which address and port the exporter is configured to use. Do not open the endpoint to the public internet simply to make this test work. Keep it local for a same-server scraper, or restrict access to a known Prometheus host or private network.
Port 9100 is the commonly used exporter port in the cited setup examples. In a split-host design, allow inbound TCP 9100 on the stream server only from the Prometheus server’s address or the relevant private network. The firewall rule should match your actual network layout. Hetzner’s community tutorial describes a Debian-oriented installation and target-check flow, but it dates from 2021, so treat its package steps as historical guidance and confirm current commands for your distribution.
When Node Exporter runs in a container, review its configuration and host visibility carefully. A container can have a distinct view of process, filesystem, and network information. If you need to monitor the server as a whole, follow the exporter’s documented host-monitoring arrangement and restrict permissions to what that arrangement requires. Avoid exposing additional host access without understanding why it is needed.
Configure Prometheus scraping
Prometheus needs a scrape target: the address at which it can reach Node Exporter. If both run on the same machine and the exporter listens locally, the target can use localhost:9100. If they run on separate machines, use the stream server’s private address and make sure routing and firewall rules allow only the scraper to connect.
The Prometheus guide shows a configuration shaped like this:
scrape_configs:
- job_name: "node"
static_configs:
- targets: ["localhost:9100"]
Use the address that applies to your arrangement; localhost on a separate Prometheus server would refer to that server, not the stream host. Prometheus’s guide also uses a 15-second scrape interval in its example. Treat that as an example configuration, not a required interval for every nonstop stream. Choose a cadence appropriate to the operational detail you need and the storage you intend to retain.
After changing the configuration, reload or restart Prometheus using the method documented for your installation, then check its targets page. Confirm the Node Exporter target is reported as up and inspect any last error before relying on a dashboard. A graph with no data can indicate a query issue, but it can also mean that the scrape target is unreachable or the exporter is not running.
A scrape being up means Prometheus can collect metrics; it does not mean the stream is live. For a single server, test the scraper path locally first, then confirm the same target from Prometheus. For separate hosts, check firewall rules, private addressing, and the exporter’s listening address. Keep the metrics endpoint private throughout. The separate decisions involved in routing a live feed are covered in how to convert RTMP to HLS for live streaming, though that transport question is distinct from collecting host metrics.
Activate components in Hetzner’s app image if used
Hetzner provides a Prometheus/Grafana app image as a packaged starting point. Its documentation lists Prometheus, Grafana, Node Exporter, and other components as preinstalled, but it explicitly requires activation after the server boots. Do not assume that selecting the image means the services are already running. Follow the current Hetzner Prometheus/Grafana app-image documentation for the activation procedure and any current image-specific details.
You can provision the image through the Hetzner Console or API as described in that documentation. Once the server is ready, connect using the documented access procedure and activate the components. Do not copy credentials from examples or share real credentials in notes, dashboards, or support messages. Confirm each component’s service status after activation, and check that Prometheus can reach Node Exporter before opening Grafana to build panels.
The image is convenient when you want the pieces in one place and do not already maintain a monitoring stack. It also concentrates monitoring on the same server unless you configure it otherwise. Consider how you will inspect the graphs if the stream server becomes unavailable. If the server itself hosts the dashboard and scraper, the absence of access to that server can be part of the incident, so external checks or a separate monitoring host may still be useful.
An app image is not a substitute for understanding the network exposure of its web interfaces and metrics ports. Review the current Hetzner documentation and your firewall settings. Allow only the access you need, and do not make Prometheus, Grafana, or Node Exporter publicly reachable merely for convenience.
Build Grafana views for current values and trends
Start by adding Prometheus as Grafana’s data source using the address appropriate to where those services run. Then build a small dashboard around questions you can act on: is the scraper receiving samples, what is the CPU trend, is available memory changing over time, and is swap activity appearing? Add filesystem space and network activity as supporting context if they help explain a change. Node Exporter has many metrics, so verify names and labels against the metrics exposed by your installed version before relying on a query.
For CPU, use a rate expression rather than a raw cumulative counter. The Prometheus guide demonstrates an expression such as rate(node_cpu_seconds_total{mode="system"}[1m]). That example selects system CPU time; it is not a universal “CPU used” query for every dashboard. Decide whether you want to examine particular CPU modes, aggregate across cores, or compare idle time, and label the panel so its meaning is clear. The exact query depends on the metric labels and interpretation you choose.
For memory, plot available memory as a time series and include swap activity if the exporter exposes the relevant metrics. A current-value panel can help with a quick check, but it is the line over time that shows whether available memory is steadily falling or whether a reading was only a brief dip. Keep units visible, choose a useful time range for an overnight or multi-day stream, and annotate known changes such as a software update or a stream restart.
Include a panel for target availability or otherwise check Prometheus’s target status before trusting an empty graph. A blank panel may mean the query is wrong, the target is down, or the time range contains no samples. It is a different signal from a real reading of zero. Make the dashboard understandable enough that someone checking it during an overnight interruption can distinguish “no data” from “normal resource use”.
Dashboards work best when they are paired with basic operational notes: the stream service name, where its logs live, how to check its status, and how to reach YouTube Studio. If you are tuning a local encoder before moving work onto a server, YouTube Live’s recommended bitrate for 1440p prerecorded video addresses output settings; those settings do not replace server monitoring, but can help you separate encoder configuration from host-resource questions.
Investigate resource pressure in context
Begin by establishing a normal baseline while the stream is running in its usual configuration. Observe more than one period: startup, steady playback, and any scheduled changes in workload. Note the stream software and version, whether encoding happens on the server, and any other services running there. That context makes later comparisons useful; a reading has little value if you cannot tell what was happening at the time.
When a graph changes, compare the timing with stream-service logs and status. Check whether the service restarted, whether the process is consuming more resources than usual, and whether a content or configuration change coincided with the shift. A rising CPU rate may be a reason to investigate, but it does not by itself prove that the stream is unhealthy. Similarly, low available memory needs context from the full workload and trend, not a generic pass/fail number.
Set alerts around your own baseline and tests, not a supposed universal threshold for YouTube. Useful alert conditions can include the Prometheus target being down, exporter unavailability, sustained CPU pressure, a continuing decline in available memory, increasing swap activity, or the stream service failing. Treat these as conditions to investigate. A short spike may be expected during startup or a maintenance task, so duration and trend can help prevent an alert from reacting to every transient change.
If you do configure alert rules, record why each condition matters and how to respond. For example, a target-down notification asks you to check the exporter, Prometheus, and network path; a service-failure notification asks you to inspect the stream process and its logs. Resource alerts should prompt investigation before resizing. First look for a changed workload, a stuck process, a duplicate job, or a configuration issue. Resize only after you have evidence that the existing server cannot handle the intended workload.
Finally, check the end-to-end feed. A healthy host dashboard does not show whether frames are reaching YouTube, whether the live event is receiving input, or whether the correct content is playing. Use the stream application’s own status and YouTube’s current live controls alongside the system graphs. Monitoring can make diagnosis faster, but it cannot guarantee uninterrupted broadcasting or replace a way to notice stream failure.
If the recurring problem is that your personal computer must remain switched on to keep a file-based channel running, StreamNeo removes that particular dependency: you upload the video and the broadcast continues from the cloud while your computer is off. It does not replace the need to check your YouTube event or decide whether a VPS-based monitoring setup suits your operation.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Can I monitor CPU and memory with Hetzner Cloud graphs alone?
Provider graphs and guest-level metrics answer different questions. For process and operating-system context inside the Linux server, use Node Exporter and Prometheus; verify what any provider graph actually measures before treating it as a view of guest memory or a particular process.
Does the Hetzner Prometheus/Grafana image start monitoring automatically?
No. Hetzner’s documentation says the components are preinstalled but need to be activated after boot. Follow the current app-image instructions, then confirm Prometheus can scrape Node Exporter and that Grafana has data to display.
What CPU or memory reading means my stream is in danger?
There is no universal CPU or memory percentage that guarantees stream health. Establish a baseline for your actual server and workload, investigate sustained changes, and check stream-service status and YouTube ingest alongside the metrics.
Should Node Exporter’s port be open to the internet?
No. Keep the metrics endpoint private or restrict it to the Prometheus host or a private network. For a same-server scraper, use local access; for separate hosts, configure a narrow firewall rule for the intended source.