Skip to main content

NoETL Platform Components

This document describes all components in the NoETL platform, their dependencies, and how they interact with each other.

Architecture Overview

The NoETL platform consists of multiple interconnected components that work together to provide a complete data processing and observability solution in Kubernetes.

Platform Architecture Diagram

This document describes all components in the NoETL platform, their responsibilities, and their dependencies on each other.

All Components

  • PostgreSQL: Running in postgres namespace
  • NoETL Server: Accessible at http://localhost:30082
  • NoETL Workers: All 3 worker pools running (cpu-01, cpu-02, gpu-01)
  • NATS JetStream: Message bus for command notifications (event-driven). See operations/nats_integration.md
  • Grafana: Accessible at http://localhost:3000 (admin/admin)
  • VictoriaMetrics: Running and accessible at http://localhost:8428/vmui/
  • VictoriaLogs: Running and accessible at http://localhost:9428
  • Dashboards: Both NoETL server and worker dashboards provisioned
  • Datasources: Grafana datasources ConfigMap found and provisioned

Architecture Diagram

                            +---------------------+
| PostgreSQL |
| (metadata, jobs) |
+----------^----------+
|
reads/writes via
|
+----------------------+ +-------+--------+ +----------------------+
| VictoriaMetrics |<------| NoETL Server |---+--->| NoETL Workers |
| (metrics storage) | scrapes | (API & UI) | \ | (cpu-01, cpu-02, |
+----------^-----------+ | | \ | gpu-01 pools) |
| | | \ +----------^-----------+
| emits|metrics & logs| \ |
| v v \ |
| +---------------+ +---------------+ |
| | Vector/Logs |-->| VictoriaLogs |<-------+
| | (agents) | | (logs store) |
| +---------------+ +---------------+
|
+---------------------> Grafana <-------------------------+
(dashboards & alerting)
reads from VM + VictoriaLogs datasources

event notifications
|
v
+----------+
| NATS |
|JetStream |
+----------+
^
publish/subscribe

Legend:

  • NoETL Server communicates with Workers (task scheduling, status updates). Both write job/task metadata to PostgreSQL.
  • NATS JetStream is used for event-driven command notifications: the Server publishes and Workers subscribe (durable pull consumers). See operations/nats_integration.md
  • Metrics are scraped by VictoriaMetrics (via PodMonitor/PodScrape). Logs are shipped by agents (Vector) to VictoriaLogs.
  • Grafana reads from VictoriaMetrics and VictoriaLogs and shows pre-provisioned dashboards and datasources.

Component Responsibilities & Dependencies

1. PostgreSQL

  • Purpose: System-of-record for metadata (pipelines, jobs, tasks, results, scheduling state).
  • Depends on: Persistent storage (Kubernetes PVC or external DB).
  • Used by: NoETL Server.

2. NoETL Server

  • Purpose: HTTP API/UI, orchestration, scheduling, and coordination of workers.
  • Depends on:
    • PostgreSQL (read/write job and pipeline metadata)
    • Kubernetes (service discovery and worker orchestration)
    • Observability stack for metrics/logs export
  • Provides:
    • API at http://localhost:30082
    • Metrics endpoint scraped by VictoriaMetrics
    • Logs shipped to VictoriaLogs via Vector agents

3. NoETL Workers (cpu-01, cpu-02, gpu-01)

  • Purpose: Execute tasks; report status and metrics.
  • Depends on:
    • NoETL Server (work assignment, heartbeats)
    • Container runtime / GPU drivers (for gpu-01)
  • Emits:
    • Metrics scraped by VictoriaMetrics
    • Logs shipped to VictoriaLogs

4. NATS JetStream

  • Purpose: Event bus for lightweight command notifications and retries (no DB polling).
  • Depends on:
    • NATS deployment (cluster or single) and JetStream enabled
    • Proper subjects/streams (e.g., NOETL_COMMANDS stream, noetl.commands subject)
  • Used by:
    • NoETL Server (publisher)
    • NoETL Workers (durable pull consumers)
  • Configuration hints:
    • NATS_URL env var (e.g., nats://noetl:noetl@nats.nats.svc.cluster.local:4222)
    • See detailed integration: operations/nats_integration.md

5. VictoriaMetrics

  • Purpose: Time-series metrics storage and query (PromQL-compatible).
  • Depends on:
    • PodMonitor/PodScrape configs to discover Server and Worker metrics endpoints
  • Used by:
    • Grafana (dashboards)

6. VictoriaLogs

  • Purpose: Centralized logs storage and query.
  • Depends on:
    • Log shippers (Vector agents) to forward container logs
  • Used by:
    • Grafana (Explore/log panels)

7. Grafana

  • Purpose: Visualization, dashboards, alerts.
  • Depends on:
    • Datasource provisioning for VictoriaMetrics and VictoriaLogs
    • Dashboard provisioning for NoETL Server and Workers
  • Endpoints:

8. Provisioned Dashboards and Datasources

  • Dashboards:
    • NoETL Server dashboard
    • NoETL Worker dashboard
  • Datasources:
    • VictoriaMetrics (metrics)
    • VictoriaLogs (logs)

Operational Notes

  • Namespaces: PostgreSQL runs in the postgres namespace; other components typically run in a unified platform namespace (e.g., noetl-platform).
  • Health checks: Use the unified make targets (e.g., make unified-health-check) to validate all components are up and endpoints are reachable.
  • Troubleshooting:
    • Metrics scraping: see k8s/observability/vmpodscrape-noetl.yaml
    • Worker metrics monitors: see k8s/observability/podmonitor-noetl-workers.yaml
    • Logs shippers: see k8s/observability/vector-values.yaml
    • Prometheus/VictoriaMetrics tips: docs/observability/troubleshoot-prometheus.md
    • NATS/JetStream setup and flows: documentation/docs/operations/nats_integration.md