如何将Azure Log Analytics Workspace检测到的新Bug事件推送至Azure DevOps创建Bug工单？

Hey there! I’ve set up this exact workflow a handful of times, so let me walk you through the two most practical methods—one low-code (perfect for quick setups) and one for custom scenarios where you need more control.

Method 1: Azure Logic Apps (Low-Code, No Coding Required) #

This is the fastest way to get up and running if you don’t need heavy custom logic. Here’s how to build it:

• Step 1: Create a Logic App with the right trigger
  Start by making a Consumption Logic App. Search for the Azure Monitor Logs - When a log query returns results trigger, connect it to your Log Analytics Workspace, then write a Kusto query that targets new bugs. For example:

  // Replace with your actual log table and bug-specific filters
  BugDetectionEvents
  | where TimeGenerated > ago(5m) // Check for bugs in the last 5 minutes
  | where BugStatus == "New"
  | project BugUniqueID, ErrorMessage, StackTrace, AffectedService, TimeGenerated
  

  Set the trigger recurrence (like every 5 minutes) to regularly check for new bugs.

• Step 2: Add an Azure DevOps action to create a Bug
  Next, add the Azure DevOps - Create a work item action. Authenticate with your Azure DevOps organization, pick your target project, and set the work item type to Bug.

  Map your Log Analytics data to DevOps Bug fields for context:

  • Title: Combine a label with the error message (e.g., concat("Auto-Detected Bug: ", ErrorMessage))
  • Description: Stack the StackTrace, AffectedService, and TimeGenerated to give devs full context
  • Priority: Map to your severity levels (e.g., if Severity is "Critical", set to Priority 1)
  • Tags: Add a tag like LogAnalytics-Automated to easily spot auto-created bugs

• Step 3: Add deduplication logic (don’t skip this!)
  To avoid duplicate Bug tickets, track processed BugUniqueID values in Azure Table Storage. Before creating the work item, check if the ID exists in the table—only proceed if it’s a new entry.

• Step 4: Test and tweak
  Generate a test bug in your system that triggers the Log Analytics query, then verify the Bug work item appears in DevOps with all the right details. Adjust the query or field mappings if needed.

Method 2: Azure Functions (For Custom Logic) #

If you need complex data transformation, custom error handling, or integration with other systems, go with Azure Functions. Here’s the high-level process:

• Step 1: Set up a Function App
  Create a Function App (use C# or Python based on your team’s stack) with a timer trigger (e.g., every 5 minutes) to run your Log Analytics query on schedule.

• Step 2: Query Log Analytics for new bugs
  Use the Azure Monitor Logs SDK to run your Kusto query. For C#, use Microsoft.Azure.Management.LogAnalytics; for Python, use azure-monitor-query. Filter for bugs that haven’t been processed yet (track IDs in Azure Table Storage or Cosmos DB).

• Step 3: Call Azure DevOps REST API to create a Bug
  Use the Azure DevOps REST API (or the azure-devops Python SDK) to create the Bug work item. You’ll need a Personal Access Token (PAT) with Work Items (Read & Write) permissions. Map your log data to DevOps fields just like in the Logic Apps method.

• Step 4: Handle errors and logging
  Add try/catch blocks to handle API failures, log success/failure details in Application Insights, and implement retry logic for transient errors (like DevOps API timeouts).

Pro Tips to Avoid Headaches #

• Validate your Kusto query first: Run it directly in Log Analytics to make sure it only returns the new bugs you want to capture.
• Use least-privilege permissions: For Logic Apps/Functions, grant only the access needed (e.g., Log Analytics Reader for the workspace, DevOps PAT with minimal scope).
• Add failure alerts: Include a step to send an email/Slack notification if a bug fails to create—so you can troubleshoot before issues pile up.

内容的提问来源于stack exchange，提问作者Julien