AgentRules.org
RulesStacksClientsAuditorPrunerSelf-HealRFCsBenchmarkCLICI/CDAuthorsSubmit
This specification is maintained by the AgentRules Working Group. Have enhancements or want to claim maintainership?Submit Specification →
devopscritical PriorityID: otel-collector-0115-memory-limiter-tenant-isolation

OpenTelemetry Collector 0.115 Memory-Limiter Tenant Isolation Guardrail

Enforces strict tenant pipeline isolation and preemptive backpressure using scoped memory-limiter processors in OpenTelemetry Collector 0.115+. Prevents noisy-neighbor memory exhaustion and Out-Of-Memory (OOM) cluster crashes by ensuring memory-limiter processors precede queuing and batching within tenant-isolated routing pipelines.

Prohibited Anti-Pattern: Global Unpartitioned Memory Limiter or Downstream Limiter Placement Causing OOM Cascade

Export Ready-to-Drop Configuration

Select format below to copy code or download file directly.

---
description: OpenTelemetry Collector 0.115 Memory-Limiter Tenant Isolation Guardrail - Enforces strict tenant pipeline isolation and preemptive backpressure using scoped memory-limiter processors in OpenTelemetry Collector 0.115+. Prevents noisy-neighbor memory exhaustion and Out-Of-Memory (OOM) cluster crashes by ensuring memory-limiter processors precede queuing and batching within tenant-isolated routing pipelines.
globs: **/otel-collector*.yaml, **/otel-collector*.yml, **/collector-config*.yaml, **/collector-config*.yml, k8s/**/collector*.yaml, deploy/otel/**/*.yaml
alwaysApply: true
verified_by: "agentrules.org"
license: "CC-BY-4.0"
source: "https://agentrules.org/rules/otel-collector-0115-memory-limiter-tenant-isolation"
---

# OpenTelemetry Collector 0.115 Memory-Limiter Tenant Isolation Guardrail

> **Severity**: CRITICAL | **Category**: devops
> **Anti-Pattern Warning**: Global Unpartitioned Memory Limiter or Downstream Limiter Placement Causing OOM Cascade

## System Constraints
You are a Principal Observability and Infrastructure Architect enforcing OpenTelemetry Collector 0.115+ tenant isolation invariants. In shared multi-tenant collectors, unbounded telemetry ingestion from a single errant tenant can trigger container SIGKILL via kernel OOM. You must strictly mandate that memory_limiter processors are placed as the FIRST processor in every pipeline (or router-isolated sub-pipeline), explicitly defining check_interval, limit_percentage or limit_mib, and spike_limit_percentage or spike_limit_mib. You must prohibit placing memory_limiter after batch or buffering processors.

## Strict Guidelines
- Pipelines MUST ALWAYS position the memory_limiter processor as the very first processor in the pipeline definition, directly following receivers.
- Engineers MUST NOT place batch, queue, or transformation processors before the memory_limiter processor.
- Configurations MUST define check_interval (recommended 1s or 500ms) alongside limit_percentage/spike_limit_percentage or absolute limit_mib/spike_limit_mib tuned to cgroup v2 container allocations.
- Multi-tenant setups MUST use routing processors (e.g., routingconnector or routing processor) to isolate tenants into distinct downstream sub-pipelines with bounded queue exporters.
- Exporters MUST configure sending_queue with bounded queue_size and explicit storage or drop policies instead of unbounded in-memory queues.

## Bad vs Good Implementations
### Unsafe Shared Pipeline with Memory Limiter Placed After Batch Processor

#### Bad Antipattern (AI Common Hallucination)
> **Why it fails**: Placing batch before memory_limiter forces incoming telemetry to be buffered in heap memory before checks execute. A 95% threshold with a 5s check interval provides insufficient headroom, causing the container to breach Kubernetes cgroup memory limits and crash via OOMKilled before backpressure is signaled.
```yaml
receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
processors:
  batch:
    send_batch_size: 10000
    timeout: 10s
  memory_limiter:
    check_interval: 5s
    limit_percentage: 95
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, memory_limiter] # VIOLATION: Batching allocates memory before limiter can drop/reject
      exporters: [otlp/backend]
```

#### Production Standard (Correct)
> **Standard**: The memory_limiter is the absolute first processor in the chain, polling at 1s intervals with a 20% spike headroom. Preemptive 429/ResourceExhausted gRPC status codes are returned to incoming clients before buffer allocation, protecting the shared collector.
```yaml
receivers:
  otlp:
    protocols:
      grpc: { endpoint: 0.0.0.0:4317 }
processors:
  memory_limiter/tenant_guard:
    check_interval: 1s
    limit_percentage: 75
    spike_limit_percentage: 20
  batch:
    send_batch_size: 8192
    timeout: 1s
exporters:
  otlp/backend:
    endpoint: tempo:4317
    sending_queue:
      enabled: true
      num_consumers: 4
      queue_size: 500
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter/tenant_guard, batch] # INVARIANT: memory_limiter is first
      exporters: [otlp/backend]
```
Recommended MCP Servers (mcp-serverlist.com)

Equip agent with system tools to verify code for this stack.

Kubernetes Cluster Inspector MCP
Inspects running collector pods, cgroup limits, restart counts, and OOMKilled events in production namespaces.
Recommended Agent Skills (askills.dev)

Ready-to-use executable skill functions tailored to this stack.

OTel Collector Config Validator
CLI utility to run otelcol validate and otelcol-contrib validate on pipeline configurations prior to deployment.
Architectural Specification & Invariant Rationale

Architectural Invariant Design: OpenTelemetry Collector 0.115 Memory-Limiter Tenant Isolation Guardrail

OpenTelemetry Collector 0.115 Memory-Limiter Tenant Isolation Guardrail defines an industrial-grade behavioral standard for devops engineering. Enforces strict tenant pipeline isolation and preemptive backpressure using scoped memory-limiter processors in OpenTelemetry Collector 0.115+. Prevents noisy-neighbor memory exhaustion and Out-Of-Memory (OOM) cluster crashes by ensuring memory-limiter processors precede queuing and batching within tenant-isolated routing pipelines. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Global Unpartitioned Memory Limiter or Downstream Limiter Placement Causing OOM Cascade Without an explicit system instruction file, developers spend hours debugging silent failures.
Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure ModeAI Symptom (The Anti-Pattern)SeverityProduction Impact & Remedy
AI Hallucination & Deprecation DriftGlobal Unpartitioned Memory Limiter or Downstream Limiter Placement Causing OOM CascadeCritical
Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production.
Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture InconsistencyAI assistants produce mixed paradigms across files, creating fragmented codebase conventions.Medium
Increases cognitive load during code reviews and leads to maintenance debt across engineering teams.
Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.
Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

1

Pipelines MUST ALWAYS position the memory_limiter processor as the very first processor in the pipeline definition, directly following receivers.

Pipelines MUST ALWAYS position the memory_limiter processor as the very first processor in the pipeline definition, directly following receivers.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
2

Engineers MUST NOT place batch, queue, or transformation processors before the memory_limiter processor.

Engineers MUST NOT place batch, queue, or transformation processors before the memory_limiter processor.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
3

Configurations MUST define check_interval (recommended 1s or 500ms) alongside limit_percentage/spike_limit_percentage or absolute limit_mib/spike_limit_mib tuned to cgroup v2 container allocations.

Configurations MUST define check_interval (recommended 1s or 500ms) alongside limit_percentage/spike_limit_percentage or absolute limit_mib/spike_limit_mib tuned to cgroup v2 container allocations.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
4

Multi-tenant setups MUST use routing processors (e.g., routingconnector or routing processor) to isolate tenants into distinct downstream sub-pipelines with bounded queue exporters.

Multi-tenant setups MUST use routing processors (e.g., routingconnector or routing processor) to isolate tenants into distinct downstream sub-pipelines with bounded queue exporters.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
5

Exporters MUST configure sending_queue with bounded queue_size and explicit storage or drop policies instead of unbounded in-memory queues.

Exporters MUST configure sending_queue with bounded queue_size and explicit storage or drop policies instead of unbounded in-memory queues.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
Technical Questions & Answers

Frequently Asked Technical Questions

Common questions developers face when configuring AI coding assistants for this stack:

Q:Why is OpenTelemetry Collector 0.115 Memory-Limiter Tenant Isolation Guardrail critical for AI coding assistants?

Enforces strict tenant pipeline isolation and preemptive backpressure using scoped memory-limiter processors in OpenTelemetry Collector 0.115+. Prevents noisy-neighbor memory exhaustion and Out-Of-Memory (OOM) cluster crashes by ensuring memory-limiter processors precede queuing and batching within tenant-isolated routing pipelines. Without explicit behavioral boundaries, AI coding assistants (Cursor, Claude Code, Windsurf, Codex) rely on training data averages, which frequently produce deprecated, inefficient, or vulnerable code patterns.

Q:How does adopting this rule prevent AI hallucinations?

This rule explicitly declares what the AI must avoid (Global Unpartitioned Memory Limiter or Downstream Limiter Placement Causing OOM Cascade) and prescribes verified positive examples. Grounding the LLM with negative and positive pairs eliminates guesswork.

Q:Which AI coding environments are supported?

This specification is multi-platform compatible: Cursor (.cursor/rules/*.mdc & .cursorrules), Anthropic Claude Code (CLAUDE.md), Windsurf (.windsurfrules), Codex / Cline (AGENTS.md), and GitHub Copilot (.github/copilot-instructions.md).

Q:Can I combine this rule with other technology stacks?

Yes. Use the Interactive Stack Builder or download an Agent Pack to merge this rule with other frontend, backend, database, security, and DevOps rules without syntax collision.

Open Specification · CC BY 4.0·Free for Personal, Team & Commercial In-Repo Use

Citation & Open Source Attribution Guidelines

This specification is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You are completely free to adapt and share this rule in your workspace. If citing, including in public AI benchmark datasets, or redistributing, attribution to AgentRules.org is required.

Related DEVOPS Rules

View all rules →
devops
86

Kubernetes Gateway API v1 HTTPRoute Canary and ReferenceGrant Invariants

Enforces strict conformance to Kubernetes Gateway API v1 specifications during migration from legacy Ingress controllers. Mandates explicit ReferenceGrant resources for cross-namespace routing, strict relative integer weighting for HTTPRoute canary releases, and explicit backendRef port declarations.

devops
118

ArgoCD ApplicationSet Matrix Generator Invariants & Cascade Deletion Guards

Enforces strict structural constraints on ArgoCD ApplicationSet Matrix generators combining cluster selectors and Git directories. Prevents catastrophic multi-cluster cascade pruning, accidental secret exposure through parameter interpolation, and runaway Application CR explosion via explicit sync policies, preservation finalizers, and parameter validation.

devops
40

Karpenter Resilient Topology, Interruption Queue, and Consolidation Budget Standard

Enforces deterministic disruption budgets, multi-instance-type diversification, and event-driven SQS interruption queue handling across Karpenter NodePools and EC2NodeClasses. Eliminates cascading eviction loops, instance starvation, and availability downtime during AWS Spot rebalances and underutilized node consolidation.

1 Rule in Stack

OpenTelemetry