{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/",
        "slug": "define-opentelemetry-collector-loss-boundaries-before-increasing-queues",
        "url": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/"
        },
        "title": "Define OpenTelemetry Collector loss boundaries before increasing queues",
        "summary": "Retrying and buffering reduce some interruptions but cannot guarantee that every telemetry item survives.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "network-infrastructure",
            "label": "Networks & infrastructure",
            "alt": "Resilient network core with engineered blue and gold data paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "it",
                "name": "IT",
                "url": "https://update.dsesecurity.com/topic/it/"
            },
            {
                "slug": "networks-infrastructure",
                "name": "Networks & Infrastructure",
                "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-10-20T18:15:44+00:00",
        "modified_at": "2026-10-20T18:34:33+00:00",
        "reviewed_on": "2026-10-20",
        "reading_minutes": 2,
        "word_count": 249,
        "potentially_affected": "Review Collector exporter queue, retry and persistent-storage loss boundaries in the resiliency guidance.",
        "dse_recommendation": "DSE recommends defining acceptable telemetry loss and expected destination outage duration before choosing queue and retry settings.",
        "primary_source": {
            "name": "OpenTelemetry documentation — Resiliency",
            "url": "https://opentelemetry.io/docs/collector/resiliency/",
            "published_on": null,
            "authority": "opentelemetry.io"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>Retrying and buffering reduce some interruptions but cannot guarantee that every telemetry item survives.</p>\n<h2>Source facts</h2>\n<p>OpenTelemetry Collector resiliency guidance describes sending queues, retries, and optional persistent storage. An in-memory queue can drop incoming data when full; retry-duration exhaustion can also discard data. Persistent storage through file_storage can retain queued items across Collector restart, but disk failure, exhausted space, and other limits remain potential loss paths.</p>\n<p>Source: <a href=\"https://opentelemetry.io/docs/collector/resiliency/\">OpenTelemetry documentation — Resiliency</a>.</p>\n<h2>Applicability</h2>\n<p>Review Collector exporter queue, retry and persistent-storage loss boundaries in the resiliency guidance.</p>\n<h2>DSE recommendation</h2>\n<p>DSE recommends defining acceptable telemetry loss and expected destination outage duration before choosing queue and retry settings. Account for arrival rate, memory or disk capacity, and catch-up throughput. Give persistent storage its own monitoring and recovery owner. Separate endpoint failure from backend overload; a larger queue can defer a problem without fixing it. Keep important audit or business records on a delivery system whose guarantees match their requirement rather than relying on an unspecified telemetry buffer.</p>\n<h2>Verification</h2>\n<p>In an isolated pipeline, interrupt a test destination and observe queue growth, retries, recovery, and any loss indicators. Restart a Collector containing disposable queued data to validate the chosen storage behavior. Confirm disk-space and retry-limit alerts are useful before applying the configuration to production telemetry. Retain sample identifiers and the exporter queue state across the interruption. Have the pipeline owner reconcile received and missing test items and approve the tested outage boundary before increasing the queue in production.</p>\n<h2>Official reference</h2>\n<p><a href=\"https://opentelemetry.io/docs/collector/resiliency/\">OpenTelemetry documentation — Resiliency</a>. Reviewed October 20, 2026.</p>",
        "content_text": "Retrying and buffering reduce some interruptions but cannot guarantee that every telemetry item survives.\nSource facts\nOpenTelemetry Collector resiliency guidance describes sending queues, retries, and optional persistent storage. An in-memory queue can drop incoming data when full; retry-duration exhaustion can also discard data. Persistent storage through file_storage can retain queued items across Collector restart, but disk failure, exhausted space, and other limits remain potential loss paths.\nSource: OpenTelemetry documentation — Resiliency.\nApplicability\nReview Collector exporter queue, retry and persistent-storage loss boundaries in the resiliency guidance.\nDSE recommendation\nDSE recommends defining acceptable telemetry loss and expected destination outage duration before choosing queue and retry settings. Account for arrival rate, memory or disk capacity, and catch-up throughput. Give persistent storage its own monitoring and recovery owner. Separate endpoint failure from backend overload; a larger queue can defer a problem without fixing it. Keep important audit or business records on a delivery system whose guarantees match their requirement rather than relying on an unspecified telemetry buffer.\nVerification\nIn an isolated pipeline, interrupt a test destination and observe queue growth, retries, recovery, and any loss indicators. Restart a Collector containing disposable queued data to validate the chosen storage behavior. Confirm disk-space and retry-limit alerts are useful before applying the configuration to production telemetry. Retain sample identifiers and the exporter queue state across the interruption. Have the pipeline owner reconcile received and missing test items and approve the tested outage boundary before increasing the queue in production.\nOfficial reference\nOpenTelemetry documentation — Resiliency. Reviewed October 20, 2026.",
        "content_markdown": "Retrying and buffering reduce some interruptions but cannot guarantee that every telemetry item survives.\n\n## Source facts\n\nOpenTelemetry Collector resiliency guidance describes sending queues, retries, and optional persistent storage. An in-memory queue can drop incoming data when full; retry-duration exhaustion can also discard data. Persistent storage through file_storage can retain queued items across Collector restart, but disk failure, exhausted space, and other limits remain potential loss paths.\n\nSource: [OpenTelemetry documentation — Resiliency](https://opentelemetry.io/docs/collector/resiliency/).\n\n## Applicability\n\nReview Collector exporter queue, retry and persistent-storage loss boundaries in the resiliency guidance.\n\n## DSE recommendation\n\nDSE recommends defining acceptable telemetry loss and expected destination outage duration before choosing queue and retry settings. Account for arrival rate, memory or disk capacity, and catch-up throughput. Give persistent storage its own monitoring and recovery owner. Separate endpoint failure from backend overload; a larger queue can defer a problem without fixing it. Keep important audit or business records on a delivery system whose guarantees match their requirement rather than relying on an unspecified telemetry buffer.\n\n## Verification\n\nIn an isolated pipeline, interrupt a test destination and observe queue growth, retries, recovery, and any loss indicators. Restart a Collector containing disposable queued data to validate the chosen storage behavior. Confirm disk-space and retry-limit alerts are useful before applying the configuration to production telemetry. Retain sample identifiers and the exporter queue state across the interruption. Have the pipeline owner reconcile received and missing test items and approve the tested outage boundary before increasing the queue in production.\n\n## Official reference\n\n[OpenTelemetry documentation — Resiliency](https://opentelemetry.io/docs/collector/resiliency/). Reviewed October 20, 2026."
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/",
                "url": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-20"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "IT",
                        "item": "https://update.dsesecurity.com/topic/it/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 3,
                        "name": "Define OpenTelemetry Collector loss boundaries before increasing queues",
                        "item": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/#article",
                "identifier": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/",
                "url": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/",
                "headline": "Define OpenTelemetry Collector loss boundaries before increasing queues",
                "description": "Retrying and buffering reduce some interruptions but cannot guarantee that every telemetry item survives.",
                "abstract": "Retrying and buffering reduce some interruptions but cannot guarantee that every telemetry item survives.",
                "articleBody": "Retrying and buffering reduce some interruptions but cannot guarantee that every telemetry item survives.\nSource facts\nOpenTelemetry Collector resiliency guidance describes sending queues, retries, and optional persistent storage. An in-memory queue can drop incoming data when full; retry-duration exhaustion can also discard data. Persistent storage through file_storage can retain queued items across Collector restart, but disk failure, exhausted space, and other limits remain potential loss paths.\nSource: OpenTelemetry documentation — Resiliency.\nApplicability\nReview Collector exporter queue, retry and persistent-storage loss boundaries in the resiliency guidance.\nDSE recommendation\nDSE recommends defining acceptable telemetry loss and expected destination outage duration before choosing queue and retry settings. Account for arrival rate, memory or disk capacity, and catch-up throughput. Give persistent storage its own monitoring and recovery owner. Separate endpoint failure from backend overload; a larger queue can defer a problem without fixing it. Keep important audit or business records on a delivery system whose guarantees match their requirement rather than relying on an unspecified telemetry buffer.\nVerification\nIn an isolated pipeline, interrupt a test destination and observe queue growth, retries, recovery, and any loss indicators. Restart a Collector containing disposable queued data to validate the chosen storage behavior. Confirm disk-space and retry-limit alerts are useful before applying the configuration to production telemetry. Retain sample identifiers and the exporter queue state across the interruption. Have the pipeline owner reconcile received and missing test items and approve the tested outage boundary before increasing the queue in production.\nOfficial reference\nOpenTelemetry documentation — Resiliency. Reviewed October 20, 2026.",
                "datePublished": "2026-10-20T18:15:44+00:00",
                "dateModified": "2026-10-20T18:34:33+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/define-opentelemetry-collector-loss-boundaries-before-increasing-queues/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Define OpenTelemetry Collector loss boundaries before increasing queues"
                },
                "articleSection": [
                    "IT",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "IT",
                    "Networks & Infrastructure",
                    "Guide",
                    "Information priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "IT",
                        "url": "https://update.dsesecurity.com/topic/it/"
                    },
                    {
                        "@type": "Thing",
                        "name": "Networks & Infrastructure",
                        "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
                    }
                ],
                "wordCount": 249,
                "timeRequired": "PT2M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "OpenTelemetry documentation — Resiliency",
                    "url": "https://opentelemetry.io/docs/collector/resiliency/"
                }
            }
        ]
    }
}