1. Pilae
2. Apps
3. Grafana

Running Grafana in production: what it takes

1. Deploy the stack

   Grafana on PostgreSQL, with Prometheus and Loki beside it, each pinned to a version we have run and sized for your series count and log volume.

2. Provision from your repository

   Data sources, dashboards and alert rules are files in Git. The console shows what changed, and a new instance is a deploy rather than a rebuild by hand.

3. Route alerts to people

   Notification policies send each alert to the team that owns it, with quiet hours and escalation written down rather than remembered.

4. Back up and restore on a schedule

   The Grafana database goes offsite daily, encrypted. Once a month we restore it into a scratch instance and check that dashboards and alert rules load.

5. Upgrade in your window

   Grafana ships a major release each year and minors in between. The Pilae Agent tests each upgrade against a copy of your dashboards, waits for your approval and applies it in your window.

What Grafana is, and who runs it

Grafana system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory

2 vCPU · 4 GBFor Grafana itself. Prometheus and Loki are sized separately, by series count and log volume rather than by viewers.

Database

PostgreSQLHolds users, dashboards, alert state and annotations. The default SQLite file cannot back a second Grafana node.

Metrics store

PrometheusScrapes exporters on your machines and keeps the time series. Retention is set by disk, and long retention can move to object storage.

Log store

Loki + S3-compatible bucketIndexes labels, not full text, and keeps log chunks in a bucket, which keeps storage cost in line with volume.

Alert routing

Email, Teams, Slack, webhookContact points and notification policies decide who is told, and when, for each alert.

Access

Private network onlyGrafana and its data sources answer on your private mesh, behind the Pilae gate on port 443.

Migrating from Datadog dashboards to Grafana

Datadog is a whole observability platform, and Grafana is the part you look at. Leaving Datadog dashboards means replacing three things: the agent that collects, the store that keeps, and the screen that shows. We collect with Prometheus exporters or OpenTelemetry, keep metrics in Prometheus and logs in Loki, and draw them in Grafana. Grafana has no official import for Datadog dashboards, so the panels are rebuilt, and queries move from Datadog syntax to PromQL and LogQL. Monitors become Grafana alert rules routed to the same people. Datadog APM and its hosted features such as synthetic tests are a separate conversation, and we scope them rather than assume them.

1. List the dashboards and monitors in use

   Dashboards opened and monitors that fired in the last ninety days, with their owners. The rest is retired rather than rebuilt.

2. Collect in parallel

   Prometheus exporters or OpenTelemetry collectors go on beside the Datadog agent, so both systems see the same machines while the rebuild happens.

3. Rebuild as code

   Panels and alert rules are written as provisioned files in your repository, with queries translated to PromQL and LogQL and checked against the Datadog figures.

4. Move the pager, then the agent

   Alert routing switches once both systems have fired the same alerts for a full cycle. The Datadog agent comes off last.

Grafana data sources, provisioned from Git

# provisioning/datasources/telemetry.yaml
apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    url: http://prometheus.internal:9090
    isDefault: true
    jsonData:
      timeInterval: 30s
  - name: Loki
    type: loki
    url: http://loki.internal:3100
    jsonData:
      maxLines: 5000
  - name: Postgres (read-only)
    type: grafana-postgresql-datasource
    url: db-02.internal:5432
    user: grafana_ro
    secureJsonData:
      password: $__file{/run/secrets/grafana_ro}
    jsonData:
      database: reporting
      sslmode: require

What Pilae is responsible for

Where it runs

zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware

Who holds the credentials

You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.

If you leave

The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What running Grafana costs

On Starter, Grafana runs in Pilae Cloud for CHF 449EUR 479USD 559 a month, hosting and onboarding included. On Business, it is one of up to three apps for CHF 1,590EUR 1,690USD 1,990 a month, on your own servers or in Pilae Cloud. Enterprise is quoted. The plans set what each includes; these are the inputs that move the price around them.

Instance size

The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.

High availability

One machine with tested restores, or a replicated setup that keeps serving when a node fails.

Storage and backups

How much data it holds, how long backups are kept, and point-in-time recovery for its database.

Plan and support

Starter, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.

Region

Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where machines are priced per month. On Starter, Pilae chooses the site.

Sign-on and integrations

Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Grafana: common questions

Also in workflow and data