Set up Azure Event Hubs as an ingest method
Step 1 - Prepare the Azure Event Hub and checkpoint storage
Why? Log Collector reads events from the Event Hub and stores per-partition processing progress in Blob Storage.
Important
The following steps are provided as a general guide to configuring Azure Event Hubs for use with Log Collector. As third-party systems such as Azure Event Hubs are updated frequently and independently, some steps, options, or UI elements may differ between what is shown below, and what you see in your environment.
If you encounter discrepancies, refer to the official Azure Event Hubs documentation for the most up-to-date instructions.
In the Azure portal, identify the Event Hubs namespace and the Event Hub that contains the data you want to ingest.
Record the fully qualified namespace. It normally has the form
<namespace>.servicebus.windows.net.Create a dedicated consumer group for Log Collector, or identify an existing consumer group. CrowdStrike recommends using a dedicated consumer group rather than
$Default.Create or identify an Azure Storage account with a Blob Storage container for checkpoint data.
Record the Blob service endpoint, normally
https://<storage-account-name>.blob.core.windows.net/, and the container name.
Checkpointing enables Log Collector to resume consumption after a restart or failover. In clustered deployments, Blob Storage also supports coordination so that an Event Hub partition is not consumed concurrently by multiple Log Collector nodes.
Step 2 - Register an application in Microsoft Entra ID
Why? Log Collector authenticates to Azure using an application/service principal rather than an Event Hubs shared-access connection string.
In Microsoft Entra ID, create a new app registration for the Log Collector ingest feed.
Make a note of the Application (client) ID.
Make a note of the Directory (tenant) ID.
Create a client secret for the application and save the secret value when it is displayed.
Make a note of the secret identifier for reference.
Step 3 - Assign Azure permissions to the service principal
Why? The service principal needs both the Azure resource-management permissions documented by CrowdStrike and explicit data-plane permission to receive events from Event Hubs.
On the Event Hubs namespace, assign Contributor to the app service principal. This supplies the control-plane/resource-management access expected by Log Collector.
On the Event Hubs namespace (or the specific Event Hub, if you want a narrower scope), also assign Azure Event Hubs Data Receiver to the app service principal.
On the Storage account, assign Storage Blob Data Contributor to the app service principal so Log Collector can read, write, and update the Blob Storage data used for checkpointing.
Step 4 - Start a new Azure ingest feed in Log Collector
Why? The first part of the Log Collector configuration defines how incoming Event Hub data is preprocessed and parsed.
Detailed steps:
In Log Collector, go to Repositories and views and select the repository that will receive the data.
Select Settings. Under Ingest, select Ingest feeds.
Select New ingest feed, then select New Azure ingest feed.
Configure the feed:
Name - Enter a name for the feed. This field is required.
Description - Enter a meaningful description.
Preprocessing - Select how Log Collector should split the incoming data. The documented options are Azure records or new line; the correct choice depends on the source data.
Parser - Select the parser to apply to the ingested data. This field is required.
Select Next.
Step 5 - Configure the Azure Event Hub credentials
Why? These values identify the Event Hub source, the consumer group, and the Blob Storage location used for checkpointing.
In the Add credentials dialog, specify:
Fully qualified namespace - The Event Hubs namespace host name, for example
<namespace>.servicebus.windows.net.Event hub name - The name of the Event Hub to consume.
Consumer group - Select the dedicated consumer group created for LogScale, or another appropriate group.
Blob storage endpoint - The Blob service endpoint for the Storage account.
Storage Blob container name - The container used to store checkpoint data.
Default checkpoint - Choose Oldest position, Custom position, or Newest position to determine where consumption begins when no checkpoint exists.
Choose the initial checkpoint carefully. Oldest position begins with the earliest available event, while Newest position starts with newly queued events. A custom position lets you specify a starting position.
Step 6 - Configure authentication and test the feed
Why? LogScale uses the Entra application credentials to authenticate to the Azure resources configured for the feed.
In the Add authentication dialog, specify:
Client ID - The Application (client) ID from the app registration.
Client secret - The client secret value created for the app registration.
Secret ID - An identifier for the secret.
Tenant ID - The Directory (tenant) ID from the app registration.
Select Test Azure feeds to verify the configuration.
Resolve any authentication, Event Hub, storage, or permissions errors reported by the test.
Select Save to create the ingest feed.
Step 7 - Verfify ingestion
Why? An end-to-end check confirms that the source is producing events, LogScale can consume them, checkpoints can be written, and the selected parser handles the data correctly.
Ensure representative events are being sent to the configured Event Hub.
In LogScale, open the target repository and search for newly ingested events.
Verify that event timestamps and parsed fields are correct.
Confirm that checkpoint data is being created or updated in the configured Blob Storage container.
If data does not arrive, review the ingest-feed test result, service-principal role assignments, Event Hub and consumer-group values, Blob Storage endpoint/container, and parser configuration.