Wazowski: Observability Platform 🚀

A distributed, microservices-based observability platform designed to ingest, monitor, and visualize telemetry data (requests and exceptions). Built with modern cloud-native principles, it leverages an event-driven architecture to decouple ingestion from persistence and analysis.

Project Philosophy

After three decades facing critical scenarios, I realized that a system's resilience is not measured by the absence of failures, but by the intelligence with which we react to them. Wazowski was born under the principle that error is the most valuable data in an operation.

While v0 (Node.Js) proved the concept, v1, v2, v3 (NestJS) keep the light bright, v4 evolves to the .NET 10 platform, focusing on high throughput and low operational cost, using event-driven architecture to ensure that monitoring never becomes the bottleneck of the business.

Architecture

The platform consists of several distributed components that communicate via HTTP APIs and Kafka streams.

Architecture Flow

graph TD
    %% Camada Externa
    User((User / Clients)) --> FE[Frontend: Angular]
    User --> GW[API Gateway: YARP]

    subgraph Edge_Layer [Edge & Routing]
        FE
        GW
        KAPI
        NAPI
        AAPI
        TAPI
    end

    %% Roteamento do Gateway
    GW --> TAPI[Telemetry API]
    GW --> AAPI[Admin API]
    GW --> KAPI[Kafka API]
    GW --> NAPI[Notification API]

    %% Barramento de Eventos
    subgraph Event_Bus [Event Driven Core]
        Kafka((Apache Kafka))
        KUI[Kafka UI] -- monitora --> Kafka
    end

    %% Ingestão e Processamento
    TAPI -- publish --> Kafka
    Kafka -- read info --> KAPI
    Kafka -- consume --> CW[Consumer Worker]
    Kafka -- consume --> NW[Notification Worker]
    Kafka -- consume --> MW[Maintenance Worker]

    %% Camada de Notificação e IA
    NW -- calls internal --> NAPI
    NAPI -- analysis --> AI[External AI: Google/Anthropic/Azure]
    NAPI -- send --> MP[Mailpit: SMTP]

    %% Persistência
    subgraph Data_Storage [Data Persistence]
        CW --> Mongo[(MongoDB)]
        MW --> Mongo
        NW --> Mongo
        AAPI --> Mongo
        MEX[Mongo Express] -- visualiza --> Mongo
    end

    %% Exemplo de Integração
    subgraph Samples [Integration Examples]
        CS[Example C# App] -- telemetry --> GW
        NJ[Example NestJS App] -- telemetry --> GW
    end

    %% Estilização
    style Kafka fill:#000,color:#fff,stroke:#333
    style Mongo fill:#47A248,color:#fff,stroke:#333
    style GW fill:#512bd4,color:#fff,stroke:#333
    style AI fill:#f39c12,color:#fff,stroke:#333
    style MP fill:#e74c3c,color:#fff,stroke:#333

Loading

Admin Dashboard

Core Services

1. Observability.ApiGateway (YARP)
   • The primary entry point for all external traffic.
   • Routes telemetry/api/v1/* traffic directly to the ingestion pipeline.
   • Routes admin/api/v1/* admin and query traffic to the administration layer.
   • Routes kafka/api/v1/* traffic to the dedicated Kafka API for read kafka info.
   • Routes notification/api/v1/* traffic to the dedicated Kafka API for Notifications.

            

2. Observability.IngestionApi (Telemetry)
   • High-throughput endpoint designed solely to receive telemetry data.
   • Immediately publishes incoming logs and exceptions to Kafka topics (observability-logs, observability-exceptions).
   • Ensures fast response times by deferring processing.

            

3. Apache Kafka (Event Bus)
   • Acts as the central nervous system of the platform.
   • Persists telemetry events temporarily and enables decoupled downstream consumers.
   • Runs in KRaft mode (no Zookeeper required).

            

4. Observability.ConsumerWorker

   • A background service listening to Kafka topics.

   • Consumes and persists the incoming telemetry data into the MongoDB data store.

                 
     

5. MongoDB (Data Store)

   • Persists the application metadata, users, request logs, and exception logs.

            

6. Observability.AdminApi
   • Provides REST endpoints to manage applications, users, and read back telemetry logs for visualization.
   • Handles JWT authentication and authorization.

            

7. Observability.KafkaApi (Telemetry)
   • Provides real-time information and metrics about the Kafka infrastructure, topics, and message queues.

            

8. Observability.NotificationApi (Notification)
   • Receive analisys report.

            

9. Observability.Notification.Worker (Notification Worker)
   • Deliver analisys report.

            

10. Observability.Maintenance.Worker (Maintenance Worker, The Janitor)

• Looking for DLQs.

            

11. **Final Message, delivered

            

Client Applications

• Frontend (Angular)

  • A modern web UI to view incoming telemetry data, analyze exceptions, and manage registered applications and users. Includes a dashboard for system-wide performance statistics.

• Example Integrations (C# & NestJS)

  • Included sample applications that demonstrate how to send telemetry data to the TelemetryApi.

Technologies Used

• Backends: C# (.NET 8 Minimal APIs, Controllers, Worker Services)
• Frontend: Angular 17+, TypeScript, Tailwind CSS / Custom CSS
• Proxy/Gateway: YARP (Yet Another Reverse Proxy)
• Messaging: Apache Kafka with Bitnami.Kafka client
• Database: MongoDB with MongoDB.Driver
• Containerization: Docker & Docker Compose

Quick Start (Running Locally)

The easiest way to run the entire stack locally is via Docker Compose. Ensure you have Docker and Docker Compose installed on your system.

1. Build and Start the Stack

Open a terminal in the root directory and run:

./wazowski/wazowski-build.sh

This command will download necessary base images (Kafka, MongoDB) and build all the .NET microservices and the Angular frontend.

2. Accessing the Platform

Once all containers are healthy, you can access the platform at the following default local addresses:

• Frontend UI: http://localhost:4200
• API Gateway: http://localhost:5000 (Routes requests internally)

(Note: Use default credentials or create a new user via the interface if self-registration is enabled.)

3. Ports Summary

• 4200: Frontend UI
• 5000: API Gateway (YARP)
• 5001: Telemetry API
• 5002: Admin API
• 5003: Kafka API (WIP)
• 5010: Example C# Application
• 3000: Example NestJS Application
• 9092: Kafka Broker (Internal 29092)
• 27017: MongoDB

4. Stopping the Stack

To shut down the platform gracefully, preserving data in volumes:

docker-compose down

To shut down AND remove all persistent data (MongoDB documents, Kafka streams):

docker-compose down -v

ONLY USE

Images at Docker Hub:

• avmesquita/observabilityplatform_api-gateway:v0
• avmesquita/observabilityplatform_telemetry-api:v0
• avmesquita/observabilityplatform_notification-api:v0
• avmesquita/observabilityplatform_kafka-api:v0
• avmesquita/observabilityplatform_notification-worker:v0
• avmesquita/observabilityplatform_admin-api:v0
• avmesquita/observabilityplatform_maintenance-worker:v0
• avmesquita/observabilityplatform_consumer-worker:v0
• avmesquita/observabilityplatform_frontend:v0

cd only-use
cp ./.env.sample ./.env
chmod +x ./wazowski-only-use.sh
./wazowski-only-use.sh

FIRST EVIDENCE

The first complete process analysis performed by the tool indicates an interesting and positive scenario for the project to continue.

This report took 5 seconds to be received by the RESTful API and arrive in the Mailpit inbox.

License ⚖️

Copyright (c) 2026 Andre Veloso de Mesquita.

This project is licensed under the GNU Affero General Public License v3 (AGPL-3.0).

Why AGPL-3.0?

As a platform designed for infrastructure and observability, the AGPL ensures that the spirit of open-source is preserved, especially in cloud-native and service-oriented environments.

• Network Transparency: If you modify this software and offer it as a service (SaaS) over a network, you are obligated to release your modified source code under the same license.
• Continuous Improvement: This aligns with the project's core philosophy: turning errors into opportunities for better software. By sharing improvements, the entire ecosystem becomes more resilient.
• No Hidden Forks: It prevents the creation of "private" cloud forks that benefit from the community's work without giving back.

"The right to learn from a system's failure should belong to everyone who depends on it."