Azure

When an IP address no longer requires access, delete its firewall rule to maintain a secure environment.

Delete a server-level rule:

EXECUTE sp_delete_firewall_rule @name = 'AllowOfficeIP';

Delete a database-level rule:

EXECUTE sp_delete_database_firewall_rule @name = 'AllowDevMachine';

If you encounter issues deleting rules (for instance, due to missing permissions), ensure you’re connected with sufficient administrative rights or use the Azure Portal for manual removal.

Source: Microsoft Docs – sp_delete_database_firewall_rule

To check which IP addresses have access to your Azure SQL Database, use the following T-SQL queries:

To list server-level firewall rules:

SELECT * FROM sys.firewall_rules;

To list database-level firewall rules:

SELECT * FROM sys.database_firewall_rules;

This helps verify which IP ranges currently have access and ensures that no outdated or overly broad rules are active. Regular audits of firewall rules are essential for maintaining data security.

Source: Todd Kitta GitHub – Configure Firewall Settings T-SQL

You can create firewall rules in Azure SQL using T-SQL commands or directly in the Azure Portal.

Using T-SQL (Server-level example):

EXECUTE sp_set_firewall_rule 
    @name = 'AllowOfficeIP', 
    @start_ip_address = '203.0.113.0', 
    @end_ip_address = '203.0.113.0';

For a database-level rule:

EXECUTE sp_set_database_firewall_rule 
    @name = 'AllowDevMachine', 
    @start_ip_address = '198.51.100.10', 
    @end_ip_address = '198.51.100.10';

Tip: Always double-check the IP range and limit access to only the addresses that genuinely need it to avoid overly broad access.

Source: SQLShack – Configure IP Firewall Rules for Azure SQL Databases

Azure SQL uses a layered firewall model:

• Server-level firewall rules: These define allowed IP address ranges for the entire logical SQL server. Any database under that server inherits these settings.
• Database-level firewall rules: These are stored within an individual database and apply only to connections to that database.

When to use each:

• Use server-level rules when multiple databases need the same IP access.
• Use database-level rules when access needs to be restricted to specific databases or when users lack server-level permissions.

Example:

• Allowing your organization’s office IP to access all databases? → Use server-level.
• Granting temporary access to a consultant for one database? → Use database-level.

Reference: Rishan Digital – Firewall Rules and Authentication

Firewall rules in Azure SQL Database control which IP addresses can connect to your database server. Configuring these rules correctly ensures that only trusted users and applications access your data while keeping it secure from unauthorized traffic.

Azure provides two levels of firewall configuration: server-level and database-level rules. Server-level rules allow access to all databases under a logical server, while database-level rules apply only to a specific database.

You can configure firewall rules using the Azure Portal, Transact-SQL (T-SQL) commands, or PowerShell. Understanding how and where to apply these rules helps ensure a secure and flexible environment for managing database access.

Learn more from Microsoft Docs

When you use EventId in .NET logs, both the Id (an integer) and Name are sent to Application Insights as part of customDimensions. However, the EventId.Id is stored as a string, which affects how you can filter it.

Limitation in UI Filters

The Application Insights UI filter panel only supports string operations like equals or contains. You can’t use greater than or less than filters directly in the UI.

Use KQL for Numeric Filtering

To filter numerically, use the Logs (Analytics) tab with Kusto Query Language (KQL):

traces
| extend EventIdInt = toint(customDimensions["EventId.Id"])
| where EventIdInt > 1000

This converts the string to an integer so you can filter properly.

Pro Tip

Use numeric ranges for EventId to categorize logs (e.g., 1000–1999 = Auth, 2000–2999 = Payments) and filter easily with KQL.

Tracking custom events with TrackEvent() in Azure Application Insights helps you monitor how users interact with your app. However, to obtain meaningful data, it's essential to name your events clearly and consistently.

Here are some best practices:

Use Clear, Descriptive Names

Write event names using a Verb-Noun format like UserLoggedIn, FileDownloaded, or OrderSubmitted. This makes them easy to understand.

Stick to PascalCase

Use PascalCase (each word starts with a capital letter), and avoid:

• Spaces (User Logged In)
• Dashes (User-Logged-In)
• Underscores (user_logged_in)

Use: UserLoggedIn

Don’t Include Dynamic Data

Keep user IDs, file names, or other changing values out of the event name.
Instead, put that info in custom properties or metrics.

telemetryClient.TrackEvent("ReportDownloaded", 
  new Dictionary<string, string> { { "FileType", "PDF" }, { "UserRole", "Admin" } });

Keep It Consistent

Follow the same naming style across your app. This makes it easier to search and analyze data later.

Be Specific When Needed

If similar actions happen in different contexts, make your event name more specific:
ContactFormSubmitted vs. FeedbackFormSubmitted

Tip

Use a naming template like:
<Action><Entity>[<Qualifier>]
Example: AddedItemToCart

A clean, consistent naming strategy makes your telemetry easier to work with, both now and in the future.

Application Insights doesn’t store the original .NET LogLevel (like Debug or Trace) — it only stores SeverityLevel, which combines them. To make your logs easier to filter and analyze, you can add LogLevel as a custom property using a TelemetryInitializer.

Example:

public class LogLevelInitializer : ITelemetryInitializer
{
    public void Initialize(ITelemetry telemetry)
    {
        if (telemetry is TraceTelemetry trace &&
            telemetry is ISupportProperties props &&
            !props.Properties.ContainsKey("LogLevel"))
        {
            props.Properties["LogLevel"] = trace.SeverityLevel switch
            {
                SeverityLevel.Verbose => "TraceOrDebug",
                SeverityLevel.Information => "Information",
                SeverityLevel.Warning => "Warning",
                SeverityLevel.Error => "Error",
                SeverityLevel.Critical => "Critical",
                _ => "Unknown"
            };
        }
    }
}

Integration

Register the initializer in your app:

services.AddSingleton<ITelemetryInitializer, LogLevelInitializer>();

Now, every trace will include a LogLevel key in customDimensions.

Application Insights uses a fixed enum called SeverityLevel with 5 levels: Verbose, Information, Warning, Error, and Critical.

When logging in .NET using ILogger, the log level (such as Debug, Information, or Error) is internally mapped to Application Insights’ SeverityLevel. However, the mapping isn’t one-to-one — and by default, you can lose detail.

SeverityLevel Mapping Overview

Application Insights uses this enum:

Both Trace and Debug are treated as Verbose, which means they can’t be distinguished once sent to Application Insights.

Tip: Add LogLevel as a Custom Property

To retain the original LogLevel, consider using a TelemetryInitializer to add it manually — so you can later filter logs by both SeverityLevel and original LogLevel.

Are you just starting your cloud journey or looking for ways to upgrade your knowledge in specific areas? Azure Charts is a web-based application that allows you to see what Azure consists of and how it evolves. 

References

• Azure Charts
• Azure Charts Visualize your cloud learning journey - Microsoft Community Hub