Azure Integration Services – Techy Chalkboard in bits and pieces

When running applications on Azure, ensuring security and performance is paramount. Azure Web Application Firewall (WAF) and Application Gateway generate extensive logs that help diagnose security threats, server failures, and performance bottlenecks. But how do you extract meaningful insights from these logs? The answer lies in Kusto Query Language (KQL).
In this blog post, I’ll guide you through some powerful KQL queries to analyze WAF logs and detect failures in Azure Application Gateway. Whether you’re a security analyst or a DevOps engineer, these queries will help you troubleshoot issues like a pro!

🔥 Detecting Blocked Requests by WAF
Azure WAF is designed to protect your applications from malicious requests. But how do you check if legitimate users are getting blocked?

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where action_s == "Block"
| project TimeGenerated, clientIp_s, requestUri_s, ruleName_s, details_data_s
| order by TimeGenerated desc

🛠️ How This Helps:
Identifies requests that were blocked by WAF.
Helps fine-tune WAF rules to reduce false positives.
Tracks client IPs and URLs being flagged as threats.
🚨 Identifying Application Gateway Failures
Application Gateway failures can be catastrophic for your users. If your app is throwing HTTP 500 errors, you need to know why.

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayAccessLog"
| where httpStatus_d >= 500
| project TimeGenerated, requestUri_s, httpStatus_d, backendPoolName_s,backendSettingName_s, host_s
| order by TimeGenerated desc

🛠️ Why This Query is Important:
Helps identify server-side failures.
Detects backend servers that may be down.
Quickly find affected URLs and services.
⚡ Uncovering High Latency Requests
Nobody likes a slow website. If users experience delays, they might leave your site frustrated. This query helps find slow API responses.

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayPerformanceLog"
| where timeTaken_d > 3000 // Requests taking more than 3 seconds
| project TimeGenerated, requestUri_s, timeTaken_d, clientIp_s, host_s
| order by timeTaken_d desc

🛠️ What You Gain:
Detects slow requests causing performance issues.
Identifies whether the delay is from the backend or frontend.
Helps optimize server response times.
🕵️ Tracking WAF Logs for a Specific Client IP
Want to investigate if a particular user or bot is getting blocked? This query is your best friend!

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where clientIp_s == "X.X.X.X" // Replace with actual client IP
| order by TimeGenerated desc

🛠️ Why Use This:
Track a specific user experiencing access issues.
Identify potential attackers trying to breach security.
Debug WAF rule misconfigurations.
💀 Detecting Backend Failures in App Gateway
Application Gateway connects to backend servers. If the backend is failing, requests will not be processed correctly.

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayAccessLog"
| where httpStatus_d <> "200"
| where requestUri_s = "/status-0123456789abcdef"
| project TimeGenerated, requestUri_s, httpStatus_d, backendPoolName_s, backendSettingName_s, host_s
| order by TimeGenerated desc

🛠️ Key Insights:
Detects backend servers going offline.
Helps analyze downtime patterns.
Prevents cascading failures in multi-server deployments.
Final Thoughts
Mastering KQL can transform the way you troubleshoot and secure your Azure infrastructure. Whether you’re dealing with WAF security issues, slow applications, or backend failures, these queries will make your life easier.
So, next time your boss asks, “Why is our app slow?” or “Why did a request get blocked?”, you know exactly where to look!
🔎 Have a favorite KQL query for Azure logs? Drop it in the comments below!

Azure Logic Apps & Service Bus: When Do You Need the ‘Manage’ Claim?

March 5, 2025March 5, 2025 Manjunath

Ever wondered why your Azure Logic Apps sometimes fail to process messages consistently from a Service Bus queue? If you’ve run into issues with scaling, missing permissions, or unexpected failures, you’re not alone.

One of the key reasons for these inconsistencies is whether runtime scaling is enabled or disabled. And a major factor that affects this is the ‘Manage’ claim in your Service Bus connection string.

Understanding the Role of Runtime Scaling

Azure Functions that process messages from Service Bus queues can scale dynamically based on queue length. This is controlled by runtime scale monitoring. Whether you need the ‘Manage’ claim depends on whether this setting is enabled or not.

When Runtime Scaling is Enabled – ‘Manage’ Claim is Required

When runtime scaling is ON, Azure needs to check the active message count to decide whether to scale up.
To get this information, the system queries the Service Bus queue metadata.
Without the Manage claim in the connection string, the system cannot access queue details and fails to determine the active message count.

And that’s when you start seeing errors like this:

“Connection string does not have ‘Manage Claim’ for queue ‘[Queue_Name_Here]‘. Unable to determine active message count.”

Since it can’t retrieve the queue length, it falls back on alternative metrics:

“Failed to get queue description to derive queue length metrics. Falling back to using first message enqueued time.”

When Runtime Scaling is Disabled – ‘Manage’ Claim is NOT Required

When runtime scaling is OFF, Azure Functions do not need to query the queue length.
The function still processes messages as they arrive, but without automatic scaling.
Since it doesn’t check queue metadata, the Manage claim is not needed.

This is why, in some cases, disabling runtime scaling makes things appear to work more reliably. There’s no interference from scaling decisions, and messages just get processed at a steady rate.

How to Avoid Failures and Keep Things Running Smoothly

If You Want Scaling (Runtime Scaling ON)

✅ Make sure your Service Bus connection string has the Manage permission.
✅ Enable runtime scale monitoring in Azure Function settings.
✅ Keep an eye on scaling behavior in Application Insights to avoid thread pool starvation.

If You Don’t Need Scaling (Runtime Scaling OFF)

✅ No need for the ‘Manage’ claim—just Listen and Send permissions are enough.
✅ Adjust function concurrency settings to control the processing rate manually.
✅ Monitor your Service Bus queue to ensure messages don’t pile up.

By understanding how runtime scaling and permissions interact, you can avoid frustrating failures and keep your Azure Logic Apps running smoothly. Whether you need scaling or just steady processing, configuring things the right way makes all the difference.

Azure, Azure Integration Services, Nutshell Series

Understanding DNAT, Application, and Network Rules in Azure Firewall

February 16, 2025February 16, 2025 Manjunath

Azure Firewall is a cloud-native security service that provides advanced threat protection for Azure workloads. It supports three main rule types:

DNAT (Destination Network Address Translation) Rules – Used to expose internal resources externally.
Application Rules – Controls outbound HTTP(S) traffic using FQDNs, URL filtering, and web categories.
Network Rules – Filters non-HTTP(S) traffic based on IP addresses, ports, and service tags.

1. DNAT (Destination Network Address Translation) Rules

DNAT rules allow inbound traffic from the internet. This traffic can be redirected to a private resource inside an Azure Virtual Network (VNet).

Example DNAT Rule

Source Type/IP/IP Group	Destination IP/Port	Translated IP/FQDN	Translated Port	Protocol
52.10.20.30	443	10.1.0.10 or app.internal.local	443	TCP or UDP

2. Application Rules

Application rules control outbound HTTP(S) traffic using:

FQDNs (e.g., *.microsoft.com)
FQDN Tags (e.g., WindowsUpdate, AzureActiveDirectory)
URL Filtering (block specific URLs)
Web Categories (e.g., Social Networking, Streaming)

Example Application Rule

Source IP Range	Protocol	Port	Allowed FQDNs	FQDN Tag	Web Category
10.0.0.0/24	HTTPS	443	*.microsoft.com	WindowsUpdate	Shopping

3. Network Rules

Network rules filter non-HTTP(S) traffic using:

IP Addresses
Service Tags (e.g., AzureSQL, Storage)
IP Groups
FQDNs

Example Network Rule

Source IP Range	Destination IP/FQDN	Protocol	Port	Service Tag
10.1.0.0/24	10.2.0.10 or db.internal.local	TCP	1433 (SQL)	AzureSQL

4. Comparison of DNAT, Application, and Network Rules

Destination Types

Rule Type	Best For	Filters By	Supports FQDN?	Supports FQDN Tags?	Supports URL Filtering?	Supports Web Categories?	Supports Service Tags?	Supports IP Groups?	Supports IP Addresses?
DNAT Rules	Inbound traffic redirection	Firewall IP → Translated IP/FQDN	✅	❌	❌	❌	❌	❌	✅ (Destination)
Application Rules	Outbound HTTP(S) control	FQDNs, FQDN Tags, URLs, Web Categories	✅	✅	✅	✅	❌	❌	❌
Network Rules	Non-HTTP traffic control	IP, Service Tags, FQDN, IP Groups	✅	❌	❌	❌	✅	✅	✅

5. When to Use Each Rule Type

DNAT Rules – Expose internal resources to external users.
Application Rules – Control outbound HTTP(S) traffic with FQDN, URL filtering, and Web Categories.
Network Rules – Allow or block non-HTTP(S) traffic based on IPs, Service Tags, and IP Groups.

Azure, Azure Integration Services, Nutshell Series

Azure Tagging Strategies

September 25, 2024September 25, 2024 Manjunath

Tags in Azure help organize resources for cost management, governance, and automation. Here’s a quick guide to effective tagging.

Common Tag Categories

Owner: Who is responsible for the resource (e.g., Owner).
Billing: Track costs (e.g., CostCenter, Project).
Environment: Classify resources by environment (e.g., Production, Development).
Application: Identify apps or services (e.g., Application, Role).
Compliance: Ensure security and compliance (e.g., Compliance, DataClassification).

Best Practices

Use consistent tag keys and values.
Inherit tags to all resources from resource groups.
Limit tags to essentials for simplicity.
Automate tagging using Azure Policy and CLI.
Leverage tags for cost tracking and governance.

“Tags are vital for managing cloud resources efficiently in Azure.”
– Azure Expert

Learn More About Azure Tags

Azure Integration Services, Nutshell Series, Technology and tricks

Symmetric vs Asymmetric Encryption

September 23, 2024September 24, 2024 Manjunath

Symmetric Encryption

Key: Shared between sender and receiver.
Encryption: Sender encrypts using key, creating ciphertext.
Example: AES encryption.
Advantages: Faster, suitable for large data.
Disadvantages: Key distribution challenge, security compromised if key is leaked.

Asymmetric Encryption

Keys: Public for encryption, private for decryption.
Encryption: Sender uses recipient’s public key.
Decryption: Recipient uses private key.
Digital Signature: Sender signs with private key.
Verification: Recipient verifies with sender’s public key.
Advantages: No shared key needed; public keys distributable via CA (certificate Authority).
Disadvantages: Slower, computationally intensive.

Azure, Azure Integration Services, Nutshell Series, Technology and tricks

Essential Network Commands – Nutshell

September 18, 2024August 6, 2025 Manjunath

Managing network connections and diagnosing issues can be made easier by using the right network commands. Here’s a quick guide to essential network commands for Windows, Azure Function Apps Console, and OpenSSL.

1. Windows Network Commands

Command	Environment	Description	Example
`ipconfig`	Windows (CMD)	Displays network configuration	`ipconfig`
`Get-NetIPAddress`	Windows (PowerShell)	PowerShell version of ipconfig	`Get-NetIPAddress`
`ping`	Windows (CMD)	Tests connectivity to a host	`ping google.com`
`Test-Connection`	Windows (PowerShell)	PowerShell version of ping	`Test-Connection google.com`
`tracert`	Windows (CMD)	Traces network packet route	`tracert google.com`
`Test-NetConnection`	Windows (PowerShell)	PowerShell version of tracert	`Test-NetConnection google.com -TraceRoute`
`netstat`	Windows (CMD)	Shows active connections	`netstat -an`
`Get-NetTCPConnection`	Windows (PowerShell)	PowerShell version of netstat	`Get-NetTCPConnection`

2. Azure Function Apps Console Network Commands

Command	Environment	Description	Example
`curl`	Azure Function Apps	Tests network/API endpoint	`curl https://example.com`
`nslookup`	Azure Function Apps	Resolves DNS name	`nslookup example.com`
`ping`	Azure Function Apps	Tests connectivity to a remote host	`ping example.com`
`traceroute`	Azure Function Apps	Traces packet path to a host	`traceroute example.com`

3. OpenSSL Command

Command Environment Description Example

Command	Environment	Description	Example
`openssl s_client -connect`	OpenSSL (CMD, Console)	Tests SSL/TLS connection to a host Pass additional parameter -tls1 or -tls1_1 or -tls1_2 or -tls1_3 or -ssl3 to check appropriate TLS/SSL protocols	`openssl s_client -connect example.com:443`

openssl s_client -connect

OpenSSL (CMD, Console)

Tests SSL/TLS connection to a host

Pass additional parameter -tls1 or -tls1_1 or -tls1_2 or -tls1_3 or -ssl3 to check appropriate TLS/SSL protocols

openssl s_client -connect example.com:443

These commands can simplify network troubleshooting across various environments: Windows, Azure Function Apps, and OpenSSL. With the right tools, managing your network connections becomes more efficient and secure.

Azure, Azure Integration Services, Nutshell Series, Technology and tricks

Basic Azure CLI Commands – Nutshell

September 16, 2024September 16, 2024 Manjunath

Authentication & Subscription


# Login to Azure:
az login

# Show current subscription:
az account show

# List all subscriptions:
az account list

# Set active subscription:
az account set --subscription <subscription-id>

Resource Groups


# Create a resource group:
az group create --name <resource-group-name> --location <location>

# List all resource groups:
az group list

# Delete a resource group:
az group delete --name <resource-group-name> --yes

Virtual Machines (VMs)


# List all VMs:
az vm list --output table

# Create a VM:
az vm create --resource-group <resource-group-name> --name <vm-name> --image <image> --admin-username <username> --admin-password <password>

# Start a VM:
az vm start --name <vm-name> --resource-group <resource-group-name>

# Stop a VM:
az vm stop --name <vm-name> --resource-group <resource-group-name>

# Delete a VM:
az vm delete --resource-group <resource-group-name> --name <vm-name>

Storage Accounts


# Create a storage account:
az storage account create --name <storage-account-name> --resource-group <resource-group-name> --location <location> --sku Standard_LRS

# List storage accounts:
az storage account list --output table

# Delete a storage account:
az storage account delete --name <storage-account-name> --resource-group <resource-group-name>

Blob Storage


# Create a container in a storage account:
az storage container create --name <container-name> --account-name <storage-account-name>

# Upload a file to a container:
az storage blob upload --container-name <container-name> --file <file-path> --name <blob-name> --account-name <storage-account-name>

# List blobs in a container:
az storage blob list --container-name <container-name> --account-name <storage-account-name> --output table

# Download a blob:
az storage blob download --container-name <container-name> --name <blob-name> --file <destination-path> --account-name <storage-account-name>

App Services


# Create an App Service plan:
az appservice plan create --name <plan-name> --resource-group <resource-group-name> --sku B1 --is-linux

# Create a web app:
az webapp create --resource-group <resource-group-name> --plan <plan-name> --name <webapp-name> --runtime "NODE|14-lts"

# List web apps:
az webapp list --output table

# Delete a web app:
az webapp delete --resource-group <resource-group-name> --name <webapp-name>

Azure Function Apps


# Create a function app:
az functionapp create --resource-group <resource-group-name> --consumption-plan-location <location> --name <functionapp-name> --storage-account <storage-account-name> --runtime <runtime>

# List function apps:
az functionapp list --output table

# Delete a function app:
az functionapp delete --resource-group <resource-group-name> --name <functionapp-name>

Service Bus


# Create a Service Bus namespace:
az servicebus namespace create --resource-group <resource-group-name> --name <namespace-name> --location <location>

# Create a Service Bus queue:
az servicebus queue create --resource-group <resource-group-name> --namespace-name <namespace-name> --name <queue-name>

# List Service Bus namespaces:
az servicebus namespace list --output table

# Delete a Service Bus namespace:
az servicebus namespace delete --resource-group <resource-group-name> --name <namespace-name>

Key Vault


# Create a Key Vault:
az keyvault create --name <keyvault-name> --resource-group <resource-group-name> --location <location>

# List Key Vaults:
az keyvault list --output table

# Delete a Key Vault:
az keyvault delete --name <keyvault-name> --resource-group <resource-group-name>

Azure Monitor


# List metrics for a resource:
az monitor metrics list --resource <resource-id>

# List activity logs:
az monitor activity-log list --output table

Logic Apps


# Create a Logic App:
az logic workflow create --resource-group <resource-group-name> --name <logic-app-name> --location <location>

# List Logic Apps:
az logic workflow list --resource-group <resource-group-name> --output table

# Delete a Logic App:
az logic workflow delete --resource-group <resource-group-name> --name <logic-app-name>

Event Grid


# Create an Event Grid topic:
az eventgrid topic create --name <topic-name> --resource-group <resource-group-name> --location <location>

# List Event Grid topics:
az eventgrid topic list --resource-group <resource-group-name> --output table

# Delete an Event Grid topic:
az eventgrid topic delete --name <topic-name> --resource-group <resource-group-name>

Event Hubs


# Create an Event Hubs namespace:
az eventhubs namespace create --name <namespace-name> --resource-group <resource-group-name> --location <location>

# Create an Event Hub:
az eventhubs eventhub create --resource-group <resource-group-name> --namespace-name <namespace-name> --name <eventhub-name>

# List Event Hubs in a namespace:
az eventhubs eventhub list --resource-group <resource-group-name> --namespace-name <namespace-name> --output table

# Delete an Event Hub:
az eventhubs eventhub delete --resource-group <resource-group-name> --namespace-name <namespace-name> --name <eventhub-name>

Azure, Azure Integration Services, Design Patterns, Technology and tricks

Restful API design principles – Nutshell

September 8, 2024September 14, 2024 Manjunath

HTTP Verb	Query	Description
GET	/users	Retrieves a list of users
GET	/users/8	Retrieves a specific user
POST	/users	Creates a new user
PUT	/users/8	Updates user #8
PATCH	/users/8	Partially updates
PATCH	/users/8/status	Updates status against user #8
DELETE	/users/8	Deletes user #8

RESTful APIs are vital for modern web applications, providing a flexible and scalable way for systems to communicate. Here’s a quick guide to key principles, best practices, HTTP methods, status codes, and common errors.

Key RESTful Principles

1. Uniform Interface: Resources identified by URLs (e.g., “/users/123”) using HTTP methods (“GET”, “POST”, etc.).
2. Stateless: Each request includes all information required; no session state stored server-side.
3. Client-Server Separation: Clients handle UI, while servers manage data and logic independently.
4. Cacheable: Define caching rules (e.g., “Cache-Control”) to improve performance.
5. Layered System: Clients interact with layers (e.g., proxies) without knowing internal server details.

Best Practices

1. Use Nouns in URLs: “/users”, not “/getUsers”.
2. Version Your API: “/v1/users”, to maintain backward compatibility.
3. Use Proper Status Codes: Ensure clear communication of the outcome.
4. Paginate Large Responses: For example, “GET /users?page=1&limit=50”.
5. Secure Your API: Use authentication (OAuth, API keys) and HTTPS.

HTTP Methods and REST Mapping

– GET: Retrieve data (read).
– Example: “GET /users/123” – Get user with ID 123.
– POST: Create a new resource.
– Example: “POST /users” – Create a new user.
– PUT: Update or replace an existing resource.
– Example: “PUT /users/123” – Update user with ID 123.
– PATCH: Partially update a resource.
– Example: “PATCH /users/123” – Update a user’s email.
– DELETE: Remove a resource.
– Example: “DELETE /users/123” – Delete user with ID 123.

HTTP Status Codes

– Success:
– “200 OK”: Request succeeded (GET, PUT).
– “201 Created”: New resource created (POST).
– “204 No Content”: Request successful, no content to return (DELETE).

– Client-Side Errors:
– “400 Bad Request”: Malformed request.
– “401 Unauthorized”: Authentication required.
– “403 Forbidden”: Access denied.
– “404 Not Found”: Resource not found.

– Server-Side Errors:
– “500 Internal Server Error”: Generic server failure.
– “502 Bad Gateway”: Invalid response from an upstream server.
– “503 Service Unavailable”: Server temporarily unable to handle the request.

By following these principles and best practices, you can design scalable, secure, and maintainable RESTful APIs that provide a seamless experience for users and developers alike.

Azure, Azure Integration Services

API Management Common Policies – Nutshell

September 10, 2019September 16, 2024 Manjunath

Common Policies

1. Authentication

check-header – Validates the presence and value of a header.

<check-header name="Authorization" exists="true" />

check-query-parameter – Validates the presence and value of a query parameter.

<check-query-parameter name="apikey" exists="true" />

2. Rate Limiting

rate-limit-by-key – Limits the number of calls based on a key.

<rate-limit-by-key calls="100" renewal-period="60" />

rate-limit – General rate limiting for API calls.

<rate-limit calls="1000" renewal-period="3600" />

3. Caching

cache-lookup – Retrieves data from the cache.

<cache-lookup vary-by-developer="false" vary-by-developer="false" />

cache-store – Stores data in the cache.

<cache-store duration="300" />

4. Transformation

set-header – Sets or modifies HTTP headers.

<set-header name="X-Custom-Header" exists-action="override">MyValue</set-header>

rewrite-uri – Changes the request URI.

<rewrite-uri template="/new-path/{path}" />

json-to-xml – Converts JSON data to XML.

<json-to-xml />

5. Response Manipulation

set-status – Sets the HTTP status code.

<set-status code="200" reason="OK" />

set-body – Sets or modifies the response body.

<set-body>{"message":"Success"}</set-body>

6. Logging

log-to-eventhub – Sends logs to Azure Event Hub.

<log-to-eventhub />

log-to-application-insights – Sends logs to Application Insights.

<log-to-application-insights />

7. Security

validate-jwt – Validates JWT tokens.

<validate-jwt header-name="Authorization" require-scheme="Bearer" />

cors – Configures Cross-Origin Resource Sharing (CORS).

<cors allow-headers="*" allow-methods="*" allow-origins="*" />

Examples for Request Parameters

1. Query Parameters

Extract query parameters from the request.

<set-variable name="queryParam" value="@(context.Request.OriginalUrl.Query["paramName"])" />

2. Path Parameters

Extract path parameters from the request URL.

<set-variable name="pathParam" value="@(context.Request.MatchedParameters["pathParamName"])" />

3. Headers

Access HTTP headers from the request.

<set-variable name="headerValue" value="@(context.Request.Headers.GetValueOrDefault("HeaderName", "defaultValue"))" />

4. Matched Parameters

Use parameters matched by routing templates.

<set-variable name="matchedParam" value="@(context.Request.MatchedParameters["matchedParamName"])" />

Usage Tips

Use these policies and examples to manage API access, control traffic, transform requests/responses, and handle various API management tasks effectively.

Azure, Azure Integration Services