Jitsu Documentation

repository·newjitsu·Indexed 26 days ago

https://github.com/jitsucom/jitsu

Jitsu is an open-source, real-time event data platform designed as an alternative to Segment. It enables developers to collect, transform via JavaScript Functions, and deliver event data to various SaaS tools and data warehouses. The platform includes Bulker, an ingestion engine for streaming and batching semi-structured JSON data into destinations such as PostgreSQL, ClickHouse, Snowflake, BigQuery, Redshift, MySQL, DuckDB, S3, and Google Cloud Storage.

Tokens
57.8K
Snippets
109
Records
381
Agent score
89%

What's inside Jitsu

  1. Overview of Jitsu Event Data Platform

    newjitsu

    Jitsu is an open-source event data platform (an alternative to Segment) that collects event data from websites, apps, and servers, and delivers it to data warehouses and SaaS tools.

    Key features include:

    • Event collection: Via SDKs, HTTP API, or a Segment proxy.
    • Destination delivery: Streams or micro-batches data to ClickHouse, BigQuery, Snowflake, Redshift, Postgres, S3, GCS, and more.
    • Functions: JavaScript-based transformations, filtering, and enrichment that run on every event.
    • Connector syncs: Airbyte-compatible connectors to pull data into your warehouse.
    • Identity Graph: Automatically builds user profiles from the event stream.
    • Live Events: Real-time debugging of pipelines, function logs, and destination writes.
    • MCP Server: Allows AI agents to configure and operate pipelines.
  2. Overview of Bulker

    newjitsu
    Bulker is an ingestion engine designed to stream and batch large amounts of semi-structured JSON data into data warehouses. It handles JSON flattening, schema management (creating tables and columns on the fly), and type inference. It ensures reliability by immediately sending objects to a Kafka queue to prevent data loss if the destination warehouse is unavailable.
  3. Understand the Jitsu Event Processing Pipeline Architecture

    newjitsu

    Jitsu processes events through a sequential 3-step pipeline to filter, transform, and enrich data before it reaches its destination:

    1. Step 1: Builtin Transformations: System-level functions like Identity Stitching (merging user identities across sessions) that run first.
    2. Step 2: User Defined Function (UDF) Pipeline: Custom JavaScript functions executed sequentially. These can be used to Filter (exclude data), Transform (modify structure), or Enrich (add external data) events.
    3. Step 3: Builtin Destination Function: The final step that sends the processed event to the configured destination (e.g., Mixpanel, Amplitude, BigQuery, ClickHouse, etc.).
  4. Jitsu Architecture and Services

    newjitsu

    Jitsu consists of several independently scalable services:

    ServiceStackFunction
    ingestGoHTTP endpoint that accepts events and writes them to Kafka
    rotorTypeScriptRoutes events, runs Functions, applies destination-specific transforms
    bulkerGoHigh-throughput warehouse ingestion (batching, schema management, retries)
    sync-controllerGoOrchestrates connector syncs (pulling data from third-party sources)
    consoleNext.jsAdmin UI, Management API, and the MCP server

    Data Layer:

    • Postgres: Configuration
    • Kafka/Redpanda: Event bus
    • ClickHouse: Live events and metrics
    • MongoDB: Profiles
  5. Basic Usage of orderedmap

    newjitsu

    Use orderedmap.NewOrderedMap[K, V]() to create a high-performance ordered map that maintains amortized O(1) complexity for Set, Get, Delete, and Len operations.

    Requirements:

    • Requires Go v1.18 or higher for generics support. For Go 1.17 or below, use v1 of the package.
    import "github.com/elliotchance/orderedmap/v2"
    
    func main() {
    	m := orderedmap.NewOrderedMap[string, any]()
    
    	m.Set("foo", "bar")
    	m.Set("qux", 1.23)
    	m.Set("123", true)
    
    	m.Delete("qux")
    }
  6. Get started with Jitsu Cloud

    newjitsu

    Jitsu Cloud is a hosted version of the platform. The free tier includes 200k events/month, unlimited destinations, and a free ClickHouse instance.

    To get started with a workspace:

    1. Create a site (a stream) and retrieve your write key.
    2. Add a destination (e.g., ClickHouse, BigQuery, Snowflake, Postgres, S3) from the destination catalog.
    3. Start sending events using one of the supported methods (HTML snippet, @jitsu/js, @jitsu/jitsu-react, HTTP API, or Segment proxy).
  7. Start Jitsu using Docker Compose

    newjitsu

    To start all necessary Jitsu services for exploration or development, use the following command. Once running, access the main UI at http://localhost:3000.

    Default Credentials:

    • Email: admin@jitsu.com
    • Password: admin123

    Note: This setup is for exploration and development only. For production, refer to the official self-hosting production deployment guide.

    docker compose -f ./docker/docker-compose.yml up --force-recreate
  8. Handle errors in Builtin Functions

    newjitsu

    Builtin transformation and destination functions follow strict error handling rules. Errors are logged to the destination log and can result in events being sent to dead-letter storage or a retry queue.

    • Standard Error: Any standard error results in the event being sent to dead-letter storage (viewable in the UI Live Events section).
    • RetryError: Throwing a RetryError sends the event to the retry queue. After a successful retry, processing resumes from the failed step with any payload changes retained.
    throw new RetryError("Temporary failure");
  9. Configure Kubernetes for Jitsu Syncs (Syncctl)

    newjitsu

    The syncctl service manages synchronization jobs in Kubernetes. If Kubernetes is not configured, syncs (Connectors) will not be available.

    This is secure and does not require mounting a kubeconfig.

    1. Start kubectl proxy on your host machine: kubectl proxy --port=8001 --context my-context
    2. Set the following environment variables:
      • SYNCCTL_KUBERNETES_CLIENT_CONFIG=http://host.docker.internal:8001
      • SYNCS_ENABLED=true

    Option 2: Direct cluster access

    For remote clusters using a service account, set these in .env.local:

    • SYNCCTL_KUBERNETES_CLIENT_CONFIG (e.g., https://your-cluster-api:6443)
    • SYNCCTL_KUBERNETES_CONTEXT (e.g., my-context)
    • SYNCCTL_KUBERNETES_TOKEN (your service account token)
    # Example for direct cluster access in .env.local
    SYNCCTL_KUBERNETES_CLIENT_CONFIG=https://your-cluster-api:6443
    SYNCCTL_KUBERNETES_CONTEXT=my-context
    SYNCCTL_KUBERNETES_TOKEN=<your-service-account-token>
  10. Manage Transition from Free to Dedicated Class

    newjitsu

    To transition a workspace from free to dedicated without downtime, follow this sequence:

    1. Rotor Fallback: Rotor initially assumes dedicated status but falls back to the free deployment because the dedicated record doesn't exist yet.
    2. Deployment Creation: The Operator initiates the new deployment.
    3. Record Update: The Operator updates the FunctionsServer record only after the deployment is fully rolled out.
    4. Safe Handoff: To exclude the workspace from the free deployment, ensure the old record meets the safety criteria (e.g., it is older than 5 minutes) to allow all Rotor instances to sync:
    SELECT count(*) FROM "FunctionsServer"
    WHERE "workspaceId" = ?
      AND "deploymentId" <> ?
      AND "createdAt" < now() - interval '5 minutes'
      AND "shutdownAt" IS NULL
      AND deleted = false
    1. Finalization: Rotor picks up the dedicated record and routes accordingly.