Set up Azure VNet Flow Logs monitoring

Azure Virtual Network (VNet) Flow Logs allow you to log information about IP traffic flowing through your virtual networks. With the New Relic VNet Flow Logs Forwarder, you can automatically forward these logs to New Relic for performance analytics and network connectivity troubleshooting.

How it works

The VNet Flow Logs Forwarder is an event-driven Azure Function App:

Event Grid → Event Hub: An Event Grid subscription on your flow-log storage account listens for BlobCreated events on the PT1H.json blobs and delivers them directly to an Event Hub. The subscription uses the blob path (event subject) as the partition key to guarantee per-file chronological ordering. There's no separate relay function.
VNetFlowLogsConsumer: An Event Hub-triggered function that processes each blob event by:
- Reading a cursor from Azure Table Storage to determine what's already been processed.
- Downloading only newly appended blocks from the PT1H.json blob (delta reads).
- Parsing VNet flow log records (flow tuples) into structured log entries.
- Sending the parsed records to New Relic via the Logs API.
- Committing the updated cursor on successful delivery.
VNetFlowLogsCleanup: A timer-triggered function that periodically removes stale cursor entries from Azure Table Storage (by default, daily at 03:00 UTC).

This architecture ensures efficient, incremental processing — only new data is read and forwarded, avoiding duplicate processing of already-seen records.

Prerequisites

New Relic prerequisites

You need the following in New Relic:

A New Relic account. Don't have one? Sign up for free! No credit card required.
A New Relic .

Azure prerequisites

You need the following in Azure:

An Azure subscription with VNet Flow Logs enabled on the target virtual networks. See Microsoft's documentation on enabling VNet Flow Logs.
A Storage Account where your VNet Flow Logs are being written (PT1H.json blobs).
An Event Hub namespace and Event Hub for event delivery (can be created automatically by the ARM/Bicep template).
An Azure Storage Account for the Function App runtime and cursor table storage (can be created automatically by the ARM/Bicep template).

Deploy the VNet Flow Logs Forwarder

You can deploy the VNet Flow Logs Forwarder using ARM/Bicep templates (recommended) or manually.

The New Relic VNet Flow Logs ARM template and Bicep template provide automated deployment of all required resources.

The template will automatically:

Create an Event Hub namespace, Event Hub, and consumer group
Deploy the Function App (Flex Consumption plan, Node.js 22) with the VNet Flow Logs functions
Create a Storage Account for the Function App runtime and cursor tracking
Create an Event Grid system topic and subscription that routes PT1H.json blob-creation events directly to the Event Hub
Assign a managed identity with the required role assignments
Configure all necessary application settings
Optionally enable private networking with VNet integration and private endpoints
Follow these steps:

Go to one.newrelic.com > Integrations & Agents.
Under Collections, select Logging, then click the Microsoft Azure VNet Flow Logs tile.
From the Select an account dropdown, choose the account to send your logs to, and click Continue.
On the Enter your license key step, click Create a new key, click Copy key and save it somewhere safe, then click Continue.
Click Deploy to Azure. A new tab opens in Azure with the ARM template loaded.
Select the Resource group and a Region for the deployment. We recommend a new resource group, to avoid accidentally deleting the components it creates.
In the New Relic license key field, paste the license key you copied earlier.
Ensure the New Relic endpoint is set to the one corresponding to your account (US, EU, or JP).
(Optional) Enter the Source Storage Account Name where your VNet Flow Logs are stored. It must be in the same resource group as this deployment. Leave it blank to create a new source storage account automatically.
(Optional) Select Disable Public Access To Storage Account to enable private networking mode with VNet integration and private endpoints.
(Optional) Configure advanced settings:
- New Relic Tags: Semicolon-separated tags (format: key1:value1;key2:value2)
- Max Retries: Maximum delivery retry attempts (default: 3)
- Retry Interval: Milliseconds between retries (default: 2000)
- Function Log Level: Verbosity of the Function App logs — Trace, Debug, Information, Warning, or Error (default: Information)
- Max Event Batch Size: Maximum number of Event Hub events processed per batch (default: 10)
- Min Event Batch Size: Minimum number of Event Hub events per batch (default: 5)
- Max Wait Time: Maximum time the trigger waits to fill a batch before processing, as hh:mm:ss (default: 00:00:30)
- Event Hub Scaling Mode: Basic (1 throughput unit, 4 partitions, no auto-inflate — low-to-medium traffic) or Enterprise (auto-inflate up to 40 throughput units, 32 partitions — high-throughput volumes) (default: Basic)
Click Review + create, review the configuration, and click Create.
Back in New Relic, on the Create log partition step, click Create partition. This creates a Log_VNET_Flows_Azure data partition (rule: instrumentation.name = 'vnet-app', STANDARD retention) so your VNet Flow Logs are stored and queried separately from your other logs. If a Log_VNET_Flows_Azure partition already exists on the account, click Continue to skip this step.
On the Test your logs step, confirm data is arriving by running SELECT * FROM Log_VNET_Flows_Azure, then click See your data.
Deployment architectures
The ARM/Bicep template supports two deployment modes:
Standard deployment (default):

Uses Event Grid to monitor blob creation in the source storage account
Routes events directly to the Event Hub for ordered processing, using the subject as the partition key
Processes VNet flow logs in the Function App and forwards them to New Relic
Enables public network access on the Function App, its storage account, and the Event Hub
Private networking deployment (optional, disablePublicAccessToStorageAccount=true):
Includes all features of the standard deployment
Isolates the Function App, its storage account, and the Event Hub within a private virtual network, with public network access to them disabled
Adds VNet integration with private endpoints for storage services (blob, file, queue, and table)
Creates private DNS zones for name resolution
Doesn't modify the source storage account (containing the VNet Flow Logs), which should keep public network access enabled

If you prefer manual deployment or need custom configuration:

Deploy the azure-vnet-flow-logs Function App to your Azure subscription.
Ensure the VNetFlowForwarder functions (VNetFlowLogsConsumer and VNetFlowLogsCleanup) are included in the deployment.
Configure the required environment variables (application settings) listed below.
Set up an Event Grid subscription on your flow-log storage account to route BlobCreated events directly to the Event Hub, using the event subject as the partition key.

Configuration

Configure the following application settings on your Azure Function App:

Required settings

Environment variable	Description
`NR_LICENSE_KEY`	Your New Relic license key.
`SOURCE_STORAGE_CONNECTION`	Connection string for the Azure Storage account where VNet Flow Logs are stored.
`CURSOR_STORAGE_CONNECTION`	Connection string for the Azure Storage account used to persist cursor state (can be the same as source).
`EVENTHUB_CONSUMER_CONNECTION`	Connection string for the Event Hub that delivers blob-creation events to the consumer function.
`EVENTHUB_NAME`	Name of the Event Hub instance.

Optional settings

Environment variable	Description	Default
`NR_ENDPOINT`	New Relic Logs API endpoint. Use `https://log-api.eu.newrelic.com/log/v1` for EU accounts.	`https://log-api.newrelic.com/log/v1`
`NR_TAGS`	Semicolon-separated tags to add to all forwarded logs. Format: `key1:value1;key2:value2`	None
`NR_MAX_RETRIES`	Maximum number of delivery retries to New Relic.	`3`
`NR_RETRY_INTERVAL`	Interval between retries in milliseconds.	`2000`
`EVENTHUB_CONSUMER_GROUP`	Event Hub consumer group.	`$Default`
`CURSOR_RETENTION_HOURS`	Number of hours to retain blob-cursor records before the cleanup job removes them.	`48`
`CURSOR_CLEANUP_SCHEDULE`	NCRONTAB schedule for the cursor cleanup timer trigger.	`0 0 3 * * *` (daily at 03:00 UTC)
`MAX_CONSECUTIVE_FAILURES`	Number of consecutive failures per blob before the forwarder skips it as a poison event.	`5`

View flow log data

Once configured, VNet Flow Log data will appear in New Relic. You can query it using NRQL:

SELECT * FROM Log_VNET_Flows_Azure

You can also visualize this data in the Conversations view, which groups your top flows by source, direction, protocol, and destination:

Conversations view showing top flows grouped by source endpoint, direction, protocol, and destination address

Each flow log record includes the following attributes:

Attribute	Description
`srcAddr`	Source IP address
`destAddr`	Destination IP address
`srcPort`	Source port
`destPort`	Destination port
`protocol`	Protocol (TCP, UDP, and ICMP)
`direction`	Traffic direction (Inbound, Outbound)
`flowState`	Flow state: `Begin`, `Continuing`, `End`, or `Deny`. A denied flow is expressed here as `Deny` — there's no separate action attribute.
`encryption`	Encryption status: `Encrypted`, `Not Encrypted`, or an `NX_*` reason code (for example, `NX_HW_NOT_SUPPORTED`)
`bytesSrcToDest`	Bytes from source to destination
`bytesDestToSrc`	Bytes from destination to source
`packetsSrcToDest`	Packets from source to destination
`packetsDestToSrc`	Packets from destination to source
`aclID`	Access control list ID associated with the flow
`rule`	NSG/ACL rule name that matched the flow
`targetResourceID`	Full Azure resource ID of the monitored target resource
`virtualNetworkName`	Virtual network name (when the target is a VNet or subnet)
`subnetName`	Subnet name (when applicable)
`macAddress`	MAC address associated with the flow log record
`category`	Log category (for example, `FlowLogFlowEvent`)
`operationName`	Operation name from the flow log record
`flowLogVersion`	VNet Flow Logs schema version
`flowLogGUID`	Unique identifier of the flow log resource
`flowLogResourceID`	Azure resource ID of the flow log

Dica

Each forwarded log also carries the common attributes instrumentation.provider (azure), instrumentation.name (vnet-app), and instrumentation.version (the forwarder version), plus any custom key/value pairs you set in NR_TAGS. The raw flow tuple CSV is preserved in the log message field.

Troubleshooting

For help with missing flow log data, duplicate records, or skipped (poison) events, see Troubleshoot Azure VNet Flow Logs monitoring.

How it works .css-21sua1{background:none;border:none;width:0;padding:0;}