How the Azure Event Hubs input gets Entra ID and Azure logs into Graylog
The Graylog Azure Event Hubs input is a Graylog Enterprise feature that reads log messages from an Azure Event Hub and feeds them into Graylog. If your security or platform team needs Entra ID and other Azure logs in Graylog, this input is the documented route, but it is not part of Graylog Open, so the licensing decision comes before any build work. Confirm with Graylog which license tier your deployment holds before you plan the Event Hubs side, because the input will not run on an Open installation.
The input covers Azure Active Directory sign-in and audit logs, Azure Audit logs, Azure Network Watcher logs, Azure Kubernetes Service logs and Azure SQL logs. Each of these reaches Graylog only if the Azure side routes it into an Event Hub, so the first task is inventory: list which log categories your tenant and subscriptions produce, which of them your detections depend on, and which Event Hub each one will land in. Confirm the current category names and the diagnostic setting options in Microsoft's Azure documentation for each service, since those names change and the input simply reads whatever arrives in the hub.
Plan the Azure export and the Graylog license together. Entra ID sign-in and audit logs are emitted through diagnostic settings, and the same tenant may already send some of them to a Log Analytics workspace or storage account. Adding an Event Hub destination is an additional route, not a replacement, so check what is already exported before you add cost or duplicate ingestion. The Graylog Azure Event Hubs input documentation is the natural next read for the exact supported log types and setup fields.
What you need before configuring the Event Hubs input
The Graylog Azure Event Hubs input depends on Azure resources you create and a Graylog Enterprise license, and the Azure side has to be ready before Graylog can read anything. Confirm each item below with the team that owns your Azure subscription and your Graylog environment before scheduling the configuration work.
Event Hubs instance
The input reads from an Azure Event Hubs instance, which is the queue that receives the exported logs. Decide which namespace and hub will carry Entra ID and Azure logs, and whether they share a hub with other data. Ask who owns the namespace, which region it sits in, and how it is sized, because hub capacity and retention affect how much backlog Graylog can recover after an outage.
Shared Access Signature policy
Create a Shared Access Signature policy on the Event Hub with only the Listen permission. Graylog needs to read events, not send or manage them, so a policy with broader rights widens the blast radius if the connection string leaks. Confirm with your Azure administrators that the policy is scoped to this hub and not reused by other tools.
Consumer group
A dedicated consumer group gives Graylog its own read position in the hub, so its progress does not interfere with other readers. Create one for this input and name it so the owning team can recognize it later. Confirm that no other consumer reads the same group, because two readers sharing one group will split events and produce gaps in searches.
Event Hub connection string
Graylog needs the connection string for the policy to authenticate to the hub. Store it in a secrets manager or the Graylog configuration store under restricted access, and rotate it when people with access change roles. Ask your Azure team how the string is issued and rotated, since a rotation that is not coordinated with Graylog will stop ingestion until the input is updated.
Graylog Enterprise license
The Azure Event Hubs input is an Enterprise feature, so the Graylog deployment must carry an Enterprise license before the input can be created. Confirm the license covers the node count and daily volume you expect, and check the edition assumptions against the pricing page before the project is scoped. Open edition deployments cannot use this input.
Network path and diagnostic settings
Graylog nodes must reach the Event Hubs endpoints over the network, which may need outbound rules on your firewall or proxy. Separately, Azure diagnostic settings must route Entra ID sign-in and audit logs, Azure activity, Network Watcher, AKS and Azure SQL logs into the Event Hub. Confirm both with your network and Azure administrators, since missing diagnostic routes produce a working input that receives nothing.
Configuring the input step by step
This sequence takes you from licensing and Azure preparation to a running Graylog Azure Event Hubs input that delivers Entra ID and Azure logs, with a check at each stage so you know the data path works before you rely on it.
Confirm the Enterprise license is in place
Before any Azure work, confirm that your Graylog installation is licensed for Graylog Enterprise, because the Azure Event Hubs input is an Enterprise feature and will not appear as usable on Graylog Open. Ask the Graylog account team or check your license in the Graylog interface, and confirm the license covers the server nodes you plan to run the input on. Done means the input type is available in the inputs list of your target Graylog node. If it is not, stop here and resolve licensing first, since later steps will not produce data without it.
Create or select the Event Hub
Identify or create the Event Hubs namespace and the Event Hub instance that will receive your Azure logs. Work with the Azure administrator who owns the subscription, because the namespace location and network rules affect whether Graylog can reach it later. Record the Event Hub name, since you will need it when you configure the input. Done means the Event Hub appears in the Azure portal under its namespace with a status of active, and you can see it listed when you browse the namespace.
Configure diagnostic settings for each log category
In the Azure resource or Entra ID diagnostic settings, add one diagnostic setting per log category you want, and route each one to the Event Hub you created. Entra ID sign-in and audit logs, Azure Activity, Network Watcher, AKS and Azure SQL logs each come from their own source, so enable only the categories your security team needs and record which ones you chose. Done means each diagnostic setting shows the Event Hub as its destination, and after some activity you can see events arriving in the Event Hub metrics or through the portal's data view.
Create a SAS policy with only Listen
Create a Shared Access Signature policy on the Event Hub, or on the namespace if your design requires it, and grant it only the Listen permission. Graylog reads from the Event Hub and never sends to it, so Send and Manage rights add risk without benefit. Name the policy for this Graylog environment so it can be rotated independently. Done means the policy lists Listen as its only permission, and you have copied the connection string for it into your secrets handling process, not into a shared document.
Create a dedicated consumer group for this input
Create a consumer group on the Event Hub that is used only by this Graylog input. Each consumer group keeps its own read position, so sharing one between Graylog and another consumer, or between two Graylog inputs, causes readers to compete for partitions and miss or split events. Record the consumer group name exactly as created. Done means the consumer group appears on the Event Hub, is not used by any other application in your records, and is named so that the owning Graylog input can be identified from the name.
Add the connection string to the Graylog input
In Graylog, open System, Inputs, and launch an Azure Event Hubs input on a node that will run it. Enter the Event Hub connection string from the SAS policy, the Event Hub name, the consumer group you created, and the other required fields as the input form requests them. Save the input without starting it first if your process requires review. Done means the input is listed in the inputs page with the correct consumer group and Event Hub name shown in its configuration, and the connection string is stored by Graylog rather than pasted into any ticket or chat.
Start the input and verify messages arrive
Start the input and open the input's message count or the node's input diagnostics page. Confirm that the Event Hub produces new events after the diagnostic settings were enabled, and that the message count increases over a short period. Then run a search in Graylog for a known Entra ID sign-in or Azure activity event, filtering by the source or timestamp, and confirm the record is present with the expected fields. Done means the message count increases, the test event appears in search results, and any parsing errors are logged for follow-up before you build alerts or dashboards on this data.
How consumer groups and throughput planning shape ingestion
Each reader of an Event Hub needs its own consumer group, because a consumer group keeps its own position in each partition. If Graylog and another tool such as a SIEM or archive pipeline share one consumer group, they compete for the same offsets, and one reader can skip or stall the other. Create a dedicated consumer group for the Graylog input, name it in the input configuration, and record which Event Hub and which consumer group each Graylog input uses. Confirm the consumer group limits for your Event Hubs tier in Microsoft's documentation before you add readers, since the number of readers per group and the number of groups per hub are fixed by the service.
Partitions set the upper bound on parallel reading, and message volume sets the load each partition carries. Sign-in logs from a large tenant can arrive in bursts after a morning login peak, a mass password reset or an incident that triggers many authentication events. The Event Hubs input reads what the partitions hold, so the work lands on the Graylog nodes that run the input. Ask the Event Hub owner for the partition count, the expected peak messages per second for each log category, and the retention period on the hub, then compare those figures with what the input can consume during a burst.
Graylog sizing follows the pillar guidance: plan storage as daily ingest times retention days times 120 percent, and give the message journal 3 to 5 times daily ingest on SSDs. The journal is the buffer that absorbs a burst when indexing falls behind, so an undersized journal turns a short spike into lost or delayed sign-in events. Also plan node count with failover in mind. The multi-node guidance calls for three Graylog nodes with the is_leader setting set to false on followers, so a single node restart does not stop ingestion. Measure your real daily volume for each Entra ID and Azure category over a representative week before you fix the journal size.
Which Graylog edition and log sources fit your team
Graylog Open is free to download and run, and it is licensed under SSPL-1.0, which is not an OSI-approved open source license. It ingests logs through inputs such as syslog, GELF and Beats, and it supports Active Directory and LDAP authentication and trusted header authentication for people who sign in to the web interface. It does not include the Azure Event Hubs input, so a team that needs Entra ID or Azure logs inside Graylog Open must find another collection path, such as forwarding through a collector the team operates. Graylog Open does not provide Entra ID sign-in for the Graylog interface either, since Okta, generic OpenID Connect and SAML single sign-on are listed for Enterprise.
- Identity for Graylog users: Active Directory, LDAP and trusted header authentication are available on Open, so the Graylog login can follow your directory model.
- Azure input access: The Event Hubs input is a Graylog Enterprise feature, not part of Open.
- Community support only: Graylog Open comes with community support, so production ownership of the Azure pipeline rests with your team.
- Verify before you commit: Confirm your edition entitlements with Graylog before designing the pipeline around any input.
Confirm with your Graylog account contact which features your planned edition includes before you finalize the architecture.
The Azure Event Hubs input is part of Graylog Enterprise. According to the Graylog pricing page, Graylog Enterprise starts at 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units. Licensing is based on processed data, with no per-user or per-device fees, so the cost tracks the volume of Azure logs you route through Graylog. Graylog Enterprise also adds a data lake with archive restore, data tiering, a correlation engine and 24/7 support, which matter when Azure sign-in history must be kept for long periods.
- Starting price: The Enterprise starting point is 15,000 US dollars per year according to the Graylog pricing page, and the final figure depends on your data volume and quote.
- Processed data basis: Licensing is on processed data, so the Azure categories you enable directly affect the license scope.
- Included capabilities: Archive restore, data tiering and the correlation engine are Enterprise features that shape long-term Azure log handling.
- Security tier: Graylog Security, at 18,000 US dollars per year according to the same pricing page, adds SIEM features such as investigations and prebuilt threat detection content.
Ask Graylog for a written quote that states the data volume basis, the minimum tier and whether the Azure categories you need are covered by your chosen license.
The Event Hubs input is documented to handle several Azure log families, and each one arrives through the same Event Hub connection. Entra ID sign-in and audit logs are the identity records most security teams start with, because they show who signed in, from where and what administrative changes were made. Azure Audit, Azure Network Watcher, Azure Kubernetes Service and Azure SQL logs cover control plane activity, network flow visibility, cluster events and database access. Choose the categories by the questions your team must answer, not by which ones are easiest to switch on, because each enabled category adds to processed volume.
- Entra ID sign-in and audit logs: Identity events for authentication review and administrative change tracking.
- Azure Audit: Control plane activity across subscriptions for change investigations.
- Network Watcher and AKS: Network and container platform logs for infrastructure and cluster investigations.
- Azure SQL: Database access and audit records for data access reviews.
Confirm with Microsoft which diagnostic settings must be enabled in each Azure source so that the categories you select actually emit data into the Event Hub.
If your identity and productivity audit trails come mainly from Microsoft 365 or Okta, a sibling Graylog input may fit better than the Azure Event Hubs input. These are also Enterprise-licensed inputs, so the license question stays the same, but the collection path, prerequisites and polling model differ. The Microsoft 365 input requires an Azure application registration and audit log prerequisites, while the Okta input uses an Okta API key and a polling interval. Many organizations run more than one of these, so decide which source owns each log family before you build dashboards that span them.
- Microsoft 365 audit path: Pulls Office 365 audit trails through Azure application registration, which is separate from Event Hubs.
- Okta audit path: Pulls Okta system logs using API keys and polling, useful when Okta is your primary sign-in system.
- Overlap check: Entra ID sign-ins can appear through more than one path, so avoid duplicate ingestion and double licensing.
- Version checks: Review version issues in the sibling guidance before upgrading Graylog.
Confirm which identity source is authoritative for each event type before you assign inputs to streams.
How Azure log categories map to Graylog messages and streams
This table pairs each Azure log source the Graylog Azure Event Hubs input supports with the Event Hub feed it arrives on and a suggested stream or index routing. Use it to plan which Event Hub and consumer group each category needs, then confirm field names against real message samples before writing stream rules. The main takeaway is that routing should follow the source category, while field-level parsing stays unverified until your own samples are reviewed.
| Azure log source | Event Hub source | Suggested stream or index routing | Verify against message samples |
|---|---|---|---|
| Entra ID sign-in logs | Diagnostic setting exporting SignInLogs to an Event Hub | Dedicated identity stream with its own index set | User, client app, IP address, result and conditional access fields |
| Entra ID audit logs | Diagnostic setting exporting AuditLogs to an Event Hub | Separate identity change stream, reviewed by administrators | Initiator, target resource, operation name and category fields |
| Azure Audit (activity) logs | Activity log exported through a diagnostic setting | Cloud control plane stream, grouped by subscription | Caller, subscription ID, resource ID and operation fields |
| Azure Network Watcher logs | Network Watcher flow or diagnostic category to Event Hub | Network stream, kept apart from identity events | Flow tuple layout, source and destination fields, and version |
| Azure Kubernetes Service logs | Control plane or audit category to Event Hub | Container platform stream, sized separately from identity | Namespace, verb, user and request URI fields |
| Azure SQL logs | Diagnostic setting for database audit or diagnostics | Database audit stream with a longer retention index set | Server name, database name, action and principal fields |
Securing the Event Hubs credential and network path
The Event Hubs connection string is the only thing that lets the input read your Azure logs, so it deserves the same care as any other production secret. The cards below cover scoping the credential, rotating it, storing it inside Graylog, limiting outbound paths and restricting who can view the configuration.
Scope the SAS policy to Listen
The input needs a Shared Access Signature policy with the Listen permission and nothing more. Create a dedicated policy on the Event Hub used for this input, not the namespace root policy that also grants send and manage rights. If the policy is ever exposed, a Listen-only key can read the stream but cannot publish events or change the namespace. Confirm the exact permission labels in the Azure portal for your tier.
Plan key rotation without downtime
Rotating a SAS key changes the connection string, so every input using it must be updated. Azure allows two keys per policy, so you can switch the input to the secondary key, then regenerate the primary. Record which key each Graylog input uses and schedule rotation during a maintenance window. Confirm with your Azure administrator how often your security policy requires rotation and who approves it.
Store the connection string securely
Do not paste the connection string into change tickets, shared runbooks or configuration files stored in Git. Keep it in your organization's secrets manager and enter it into Graylog only through the input configuration form. Check how your Graylog version stores and masks the value in the input settings, and confirm that exports, backups and support bundles do not expose it in clear text.
Restrict outbound access from Graylog nodes
Graylog server nodes need outbound connectivity to the Event Hubs endpoints for your namespace, and nothing else for this input. Limit egress from the Graylog subnet to those endpoints and to the AMQP or Kafka ports the Event Hubs client uses, and log denied flows. Confirm the endpoint names and ports for your Azure cloud, since sovereign and government clouds use different domains, and test the path from every Graylog node, not only one.
Limit who can read the input
Graylog users who can view an input's configuration may see its stored credentials or the parts of them Graylog displays. Restrict input management to a small administrator role and give analysts search access only. Review which roles can edit inputs, and confirm with Graylog's role documentation for your edition whether input settings are visible to read-only users.
Review access and key use regularly
Keep a record of who created the Event Hub policy, when keys were last rotated and which Graylog inputs depend on each key. Review Azure activity logs for unexpected use of the policy, and compare them with the events Graylog receives. Ask your Azure team which monitoring is available for Event Hubs in your subscription, since options depend on your tenant and licensing.
Why Azure logs stop arriving in Graylog
This table lists the failures that most often stop Azure logs from reaching Graylog through Event Hubs, with the cause and fix for each. Work down the rows in order, since a missing license or a wrong policy blocks everything else. Check the Graylog input status and the Event Hubs side before changing anything in Graylog.
| Symptom or failure | Likely cause | Fix |
|---|---|---|
| Input will not start or shows no data | Graylog Enterprise license is missing or expired, and the Azure Event Hubs input is an Enterprise feature | Confirm the Enterprise license is installed and active on the Graylog cluster, then restart or re-create the input |
| Connection fails at startup | The Shared Access Signature policy lacks the Listen permission, so Graylog cannot read from the event hub | Create or edit a policy on the Event Hub with Listen only, and use its connection string in the input |
| Messages arrive for one input but are missing or uneven | Two readers share the same consumer group and compete for partitions | Give each Graylog input its own consumer group, and do not reuse the default group for other applications |
| Input connects but shows errors or nothing arrives | Wrong connection string or entity path, such as a namespace-level string used where the event hub name is required | Copy the connection string for the specific event hub, confirm the entity path matches it, and retest |
| Specific Azure categories are missing | Diagnostic settings are not enabled for that log category on the source resource or Entra ID tenant | Enable each required category in the diagnostic settings and point it at the event hub the input reads |
| Input reads from Event Hubs but cannot reach Graylog data or processing | Egress from the Graylog nodes to Azure endpoints is blocked by a firewall, proxy or network security rule | Allow outbound connections from every Graylog node to the Event Hubs endpoints, and test from each node, not only one |
| Delay grows and the input falls behind | Journal backlog from ingest rate above what the nodes or Data Nodes can index | Check journal utilization, add processing capacity or Data Node capacity, and review the volume of each Azure category before enabling it |
Questions teams ask before configuring Azure logs in Graylog
Does the Graylog Azure Event Hubs input require a paid license?
Yes. The Azure Event Hubs input is a Graylog Enterprise feature, so it is not available in Graylog Open, which is licensed under SSPL-1.0 and is not an OSI-approved open source license. Graylog's pricing page lists Graylog Enterprise from 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees. Confirm the current terms and the minimum that applies to your ingest with Graylog before you commit, because the minimum affects which tier fits.
What does it cost to collect Azure logs through Event Hubs?
Expect three cost groups. The first is the Graylog Enterprise license, which is a recurring annual fee tied to processed data. The second is Azure spend for Event Hubs throughput, diagnostic settings and any capture or retention you configure, billed by Microsoft. The third is storage and compute for your Graylog nodes and Data Node or OpenSearch backend, which you provision in your own infrastructure. Ask any partner for a quote that separates one-time setup from recurring license, Azure and infrastructure costs, and confirm current Azure Event Hubs pricing in your region with Microsoft.
How long does it take to set up the Azure Event Hubs input?
The input itself is a short configuration once the Azure side exists, but the total time depends on what is already in place. The main variables are whether an Event Hubs namespace and instance already exist, whether the diagnostic settings that export Entra ID sign-in and audit logs are configured, who approves the Shared Access Signature policy, and whether Graylog Enterprise is already licensed. Your team or a partner can agree the duration in a written scope once those prerequisites are confirmed.
What does my team need to provide before the work starts?
You need an Azure subscription where you can create or reuse an Event Hubs namespace and instance, permission to create a Shared Access Signature policy with the Listen permission, and a consumer group for Graylog. You also need the Event Hub connection string handled under your secrets practice, a running Graylog Enterprise deployment with enough capacity for the expected volume, and a named owner who can approve diagnostic setting changes in Entra ID and Azure. Confirm network paths from Graylog nodes to the Event Hubs endpoints before the build.
Can our own team set this up without a partner?
Yes, if you have people who can administer Azure Event Hubs and Entra ID diagnostic settings and who operate Graylog. The configuration steps are documented by Graylog, and the Listen policy, consumer group and connection string are standard Azure objects. Teams usually decide to bring in help for throughput planning, consumer group design for multiple readers, secrets handling, and validation that every category you need is arriving and parsed. A fixed-scope engagement lets you buy only the parts you cannot staff.
Do we need Entra ID Premium to export sign-in and audit logs?
Confirm this with Microsoft before you plan the work. Entra ID sign-in and audit logs are exported through diagnostic settings, and some log categories and retention options depend on the Entra ID license tier in your tenant. Check which log categories your tenant can export, whether any require a premium license, and whether your existing security tooling already consumes the same export. Record the answer in your design so the Graylog scope matches what your tenant can deliver.
How do consumer groups and throughput affect what we can ingest?
Each reader needs its own consumer group, so a second Graylog or tool reading the same Event Hub must use a separate group to avoid sharing offsets. Throughput depends on the number of partitions and throughput units on the Event Hub, and on how many Graylog nodes process the stream. Ask Graylog and your Azure administrator to confirm partition count, expected events per second and the Enterprise tier that matches your daily volume, then test with real sign-in and audit traffic before you rely on the pipeline.
How to test that the input is complete and stays healthy
Test the input end to end before you trust it. Generate known events on purpose, then follow them from the Azure source through Event Hubs into Graylog. Sign in with a test account in the tenant, make a configuration change in Azure Activity or a read against a resource covered by your chosen log categories, and confirm that each event lands in Graylog within the window you expect. Compare message counts per source (Entra ID sign-in, Entra ID audit, Azure Audit, Network Watcher, AKS and Azure SQL) against what the Azure portal shows for the same period. A source that is enabled in Azure but absent in Graylog usually points to a diagnostic setting that was never pointed at the Event Hub, or to a category you did not select. Record the counts as your baseline so that later drift is visible.
Then check that the data is usable, not just present. Confirm that the timestamp on each message matches the event time in Azure rather than the ingest time, because a skew here breaks time-based searches and alert windows. Open sample messages from each source and check that the fields you plan to query, such as user principal name, IP address, operation name and result, are extracted as the Graylog fields you expect. Confirm that each source is routed to the stream you designed, and that messages do not fall into the default stream. Finally, prove the data serves a purpose by running a dashboard widget or an event definition that uses it, such as a failed sign-in threshold. Confirm the Enterprise license is active before you rely on the input, since the input is an Enterprise feature.
For ongoing health, set a recurring review rather than a one-time test. Check the input status and any error messages in the Graylog system pages, watch the message journal depth and the rate of incoming messages on each node, and compare daily counts per source with the baseline. Rerun the sign-in test after any change to the tenant, Event Hub, consumer group, shared access policy or Graylog version, because those changes can stop delivery without an obvious error. Confirm the review cadence, owner and escalation path with your own operations team, and check the Azure Event Hubs input documentation for the settings your Graylog version exposes before you write the runbook.
How DeployOpen scopes and delivers Azure Event Hubs integrations
DeployOpen plans, builds, tests and documents the Azure Event Hubs input for Graylog inside your own environment, starting from a written scope. The work covers the Azure side of Entra ID and Azure log export, the Graylog input configuration and the operating notes your team needs after handover.
How we scope
- The written scope lists which Azure log categories reach Graylog, such as Entra ID sign-in and audit logs or AKS logs.
- We confirm your Graylog edition, since the Event Hubs input requires an Enterprise license before any build starts.
- The scope records the Event Hub namespaces, consumer groups and the expected daily volume that will drive throughput planning.
How we build
- We create or review the Shared Access Signature policy so it carries only the Listen permission the input needs.
- We configure one consumer group per reading application so Graylog nodes do not compete for the same partitions.
- We test ingestion end to end, checking parsing, stream routing and index placement against sample sign-in and audit events.
How we hand over
- You receive configuration records for the Azure objects, the Graylog input and the connection string handling process.
- The runbook explains how to rotate the policy key, add a log category and recognize a stalled consumer group.
- We walk your platform and security teams through the test results and the open items agreed in the scope.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial delivery.
- Changes to Azure log categories or Graylog versions can be scoped as separate, fixed-scope change requests.
- Confirm with DeployOpen the support hours, response terms and Graylog version coverage before signing any retainer.
