Applications

Applications are the foundational namespace unit in Castrel for organizing and isolating operational context. If you have multiple unrelated business systems within the same Castrel tenant, Applications allow you to keep them logically separated.

What is an Application?

An Application is a container that groups related operational resources together:

• Services — The microservices, APIs, and components that make up your system
• Infrastructures — Infrastructure like servers, databases, and cloud resources
• Knowledges — Operational documentation, runbooks, and context specific to this application

Architecture Overview

graph TB
    subgraph AA[Application A]
        SA1[Service: order-api]
        SA2[Service: mysql]
        IA1[Infra: ns-order]
        IA2[Infra: ns-database]
        SI1([Deployment: order-api])
        SI2([Deployment: mysql])
        SA1 -.-> SI1
        SA2 -.-> SI2
        SI1 -.-> IA1
        SI2 -.-> IA2
    end

    subgraph AB[Application B]
        SB1[Service: payment-api]
        SB2[Service: mysql]
        IB1[Infra: ns-payment]
        IB2[Infra: ns-database]
        SI3([Deployment: payment-api])
        SI4([Deployment: mysql])
        SB1 -.-> SI3
        SB2 -.-> SI4
        SI3 -.-> IB1
        SI4 -.-> IB2
    end

    PS([Public Service: MySQL])
    PI([Public Infra: K8s Cluster])

    subgraph GC[Global Connectors]
        C1[Connector: Prometheus]
        C2[Connector: Elasticsearch]
    end

    SA2 -.- PS
    SB2 -.- PS
    IA1 -.- PI
    IA2 -.- PI
    IB1 -.- PI
    IB2 -.- PI

    AA --> C1
    AA --> C2
    AB --> C1

Core Concepts

Services and Infrastructures

Both Services and Infrastructures belong to an Application. They are connected through Service Instances:

• A Service is instantiated into a Service Instance
• A Service Instance is deployed on an Infrastructure

This model captures the relationship between what your application does (Services) and where it runs (Infrastructures).

Public Services and Public Infrastructures

In real-world scenarios, multiple Applications often share common components:

• Public Service: A shared service definition like MySQL or Redis. When Application A and Application B both use MySQL, each Application maintains its own mysql Service entry, but both reference the same Public Service definition. This allows each team to maintain application-specific knowledge while sharing common documentation.
• Public Infrastructure: Shared infrastructure like a Kubernetes cluster or a database server. Each Application maintains its own Infrastructure entries (e.g., specific pods or VMs) that reference the common Public Infrastructure. This preserves the application-level relationship and context.

Connectors (Global)

Connectors are global resources that represent data sources like Prometheus, Elasticsearch, or Grafana Loki. They are not scoped to any specific Application.

Applications record which Connectors contain their observability data. This linkage tells Castrel: "When investigating this Application, query these Connectors for relevant data."

Why Use Applications?

Context Isolation

When investigating incidents or triaging alerts, Castrel uses the Application boundary to scope its analysis:

• Queries only access relevant data sources
• Knowledge retrieval is focused on applicable documentation
• Alert correlation considers only related services

Multi-Team Support

Different teams can work independently within their own Applications:

• Team A manages their e-commerce platform in app-ecommerce
• Team B manages their data pipeline in app-data-platform
• Both teams share the same Castrel tenant without interference

Getting Started

1. Create an Application in the Castrel console
2. Add Services that belong to this application
3. Add Infrastructures where your services run
4. Link the Application to Connectors that contain its observability data
5. Upload or generate Knowledges for operational context

Once configured, Castrel will automatically scope its operations to the appropriate Application context.