Observability Azure

Vector on Ubuntu 24.04 on Azure User Guide

| Product: Vector Observability Pipeline on Ubuntu 24.04 LTS on Azure

Overview

This guide covers the deployment and configuration of Vector on Ubuntu 24.04 on Azure using cloudimg Azure Marketplace images. Vector is a fast, vendor neutral observability data pipeline developed by Datadog. It collects logs, metrics and traces, reshapes them with a powerful transform language, and routes them to the destinations you choose, all as a single self contained binary driven entirely by one plain text configuration file, with no database and no agent fleet to manage.

The image installs the pinned official Vector 0.57.0 release, verified by checksum, and runs it under systemd as the unprivileged vector user.

Ready on first boot. The image ships a working demo pipeline so Vector is processing data the moment the VM boots: a demo_logs source generates sample Apache log events, a remap transform parses each event with Vector Remap Language (VRL) and stamps a marker field, and the results fan out to a console sink (JSON to the journal) and a file sink on disk. You replace the demo source and sinks with your own when you are ready (see Step 8).

Security by design — nothing exposed by default. Vector's optional GraphQL API is a management surface. This image binds it to loopback only (127.0.0.1:8686), so vector top and vector tap work locally while nothing, including the GraphQL playground, is reachable off the box. The demo pipeline's only source is a self contained generator, so the image opens no listening data port. The only inbound port is SSH 22.

Security by design — no baked credential. Vector has no login and no admin password, and the shipped configuration contains no secrets, tokens or keys. The per VM details written to /root/vector-credentials.txt on first boot are just endpoint notes, not a secret. If you later add a sink that needs a token, supply it as an environment variable at deploy time (Step 8).

What is included:

  • Vector 0.57.0 (pinned, checksum verified), run under systemd as the unprivileged vector user (vector.service)

  • A working demo pipeline: a demo_logs source, a remap (VRL) transform, and console plus file sinks

  • The optional GraphQL API bound to loopback only (127.0.0.1:8686), so vector top works locally but nothing is exposed off the box

  • No listening data port by default and no secret baked into the image

  • Unattended security upgrades left enabled so the OS keeps receiving patches

Prerequisites

  • Active Azure subscription, SSH public key, VNet and subnet in the target region

  • Subscription to the Vector listing on Azure Marketplace

  • A Network Security Group rule allowing TCP 22 for administration

Recommended virtual machine size: Standard_B2s (2 vCPU, 4 GB RAM) for a light pipeline. Pipelines handling heavy event volumes should use Standard_D2s_v5 or larger, and Vector scales well with more CPU.

Step 1: Deploy from the Azure Portal

Search Vector in Marketplace, select the cloudimg publisher, and click Create. Configure the Network Security Group to allow TCP 22 for administration. Vector does not need any inbound data port for the demo pipeline; if you later add a network source (for example a syslog or http_server source), open only the ports that source listens on.

Step 2: Deploy from the Azure CLI

RG="observability-prod"; LOCATION="eastus"; VM_NAME="vector1"
GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-cloudimg/providers/Microsoft.Compute/galleries/cloudimgGallery/images/vector-ubuntu-24-04/versions/<version>"
SSH_KEY="$(cat ~/.ssh/id_rsa.pub)"
az group create --name "$RG" --location "$LOCATION"
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
# Open the admin port on the VM's NSG:
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1001

Step 3: First boot

On first boot the image resolves the VM address for its documentation, asserts the GraphQL API is bound to loopback only, validates the pipeline config, starts Vector, confirms the demo pipeline is moving events, and writes /root/vector-credentials.txt. This completes within a minute. SSH in as azureuser and read the details:

sudo cat /root/vector-credentials.txt

The details file records the loopback API endpoint, the demo sink directory, and confirms the demo pipeline is flowing. Vector has no login and no baked secret, so there is no password to retrieve.

Step 4: Confirm the service is running

vector.service is active, vector --version reports the pinned release, vector validate reports the config valid, and the loopback GraphQL API answers /health with {"ok":true}.

systemctl is-active vector.service
vector --version
sudo vector validate /etc/vector/vector.yaml
curl -s http://127.0.0.1:8686/health

Expected output:

active
vector 0.57.0 (x86_64-unknown-linux-gnu 8832452 2026-07-14)
√ Loaded ["/etc/vector/vector.yaml"]
√ Health check "console_out"
√ Health check "file_archive"
                           Validated
{"ok":true}

vector.service reports active, vector --version shows the pinned 0.57.0 release, vector validate loads the config and passes the console and file sink health checks reporting Validated, and a curl to the loopback GraphQL API health endpoint returns ok true

Step 5: Review the demo pipeline

The pipeline is defined entirely in /etc/vector/vector.yaml: a demo_logs source generates sample Apache log lines, a remap transform parses each line with VRL and adds an env marker, and the events fan out to a console sink and a file sink.

sudo cat /etc/vector/vector.yaml

The shipped pipeline looks like this:

api:
  enabled: true
  address: "127.0.0.1:8686"

sources:
  demo_logs:
    type: demo_logs
    format: apache_common
    interval: 1.0

transforms:
  parse_and_tag:
    type: remap
    inputs: [demo_logs]
    source: |
      . = parse_apache_log!(.message, format: "common")
      .env = "cloudimg-demo"
      .processed_by = "vector"

sinks:
  console_out:
    type: console
    inputs: [parse_and_tag]
    encoding:
      codec: json
  file_archive:
    type: file
    inputs: [parse_and_tag]
    path: "/var/lib/vector/demo-out/apache-%Y-%m-%d.log"
    encoding:
      codec: json

the shipped etc vector vector.yaml demo pipeline config showing the loopback api block on 127.0.0.1 8686, a demo_logs source in apache_common format, a remap transform that parses each event and adds the cloudimg-demo env marker, and console plus file sinks encoding json

Step 6: See events flowing source to sink

The console sink writes structured JSON events to the journal, and the file sink writes the same events to disk. Both carry the parsed Apache fields (method, status, host) and the env: cloudimg-demo marker added by the transform, so you can see the full round trip from source through transform to sink.

sudo journalctl -u vector.service -n 5 -o cat
sudo tail -n 3 /var/lib/vector/demo-out/apache-*.log

Expected output (one event per line, structured JSON):

{"env":"cloudimg-demo","host":"232.142.241.76","message":"HEAD /user/booperbot124 HTTP/1.0","method":"HEAD","path":"/user/booperbot124","processed_by":"vector","protocol":"HTTP/1.0","size":22106,"status":200,"timestamp":"2026-07-18T13:33:53Z","user":"cache_cowboy"}

journalctl for the vector service shows structured JSON events from the console sink and tail of the demo out apache log file shows the same events on disk, each carrying the parsed apache fields method status and host plus the env cloudimg-demo marker added by the remap transform, proving events flow from source through transform to sink

Step 7: Watch live pipeline throughput

The demo pipeline is continuously moving events. You can watch its live throughput with vector top, an interactive terminal dashboard that reads the loopback GraphQL API and shows events in and out for every component:

vector top

You can also see the file sink growing as events land on disk, which is a quick way to confirm the pipeline is actively flowing:

sudo bash -c 'C1=$(wc -l < /var/lib/vector/demo-out/apache-*.log); sleep 5; C2=$(wc -l < /var/lib/vector/demo-out/apache-*.log); echo "events on disk: $C1 -> $C2"'

the vector top terminal dashboard reads the loopback graphql api and lists each pipeline component, the demo_logs source, the parse_and_tag transform and the console and file sinks, with the running count of events received and sent, and the file sink line count grows over five seconds confirming the pipeline is actively moving data

Step 8: Build your own pipeline

Replace the demo source and sinks in /etc/vector/vector.yaml with your own. Vector has a large catalogue of sources (files, journald, syslog, Kafka, HTTP, cloud services), transforms (remap/VRL, filter, sample, aggregate, route) and sinks (Elasticsearch, Loki, S3, Kafka, HTTP, Datadog and many more). For example, to tail a log file, redact a field with VRL and forward to an HTTP endpoint:

sources:
  app_logs:
    type: file
    include: ["/var/log/myapp/*.log"]

transforms:
  redact:
    type: remap
    inputs: [app_logs]
    source: |
      .message = redact(.message, filters: ["us_social_security_number"])

sinks:
  backend:
    type: http
    inputs: [redact]
    uri: "https://logs.example.com/ingest"
    encoding:
      codec: json

If a sink needs a secret (an API token, for example), do not put it in the config file. Supply it as an environment variable in /etc/default/vector and reference it, then enable env interpolation, since Vector 0.57 disables it by default as a security hardening measure:

# /etc/default/vector
VECTOR_DANGEROUSLY_ALLOW_ENV_VAR_INTERPOLATION=true
BACKEND_TOKEN=your-secret-token

Always validate a change before applying it, then reload Vector so it picks up the new config without dropping in flight events:

sudo vector validate /etc/vector/vector.yaml

Apply the change with a graceful reload (documented in Step 9).

Step 9: Manage the service

Vector is managed with systemd and the vector CLI. Common operations:

systemctl status vector.service --no-pager
sudo vector validate /etc/vector/vector.yaml

To apply a config change without dropping events, send a graceful reload:

sudo systemctl reload vector

To inspect a running pipeline live, vector top shows throughput per component and vector tap streams events out of any component for debugging:

vector top
vector tap parse_and_tag

Step 10: Security recommendations

  • Keep the API on loopback. The GraphQL API is bound to 127.0.0.1:8686 so it is not reachable off the box. Do not change api.address to 0.0.0.0 unless you place strong network controls in front of it, since the API is unauthenticated.

  • Open only the ports your sources need. The demo pipeline needs no inbound data port. If you add a network source, open only that source's port on the NSG, and only from the networks that should reach it.

  • Keep secrets out of the config file. Supply sink credentials through /etc/default/vector environment variables rather than hard coding them in vector.yaml.

  • Reduce before you route. Use filter, sample and remap transforms to drop noise and redact sensitive fields at the edge, which lowers both risk and downstream storage cost.

  • Keep the OS and Vector patched. Unattended security upgrades remain enabled for the OS. Track new Vector releases and update the binary when you upgrade.

Step 11: Support and Licensing

Vector is developed by Datadog and distributed under the Mozilla Public License 2.0 (MPL-2.0), free and open source with no per CPU or per deployment fee. This cloudimg image bundles the unmodified official Vector release. cloudimg provides the packaging, the working demo pipeline, the loopback only API posture, the no exposed data port and no baked secret defaults, and 24/7 support with a guaranteed 24 hour response SLA.

cloudimg is not affiliated with or endorsed by Datadog. Vector is a mark of its respective owner and is used here only to identify the software.

Deploy on Azure

Find Vector on Ubuntu 24.04 LTS on the Azure Marketplace, published by cloudimg. Deploy from the Portal or the Azure CLI as shown above.

Need Help?

Email support@cloudimg.co.uk for deployment help, configuration questions, or licensing enquiries.