Is this page helpful?

Architecture#

../../_images/ov_cloud_banner.jpg

The architecture diagram below illustrates the complete data flow from Kit application logs to your observability platform.

../../_images/obs_architecture.png

The Kit application is embedded with an open-source log processor (vector.dev in this case) to scrape stdout/stderr or log files. Vector is embedded within the same container.

Vector has the following functionalities:

  • Log Capture: Scraping the stdout/stderr or a log file location of the Kit Application.

  • Transformation: Transform plaintext logs into OpenTelemetry (OTel) format required by NVCF.

  • Forwarding: Forward the transformed Kit-OTel logs to the BYOO-OTel collector in the NVCF.

Components#

The following components make up the Observability Kit + Vector solution:

  • Kit Application — Existing Kit App

  • Vector.dev — Open-source log processor that captures, transforms, and forwards logs

  • Dockerfile — Defines the Vector & Kit integration within the same container (copying binaries, configs, and entrypoints)

  • Custom Entrypoint — Orchestrates Vector configuration and application startup (e.g., entrypoint_vector_dev.sh)

  • Vector Configuration — Defines log sources, transforms (VRL), and sinks. Can be provided as Base64 via VECTOR_CONF_B64 or as a static vector.toml

  • NVCF BYOO Collector — Platform component that receives Kit-OTel logs from Vector and routes them to the observability endpoint

  • Customer Cloud BYOO — The observability endpoint (Azure Monitor, Datadog, or Grafana Cloud) that receives container telemetry

Container Architecture#

The enhanced container (Kit + Vector) includes:

  • A Kit App and any extension dependencies

  • Vector binary (/opt/vector/bin/vector)

  • Custom entrypoint script for orchestration

  • Health monitoring script

  • Vector configuration template