# Handling organization\_id

## Multi-tenant API service sxample

Let's explore common scenarios using a real-world example of a multi-tenant API service. In this example, you're running an API that serves multiple organizations, and you want to monitor various metrics. Some metrics are naturally split by organization (like latency and request volume), while others are collected globally (like error rates).

The `organization_id` in these examples could represent different identifiers depending on your use case:

* `customer_id`: When serving multiple end customers (e.g., SaaS platform)
  * Email service monitoring delivery rates per business account
  * DEX monitoring liquidity provider positions
  * NFT marketplace tracking collection trading volume
* `vendor_id`: When aggregating metrics across different suppliers or partners
  * Marketplace measuring seller performance metrics
  * RPC node provider tracking request volumes
  * Oracle service monitoring price feed updates
* `service_id`: When monitoring multiple internal services or microservices
  * E-commerce tracking checkout service reliability
  * Bridge monitoring cross-chain transfers
  * Smart contract monitoring function calls
* `integration_id`: When tracking metrics for different third-party integrations
  * Payment platform monitoring gateway success rates
  * Multi-chain wallet tracking transaction status
  * DEX aggregator monitoring swap routes

### Scenario 1: Organization-Specific Metrics (Per-Organization Latency)

Context: Your API tracks request latency per organization, which is essential for:

* Monitoring individual organization experience
* Meeting specific SLAs per organization
* Identifying organization-specific performance issues

```prometheus
# Prometheus metrics
# Each request is tagged with organization_id
api_request_latency_seconds{organization_id="org123", endpoint="/api/v1/users"} 0.45
api_request_latency_seconds{organization_id="org456", endpoint="/api/v1/users"} 0.32

# slaOS configuration
queries:
  - query: 'histogram_quantile(0.95, sum by (le, organization_id) (rate(api_request_latency_seconds_bucket[5m])))'
    step: 
      value: 60
      unit: "s"
    slaos_metric_name: "p95_latency"
    organization_identifier: "organization_id"  # Each organization gets their own latency metrics
```

Use Case Examples:

* SaaS Platform: Track response times for each customer's API usage
* Marketplace: Monitor transaction processing times for different vendors
* Microservices: Measure inter-service communication latency
* Integration Platform: Track external API call latencies per integration

### Scenario 2: Service-Wide Metrics (Global Error Rates)

**Context:** Your API tracks error counts globally due to:

* Infrastructure limitations
* Metric collection setup
* No business need to track errors per organization

```prometheus
# Prometheus metrics
# Error counts are only tagged with status code
http_errors_total{status="500"} 10
http_errors_total{status="400"} 25
http_errors_total{status="200"} 1000
```

```yaml
# slaOS configuration
queries:
  - query: 'sum(rate(http_errors_total{status=~"5.."}[5m])) / sum(rate(http_errors_total[5m]))'
    step: 
      value: 60
      unit: "s"
    slaos_metric_name: "error_rate"
    fallback_org_id: "global_service"  # All error metrics go to a default organization
```

In this case:

* Error metrics don't have organization identification
* Using `fallback_org_id` assigns all error rates to a default organization
* Useful for service-wide SLAs or general monitoring
* All organizations reference the same error rate metrics

### Scenario 3: Mixed Metrics (Combined Approach)

```prometheus
# Organization-specific requests
api_requests_total{organization_id="org123", endpoint="/api/v1/users"} 150
api_requests_total{organization_id="org456", endpoint="/api/v1/orders"} 75

# Public endpoint requests (no organization_id)
api_requests_total{endpoint="/public/status"} 50
api_requests_total{endpoint="/health"} 25

# slaOS configuration
queries:
  - query: 'sum by (organization_id) (rate(api_requests_total[5m]))'
    step: 
      value: 60
      unit: "s"
    slaos_metric_name: "request_rate"
    organization_identifier: "organization_id"
    fallback_org_id: "public_endpoints"  # For requests without organization_id
```

#### Best Practices for Mixed Environments

**Consistent Labeling:**

```prometheus
# Good - consistent organization identification
api_latency_seconds{organization_id="org123", ...}
api_requests_total{organization_id="org123", ...}

# Avoid - inconsistent labeling
api_latency_seconds{organization_id="org123", ...}
api_requests_total{client="org123", ...}  # Different label name
```

**Clear Separation:**

```prometheus
queries:
  # Organization-specific latency
  - query: 'histogram_quantile(0.95, sum by (le, organization_id) (rate(api_latency_seconds_bucket[5m])))'
    organization_identifier: "organization_id"
    slaos_metric_name: "org_latency"

  # Global error rates
  - query: 'sum(rate(http_errors_total{status=~"5.."}[5m])) / sum(rate(http_errors_total[5m]))'
    fallback_org_id: "global_service"
    slaos_metric_name: "global_error_rate"
```

**Meaningful Fallback IDs:**

```prometheus
# Descriptive fallback IDs
fallback_org_id: "public_api_endpoints"    # Clear purpose
fallback_org_id: "unauthenticated_users"   # Clear purpose

# Avoid generic fallbacks
fallback_org_id: "default"                 # Too generic
fallback_org_id: "other"                   # Not descriptive
```

Remember:

* Choose the appropriate organization identifier based on your use case
* Not all metrics need to be split by organization
* Use fallback IDs thoughtfully and consistently
* Document your choices for future reference
* Consider future changes in metric collection
* Balance granularity with system complexity


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.rated.co/onboarding-your-data/integrations/prometheus/handling-organization_id.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.