[Host 1 + Alloy] ──┐
[Host 2 + Alloy] ──┼──push──> [Loki] <──query── [Grafana]
[Host N + Alloy] ──┘

.

This file is responsible for configuring where to store the logs and for how long Loki will store them.

To make it short and simple, I'll go in general over each block:



```auth_enabled: false```

 — Disables multi-tenancy; uses a default tenant.



```server```

 — Sets the HTTP port Loki listens on, the default is 3100.



```common```

 — Shared default configs for all jobs.



```schema_config```

 — Defines how data is indexed and stored from a given date.



```storage_config```

 — Specifies where chunks (actual log data) are physically written on disk when using filesystem storage. This is important — I recommend creating a volume so it won't get deleted if the container fails.



```limits_config```

 — Per-tenant limits: for example, 7-day retention.



```chunk_store_config```

 — Caps how far back queries can look, preventing reads beyond the retention window.

plaintext

Now after we created the config file, let's run the container:

plaintext

### Running Alloy on the host

Before running the Alloy container we need to understand how to tell Alloy how and what logs we want to pull. For that we have the

 ```config.alloy```

 file.

The hardest part in this stack is that the config file is written in a DSL called "River", which is a Grafana config language.

But there is also a simple solution: you can use [this](https://grafana.github.io/alloy-configurator/) generator to create a simple config file for your needs.

For example, you can use this file. I will break it up a little as we need to understand what we are up to.

plaintext

### loki.write

This block creates an object to where we push the logs. We will need to give it our Loki server DNS or IP address to send the logs.

You can change the

 ```local_host```

 to anything you like, it's just a label. We will see this nature in the other blocks too.

plaintext

### loki.relabel

This block is all about relabeling.
When Loki receives journal logs, they will have specific initial names that start with

 ```__journal_<service_name>```

 like

 ```__journal__systemd_unit```

. So to make our life easier, we create certain rules to relabel them into our own groups so we will have a simpler way to query them later.

Each rule relabels a certain log group into a

 ```target_label```

. You can change the value to any label you want, e.g.

 ```target_label  = "ninja"```

.

plaintext

### loki.source.journal

The final block is getting the input. It uses the journal's API under the hood to collect our logs.
It configures which block to send the data to, which block is used to relabel our data, and finally just a small label that is added, which will be the main label for all data coming from Alloy.

shell

After we created our config file, we will need to pull the Alloy image to the host. I will leave this part to you, as it differs by environment.

I will jump straight into running the container.

> *IMPORTANT NOTE! If using automation and deploying too many containers of Alloy at once, it may crash Loki's max streaming amount, so start with one container and then deploy the rest.*

To make the Alloy container read the journal logs, we need to mount the journal logs directories and add the container root user to the group ID of the journal group of the host, so it will have permissions.
So we run this command:

> Note: the journald group ID may vary, please give the parameter the correct ID, to find the ID on the host, run

 ```getent group systemd-journal | cut -d: -f3```

plaintext

### Verify it works

Before moving on to Grafana, let's make sure everything is running as expected.

On the Loki host, check that Loki is ready:

plaintext

You should get back

 ```ready```

.

On the Alloy host, check the container logs for any errors:

shell

If Alloy is shipping logs successfully, you can confirm Loki is receiving them by querying for our job label:

If all three checks pass, you're good to go.

### Grafana

From now on, you can set Loki as a Grafana data source and create dashboards for the logs.

## Thank You

And that's a wrap!

Thank you so much for taking the time to read my guide — it really means a lot. I hope it saved you some of the headache I went through figuring this out, and that you now have a working Alloy + Loki stack pulling logs from your hosts.

If you spotted something that could be improved, have a question, or just want to share how your own monitoring setup looks, I'd love to hear from you in the comments.

Stay tuned — more monitoring guides are on the way.

— Alex (TheBlueDrara)