Apache SkyWalking

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a 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.

In the network security group (NSG), allow inbound 22/tcp from your management network and 80/tcp for the web UI. For public exposure, front the UI with TLS (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 SecureAnyCloud, and choose Create. On the Basics tab, choose 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).

On the Disks tab, review the dedicated data disk. Then choose Review + create, followed by Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:apache-skywalking-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name skywalking \
  --image sac1647283583153:apache-skywalking-ubuntu-24-04:default:latest \
  --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 initialize fully on first boot. When the UI reports active, the platform is ready.

Step 5 - Retrieve your web UI password

The first boot of your VM generates a unique UI password and writes it 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 in a safe place.

Step 6 - Check the health endpoint

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

curl -s http://localhost/health

The endpoint 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). The dashboards fill 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 stays 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 in 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 application with the agent attached and pointed 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. It can ingest OpenTelemetry, Zipkin and service-mesh (Envoy ALS) telemetry 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 (the loopback query port has no authentication):

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 only one consumer of it.

The VM also listens on these ports: 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 that 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. Check the mount:

findmnt /var/lib/skywalking

A separate Azure data disk, captured into the image and re-provisioned on every VM, backs the mount. 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. Add a DNS name for the VM, then either use the companion SecureAnyCloud 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. You can secure the agent ports (11800/12800) 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 settings are in /etc/default/skywalking-ui, and the BanyanDB settings are in /etc/default/skywalking-banyandb. Edit the file, then run sudo systemctl restart skywalking-oap (or the relevant unit) to apply the change.

• 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 stays enabled, so the OS keeps receiving security updates automatically.

Support

SecureAnyCloud provides 24/7 support for this image. Contact sales@secureanycloud.com.

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

Deploy on Azure

Launch Apache SkyWalking on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Prerequisites

Before you deploy this image, make sure you have:

• An Amazon Web Services account where you can launch EC2 instances

• IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products

• An EC2 key pair in the target Region for SSH access to the instance

• A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network and port 80 from where you will reach the UI

• An SSH client and a web browser on your workstation

Launching from the AWS Marketplace

• Open the product page in AWS Marketplace and choose Continue to Subscribe

• Accept the terms, then choose Continue to Configuration

• Choose the software version and the Region you want to deploy into, then choose Continue to Launch

• Choose Launch through EC2 for full control of networking and storage

• Choose an instance type. m5.large is the recommended minimum. Scale up as your trace and metric volume grows, because the OAP backend and BanyanDB are memory-hungry

• Choose your VPC, subnet, key pair and a security group that allows inbound 22 (SSH) from your management network and 80 (UI) from where you will browse

• Launch the instance and wait for the status checks to pass

Launching from the AWS CLI

You can launch the same AMI from the command line. Replace the AMI ID, key name, subnet and security group with your own values:

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name your-key \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=skywalking}]'

Connecting to your instance

Connect over SSH on port 22 as the default login user for your operating system variant:

OS variant SSH login user

Ubuntu 24.04 LTS ubuntu

ssh -i /path/to/your-key.pem ubuntu@<public-ip>

Retrieve the per-instance UI password

The first boot of your instance generates the UI password and writes it to a root-only file. Read the file with:

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

The file shows the generated password, the sign-in user (admin) and a note about the agent receiver ports:

SKYWALKING_URL=http://<public-ip>/ SKYWALKING_UI_USER=admin SKYWALKING_UI_PASSWORD=<set-at-first-boot>

Confirm the services are running

systemctl is-active skywalking-banyandb skywalking-oap skywalking-ui nginx

All four report active:

active active active active

The OAP JVM can take 30 to 60 seconds to finish starting on a cold boot. If a service is still activating, wait a moment and run the command again.

Confirm the UI and its authentication

The nginx health endpoint answers without authentication, and the UI itself requires the per-instance password. On the instance, run:

curl -s http://127.0.0.1/health
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/

The health endpoint returns ok, and a request to the UI without credentials is rejected with 401:

ok 401

Sign in to the web UI

Open the SkyWalking web UI in your browser at http://<public-ip>/ (port 80). When the browser prompts for HTTP basic authentication, sign in as admin with the password from the credentials file. The UI opens on the General service view, where you can see service and endpoint metrics, the service topology and distributed traces.

Send telemetry from your applications

To populate the UI, point SkyWalking agents at the instance. The OAP backend receives telemetry on gRPC port 11800 (used by most language agents) and HTTP port 12800. In the instance security group, open those ports to your own application or agent network range, not to the internet. Then configure your agent. For the SkyWalking Java agent, for example:

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

SkyWalking provides native agents for Java, .NET, Node.js, Python, Go, PHP and more, and also accepts OpenTelemetry and Zipkin data through the corresponding receivers.

Prove an end-to-end trace round-trip

You can confirm the full ingest, storage and query path without deploying an agent. Post a synthetic trace segment to the OAP native HTTP receiver, then query it back through the GraphQL API. On the instance, run:

SVC="demo-web-$(date +%s)"
NOW=$(($(date +%s)*1000)) printf '%s' "[{\"traceId\":\"demo.$(date +%s)\",\"traceSegmentId\":\"demoseg.$(date +%s)\",\"service\":\"$SVC\",\"serviceInstance\":\"$SVC-1\",\"spans\":[{\"operationName\":\"/checkout\",\"startTime\":$NOW,\"endTime\":$((NOW+42)),\"spanId\":0,\"parentSpanId\":-1,\"spanType\":\"Entry\",\"spanLayer\":\"Http\",\"componentId\":49,\"isError\":false,\"skipAnalysis\":false}]}]" > /tmp/seg.json curl -s -o /dev/null -w 'ingest HTTP %{http_code}\n' -H 'Content-Type: application/json' -X POST http://127.0.0.1:12800/v3/segments -d @/tmp/seg.json printf '%s' '{"query":"query{services:listServices(layer:\"GENERAL\"){name}}"}' > /tmp/q.json for i in $(seq 1 20); do
R=$(curl -s -H 'Content-Type: application/json' -d @/tmp/q.json http://127.0.0.1:12800/graphql); echo "$R" | grep -q "$SVC" && { echo "queried back: found $SVC"; break; }; sleep 3; done

The receiver accepts the segment (ingest HTTP 200), and within a few seconds the service is returned by the query API the UI uses:

ingest HTTP 200 queried back: found demo-web-1784939567

The synthetic service and its trace then appear in the web UI on the Service, Topology and Trace views.

Reaching the UI over an SSH tunnel

If you prefer not to open port 80, reach the UI over an SSH tunnel instead. Forward a local port to the nginx front end on the instance:

ssh -i /path/to/your-key.pem -L 8080:127.0.0.1:80 ubuntu@<public-ip>

Then browse http://127.0.0.1:8080/ on your workstation and sign in with the same admin credentials.

Storage, retention and the data volume

Apache BanyanDB stores all SkyWalking telemetry under /var/lib/skywalking/banyandb, on the dedicated EBS data volume. Because the data lives on its own volume, you can resize it independently of the operating system disk and snapshot it for backup. BanyanDB is bound to the loopback interface only, and the OAP backend is its sole client.

To grow the datastore, expand the EBS volume in the AWS console, then extend the filesystem on the instance:

sudo resize2fs $(findmnt -no SOURCE /var/lib/skywalking)

Managing the services

The platform is managed with standard systemd commands:

sudo systemctl status skywalking-oap
sudo systemctl restart skywalking-ui
sudo journalctl -u skywalking-oap -n 100 --no-pager

BanyanDB (skywalking-banyandb) must be running before the OAP backend, and the OAP backend before the UI. Systemd enforces this ordering automatically on boot.

Securing the UI with TLS

The nginx front end serves the UI over plain HTTP on port 80 with basic authentication. For production use, place the instance behind a TLS terminator, either an AWS Application Load Balancer with an ACM certificate or a certificate installed directly in nginx. This encrypts the UI password and telemetry queries in transit. Do not expose the UI to the internet without TLS.

Backup and maintenance

• Back up the observability data by snapshotting the /var/lib/skywalking EBS volume on your own schedule.

• Rotate the UI password by editing /etc/nginx/.htpasswd with sudo htpasswd /etc/nginx/.htpasswd admin, then reload nginx.

• Apply OS updates with sudo apt-get update && sudo apt-get upgrade during a maintenance window. Reboot if a new kernel was installed.

Support

SecureAnyCloud engineers are available around the clock by email and live chat for every deployment. Support covers deployment and sizing guidance, agent instrumentation across languages, exposing the UI securely behind TLS and authentication, Apache BanyanDB storage management and retention, backup and restore of the data volume, and SkyWalking and JVM tuning and troubleshooting. Contact sales@secureanycloud.com.

Apache, Apache SkyWalking and Apache BanyanDB are trademarks of The Apache Software Foundation.

Deploy on AWS

Launch Apache SkyWalking APM and Observability Platform with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com