[{"data":1,"prerenderedAt":226},["ShallowReactive",2],{"seo-verification":3,"blog-grafana-alloy-on-a-vps-install-and-migrate-from-promtail-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-grafana-alloy-on-a-vps-install-and-migrate-from-promtail-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":171,"ctaBody":172,"ctaButton":173,"ctaUrl":174,"relatedPosts":175},497,"grafana-alloy-on-a-vps-install-and-migrate-from-promtail",{"fr":12,"en":10,"ar":13,"es":14},"grafana-alloy-vps-monitoring","تثبيت-grafana-alloy-على-vps-والانتقال-من-promtail","grafana-alloy-en-un-vps-instalar-y-migrar-desde-promtail","Grafana Alloy on a VPS: install it and migrate from Promtail","Install Grafana Alloy on your VPS, collect logs and metrics with a single agent, and migrate from Promtail without losing logs or sending them twice.",12,0,false,"2026-10-22T00:00:00+00:00","2026-10-23T13:27:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fgrafana-alloy-vps-monitoring-poster.svg",{"categorySlug":34,"appSlug":35},"monitoring-observability","grafana","Promtail no longer receives any updates: Grafana has declared it end of life since March 2, 2026. If your VPS still ships its logs to Loki through that agent, any vulnerability found tomorrow will stay open. Grafana Alloy takes its place and also collects system metrics, which removes one more exporter from your server. This guide installs Alloy as a systemd service, connects it to Loki and Prometheus, migrates an existing Promtail configuration and handles the permission errors that Alloy does not always report.",[38,42,52,55,86,89,92,113,149,152,156,159,168],{"type":39,"title":40,"body":41},"h2","Why replace Promtail with Alloy now","The official Promtail page leaves no room for doubt: the agent has been end of life since March 2, 2026, commercial support has ended and all development continues in Grafana Alloy. A collection agent is a privileged process that runs permanently: leaving it without fixes is not sustainable.\n\nAlloy is not just a renamed Promtail. It is a single collector, configured through components: a log source, a system metrics exporter, a sender to Loki, another to Prometheus. On a VPS that ran Promtail and node_exporter side by side, one service is now enough. It can also relay OTLP if you instrument your applications, a topic covered in \u003Ca href=\"\u002Fen\u002Fblog\u002Fgrafana-tempo-and-opentelemetry-distributed-tracing-on-vps\">our Tempo and OpenTelemetry guide\u003C\u002Fa>.\n\nThis guide does not reinstall Loki or Prometheus: the server side is described in \u003Ca href=\"\u002Fen\u002Fblog\u002Fcentralize-docker-logs-on-your-vps-with-loki-and-grafana\">the Loki and Grafana guide\u003C\u002Fa> and in \u003Ca href=\"\u002Fen\u002Fblog\u002Fvps-monitoring-with-grafana-and-prometheus\">the Grafana and Prometheus guide\u003C\u002Fa>. Here, we focus on the agent.",{"type":43,"title":44,"items":45},"ul","What a single agent changes on your server",[46,47,48,49,50,51],"**One service to watch** — logs and metrics go through the same `alloy` process, with a single journal to read when something breaks.","**Updates that still arrive** — Alloy is published in Grafana's apt and rpm repositories: an `apt upgrade` keeps it current like the rest of the system.","**A tooled migration** — the `alloy convert` command translates an existing Promtail configuration and produces a report of what it could not convert.","**Built-in system metrics** — the `prometheus.exporter.unix` component replaces node_exporter without an extra binary or port to open.","**A local debugging interface** — the UI on port 12345 shows the component graph and their values, reachable through an SSH tunnel.","**Output to your own stack or to Grafana Cloud** — the same file sends to a self-hosted Loki or to a managed service by changing one URL.",{"type":39,"title":53,"body":54},"Sized prerequisites for Alloy on a VPS","Alloy installs on Debian, Ubuntu, AlmaLinux or Rocky Linux from Grafana's official repositories. The package creates an `alloy` system user, a systemd service of the same name and the configuration file `\u002Fetc\u002Falloy\u002Fconfig.alloy`.\n\nFor resources, the Alloy documentation gives two orders of magnitude: about 1 core and 120 MiB of memory per MiB\u002Fs of ingested logs, and about 11 GiB of memory per million active Prometheus series. A standalone VPS exposes a few thousand series and rarely writes more than a few hundred KiB of logs per second. Our editorial recommendation: reserve half a vCPU and 256 to 512 MB of RAM for the agent, plus a few GB of disk under `\u002Fvar\u002Flib\u002Falloy` for read positions and the send buffer.\n\nFinally, you need a destination: a Loki reachable on `\u002Floki\u002Fapi\u002Fv1\u002Fpush`, and a Prometheus started with the `--web.enable-remote-write-receiver` flag, which opens the `\u002Fapi\u002Fv1\u002Fwrite` endpoint. No inbound port needs to be opened on the agent's VPS: Alloy pushes, it is not polled.",{"type":56,"title":57,"steps":58},"steps","Install Alloy and connect logs and metrics",[59,62,65,68,71,74,77,80,83],{"title":60,"body":61},"Add the Grafana repository on Debian or Ubuntu","`sudo mkdir -p \u002Fetc\u002Fapt\u002Fkeyrings`\n`sudo wget -O \u002Fetc\u002Fapt\u002Fkeyrings\u002Fgrafana.asc https:\u002F\u002Fapt.grafana.com\u002Fgpg-full.key`\n`sudo chmod 644 \u002Fetc\u002Fapt\u002Fkeyrings\u002Fgrafana.asc`\n`echo \"deb [signed-by=\u002Fetc\u002Fapt\u002Fkeyrings\u002Fgrafana.asc] https:\u002F\u002Fapt.grafana.com stable main\" | sudo tee \u002Fetc\u002Fapt\u002Fsources.list.d\u002Fgrafana.list`\n`sudo apt-get update && sudo apt-get install alloy`",{"title":63,"body":64},"Or install it on AlmaLinux and Rocky Linux","Import the key with `wget -q -O gpg.key https:\u002F\u002Frpm.grafana.com\u002Fgpg.key` then `sudo rpm --import gpg.key`. Create `\u002Fetc\u002Fyum.repos.d\u002Fgrafana.repo` with `baseurl=https:\u002F\u002Frpm.grafana.com`, `repo_gpgcheck=1`, `gpgcheck=1` and `enabled=1`, as the Alloy Linux installation page shows, then run `sudo dnf install alloy`.",{"title":66,"body":67},"Start the service and check its user","`sudo systemctl enable --now alloy`\n`sudo systemctl status alloy`\n`systemctl cat alloy | grep User`\n\nThe last command should print `User=alloy`. The package does not set a `Group=`: read access therefore comes from that user's secondary groups, which matters for what follows.",{"title":69,"body":70},"Declare the log destination","Open `\u002Fetc\u002Falloy\u002Fconfig.alloy` and add the sender to Loki:\n\n`loki.write \"default\" {`\n`  endpoint {`\n`    url = \"http:\u002F\u002F127.0.0.1:3100\u002Floki\u002Fapi\u002Fv1\u002Fpush\"`\n`  }`\n`}`\n\nReplace the address with your Loki's. If it is remote, use HTTPS and a `basic_auth` block.",{"title":72,"body":73},"Collect journald and log files","`loki.source.journal \"system\" {`\n`  forward_to = [loki.write.default.receiver]`\n`  labels     = {\"job\" = \"systemd-journal\"}`\n`}`\n`local.file_match \"nginx\" {`\n`  path_targets = [{\"__path__\" = \"\u002Fvar\u002Flog\u002Fnginx\u002F*.log\", \"job\" = \"nginx\"}]`\n`}`\n`loki.source.file \"nginx\" {`\n`  targets    = local.file_match.nginx.targets`\n`  forward_to = [loki.write.default.receiver]`\n`}`\n\nBy default, the journal source reads `\u002Fvar\u002Flog\u002Fjournal` and `\u002Frun\u002Flog\u002Fjournal`, and only goes back seven hours on first start.",{"title":75,"body":76},"Collect system metrics","`prometheus.exporter.unix \"node\" { }`\n`prometheus.scrape \"node\" {`\n`  targets    = prometheus.exporter.unix.node.targets`\n`  forward_to = [prometheus.remote_write.default.receiver]`\n`}`\n`prometheus.remote_write \"default\" {`\n`  endpoint {`\n`    url = \"http:\u002F\u002F127.0.0.1:9090\u002Fapi\u002Fv1\u002Fwrite\"`\n`  }`\n`}`\n\nIf node_exporter was already running on the machine, stop it after the switch so the same series are not collected twice.",{"title":78,"body":79},"Validate before reloading","`sudo alloy validate \u002Fetc\u002Falloy\u002Fconfig.alloy`\n`sudo systemctl reload alloy`\n`sudo journalctl -u alloy -f`\n\nA syntax error or a wrongly referenced component is reported by `validate` before the service loads the configuration.",{"title":81,"body":82},"Grant read access","`id alloy` should list the `adm` and `systemd-journal` groups. The package adds them when they exist; after a binary install or a removed group, restore them with `sudo usermod -aG adm,systemd-journal alloy` then `sudo systemctl restart alloy`. For an application folder owned by another user, the documentation prefers an ACL to one more group: `sudo setfacl -R -m u:alloy:rx \u002Fvar\u002Flog\u002Fmonapp` and `sudo setfacl -R -d -m u:alloy:rx \u002Fvar\u002Flog\u002Fmonapp`.",{"title":84,"body":85},"Check end to end, then connect your dashboards","Write a marker line with `logger -t alloy-test \"ligne de test alloy\"`, then look for it in Grafana, Explore tab, with the query `{job=\"systemd-journal\"} |= \"ligne de test alloy\"`. On the metrics side, the `node_load1` query should return a series for your VPS. Both answer: reuse the dashboards from \u003Ca href=\"\u002Fen\u002Fblog\u002Fvps-monitoring-with-grafana-and-prometheus\">our Grafana and Prometheus guide\u003C\u002Fa>, which read the same `node_*` series.",{"type":39,"title":87,"body":88},"Alloy and Docker: read containers without opening everything","To read your containers' logs, Alloy installed on the host combines `discovery.docker` and `loki.source.docker`, both pointed at `unix:\u002F\u002F\u002Fvar\u002Frun\u002Fdocker.sock`. The `alloy` user must then be able to open that socket, which in practice means `sudo usermod -aG docker alloy`. Do it knowingly: Docker's documentation reminds you that the `docker` group grants root-level privileges. Your log agent effectively becomes an administrator of the machine.\n\nYou can also run Alloy itself in a container, with the `grafana\u002Falloy` image, the file mounted on `\u002Fetc\u002Falloy\u002Fconfig.alloy` and the `--storage.path=\u002Fvar\u002Flib\u002Falloy\u002Fdata` argument on a persistent volume. Mounting the socket as `:ro` does not limit calls to the Docker API: a socket is still a socket. And for host metrics, the container must receive the machine's filesystem, `\u002Fproc` and `\u002Fsys` as mounts.\n\nOn a single VPS, the systemd package remains the simplest to audit.",{"type":39,"title":90,"body":91},"Migrating from Promtail: the real risk is positions","Promtail keeps a positions file that records, for each tracked file, where it stopped reading. Alloy stores its own elsewhere, in the folder set by `--storage.path`. The conversion knows this: the `loki.source.file` block produced by `alloy convert` carries a `legacy_positions_file` argument that points to the old file, so reading resumes at the right place.\n\nThis mechanism has a documented weak spot. In grafana\u002Falloy issue #5493, a user describes the error `error reading legacy positions file` followed by `permission denied`: Alloy could not read the old file, ignored it and re-sent every log on the server from the beginning. The maintainer considered it legitimate to stop Alloy in that case, and the issue is closed, but do not bet on your version: check permissions before the first start.\n\nThe other risk is the opposite: Promtail and Alloy running together send every line twice. The order below avoids both.",{"type":56,"title":93,"steps":94},"Migrate a Promtail configuration without loss or duplicates",[95,98,101,104,107,110],{"title":96,"body":97},"Locate the configuration and the positions file","Open the Promtail configuration, often `\u002Fetc\u002Fpromtail\u002Fconfig.yml`, and note the value of `positions.filename`. In a Docker Compose install, this file lives in a volume: note its real path on the host.",{"title":99,"body":100},"Convert with a report","`alloy convert --source-format=promtail --report=\u002Ftmp\u002Fpromtail-report.txt --output=\u002Ftmp\u002Fpromtail.alloy \u002Fetc\u002Fpromtail\u002Fconfig.yml`\n\nRead the report first. The `--bypass-errors` option forces a partial conversion, but the documentation warns that behavior may then differ from the original.",{"title":102,"body":103},"Check that the alloy user can read the old file","`grep legacy_positions_file \u002Ftmp\u002Fpromtail.alloy`\n`sudo -u alloy cat \u002Fvar\u002Flib\u002Fpromtail\u002Fpositions.yaml`\n\nAdapt the path to the one noted above. If the second command fails, copy the file into a folder readable by `alloy` and fix the path in the converted configuration.",{"title":105,"body":106},"Stop Promtail before starting Alloy","`sudo systemctl stop promtail`, or `docker compose stop promtail` for a container stack. Promtail then writes its last positions, and no line is sent twice during the switch.",{"title":108,"body":109},"Switch the configuration","Copy the converted blocks into `\u002Fetc\u002Falloy\u002Fconfig.alloy`, run `sudo alloy validate \u002Fetc\u002Falloy\u002Fconfig.alloy`, then `sudo systemctl restart alloy`. Immediately check `sudo journalctl -u alloy | grep -i positions`: no `error reading legacy positions file` line should appear.",{"title":111,"body":112},"Monitor for a week, then uninstall","Compare log volume in Grafana before and after the switch, and follow Alloy's `loki_write_sent_entries_total` counter. Keep the Promtail configuration a few days, then `sudo systemctl disable promtail` and remove the package or the Compose service.",{"type":114,"title":115,"headers":116,"rows":120},"comparison","Promtail and Alloy, side by side",[117,118,119],"Criterion","Promtail","Grafana Alloy",[121,125,129,133,137,141,145],[122,123,124],"Status","End of life since March 2, 2026, no more updates","Actively developed, successor designated by Grafana",[126,127,128],"Signals collected","Logs only","Logs, metrics, OTLP traces and profiles",[130,131,132],"System metrics","node_exporter to install separately","Built-in `prometheus.exporter.unix` component",[134,135,136],"Configuration","YAML","Alloy component syntax, conversion with `alloy convert`",[138,139,140],"Read positions","File set in the configuration","`--storage.path` folder, resumed through `legacy_positions_file`",[142,143,144],"Debugging","Service journal","Service journal and local UI on port 12345",[146,147,148],"Service user","Depends on the install method","`alloy`, `adm` and `systemd-journal` groups added by the package",{"type":39,"title":150,"body":151},"Post-install configuration: UI, secrets and storage","The debugging interface listens on `127.0.0.1:12345` by default. Leave it that way and open it through a tunnel: `ssh -L 12345:127.0.0.1:12345 you@your-domain.com`, then `http:\u002F\u002Flocalhost:12345` in your browser. To expose it anyway, add `--server.http.listen-addr=0.0.0.0:12345` to `CUSTOM_ARGS`, but only behind a firewall that filters that port.\n\nLaunch options live in `\u002Fetc\u002Fdefault\u002Falloy` on Debian and Ubuntu, and in `\u002Fetc\u002Fsysconfig\u002Falloy` on AlmaLinux and Rocky. That is also where you put secrets: declare a `LOKI_PASSWORD` variable, read it in the configuration with `sys.env(\"LOKI_PASSWORD\")`, and keep the password out of `config.alloy`.\n\nFor a remote Loki, never send plain HTTP over the Internet: put Loki behind a TLS reverse proxy with authentication, as described in \u003Ca href=\"\u002Fen\u002Fblog\u002Fcentralize-docker-logs-on-your-vps-with-loki-and-grafana\">our Loki guide\u003C\u002Fa>. Finally, watch the space in `\u002Fvar\u002Flib\u002Falloy`: if Loki is unreachable, that is where data waiting to be sent piles up.",{"type":153,"title":154,"body":155},"tip","Harden the service without breaking collection","The Alloy documentation proposes a drop-in file, created with `sudo systemctl edit alloy` so it survives package upgrades: `NoNewPrivileges=yes`, `ProtectSystem=strict`, `ProtectHome=yes`, `PrivateTmp=yes` and `ReadWritePaths=\u002Fvar\u002Flib\u002Falloy`. With `ProtectSystem=strict`, add `ReadOnlyPaths=\u002Fvar\u002Flog\u002Fjournal` and `ReadOnlyPaths=\u002Frun\u002Flog\u002Fjournal`, otherwise the journal source reads nothing. Finish with `sudo systemctl daemon-reload` and `sudo systemctl restart alloy`. Prefer a per-folder ACL to adding groups, and only grant the `docker` group if you actually collect containers.",{"type":39,"title":157,"body":158},"Troubleshooting: the errors Alloy does not shout about","Most Alloy failures on a VPS are not crashes. The service is active, the interface is green, and Grafana stays empty. The reason is documented by the maintainers themselves in grafana\u002Falloy issue #2994, closed in favor of #6340: a component's health means it is running, not that it is sending.\n\nTwo reflexes are enough to get out of this fog. Read the service journal with `sudo journalctl -u alloy --since \"10 min ago\"`, and query the agent's internal metrics with `curl -s http:\u002F\u002F127.0.0.1:12345\u002Fmetrics | grep loki_write`. The `loki_write_sent_entries_total` counter should rise; `loki_write_dropped_entries_total` counts lines dropped after every send attempt failed.",{"type":43,"title":160,"items":161},"Error messages and fixes",[162,163,164,165,166,167],"**The journal source starts, but no line arrives** — the `loki.source.journal` documentation says it: without the `adm` and `systemd-journal` groups, the component starts without error and collects nothing. Fix it with `sudo usermod -aG adm,systemd-journal alloy`, then restart the service, because an added group only takes effect at the next launch.","**`failed to tail the file: open \u002Fvar\u002Flog\u002F…: permission denied`** — the file exists but `alloy` cannot read it. Grant an ACL on the folder with `setfacl -R -m u:alloy:rx` and its `-d` variant for files later created by rotation.","**No message, no line for a whole folder** — grafana\u002Falloy issue #6542 describes logs never sent without any error. A maintainer confirms there that an unreadable file is logged, but an inaccessible folder is not. Test with `sudo -u alloy ls \u002Fvar\u002Flog\u002Fmonapp`.","**`error reading legacy positions file … permission denied`** — Alloy did not read Promtail's positions and may re-send everything from the beginning (issue #5493). Stop the service, make the file readable for `alloy`, then start again.","**`failed to identify the read-write layer ID … mount-id: permission denied`** — an error from the cAdvisor component under systemd (issue #4068). The `docker` group is not enough; users report that a drop-in with `AmbientCapabilities=CAP_DAC_READ_SEARCH` and `CapabilityBoundingSet=CAP_DAC_READ_SEARCH` solves it without running the service as root. It is a community workaround, to test before rolling it out.","**The UI is green, but Grafana stays empty** — check `loki_write_sent_entries_total` and the test line written by `logger`. If the counter stalls, the failure is upstream, on the source side.",{"type":39,"title":169,"body":170},"An up-to-date agent on a server that belongs to you","Alloy needs what shared hosting does not give: a systemd service, read access to `\u002Fvar\u002Flog` and the journal, sometimes the Docker socket. On a VPS, you choose your distribution, keep your Loki and Prometheus stack, and decide which permissions the agent gets. If you would rather not administer the system yourself, the VPS administration option exists for the server.\n\nThe official documentation remains the reference for each component: \u003Ca href=\"https:\u002F\u002Fgrafana.com\u002Fdocs\u002Falloy\u002Flatest\u002Fset-up\u002Fmigrate\u002Ffrom-promtail\u002F\">migrating from Promtail\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fgrafana.com\u002Fdocs\u002Falloy\u002Flatest\u002Faccess_permissions\u002Flinux\u002F\">Linux permissions\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fgrafana.com\u002Fdocs\u002Floki\u002Flatest\u002Fsend-data\u002Fpromtail\u002F\">the Promtail end-of-life page\u003C\u002Fa>. For application tracing, continue with \u003Ca href=\"\u002Fen\u002Fblog\u002Fgrafana-tempo-and-opentelemetry-distributed-tracing-on-vps\">our Tempo and OpenTelemetry guide\u003C\u002Fa>.","A VPS where your collection agent has the permissions it needs","On a ServOrbit.com VPS, you have root access, a choice of OS between Ubuntu, Debian, AlmaLinux and Rocky, and control over systemd, groups and ACLs. You install Alloy, Loki or Prometheus the way you want, and the VPS administration option exists for the server.","See developer solutions","\u002Fsolutions\u002Fdeveloppeurs",[176,194,210],{"id":177,"slug":178,"slugs":179,"title":183,"excerpt":184,"readTime":185,"views":186,"isPinned":19,"publishedAt":187,"updatedAt":188,"category":189,"categories":190,"featuredImage":30,"bgImage":31,"posterImage":192,"relatedSolution":193},243,"centralize-docker-logs-on-your-vps-with-loki-and-grafana",{"fr":180,"en":178,"ar":181,"es":182},"loki-grafana-logs-centralises-vps","مركزة-سجلات-docker-على-vps-باستخدام-loki-وgrafana","centralizar-logs-docker-en-vps-con-loki-y-grafana","Centralize Docker logs on your VPS with Loki and Grafana","Aggregate logs from all your Docker containers into a single Grafana dashboard using Loki and Promtail on your VPS. No Datadog, no quota.",11,1,"2026-08-10T00:00:00+00:00","2026-09-08T22:00:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[191],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Floki-grafana-logs-centralises-vps-poster.svg",{"categorySlug":34,"appSlug":35},{"id":195,"slug":196,"slugs":197,"title":201,"excerpt":202,"readTime":185,"views":18,"isPinned":19,"publishedAt":203,"updatedAt":204,"category":205,"categories":206,"featuredImage":30,"bgImage":31,"posterImage":208,"relatedSolution":209},106,"vps-monitoring-with-grafana-and-prometheus",{"fr":198,"en":196,"ar":199,"es":200},"monitoring-vps-grafana-prometheus","مراقبة-الخادم-الافتراضي-vps-باستخدام-grafana-و-prometheus","monitorizacion-vps-grafana-prometheus","VPS Monitoring with Grafana and Prometheus","Deploy Prometheus 3.x, Grafana 13.x, Node Exporter and Alertmanager on your VPS with Docker Compose. Dashboards, alerts and hardening.","2026-03-06T00:00:00+00:00","2026-10-05T14:05:27+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[207],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitoring-vps-grafana-prometheus-poster.svg",{"categorySlug":34,"appSlug":35},{"id":211,"slug":212,"slugs":213,"title":217,"excerpt":218,"readTime":17,"views":186,"isPinned":19,"publishedAt":219,"updatedAt":220,"category":221,"categories":222,"featuredImage":30,"bgImage":31,"posterImage":224,"relatedSolution":225},220,"grafana-tempo-and-opentelemetry-distributed-tracing-on-vps",{"fr":214,"en":212,"ar":215,"es":216},"opentelemetry-grafana-tempo-vps","grafana-tempo-وopentelemetry-التتبع-الموزع-على-خادم-vps","grafana-tempo-opentelemetry-trazado-distribuido-vps","Grafana Tempo and OpenTelemetry: distributed tracing on VPS","Deploy OpenTelemetry + Grafana Tempo on your VPS: complete architecture, step-by-step setup, Node.js\u002FPython instrumentation, S3 retention, and TraceQL queries.","2026-08-04T00:00:00+00:00","2026-09-29T14:40:44+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[223],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fopentelemetry-grafana-tempo-vps-poster.svg",{"categorySlug":34,"appSlug":35},1792763183123]