OpenObserve 1.1.2 + Vector 0.60.0 on AWS User Guide

Overview

This guide covers launching and using the OpenObserve 1.1.2 + Vector 0.60.0 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg log management listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

OpenObserve is an open source observability platform for logs, metrics and traces with a built in web interface, SQL search, dashboards and alerts. Vector is an open source, high performance pipeline for collecting, transforming and routing logs and metrics. In this image they arrive wired together: Vector collects this instance's own journal logs and host metrics and accepts telemetry from your other machines, and ships all of it into OpenObserve. When you first sign in, your instance's logs and metrics are already there.

journald (host logs) ----\
host metrics -------------+--> Vector --(dedicated ingestion token)--> OpenObserve
your other machines ------/
   https://<host>/ingest/  (JSON over HTTPS, Basic auth)
   https://<host>/otlp/    (OpenTelemetry OTLP/HTTP, Basic auth)

The cloudimg image adds:

• A working pipeline from the first boot. Host logs land in the host_logs stream, host metrics in host_metrics, and a Host Overview (Vector) dashboard charts them. First boot proves the pipeline by writing a tagged line to the journal and reading that exact line back from OpenObserve before it finishes.
• HTTPS from the first boot. nginx is the only network entry point and serves the web interface and both ingest endpoints on port 443 with a certificate generated on your instance's first boot. Port 80 only redirects to HTTPS.
• Credentials unique to your instance. The image ships an empty store and no secrets. First boot generates the OpenObserve root password, the ingest user's password and the certificate, and has OpenObserve issue a dedicated ingestion token for Vector, then writes them to the root only file /root/openobserve-vector-credentials.txt. No two instances share a secret.
• Vector never holds your root login. It authenticates to OpenObserve with an organisation ingestion token, which OpenObserve accepts for ingestion only: the token cannot search, list streams or read dashboards.
• Everything internal on loopback. OpenObserve (HTTP 127.0.0.1:5080, gRPC 127.0.0.1:5081) and Vector (API 127.0.0.1:8686, HTTP source 127.0.0.1:9880, OTLP 127.0.0.1:4318 and 127.0.0.1:4317) are not reachable from the network.
• Fail closed. nginx refuses to start until first boot has finished, and OpenObserve and Vector will not start without the credentials first boot creates.
• Instance role access for Vector only. Vector uses the instance's IAM role via IMDSv2; no other service on the image can reach IMDS (the base OS's cloud-init and SSM Agent aside). Attach an IAM role if you add Vector's S3, CloudWatch Logs or Kinesis sinks. OpenObserve and nginx are blocked from the instance metadata service, so an alert webhook or URL import cannot be turned against the instance's credentials.
• Hardened web front end. Requests for a host name the instance does not serve are dropped, cross site requests and WebSocket upgrades are refused, session cookies are marked Secure, OpenObserve's own metrics endpoint is not exposed, and nginx logs the real client address rather than any X-Forwarded-For header a client sends.
• Data on its own volume. Everything OpenObserve stores lives on a separate 20 GiB EBS volume mounted at /var/lib/openobserve, which you can grow independently of the system disk.
• Key only SSH. Password logins, root logins and X11 forwarding are switched off.
• Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.

What is on the image: OpenObserve 1.1.2, the unmodified upstream open source build (/usr/local/bin/openobserve, GNU AGPL v3.0); Vector 0.60.0, the official release package (/usr/bin/vector, MPL 2.0); nginx; Ubuntu 24.04 LTS; cloud-init and the AWS Systems Manager agent.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route to the internet (or a private route you use for management).
• A security group that allows TCP 22 (SSH), TCP 443 (web interface and ingest) and TCP 80 (redirects to HTTPS) from your own networks and the machines that send data only. Never open 5080, 5081, 8686, 9880, 4317 or 4318; those ports listen on loopback.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick OpenObserve 1.1.2 + Vector 0.60.0 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large or larger (OpenObserve caches recent data in memory, so give busy instances more RAM), your key pair and a security group as above. The AMI includes a 20 GiB data volume; increase its size on the Configure storage step if you expect to keep a lot of data. Under Advanced details, keep Metadata version at V2 only and set the Metadata response hop limit to 1.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled,HttpPutResponseHopLimit=1 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=openobserve-vector}]'

Add --iam-instance-profile Name=<profile> only if you will configure Vector to write to AWS services (Step 10).

Step 2: Connect to your instance

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

The login message shows the web address and where to find the credentials.

Step 3: Check the services

First boot takes under a minute: it creates the credentials and the certificate, starts OpenObserve on an empty store, has it issue Vector's ingestion token, starts Vector, proves the pipeline end to end, and then nginx starts in front of everything:

systemctl is-active openobserve-vector-firstboot openobserve vector nginx
sudo test -f /var/lib/cloudimg/openobserve-vector-firstboot.done && echo FIRSTBOOT_DONE
/usr/local/bin/openobserve --version
vector --version | cut -d' ' -f1,2
curl -s http://127.0.0.1:5080/config | jq -r '"build_type=\(.build_type) commit=\(.commit_hash)"'

active
active
active
active
FIRSTBOOT_DONE
openobserve v1.1.2
vector 0.60.0
build_type=opensource commit=d16d693ba99bc20621a58b948ecbcad7ec7fa882

build_type=opensource and the commit of the upstream v1.1.2 tag confirm the open source build of OpenObserve.

Only SSH and nginx listen on public addresses; OpenObserve and Vector listen on loopback:

sudo ss -Hlntp | awk '{print $4, $6}' | grep -v '127.0.0.5' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | sort

0.0.0.0:22 users:(("sshd"),("systemd"))
0.0.0.0:443 users:(("nginx"),("nginx"),("nginx"))
0.0.0.0:80 users:(("nginx"),("nginx"),("nginx"))
127.0.0.1:4317 users:(("vector"))
127.0.0.1:4318 users:(("vector"))
127.0.0.1:5080 users:(("openobserve"))
127.0.0.1:5081 users:(("openobserve"))
127.0.0.1:8686 users:(("vector"))
127.0.0.1:9880 users:(("vector"))
[::]:22 users:(("sshd"),("systemd"))
[::]:443 users:(("nginx"),("nginx"),("nginx"))
[::]:80 users:(("nginx"),("nginx"),("nginx"))

The data lives on its own EBS volume:

findmnt -no TARGET,SOURCE,FSTYPE /var/lib/openobserve
df -h --output=size,target /var/lib/openobserve

/var/lib/openobserve /dev/nvme1n1 ext4
 Size Mounted on
  20G /var/lib/openobserve

SSH accepts keys only: passwords, root logins and X11 forwarding are switched off in /etc/ssh/sshd_config.d/00-cloudimg.conf, which sorts before every other SSH setting. Check the effective values:

sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|x11forwarding|pubkeyauthentication) '

permitrootlogin no
pubkeyauthentication yes
passwordauthentication no
kbdinteractiveauthentication no
x11forwarding no

Step 4: Get your address and credentials

The addresses and user names are in the root only file /root/openobserve-vector-credentials.txt:

sudo grep -E '^(OPENOBSERVE_URL|OPENOBSERVE_USERNAME|INGEST_URL|OTLP_URL|INGEST_USERNAME|OPENOBSERVE_INGEST_USER)=' /root/openobserve-vector-credentials.txt

OPENOBSERVE_URL=https://ec2-<public-ip-dashed>.compute-1.amazonaws.com/
OPENOBSERVE_USERNAME=admin@openobserve.local
INGEST_URL=https://ec2-<public-ip-dashed>.compute-1.amazonaws.com/ingest/
OTLP_URL=https://ec2-<public-ip-dashed>.compute-1.amazonaws.com/otlp/
INGEST_USERNAME=ingest
OPENOBSERVE_INGEST_USER=default

The same file holds three secrets, all unique to this instance: OPENOBSERVE_PASSWORD (the web interface and API root login), INGEST_PASSWORD (the login your other machines use for the ingest endpoints) and OPENOBSERVE_INGEST_TOKEN (the token Vector on this instance uses). Show one with, for example, sudo grep '^OPENOBSERVE_PASSWORD=' /root/openobserve-vector-credentials.txt and store them in your password manager.

The address uses the instance's public DNS name from EC2 instance metadata (IMDSv2), or its public or private IPv4 address when it has no public name. The certificate names that host plus the instance's public and private IP addresses:

openssl x509 -in /etc/ssl/cloudimg/openobserve-vector.crt -noout -subject -ext subjectAltName -enddate

subject=CN = ec2-<public-ip-dashed>.compute-1.amazonaws.com, O = cloudimg
X509v3 Subject Alternative Name:
    DNS:ec2-<public-ip-dashed>.compute-1.amazonaws.com, IP Address:<public-ip>, IP Address:<private-ip>, IP Address:127.0.0.1, DNS:localhost
notAfter=<date about 27 months after first boot>

Step 5: Check the logins

Port 80 redirects to HTTPS, /healthz answers without a login, the API refuses a missing or wrong password and accepts yours, Vector's token is refused for reading, the ingest endpoint refuses a missing or wrong login, and a request for a host name the instance does not serve is dropped. The commands read the secrets into shell variables and hand them to curl through a file descriptor, so they never appear in the process list or your shell history:

C=/root/openobserve-vector-credentials.txt
H=$(sudo sed -n 's#^OPENOBSERVE_URL=https://\([^/]*\)/.*#\1#p' $C)
U=$(sudo sed -n 's/^OPENOBSERVE_USERNAME=//p' $C); PW=$(sudo sed -n 's/^OPENOBSERVE_PASSWORD=//p' $C)
TU=$(sudo sed -n 's/^OPENOBSERVE_INGEST_USER=//p' $C); TK=$(sudo sed -n 's/^OPENOBSERVE_INGEST_TOKEN=//p' $C)
CA=/etc/ssl/cloudimg/openobserve-vector.crt; R=(--cacert $CA --resolve "$H:443:127.0.0.1")
curl -s -o /dev/null -w 'http://          -> %{http_code} %{redirect_url}\n' --resolve "$H:80:127.0.0.1" "http://$H/"
curl -s -w ' <- healthz, HTTP %{http_code}\n' "${R[@]}" "https://$H/healthz"
curl -s -o /dev/null -w 'no login         -> HTTP %{http_code}\n' "${R[@]}" "https://$H/api/default/streams"
curl -s -o /dev/null -w 'wrong password   -> HTTP %{http_code}\n' "${R[@]}" -K <(printf 'user = "%s:%s"\n' "$U" not-the-password) "https://$H/api/default/streams"
curl -s -o /dev/null -w 'your password    -> HTTP %{http_code}\n' "${R[@]}" -K <(printf 'user = "%s:%s"\n' "$U" "$PW") "https://$H/api/default/streams"
curl -s -o /dev/null -w 'token, read      -> HTTP %{http_code}\n' "${R[@]}" -K <(printf 'user = "%s:%s"\n' "$TU" "$TK") "https://$H/api/default/streams"
curl -s -o /dev/null -w 'ingest, no login -> HTTP %{http_code}\n' "${R[@]}" -H 'Content-Type: application/json' -d '[{"message":"x"}]' "https://$H/ingest/"
curl -s -o /dev/null -w 'ingest, wrong    -> HTTP %{http_code}\n' "${R[@]}" -K <(printf 'user = "ingest:%s"\n' not-the-password) -H 'Content-Type: application/json' -d '[{"message":"x"}]' "https://$H/ingest/"
curl -s -o /dev/null -w 'metrics          -> HTTP %{http_code}\n' "${R[@]}" "https://$H/metrics"
curl -sk -o /dev/null -w 'other host       -> HTTP %{http_code} (000 = connection dropped)\n' -H 'Host: evil.example' https://127.0.0.1/ || true

http://          -> 301 https://ec2-<public-ip-dashed>.compute-1.amazonaws.com/
{"status":"ok"} <- healthz, HTTP 200
no login         -> HTTP 401
wrong password   -> HTTP 401
your password    -> HTTP 200
token, read      -> HTTP 401
ingest, no login -> HTTP 401
ingest, wrong    -> HTTP 401
metrics          -> HTTP 404
other host       -> HTTP 000 (000 = connection dropped)

--resolve sends the request to this instance while keeping the real host name, so the certificate check passes. From another machine, drop --resolve and use the address directly.

Step 6: See the pipeline at work

The image ships /usr/local/sbin/openobserve-vector-e2e.sh, the same check first boot runs: it writes a uniquely tagged line to the system journal and waits until Vector has delivered that exact line to OpenObserve's host_logs stream. Then list the streams Vector has created:

sudo /usr/local/sbin/openobserve-vector-e2e.sh
C=/root/openobserve-vector-credentials.txt
H=$(sudo sed -n 's#^OPENOBSERVE_URL=https://\([^/]*\)/.*#\1#p' $C)
U=$(sudo sed -n 's/^OPENOBSERVE_USERNAME=//p' $C); PW=$(sudo sed -n 's/^OPENOBSERVE_PASSWORD=//p' $C)
curl -s --cacert /etc/ssl/cloudimg/openobserve-vector.crt --resolve "$H:443:127.0.0.1" -K <(printf 'user = "%s:%s"\n' "$U" "$PW") \
  "https://$H/api/default/streams" | jq -r '[.list[].name | select(startswith("host_"))] | sort | join(" ")'

E2E_PIPELINE_OK tag=cloudimg-e2e-<random> path=journald->vector->openobserve/host_logs
host_logs host_metrics

Each host_logs record is kept narrow and readable: message, service (the systemd unit), severity, host, command, pid, transport and the timestamp. OpenObserve's own routine request logging is filtered out before it is shipped, so the instance does not fill its store with logs about itself.

Step 7: Sign in to the web interface

Open the OPENOBSERVE_URL address from Step 4 in your browser. The certificate is self signed (made on your instance), so your browser asks you to accept it once; Step 11 shows how to use your own name and certificate. Sign in with the email admin@openobserve.local and your OPENOBSERVE_PASSWORD.

Logs with the host_logs stream shows this instance's journal as Vector collected it. Click a field on the left to add it to the table, or type a filter such as service='nginx.service' and choose Run query:

Dashboards holds Host Overview (Vector), provisioned at first boot, with log volume, memory, load average and filesystem usage from the host_logs and host_metrics streams:

Step 8: Send logs from your other machines

Your other machines send to the two authenticated HTTPS endpoints with the INGEST_USERNAME and INGEST_PASSWORD from Step 4. JSON posted to /ingest/ lands in the remote_logs stream. This sends one event the way a remote machine would and then finds it with an SQL search:

C=/root/openobserve-vector-credentials.txt
H=$(sudo sed -n 's#^OPENOBSERVE_URL=https://\([^/]*\)/.*#\1#p' $C)
U=$(sudo sed -n 's/^OPENOBSERVE_USERNAME=//p' $C); PW=$(sudo sed -n 's/^OPENOBSERVE_PASSWORD=//p' $C)
IU=$(sudo sed -n 's/^INGEST_USERNAME=//p' $C); IP=$(sudo sed -n 's/^INGEST_PASSWORD=//p' $C)
R=(--cacert /etc/ssl/cloudimg/openobserve-vector.crt --resolve "$H:443:127.0.0.1")
curl -s -o /dev/null -w 'ingest -> HTTP %{http_code}\n' "${R[@]}" -K <(printf 'user = "%s:%s"\n' "$IU" "$IP") \
  -H 'Content-Type: application/json' -d '[{"message":"order placed","service":"checkout","level":"info"}]' "https://$H/ingest/"
sleep 8
NOW=$(date +%s%6N); FROM=$((NOW - 3600000000))
curl -s "${R[@]}" -K <(printf 'user = "%s:%s"\n' "$U" "$PW") -H 'Content-Type: application/json' \
  -d "{\"query\":{\"sql\":\"SELECT message, service, level FROM \\\"remote_logs\\\" WHERE service = 'checkout'\",\"start_time\":$FROM,\"end_time\":$NOW,\"from\":0,\"size\":1}}" \
  "https://$H/api/default/_search" | jq -c '.hits[0] | {message, service, level}'

ingest -> HTTP 200
{"message":"order placed","service":"checkout","level":"info"}

Search times are in microseconds since the epoch.

OpenTelemetry. Send OTLP logs over HTTP to https://<your-host>/otlp/v1/logs with the same login; they land in the otlp_logs stream. Vector's OTLP receiver takes the OTLP protobuf encoding, which is what OpenTelemetry SDKs and the Collector send by default (http/protobuf). For example, an OpenTelemetry Collector exporter:

exporters:
  otlphttp/cloudimg:
    logs_endpoint: https://<your-host>/otlp/v1/logs
    encoding: proto
    headers:
      Authorization: Basic <base64 of ingest:INGEST_PASSWORD>
    tls:
      ca_file: /etc/otel/openobserve-vector.crt   # or insecure_skip_verify: true while you test

Other agents. Fluent Bit, Vector or any shipper that can POST JSON over HTTPS with Basic auth can use /ingest/. OTLP over gRPC (port 4317) is not exposed; use OTLP over HTTPS as above. Copy /etc/ssl/cloudimg/openobserve-vector.crt to your machines so they can verify the self signed certificate, or install a certificate from your own authority (Step 11), and open port 443 in the security group to their addresses only.

OpenObserve's own ingest APIs are also served at https://<your-host>/api/default/... (JSON, Elasticsearch bulk, OTLP); they take an OpenObserve login rather than the ingest password. For agents that use them, create a separate user in IAM > Users instead of sharing the root login.

Step 9: Check the security settings

OpenObserve and nginx cannot reach the EC2 instance metadata service; Vector can, so its AWS sinks can use the instance's IAM role. Every secret is in a root only file:

for u in openobserve nginx vector; do printf '%-12s IPAddressDeny=%s\n' "$u" "$(systemctl show -p IPAddressDeny --value $u)"; done
sudo stat -c '%a %U:%G %n' /root/openobserve-vector-credentials.txt /etc/openobserve/root-user.env /etc/openobserve/ingest-user.env \
  /etc/nginx/ingest-cred.env /etc/nginx/.htpasswd-ingest /etc/vector/vector.yaml /etc/ssl/cloudimg/openobserve-vector.key
cat /etc/openobserve/web-url.env

openobserve  IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128
nginx        IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128
vector       IPAddressDeny=
600 root:root /root/openobserve-vector-credentials.txt
600 root:root /etc/openobserve/root-user.env
600 root:root /etc/openobserve/ingest-user.env
600 root:root /etc/nginx/ingest-cred.env
640 root:www-data /etc/nginx/.htpasswd-ingest
640 root:vector /etc/vector/vector.yaml
600 root:root /etc/ssl/cloudimg/openobserve-vector.key
ZO_WEB_URL=https://ec2-<public-ip-dashed>.compute-1.amazonaws.com

ZO_WEB_URL is the address OpenObserve uses in links (for example in alert messages). It comes from the configured host name, never from a request. The ingest password is stored for nginx only as a bcrypt hash; Vector re-checks the same login on the requests nginx passes it.

Step 10: Change the Vector pipeline

The pipeline Vector runs is /etc/vector/vector.yaml (owner root, group vector, mode 0640), rendered at first boot from the template /usr/share/cloudimg/vector.yaml.tmpl with this instance's ingestion token and ingest password. Edit the rendered file, check it, and restart Vector:

sudo nano /etc/vector/vector.yaml
sudo vector validate --no-environment /etc/vector/vector.yaml
sudo systemctl restart vector

Typical changes: add Vector sources (files, syslog, Kafka), add host metric collectors, or add a second sink. Vector uses the instance's IAM role via IMDSv2; no other service on the image can reach IMDS, so for S3, CloudWatch Logs or Kinesis sinks attach an IAM role to the instance and never put access keys in the file. Keep every Vector listener on 127.0.0.1 and publish new endpoints through nginx with authentication, as /ingest/ is.

Step 11: Use your own DNS name, certificate or passwords

The served host name comes from configuration, never from a request. To serve the appliance under your own DNS name, point the name at the instance and run the helper, which records the name, makes a new self signed certificate for it, updates ZO_WEB_URL and /root/openobserve-vector-credentials.txt, reloads nginx and restarts OpenObserve:

sudo openobserve-vector-set-hostname logs.example.com

To use a certificate from your own certificate authority instead, put the full chain in /etc/ssl/cloudimg/openobserve-vector.crt and the private key in /etc/ssl/cloudimg/openobserve-vector.key (owner root, mode 0600), then run sudo nginx -t && sudo systemctl reload nginx. Running openobserve-vector-set-hostname again replaces them with a self signed pair.

• Root password: sign in, open IAM > Users, edit admin@openobserve.local and set a new password, then update /root/openobserve-vector-credentials.txt. The value in /etc/openobserve/root-user.env is only used when OpenObserve creates the root user on an empty store.
• Ingest password: run sudo htpasswd -B /etc/nginx/.htpasswd-ingest ingest (it prompts for the new password), put the same password in the password: line of the remote_http source in /etc/vector/vector.yaml, then sudo systemctl restart vector && sudo systemctl reload nginx, and update /etc/nginx/ingest-cred.env and the credentials file.
• Vector's ingestion token: create a new token under Data sources > Manage Tokens, put it in the four password: lines of the oo_* sinks in /etc/vector/vector.yaml, restart Vector, then disable the old token.

Step 12: Storage, backups and operations

• All data (ingested logs, metrics and traces, plus the metadata database with users, dashboards and alerts) is under /var/lib/openobserve on its own EBS volume. Grow it with Modify volume in the EC2 console, then sudo resize2fs <device> (find the device with findmnt /var/lib/openobserve).
• Back up with EBS snapshots of the data volume; for a consistent copy, stop Vector and OpenObserve first (sudo systemctl stop vector openobserve) or snapshot both volumes together.
• Data is kept for 3,650 days by default. Set a shorter retention per stream under Data > Streams, or for the whole instance with ZO_COMPACT_DATA_RETENTION_DAYS=<days> in /etc/openobserve/openobserve.env followed by sudo systemctl restart openobserve, so the volume does not fill.
• Manage the services with systemctl status openobserve vector nginx and read their logs with journalctl -u openobserve -u vector -u nginx. vector top shows live throughput through Vector's loopback API. Unattended upgrades keep Ubuntu and nginx patched; check the listing for newer OpenObserve and Vector versions.

Step 13: Security notes

• Restrict ports 443 and 80 to your team's and your machines' networks; no OpenObserve or Vector port is ever exposed.
• Give each team its own OpenObserve user with the least access it needs instead of sharing the root login; give your machines the ingest login, which can only send data.
• SSH accepts key logins as ubuntu only (no passwords, no root login, no X11 forwarding); use sudo for administration.
• The AMI requires IMDSv2; launch with a metadata hop limit of 1. nginx logs the real client address of every request and ignores X-Forwarded-For headers sent by clients.
• The web interface shows an offer for OpenObserve's commercial edition; this image runs the open source edition and works without it.

Support and licensing

OpenObserve is open source under the GNU Affero General Public License v3.0 and Vector under the Mozilla Public License 2.0. The image runs the unmodified upstream OpenObserve v1.1.2 release and the official Vector 0.60.0 package; the OpenObserve licence and a note with the release checksums and links to the corresponding source code are in /usr/share/doc/openobserve/. There is no per user or per CPU licence fee; the AMI price covers cloudimg's hardening, first boot setup and support.

• Email: support@cloudimg.co.uk
• Website: https://www.cloudimg.co.uk

OpenObserve is developed by OpenObserve Inc. and Vector by Datadog, Inc.; see https://openobserve.ai/docs/ and https://vector.dev/docs/ for the upstream documentation.

OpenObserve is a trademark of OpenObserve Inc. Vector is a Datadog, Inc. project. cloudimg is not affiliated with or endorsed by OpenObserve Inc. or Datadog, Inc.; the names are used only to identify the upstream software.