Observability Azure

Parseable on Ubuntu 24.04 on Azure User Guide

| Product: Parseable on Ubuntu 24.04 LTS on Azure

Overview

This guide covers the deployment and configuration of Parseable 3.0.0 on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Parseable is a fast, open source log analytics and observability platform built in Rust on a data-lake architecture. You point your logs, metrics, traces and events at its HTTP ingest API, then explore them in a built-in web UI backed by a SQL query engine — a lean, cost-efficient alternative to Elasticsearch or Splunk that compresses columnar telemetry to keep storage small.

The image installs the official Parseable v3.0.0 release binary (a single Rust binary) verified by both the upstream SHA-1 and a SHA-256 checksum at install time, and ships the AGPL-3.0 licence text alongside it. Parseable runs in local-storage mode, staging and storing all telemetry on the VM's own disk, so there is no external object store, no separate database and no extra network port to secure.

Security model. Upstream Parseable ships a default admin / admin login (the P_USERNAME / P_PASSWORD environment variables); this image never exposes it. Parseable binds to 127.0.0.1:8000 only and is fronted by nginx, which terminates TLS on port 443 with a certificate generated uniquely for your instance on first boot; port 80 redirects to HTTPS. Every Parseable endpoint — the web UI, the ingest API, the query API and stream management — is guarded by Parseable's own HTTP Basic Auth, so nothing that reads or writes your telemetry is reachable without the per-instance admin credential. Only the standard /api/v1/liveness and /api/v1/readiness health probes answer without authentication. The only ports exposed are SSH (22), the HTTPS UI/API (443) and the HTTP redirect (80).

What is included:

  • Parseable 3.0.0 official release binary at /usr/local/bin/parseable (SHA-1 + SHA-256 verified)

  • parseable.service systemd unit running the server in local-store mode, bound to 127.0.0.1:8000

  • nginx reverse proxy terminating TLS on port 443 (per-VM self-signed certificate), with port 80 redirecting to HTTPS

  • parseable-firstboot.service systemd oneshot that mints the per-VM admin password and the per-VM TLS certificate on first boot

  • Local filesystem storage — data at /var/lib/parseable/data, staging at /var/lib/parseable/staging — with no external object store or database

  • A credential self-test at /usr/local/sbin/parseable-credcheck.sh

  • The AGPL-3.0 licence text at /usr/local/share/parseable/LICENSE

  • Ubuntu 24.04 LTS base with latest security patches applied at build time

  • 24/7 cloudimg support with guaranteed 24 hour response SLA

Prerequisites

  • An active Azure subscription

  • A subscription to the Parseable on Ubuntu 24.04 listing on Azure Marketplace

  • An SSH public key for VM authentication

  • A virtual network and subnet in the target region

Recommended virtual machine size: Standard_B2s (2 vCPU, 4 GB RAM). Parseable is efficient; scale up CPU, memory and disk as your ingest volume and retention grow.

Step 1: Deploy from the Azure Portal

Navigate to Marketplace in the Azure Portal, search for Parseable, select the cloudimg publisher entry, and click Create.

On the Networking tab attach a network security group that allows inbound TCP 22 from your management IP range, and TCP 443 (and 80 for the HTTP-to-HTTPS redirect) from the networks that will send telemetry and use the UI. Every endpoint is protected by the per-VM admin credential, but you should still restrict source ranges.

Click Review + create, wait for validation, then Create. Deployment takes around two minutes.

Step 2: Deploy from the Azure CLI

RG="parseable-prod"
LOCATION="eastus"
az group create --name "$RG" --location "$LOCATION"

az vm create \
  --resource-group "$RG" \
  --name parseable-01 \
  --image <publisher>:<offer>:<sku>:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

# Allow SSH (22), HTTPS (443) and the HTTP->HTTPS redirect (80) from your trusted ranges
az vm open-port --resource-group "$RG" --name parseable-01 --port 22 --priority 1001
az vm open-port --resource-group "$RG" --name parseable-01 --port 443 --priority 1002
az vm open-port --resource-group "$RG" --name parseable-01 --port 80 --priority 1003

Replace <publisher>:<offer>:<sku> with the URN shown on the Marketplace listing's Usage Information tab.

Step 3: Connect via SSH

ssh azureuser@<vm-public-ip>

Use the private key that matches the public key you supplied at deploy time. The login user for this image is azureuser.

Step 4: Verify the Parseable Service

Confirm the Parseable server and the nginx proxy are running, and check the listening sockets. Parseable binds to 127.0.0.1:8000 only — it is reachable off the VM solely through nginx on port 443. The AGPL-3.0 licence ships with the image.

parseable --version
systemctl is-active parseable nginx
sudo ss -ltn | grep -E ':443 |:8000 '
head -2 /usr/local/share/parseable/LICENSE

Expected output:

parseable 3.0.0
active
active
LISTEN 0 2048 127.0.0.1:8000 0.0.0.0:*
LISTEN 0 511 0.0.0.0:443 0.0.0.0:*
LISTEN 0 511 [::]:443 [::]:*
                    GNU AFFERO GENERAL PUBLIC LICENSE
                       Version 3, 19 November 2007

Parseable and nginx active; the server is bound to loopback only while nginx listens on 443, and the AGPL-3.0 licence ships with the image

Step 5: Retrieve Your Per-VM Credentials

On the first boot of your virtual machine, parseable-firstboot.service generated an admin password unique to your instance and a per-instance TLS certificate, and wrote the credentials to a root-only file. Retrieve them with:

sudo cat /root/parseable-credentials.txt

The file reports the HTTPS URL and the admin login:

parseable.url=https://<vm-public-ip>/
parseable.admin.user=admin
parseable.admin.pass=<generated-per-vm>

A shipped self-test confirms the whole credential model without printing any secret — it proves the HTTP-to-HTTPS redirect, that the upstream admin/admin default (and common guesses) are rejected, and that the per-VM credential is accepted:

sudo bash /usr/local/sbin/parseable-credcheck.sh

Expected output:

OK

The per-VM credentials file (values redacted) and the credential self-test reporting OK

Step 6: Understand the Access Model

Every Parseable endpoint is guarded by the per-VM admin credential; only the health probes answer without authentication. The upstream admin/admin default is rejected. You can see the gate with curl (the -k flag accepts the per-VM self-signed certificate):

AP=$(sudo grep '^parseable.admin.pass=' /root/parseable-credentials.txt | cut -d= -f2-)
curl -ks -o /dev/null -w 'liveness (no auth)      -> HTTP %{http_code}\n' https://127.0.0.1/api/v1/liveness
curl -ks -o /dev/null -w 'API no auth             -> HTTP %{http_code}\n' https://127.0.0.1/api/v1/logstream
curl -ks -o /dev/null -w 'API default admin:admin -> HTTP %{http_code}\n' -u 'admin:admin' https://127.0.0.1/api/v1/logstream
curl -ks -o /dev/null -w 'API per-VM admin        -> HTTP %{http_code}\n' -u "admin:$AP" https://127.0.0.1/api/v1/logstream

Expected output:

liveness (no auth)      -> HTTP 200
API no auth             -> HTTP 401
API default admin:admin -> HTTP 403
API per-VM admin        -> HTTP 200

The liveness probe answers without authentication while the API returns 401 without credentials, 403 for the upstream admin/admin default, and 200 with the per-VM password

Step 7: Sign In to the Web UI

In a browser, go to https://<vm-public-ip>/. Because the certificate is self-signed and generated per VM, your browser will warn on the first visit — accept it (or install a CA-signed certificate as in Step 11). Sign in with user admin and the parseable.admin.pass from Step 5:

The Parseable sign-in page served over TLS

Once signed in you land on the Parseable console, where you can create log streams, explore ingested events and run SQL queries:

The Parseable console after sign-in, showing the streams and query workspace

Step 8: Create a Stream and Ingest Logs

Parseable organises telemetry into log streams. Create one, then ship events to it with an authenticated POST to /api/v1/ingest, using the X-P-Stream header to name the stream and a JSON array as the body. Run this from any client that can reach the VM (here we use the VM itself over loopback):

AP=$(sudo grep '^parseable.admin.pass=' /root/parseable-credentials.txt | cut -d= -f2-)

# Create the stream
curl -ks -o /dev/null -w 'create stream -> HTTP %{http_code}\n' \
  -X PUT -u "admin:$AP" https://127.0.0.1/api/v1/logstream/demoapp

# Ingest a batch of events
curl -ks -o /dev/null -w 'ingest        -> HTTP %{http_code}\n' \
  -X POST -u "admin:$AP" -H 'X-P-Stream: demoapp' -H 'Content-Type: application/json' \
  --data '[
    {"host":"web-01","level":"info","service":"checkout","status":200,"message":"order placed"},
    {"host":"web-02","level":"warn","service":"checkout","status":200,"message":"slow response"},
    {"host":"api-01","level":"error","service":"payments","status":504,"message":"gateway timeout"}
  ]' https://127.0.0.1/api/v1/ingest

Expected output:

create stream -> HTTP 200
ingest        -> HTTP 200

Parseable detects the schema from the JSON automatically and stamps every event with a p_timestamp. Point your real applications, agents and log shippers (Fluent Bit, Vector, the OpenTelemetry collector and more) at the same /api/v1/ingest endpoint.

A demo log stream created and events ingested through the Parseable HTTP API

Step 9: Query Your Logs with SQL

Query a stream with an authenticated POST to /api/v1/query, passing SQL and a time window. The response is a JSON array of rows:

AP=$(sudo grep '^parseable.admin.pass=' /root/parseable-credentials.txt | cut -d= -f2-)
T0=$(date -u -d '-1 hour' +%Y-%m-%dT%H:%M:%SZ)
T1=$(date -u -d '+1 hour' +%Y-%m-%dT%H:%M:%SZ)

curl -ks -u "admin:$AP" -H 'Content-Type: application/json' \
  --data "{\"query\":\"SELECT host, level, service, status, message FROM demoapp ORDER BY status DESC\",\"startTime\":\"$T0\",\"endTime\":\"$T1\"}" \
  https://127.0.0.1/api/v1/query | jq -c '.[]'

Expected output:

{"host":"api-01","level":"error","service":"payments","status":504.0,"message":"gateway timeout"}
{"host":"web-02","level":"warn","service":"checkout","status":200.0,"message":"slow response"}
{"host":"web-01","level":"info","service":"checkout","status":200.0,"message":"order placed"}

The same SQL runs interactively in the web UI, where you can build filters, save queries and chart results.

Step 10: Change the Admin Password

The admin credential is driven by the P_PASSWORD environment variable, kept in a root-only env file. To rotate it, edit the value and restart the service:

sudoedit /etc/parseable/parseable.cred.env   # change the P_PASSWORD= line
sudo systemctl restart parseable

Step 11: Put a CA-Signed Certificate in Front (Production)

The image ships a per-VM self-signed certificate. For production, replace it with a CA-signed certificate on the bundled nginx. Point your DNS A record at the VM's public IP, open port 443 in the network security group, then:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

Certbot updates the bundled nginx vhost in place, preserving the reverse-proxy access model.

Step 12: Connect Object Storage for Scale-Out (Optional)

By default Parseable stores telemetry on the VM's local disk (local-store). To store data in an S3-compatible object store instead — the basis of a distributed Parseable deployment — switch the service to s3-store and provide your bucket details. Edit the systemd unit's ExecStart to parseable s3-store and add the S3 settings to /etc/parseable/parseable.env:

# /etc/parseable/parseable.env (S3-compatible object store)
P_S3_URL=https://s3.<region>.amazonaws.com
P_S3_ACCESS_KEY=<access-key>
P_S3_SECRET_KEY=<secret-key>
P_S3_REGION=<region>
P_S3_BUCKET=<bucket>

See the Parseable storage documentation for the full list of object-store settings (AWS S3, MinIO, Azure Blob and GCS are all supported).

Step 13: Managing the Parseable Service

# Status and logs
systemctl status parseable --no-pager
sudo journalctl -u parseable -n 100 --no-pager

# Restart after changing configuration
sudo systemctl restart parseable

# nginx (the TLS reverse proxy)
sudo nginx -t && sudo systemctl reload nginx

Architecture Summary

  • Parseable 3.0.0 — a single Rust binary at /usr/local/bin/parseable, run as the non-root parseable service account under systemd in local-store mode, bound to 127.0.0.1:8000.

  • nginx on port 443 — terminates TLS with a per-VM certificate and reverse-proxies to Parseable; port 80 redirects to HTTPS. Every Parseable endpoint is authenticated by Parseable itself.

  • Local filesystem storage — data at /var/lib/parseable/data, staging at /var/lib/parseable/staging, on the VM's own disk — no external object store, no database, no database port.

  • First-boot service mints a per-VM admin password and a per-VM TLS certificate, sets the public URL, and writes the credentials to a root-only file. The upstream admin/admin default never ships, and no two VMs share a secret.

Support

cloudimg provides 24/7 technical support for this Parseable image by email (support@cloudimg.co.uk) and live chat, with a guaranteed 24 hour response SLA and a one hour average response time for critical issues. We help with deployment, retrieving and rotating the first-boot admin password, adding HTTPS with a custom domain and a CA-signed certificate, repointing Parseable at S3-compatible object storage, using the ingest and query APIs, creating and managing log streams, retention and performance tuning, upgrades and patch management, and troubleshooting. For billing, subscription changes or refund requests, contact support@cloudimg.co.uk.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.