Apache SkyWalking on Ubuntu 24.04 on Azure User Guide

Overview

Apache SkyWalking is an open-source Application Performance Monitoring (APM) and observability platform. It collects distributed traces, service and instance metrics, logs and service-mesh telemetry from your applications and renders them in a rich web UI with topology maps, service dashboards, trace views and alerting. The cloudimg image installs SkyWalking 10.4.0 as a self-contained single-node appliance: the OAP (Observability Analysis Platform) Java backend, the SkyWalking web UI, and an embedded Apache BanyanDB storage node, all on one VM. The web UI is bound to loopback behind an nginx reverse proxy on TCP 80 with HTTP Basic auth, all telemetry persists on a dedicated Azure data disk, and a unique UI password is generated on the first boot of every VM. The OAP agent receivers (gRPC 11800 and HTTP 12800) are ready for your application agents to report to. Backed by 24/7 cloudimg support.

What is included:

• Apache SkyWalking 10.4.0 (OAP server + web UI) under /opt/skywalking
• Apache BanyanDB 0.10.3 as the single-node storage engine (the storage SkyWalking 10.x is designed around), bound to loopback
• The SkyWalking web UI fronted by nginx on :80 with HTTP Basic auth (the UI has no built-in authentication) and a per-VM password in a root-only file
• The OAP agent-facing receivers: gRPC 11800 (agent data) and HTTP 12800 (the GraphQL query API)
• A dedicated Azure data disk at /var/lib/skywalking holding all observability data and the BanyanDB store, separate from the OS disk and re-provisioned with every VM
• Eclipse Temurin JDK 17 runtime; a dedicated unprivileged skywalking system user
• skywalking-oap.service, skywalking-ui.service and nginx.service as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B4ms (4 vCPU / 16 GiB RAM) is a good starting point; the OAP JVM and BanyanDB are memory-hungry, so scale up for higher trace and metric volumes. NSG inbound: allow 22/tcp from your management network and 80/tcp for the web UI (front with TLS for public exposure — see Enabling HTTPS). To let external application agents report telemetry, also open 11800/tcp (OAP gRPC) and optionally 12800/tcp (OAP HTTP) — see Step 8.

Step 1 — Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Apache SkyWalking by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Review the dedicated data disk on the Disks tab, then Review + create → Create.

Step 2 — Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name skywalking \
  --image <marketplace-image-urn> \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name skywalking --port 80 --priority 1010

Step 3 — Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 — Confirm the services are running

systemctl is-active skywalking-oap.service skywalking-ui.service nginx.service

All three services report active. The OAP JVM takes roughly 30 to 60 seconds to fully initialise on first boot; once the UI reports active the platform is ready.

Step 5 — Retrieve your web UI password

The UI password is generated uniquely on the first boot of your VM and written to a root-only file:

sudo cat /root/apache-skywalking-credentials.txt

This file contains SKYWALKING_UI_USER (admin) and SKYWALKING_UI_PASSWORD, the UI URL, and a reminder of the agent ports to open. Store the password somewhere safe.

Step 6 — Check the health endpoint

nginx serves an unauthenticated health endpoint for load balancers and probes:

curl -s http://localhost/health

It returns ok.

Step 7 — Open the web UI

Browse to http://<vm-public-ip>/ and sign in as admin with the password from Step 5. The UI opens on the Dashboard List, which shows all of SkyWalking's built-in dashboard templates (General Service, Service Mesh, Kubernetes, the AWS and database layers, and more). These dashboards populate with topology maps, metrics and traces once your agents start reporting.

The Marketplace lets you enable the observability modules you need — General Service, Service Mesh (Istio), Kubernetes, Cilium, Infrastructure, Browser, Gateway, virtual databases, caches and message queues:

The Alerting view lists triggered alarms and lets you filter by entity type, keyword and time range. It is empty until you define alarm rules and agents begin reporting:

The Settings page controls UI-wide options such as the display timezone, auto-refresh and metric ranges:

Step 8 — Connect application agents

SkyWalking collects telemetry from agents embedded in your applications. The OAP server on this VM listens for agent data on gRPC 11800 (the protocol most language agents use) and on HTTP 12800. To let agents on other hosts report, open those ports on the VM's network security group:

az vm open-port --resource-group <your-rg> --name skywalking --port 11800 --priority 1020
az vm open-port --resource-group <your-rg> --name skywalking --port 12800 --priority 1030

Then point your agents at this VM. For a Java application, download the SkyWalking Java agent and start your app with the agent attached, pointing it at the OAP gRPC receiver:

java -javaagent:/path/to/skywalking-agent.jar \
     -Dskywalking.agent.service_name=my-service \
     -Dskywalking.collector.backend_service=<vm-public-ip>:11800 \
     -jar my-application.jar

Within a minute the service appears in the UI's service list and Topology map. SkyWalking also ships agents and SDKs for Python, Go, Node.js, .NET, PHP and more, and can ingest OpenTelemetry, Zipkin and service-mesh (Envoy ALS) telemetry — all into the same OAP backend.

Step 9 — Query the OAP GraphQL API

The OAP exposes a GraphQL query API on port 12800 — the same API the UI uses. From the VM you can query it directly (no auth on the loopback query port):

curl -s -H 'Content-Type: application/json' \
  -d '{"query":"query{getGlobalTopology(duration:{start:\"2026-06-22\",end:\"2026-06-22\",step:DAY}){nodes{name}}}"}' \
  http://localhost:12800/graphql; echo

You get a JSON response with a "data" envelope. This is the programmatic entry point for building custom dashboards or exporting metrics; the UI is just one consumer of it.

The OAP also listens on the ports below — nginx on 80, the UI on 8080 (firewalled to loopback), the OAP agent receivers on 11800 and 12800, and BanyanDB on loopback 17912:

Step 10 — Confirm data lives on the dedicated disk

All observability data and the BanyanDB store live on the dedicated Azure data disk so they survive OS changes and can be resized independently:

findmnt /var/lib/skywalking

The mount is backed by a separate Azure data disk captured into the image and re-provisioned on every VM. The BanyanDB storage tree is under /var/lib/skywalking/banyandb.

Enabling HTTPS

The nginx reverse proxy terminates plain HTTP on port 80. For public exposure, put a certificate in front of it. The simplest path is to add a DNS name for the VM and use the companion cloudimg nginx-ssl-certbot image as a TLS reverse proxy, or install certbot and extend the existing nginx site with a listen 443 ssl; server block and your certificate paths. Keep the UI bound to loopback so the only public surface is the authenticated, TLS-terminated proxy. The agent ports (11800/12800) can be secured separately with mutual TLS in the OAP configuration.

Maintenance

• Configuration: OAP settings are environment-driven in /etc/default/skywalking-oap (storage target, agent ports, JVM heap); the UI in /etc/default/skywalking-ui; BanyanDB in /etc/default/skywalking-banyandb. Edit and sudo systemctl restart skywalking-oap (or the relevant unit) to apply.
• Backups: snapshot the /var/lib/skywalking data disk to back up the full BanyanDB store.
• Upgrades: replace the distribution under /opt/skywalking with a newer SkyWalking release and restart the services; keep the BanyanDB version compatible with the OAP API version.
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.

Apache SkyWalking and Apache BanyanDB are trademarks of The Apache Software Foundation. This image is produced by cloudimg and is not affiliated with or endorsed by the Apache SkyWalking project. Apache SkyWalking is distributed under the Apache License 2.0.