Skip to content

store alloy logs agent position file on hostpath - #659

Merged
samidbb merged 5 commits into
mainfrom
add/alloy-logs-storage
Sep 17, 2026
Merged

samidbb merged 5 commits into
mainfrom
add/alloy-logs-storage

Conversation

@samidbb

@samidbb samidbb commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

This pull request updates the Alloy logs DaemonSet configuration to use a persistent storage path and mounts for log data, improving data durability and aligning with best practices for stateful components. The changes ensure that Alloy's log storage is backed by a hostPath volume at /srv/alloy/data instead of the previous ephemeral /tmp/alloy path.

Persistent storage improvements:

  • Changed Alloy's storage path from /tmp/alloy to /srv/alloy/data in the DaemonSet arguments for more durable log data storage.
  • Added a new volume mount for /srv/alloy/data using the alloy-storage-logs volume in the container spec.
  • Defined a new hostPath volume named alloy-storage-logs at /srv/alloy/data with type DirectoryOrCreate to ensure the directory exists on the host.

Helm release configuration updates:

  • Updated release.yaml to add storagePath and mount definitions for /srv/alloy/data, and included the corresponding hostPath volume under volumes.extra.

@SEQUOIIA

Copy link
Copy Markdown
Member

Hmm, thoughts on doing it via hostPath instead? The data is only relevant to the node the pod is on, if it's a different node it's different logs, thus attaching a pvc with a WAL/positions from a different node doesn't make sense since it can't access those logs. With the hostPath the WAL/positions are stored with the node the logs are on anyway and we avoid creating pvcs/pvs.

@wcarlsen

Copy link
Copy Markdown
Contributor

Hmm, thoughts on doing it via hostPath instead? The data is only relevant to the node the pod is on, if it's a different node it's different logs, thus attaching a pvc with a WAL/positions from a different node doesn't make sense since it can't access those logs. With the hostPath the WAL/positions are stored with the node the logs are on anyway and we avoid creating pvcs/pvs.

If possible I think this could make a lot of sense.

@samidbb

samidbb commented Sep 15, 2026

Copy link
Copy Markdown
Contributor Author

Hmm, thoughts on doing it via hostPath instead? The data is only relevant to the node the pod is on, if it's a different node it's different logs, thus attaching a pvc with a WAL/positions from a different node doesn't make sense since it can't access those logs. With the hostPath the WAL/positions are stored with the node the logs are on anyway and we avoid creating pvcs/pvs

it makes sense for me as well. I will try to use the hostpath instead

@SEQUOIIA SEQUOIIA left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for using hostPath instead. The suggested path is the one that currently has the migrated WAL/position data in production.

Comment thread apps/grafana/release.yaml Outdated
Comment thread apps/grafana/release.yaml Outdated
@samidbb
samidbb marked this pull request as ready for review September 17, 2026 04:58
@samidbb
samidbb requested a review from a team as a code owner September 17, 2026 04:58
@samidbb
samidbb requested a review from SEQUOIIA September 17, 2026 04:59
@samidbb samidbb changed the title store alloy logs agent position file on pv store alloy logs agent position file on hostpath Sep 17, 2026
@samidbb
samidbb merged commit 31e49e6 into main Sep 17, 2026
5 checks passed
@samidbb
samidbb deleted the add/alloy-logs-storage branch September 17, 2026 08:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants