Migrera från HTTP Data Collector-API:et till API:et för logginmatning för att skicka data till Azure Monitor-loggar
Azure Monitor Log Ingestion API ger mer bearbetningskraft och större flexibilitet när det gäller att mata in loggar och hantera tabeller än det äldre HTTP Data Collector-API:et. Den här artikeln beskriver skillnaderna mellan API:et för datainsamlare och API:et för logginmatning och innehåller vägledning och metodtips för migrering till det nya LOG Ingestion-API:et.
Kommentar
Som Microsoft MVP bidrog Morten Waltorp Knudsen till och gav materialfeedback för den här artikeln. Ett exempel på hur du kan automatisera konfigurationen och den pågående användningen av Log Ingestion-API:et finns i Mortens offentligt tillgängliga AzLogDcrIngestPS PowerShell-modul.
Fördelar med API:et för logginmatning
Api:et för logginmatning ger följande fördelar jämfört med API:et för datainsamlare:
- Stöder transformeringar som gör att du kan ändra data innan de matas in i måltabellen, inklusive filtrering och datamanipulering.
- Låter dig skicka data till flera mål.
- Gör att du kan hantera måltabellschemat, inklusive kolumnnamn, och om du vill lägga till nya kolumner i måltabellen när källdataschemat ändras.
Förutsättningar
Migreringsproceduren som beskrivs i den här artikeln förutsätter att du har:
- En Log Analytics-arbetsyta där du har minst deltagarbehörighet.
- Behörigheter för att skapa regler för datainsamling på Log Analytics-arbetsytan.
- Ett Microsoft Entra-program för att autentisera API-anrop eller något annat Resource Manager-autentiseringsschema.
Behörigheter som krävs
| Åtgärd | Behörigheter som krävs |
|---|---|
| Skapa en slutpunkt för datainsamling. | Microsoft.Insights/dataCollectionEndpoints/write behörigheter som tillhandahålls av den inbyggda rollen Övervakningsdeltagare, till exempel. |
| Skapa eller ändra en datainsamlingsregel. | Microsoft.Insights/DataCollectionRules/Write behörigheter som tillhandahålls av den inbyggda rollen Övervakningsdeltagare, till exempel. |
| Konvertera en tabell som använder API:et datainsamlare till datainsamlingsregler och API:et för logginmatning. | Microsoft.OperationalInsights/workspaces/tables/migrate/action behörigheter som tillhandahålls av log analytics-deltagarens inbyggda roll, till exempel. |
| Skapa nya tabeller eller ändra tabellscheman. | microsoft.operationalinsights/workspaces/tables/write behörigheter som tillhandahålls av log analytics-deltagarens inbyggda roll, till exempel. |
| Anropa API:et för logginmatning. | Se Tilldela behörigheter till en domänkontrollant. |
Skapa nya resurser som krävs för API:et för logginmatning
Api:et för logginmatning kräver att du skapar två nya typer av resurser, som HTTP Data Collector-API:et inte kräver:
- Slutpunkter för datainsamling, från vilka de data du samlar in matas in i pipelinen för bearbetning.
- Regler för datainsamling, som definierar datatransformeringar och måltabellen som data matas in till.
Migrera befintliga anpassade tabeller eller skapa nya tabeller
Om du har en befintlig anpassad tabell som du för närvarande skickar data till med hjälp av API:et för datainsamlare kan du:
Migrera tabellen för att fortsätta mata in data i samma tabell med hjälp av API:et för logginmatning.
Underhålla den befintliga tabellen och data och konfigurera en ny tabell där du matar in data med hjälp av API:et för logginmatning. Du kan sedan ta bort den gamla tabellen när du är redo.
Det här är det bästa alternativet, särskilt om du behöver göra ändringar i den befintliga tabellen. Ändringar av befintliga datatyper och flera schemaändringar i befintliga anpassade datainsamlare-API-tabeller kan leda till fel.
Dricks
Om du vill identifiera vilka tabeller som använder API:et för datainsamlaren kan du visa tabellegenskaper. Egenskapen Typ för tabeller som använder API:et datainsamlare är inställd på Anpassad tabell (klassisk). Observera att tabeller som matar in data med hjälp av den äldre Log Analytics-agenten (MMA) också har egenskapen Typ inställd på Anpassad tabell (klassisk). Var noga med att migrera från Log Analytics-agenten till Azure Monitor Agent innan du konverterar MMA-tabeller. Annars slutar du att mata in data i anpassade fält i dessa tabeller efter tabellkonverteringen.
Den här tabellen sammanfattar överväganden att tänka på för varje alternativ:
| Tabellmigrering | Sida vid sida-implementering | |
|---|---|---|
| Namngivning av tabeller och kolumner | Återanvänd befintligt tabellnamn. Alternativ för kolumnnamngivning: – Använd nya kolumnnamn och definiera en transformering för att dirigera inkommande data till den nyligen namngivna kolumnen. – Fortsätt använda gamla namn. |
Ange det nya tabellnamnet fritt. Du måste justera integreringar, instrumentpaneler och aviseringar innan du växlar till den nya tabellen. |
| Migreringsprocedur | Engångstabellmigrering. Det går inte att återställa en migrerad tabell. | Migreringen kan utföras gradvis, per tabell. |
| Efter migrering | Du kan fortsätta att mata in data med hjälp av HTTP Data Collector-API:et med befintliga kolumner, förutom anpassade kolumner. Mata in data i nya kolumner endast med hjälp av API:et för logginmatning. |
Data i den gamla tabellen är tillgängliga fram till slutet av kvarhållningsperioden. När du först konfigurerar en ny tabell eller gör schemaändringar kan det ta 10–15 minuter innan dataändringarna börjar visas i måltabellen. |
Om du vill konvertera en tabell som använder API:et datainsamlare till datainsamlingsregler och API:et för logginmatning utfärdar du det här API-anropet mot tabellen:
POST https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{tableName}/migrate?api-version=2021-12-01-preview
Det här anropet är idempotent, så det har ingen effekt om tabellen redan har konverterats.
API-anropet aktiverar alla DCR-baserade funktioner för anpassade loggar i tabellen. API:et för datainsamlare fortsätter att mata in data i befintliga kolumner, men skapar inga nya kolumner. Tidigare definierade anpassade fält fortsätter inte att fyllas i. Ett annat sätt att migrera en befintlig tabell till med hjälp av datainsamlingsregler, men inte nödvändigtvis log ingestion-API:et är att tillämpa en arbetsytetransformering på tabellen.
Viktigt!
- Kolumnnamn måste börja med en bokstav och kan bestå av upp till 45 alfanumeriska tecken och understreck (
_). _ResourceId,id,_ResourceId,_SubscriptionId,TenantId,Type, ,UniqueIdochTitleär reserverade kolumnnamn.- Anpassade kolumner som du lägger till i en Azure-tabell måste ha suffixet
_CF. - Om du uppdaterar tabellschemat på Log Analytics-arbetsytan måste du även uppdatera indataströmsdefinitionen i datainsamlingsregeln för att mata in data i nya eller ändrade kolumner.
Anropa API:et för logginmatning
Med API:et för logginmatning kan du skicka upp till 1 MB komprimerade eller okomprimerade data per anrop. Om du behöver skicka mer än 1 MB data kan du skicka flera anrop parallellt. Det här är en ändring från API:et för datainsamlare, som gör att du kan skicka upp till 32 MB data per anrop.
Information om hur du anropar API :et för logginmatning finns i REST API-anrop för logginmatning.
Ändra tabellscheman och datainsamlingsregler baserat på ändringar i källdataobjektet
Api:et datainsamlare justerar automatiskt måltabellschemat när schemat för källdataobjektet ändras, men api:et för logginmatning gör det inte. Detta säkerställer att du inte samlar in nya data i kolumner som du inte hade för avsikt att skapa.
När källdataschemat ändras kan du:
- Ändra måltabellscheman och datainsamlingsregler så att de överensstämmer med ändringar i källdataschemat.
- Definiera en transformering i datainsamlingsregeln för att skicka nya data till befintliga kolumner i måltabellen.
- Lämna måltabellen och datainsamlingsregeln oförändrade. I det här fallet matar du inte in nya data.
Kommentar
Du kan inte återanvända ett kolumnnamn med en datatyp som skiljer sig från den ursprungliga datatypen som definierats för kolumnen.