{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/", "item": { "id": "https://update.dsesecurity.com/updates/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/", "slug": "dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export", "url": "https://update.dsesecurity.com/updates/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/" }, "title": "Separate independent monitoring consumers before sharing an Event Hubs export", "summary": "What should be checked before two downstream tools consume the same Azure Monitor export?", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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-09-10T00:24:53+00:00", "modified_at": "2026-09-10T02:04:57+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 270, "potentially_affected": "Azure Monitor platform-log or metric streams sent through Event Hubs to downstream monitoring tools.", "dse_recommendation": "Approve the consumer-group arrangement, partition compatibility and recoverable interruption window with each tool owner.", "primary_source": { "name": "Stream Azure monitoring data to an event hub and external partners - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/platform/stream-monitoring-data-event-hubs", "published_on": null, "authority": "Microsoft Learn" }, "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": "

Source facts

\n

Microsoft’s Azure Monitor export guidance recommends the default Event Hubs consumer group unless separate tools need to consume the same data. Partitions permit parallel consumption, but the receiving tool may not support multiple partitions. The guidance recommends retaining messages for at least seven days so a stopped consumer can catch up within that retained period. Diagnostic settings provide a streaming path for platform logs and metrics. Microsoft Learn.

\n

Applicability

\n

Review an existing or proposed Event Hubs destination and every independent monitoring tool reading it. Distinguish a second tool’s consumption requirement from scaling workers within one tool. Confirm each receiver’s documented partition behavior and the currently configured retention interval; the source’s recommendation is not evidence that either setting is present.

\n

DSE recommendation

\n

Approve the consumer-group arrangement, partition compatibility and recoverable interruption window with each tool owner. Record which destination and stream categories each receiver expects. Before connecting another tool, agree how its ingestion will be checked separately from the first receiver. Match the outage-recovery plan to actual retained messages rather than treating the export as an indefinite archive. Avoid selecting partition counts from an example without checking receiver support.

\n

Verification

\n

In a controlled test, send identifiable non-sensitive events and confirm their arrival in both intended tools. Pause and resume a test consumer within the approved retention window, then reconcile recovered events against the source interval. Inspect whether all configured partitions were consumed. Record missing data and receiver-specific errors independently; success in one tool does not establish complete ingestion in the other.

\n

Official references

\n

Microsoft Learn: Stream Azure monitoring data to an event hub and external partner. Source reviewed September 9, 2026.

", "content_text": "Source facts\nMicrosoft’s Azure Monitor export guidance recommends the default Event Hubs consumer group unless separate tools need to consume the same data. Partitions permit parallel consumption, but the receiving tool may not support multiple partitions. The guidance recommends retaining messages for at least seven days so a stopped consumer can catch up within that retained period. Diagnostic settings provide a streaming path for platform logs and metrics. Microsoft Learn.\nApplicability\nReview an existing or proposed Event Hubs destination and every independent monitoring tool reading it. Distinguish a second tool’s consumption requirement from scaling workers within one tool. Confirm each receiver’s documented partition behavior and the currently configured retention interval; the source’s recommendation is not evidence that either setting is present.\nDSE recommendation\nApprove the consumer-group arrangement, partition compatibility and recoverable interruption window with each tool owner. Record which destination and stream categories each receiver expects. Before connecting another tool, agree how its ingestion will be checked separately from the first receiver. Match the outage-recovery plan to actual retained messages rather than treating the export as an indefinite archive. Avoid selecting partition counts from an example without checking receiver support.\nVerification\nIn a controlled test, send identifiable non-sensitive events and confirm their arrival in both intended tools. Pause and resume a test consumer within the approved retention window, then reconcile recovered events against the source interval. Inspect whether all configured partitions were consumed. Record missing data and receiver-specific errors independently; success in one tool does not establish complete ingestion in the other.\nOfficial references\nMicrosoft Learn: Stream Azure monitoring data to an event hub and external partner. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nMicrosoft’s Azure Monitor export guidance recommends the default Event Hubs consumer group unless separate tools need to consume the same data. Partitions permit parallel consumption, but the receiving tool may not support multiple partitions. The guidance recommends retaining messages for at least seven days so a stopped consumer can catch up within that retained period. Diagnostic settings provide a streaming path for platform logs and metrics. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/stream-monitoring-data-event-hubs).\n\n## Applicability\n\nReview an existing or proposed Event Hubs destination and every independent monitoring tool reading it. Distinguish a second tool’s consumption requirement from scaling workers within one tool. Confirm each receiver’s documented partition behavior and the currently configured retention interval; the source’s recommendation is not evidence that either setting is present.\n\n## DSE recommendation\n\nApprove the consumer-group arrangement, partition compatibility and recoverable interruption window with each tool owner. Record which destination and stream categories each receiver expects. Before connecting another tool, agree how its ingestion will be checked separately from the first receiver. Match the outage-recovery plan to actual retained messages rather than treating the export as an indefinite archive. Avoid selecting partition counts from an example without checking receiver support.\n\n## Verification\n\nIn a controlled test, send identifiable non-sensitive events and confirm their arrival in both intended tools. Pause and resume a test consumer within the approved retention window, then reconcile recovered events against the source interval. Inspect whether all configured partitions were consumed. Record missing data and receiver-specific errors independently; success in one tool does not establish complete ingestion in the other.\n\n## Official references\n\n[Microsoft Learn: Stream Azure monitoring data to an event hub and external partner](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/stream-monitoring-data-event-hubs). Source reviewed September 9, 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/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/", "url": "https://update.dsesecurity.com/updates/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Separate independent monitoring consumers before sharing an Event Hubs export", "item": "https://update.dsesecurity.com/updates/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/", "url": "https://update.dsesecurity.com/updates/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/", "headline": "Separate independent monitoring consumers before sharing an Event Hubs export", "description": "What should be checked before two downstream tools consume the same Azure Monitor export?", "abstract": "What should be checked before two downstream tools consume the same Azure Monitor export?", "articleBody": "Source facts\nMicrosoft’s Azure Monitor export guidance recommends the default Event Hubs consumer group unless separate tools need to consume the same data. Partitions permit parallel consumption, but the receiving tool may not support multiple partitions. The guidance recommends retaining messages for at least seven days so a stopped consumer can catch up within that retained period. Diagnostic settings provide a streaming path for platform logs and metrics. Microsoft Learn.\nApplicability\nReview an existing or proposed Event Hubs destination and every independent monitoring tool reading it. Distinguish a second tool’s consumption requirement from scaling workers within one tool. Confirm each receiver’s documented partition behavior and the currently configured retention interval; the source’s recommendation is not evidence that either setting is present.\nDSE recommendation\nApprove the consumer-group arrangement, partition compatibility and recoverable interruption window with each tool owner. Record which destination and stream categories each receiver expects. Before connecting another tool, agree how its ingestion will be checked separately from the first receiver. Match the outage-recovery plan to actual retained messages rather than treating the export as an indefinite archive. Avoid selecting partition counts from an example without checking receiver support.\nVerification\nIn a controlled test, send identifiable non-sensitive events and confirm their arrival in both intended tools. Pause and resume a test consumer within the approved retention window, then reconcile recovered events against the source interval. Inspect whether all configured partitions were consumed. Record missing data and receiver-specific errors independently; success in one tool does not establish complete ingestion in the other.\nOfficial references\nMicrosoft Learn: Stream Azure monitoring data to an event hub and external partner. Source reviewed September 9, 2026.", "datePublished": "2026-09-10T00:24:53+00:00", "dateModified": "2026-09-10T02:04:57+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/" }, "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/dse-20260909-423-separate-independent-monitoring-consumers-before-sharing-an-event-hubs-export/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Separate independent monitoring consumers before sharing an Event Hubs export" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Checklist", "Information priority" ], "genre": "Checklist", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 270, "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": "Stream Azure monitoring data to an event hub and external partners - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/platform/stream-monitoring-data-event-hubs" } } ] } }