Plataformas

O Ongrid distribui dois binários com histórias de plataforma bem diferentes.

• ongrid (o cloud manager) é um workload Linux + Docker. É feito para viver num container, atrás do nginx, com MySQL embaixo. Não há build first-class de Windows ou macOS server.
• ongrid-edge (o edge agent) é um único binário estático que roda em cada host que você quer observar. Cross-compila para quatro alvos de fábrica: Linux em amd64 / arm64 e macOS em amd64 / arm64. Instalação grade-produção apenas em Linux + systemd; alvos macOS existem para que desenvolvedores possam rodar o agent no laptop enquanto iteram.

Matriz de suporte

Componente	linux/amd64	linux/arm64	darwin/amd64	darwin/arm64	Windows
ongrid (imagem do manager)	sim	testado como alvo de build	não	não	não
ongrid-edge (binário, supervisionado)	sim	sim	só-dev, manual	só-dev, manual	não
plugin promtail (logs)	sim	sim	não (gap upstream)	não (gap upstream)	não
plugin node_exporter (host metrics)	sim	sim	não (gap upstream)	não (gap upstream)	não
plugin process-exporter (proc metrics)	sim	sim	não (gap upstream)	não (gap upstream)	não
plugin otelcol-contrib (traces)	sim	sim	não (não bundled)	não (não bundled)	não

Os quatro alvos de cross-compile de edge vêm direto do Makefile:

build-edge-linux-amd64
build-edge-linux-arm64
build-edge-darwin-amd64
build-edge-darwin-arm64

make build-edge-all roda os quatro; make package produz o tarball de release que empacota cada alvo mais os binários de plugin Linux-only.

Por que sem edge Windows / BSD?

O próprio agent é Go puro e compilaria limpo; o gap é o bundle de plugin. promtail, node_exporter, process-exporter, e otelcol-contrib todos distribuem artefatos Linux-only em suas releases upstream. Sem esses quatro, os painéis Logs / Monitor / Traces ficam vazios mesmo depois do agent conectado. Preferimos não distribuir uma instalação meio-funcionando em vez de carregar uma plataforma escondida-desabilitada.

Se você tem um caso de uso forte de Windows ou FreeBSD, abra um issue em github.com/ongridio/ongrid — bundlers plugáveis são rastreados em ADR-015.

Requisitos do lado cloud

Em qualquer lugar onde você possa rodar Docker Engine 24+ e Docker Compose v2 vai hospedar o manager. Testamos em:

• Ubuntu 22.04 LTS, 24.04 LTS
• Debian 12 (bookworm)
• RHEL 9, Rocky Linux 9, AlmaLinux 9

Floor de memória: 4 GB. Floor de disco: 20 GB (a maior parte é retenção de Prometheus + Loki, veja Linux (servidor)).

Requisitos do lado edge

O instalador curl-pipe oficial (deploy/install/edge/install.sh) explicitamente só trata Linux:

if [[ "$OS" != "linux" ]]; then
    log_error "only linux is supported by this installer; got: $OS"
    exit 1
fi

Esse instalador coloca uma unit systemd (/etc/systemd/system/ongrid-edge.service), cria um user de sistema ongrid-edge, e supervisiona o agent via systemd com Restart=always. Hosts macOS ainda podem rodar o binário à mão para desenvolvimento — veja macOS (edge dev) — mas você não ganha o serviço supervisionado, a fonte de log journald, ou o bundle de plugin.

Escolhendo a página certa

• Instalando o manager? → Linux (servidor)
• Instalando um edge agent num host Linux real? → Linux (edge)
• Rodando o agent num Mac para desenvolvimento? → macOS (edge dev)
• Fazendo deploy de tudo no Kubernetes? → Kubernetes
• Air-gapped ou registry de container privado? → Air-gapped / on-prem

Política de versionamento

O manager e o agent compartilham um único arquivo VERSION (/Users/.../ongrid/VERSION) e são lançados como um tarball. Um edge agent mais velho que seu manager vai continuar funcionando: cada RPC de tunnel é versionado, e o manager trata campos de reply desconhecidos como valores zero. Um edge agent mais novo que seu manager não é suportado — faça upgrade do manager primeiro.

Veja Upgrade para o modelo staged-swap-then-rollback (ADR-024).