Sdílet prostřednictvím


Odesílání dat protokolu do služby Azure Monitor pomocí rozhraní API kolektoru dat HTTP (zastaralé)

V tomto článku se dozvíte, jak pomocí rozhraní API kolektoru dat HTTP odesílat data protokolů do služby Azure Monitor z klienta REST API. Popisuje, jak formátovat data shromážděná vaším skriptem nebo aplikací, zahrnout je do požadavku a nechat ji autorizovat službou Azure Monitor. Poskytujeme příklady pro Azure PowerShell, C# a Python.

Poznámka

Služba Azure Monitor, konkrétně Rozhraní API kolektoru dat HTTP, je zastaralá a od 14. 9. 2026 už nebude funkční. Rozhraní API pro příjem protokolů bylo nahrazeno.

Koncepty

Rozhraní API kolektoru dat HTTP můžete použít k odesílání dat protokolu z libovolného klienta, který dokáže volat rozhraní REST API, do pracovního prostoru služby Log Analytics ve službě Azure Monitor. Klientem může být runbook ve službě Azure Automation, který shromažďuje data správy z Azure nebo jiného cloudu, nebo se může jednat o alternativní systém pro správu, který ke konsolidaci a analýze dat protokolů používá Azure Monitor.

Všechna data v pracovním prostoru služby Log Analytics se ukládají jako záznam s konkrétním typem záznamu. Data naformátujete tak, aby se odesílala do rozhraní API kolektoru dat HTTP jako více záznamů ve formátu JSON (JavaScript Object Notation). Při odesílání dat se v úložišti vytvoří jednotlivý záznam pro každý záznam v datové části požadavku.

snímek obrazovky znázorňující přehled kolektoru dat HTTP

Vytvoření žádosti

Pokud chcete použít rozhraní API kolektoru dat HTTP, vytvoříte požadavek POST, který obsahuje data, která se mají odeslat ve formátu JSON. Následující tři tabulky uvádějí atributy, které jsou požadovány pro každý požadavek. Jednotlivé atributy podrobněji popíšeme dále v článku.

Požadavek URI

Atribut Vlastnost
Metoda POST
Identifikátor URI https://<CustomerId>.ods.opinsights.azure.com/api/logs?api-version=2016-04-01
Typ obsahu application/json

Parametry identifikátoru URI požadavku

Parametr Popis
ID zákazníka Jedinečný identifikátor pracovního prostoru služby Log Analytics.
Zdroj Název prostředku rozhraní API: /api/logs.
Verze rozhraní API Verze rozhraní API, která se má použít s tímto požadavkem. V současné době je verze 2016-04-01.

Hlavičky požadavku

Záhlaví Popis
Oprávnění Podpis autorizace. Později v článku si můžete přečíst, jak vytvořit hlavičku HMAC-SHA256.
Log-Type Zadejte typ záznamu odesílaných dat. Může obsahovat pouze písmena, číslice a podtržítko (_) a nesmí překročit 100 znaků.
x-ms-date Datum zpracování požadavku ve formátu RFC 1123.
x-ms-AzureResourceId ID prostředku Azure, ke kterému by měla být data přidružená. Naplní vlastnost _ResourceId a umožní začlenění dat do dotazů kontextu zdrojů. Pokud toto pole není specifikováno, nebudou data zahrnuta do dotazů v kontextu zdrojů.
pole vygenerované časem Název pole v datech, která obsahuje časové razítko položky dat. Pokud zadáte pole, jeho obsah se použije pro TimeGenerated. Pokud toto pole nezadáte, výchozí hodnota pro TimeGenerated je čas, kdy se zpráva ingestuje. Obsah pole zprávy by měl odpovídat formátu ISO 8601 RRRR-MM-DDThh:mm:ssZ. Hodnota Generovaná časem nemůže být starší než 2 dny před přijetím času nebo více než den v budoucnu. V takovém případě se použije čas, kdy se zpráva ingestuje.

Oprávnění

Každý požadavek na rozhraní API kolektoru dat HTTP služby Azure Monitor musí obsahovat autorizační hlavičku. Pokud chcete žádost ověřit, podepište požadavek buď primárním, nebo sekundárním klíčem pracovního prostoru, který požadavek vytváří. Pak tento podpis předejte jako součást požadavku.

Tady je formát autorizační hlavičky:

Authorization: SharedKey <WorkspaceID>:<Signature>

Id pracovního prostoru je jedinečný identifikátor pracovního prostoru služby Log Analytics. podpis je kód HMAC (Hash-based Message Authentication Code), který je vytvořený z požadavku, a pak vypočítá pomocí algoritmu SHA256. Pak ho zakódujete pomocí kódování Base64.

Tento formát použijte ke kódování řetězce podpisu SharedKey:

StringToSign = VERB + "\n" +
                  Content-Length + "\n" +
                  Content-Type + "\n" +
                  "x-ms-date:" + x-ms-date + "\n" +
                  "/api/logs";

Tady je příklad řetězce podpisu:

POST\n1024\napplication/json\nx-ms-date:Mon, 04 Apr 2016 08:00:00 GMT\n/api/logs

Pokud máte řetězec podpisu, zakódujte ho pomocí algoritmu HMAC-SHA256 v řetězci s kódováním UTF-8 a potom výsledek zakódujte jako Base64. Použijte tento formát:

Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))

Ukázky v dalších částech obsahují vzorový kód, který vám pomůže vytvořit autorizační hlavičku.

Tělo žádosti

Text zprávy musí být ve formátu JSON. Musí obsahovat jeden nebo více záznamů se dvojicemi názvů vlastností a hodnot v následujícím formátu. Název vlastnosti může obsahovat pouze písmena, číslice a znak podtržítka (_).

[
    {
        "property 1": "value1",
        "property 2": "value2",
        "property 3": "value3",
        "property 4": "value4"
    }
]

V jednom požadavku můžete sdružit více záznamů pomocí následujícího formátu. Všechny záznamy musí být stejného typu záznamu.

[
    {
        "property 1": "value1",
        "property 2": "value2",
        "property 3": "value3",
        "property 4": "value4"
    },
    {
        "property 1": "value1",
        "property 2": "value2",
        "property 3": "value3",
        "property 4": "value4"
    }
]

Typ a vlastnosti záznamu

Při odesílání dat prostřednictvím rozhraní API kolektoru dat HTTP služby Azure Monitor definujete vlastní typ záznamu. V současné době nemůžete zapisovat data do existujících typů záznamů, které byly vytvořeny jinými datovými typy a řešeními. Azure Monitor přečte příchozí data a pak vytvoří vlastnosti, které odpovídají datovým typům zadaných hodnot.

Každý požadavek na rozhraní API pro sběr dat musí obsahovat hlavičku typu protokolu s názvem typu záznamu. Přípona _CL se automaticky připojí k zadanému názvu, aby se odlišila od jiných typů protokolů jako vlastní protokol. Pokud například zadáte název MyNewRecordType, Azure Monitor vytvoří záznam s typem MyNewRecordType_CL. To pomáhá zajistit, aby nedošlo ke konfliktům mezi uživatelsky vytvořenými názvy typů a názvy dodaných v aktuálních nebo budoucích řešeních Společnosti Microsoft.

K identifikaci datového typu vlastnosti přidá Azure Monitor k názvu vlastnosti příponu. Pokud vlastnost obsahuje hodnotu null, vlastnost není zahrnuta v tomto záznamu. Tato tabulka uvádí datový typ vlastnosti a odpovídající příponu:

Datový typ vlastnosti Přípona
Řetězec _s
Booleovský _b
Dvojitý _d
Datum a čas _t
GUID (uložený jako řetězec) _g

Poznámka

Řetězcové hodnoty, které se jeví jako identifikátory GUID, mají příponu _g a formátují se jako identifikátor GUID, i když příchozí hodnota neobsahuje pomlčky. Příklad: "8145d822-13a7-44ad-859c-36f31a84f6dd" a "8145d82213a744ad859c36f31a84f6dd" jsou uloženy jako "8145d822-13a7-44ad-859c-36f31a84f6dd". Jedinými rozdíly mezi tímto a jiným řetězcem jsou _g v názvu a vložení pomlček, pokud nejsou zadané ve vstupu.

Datový typ, který Azure Monitor používá pro každou vlastnost, závisí na tom, jestli typ záznamu pro nový záznam již existuje.

  • Pokud typ záznamu neexistuje, Azure Monitor vytvoří nový pomocí odvození typu JSON k určení datového typu pro každou vlastnost nového záznamu.
  • Pokud typ záznamu existuje, Azure Monitor se pokusí vytvořit nový záznam na základě existujících vlastností. Pokud se datový typ vlastnosti v novém záznamu neshoduje a nedá se převést na existující typ nebo pokud záznam obsahuje vlastnost, která neexistuje, Azure Monitor vytvoří novou vlastnost s příslušnou příponou.

Například následující položka pro odeslání vytvoří záznam se třemi vlastnostmi, number_d, boolean_ba string_s:

snímek obrazovky s ukázkovým záznamem 1

Pokud byste chtěli odeslat tuto další položku se všemi hodnotami formátovanými jako řetězce, vlastnosti se nezměnily. Hodnoty můžete převést na existující datové typy.

snímek obrazovky s ukázkovým záznamem 2

Pokud ale provedete toto další odeslání, Azure Monitor vytvoří nové vlastnosti boolean_d a string_d. Tyto hodnoty nelze převést.

Snímek obrazovky ukázkového záznamu 3

Pokud pak před vytvořením typu záznamu odešlete následující položku, azure Monitor vytvoří záznam se třemi vlastnostmi, number_s, boolean_sa string_s. V této položce je každá z počátečních hodnot formátována jako řetězec:

snímek obrazovky s ukázkovým záznamem 4

Rezervované vlastnosti

Následující vlastnosti jsou rezervované a neměly by se používat ve vlastním typu záznamu. Pokud váš datový balíček obsahuje některý z těchto názvů vlastností, zobrazí se chyba.

  • nájemce
  • TimeGenerated
  • RawData

Omezení dat

Data odesílaná do rozhraní API pro shromažďování dat služby Azure Monitor podléhají určitým omezením:

  • Maximálně 30 MB na příspěvek do rozhraní API kolektoru dat služby Azure Monitor. Toto je limit velikosti pro jeden příspěvek. Pokud data z jednoho příspěvku překročí 30 MB, měli byste je rozdělit do bloků s menší velikostí a současně je odeslat.
  • Maximálně 32 kB pro hodnoty polí. Pokud je hodnota pole větší než 32 kB, data budou zkrácena.
  • Doporučeno maximálně 50 polí pro daný typ. Jedná se o praktický limit z hlediska použitelnosti a vyhledávání.
  • Tabulky v pracovních prostorech služby Log Analytics podporují pouze 500 sloupců (označovaných jako pole v tomto článku).
  • Maximálně 45 znaků pro názvy sloupců.

Návratové kódy

Stavový kód HTTP 200 znamená, že požadavek byl přijat ke zpracování. To znamená, že operace byla úspěšně dokončena.

Kompletní sada stavových kódů, které může služba vrátit, je uvedená v následující tabulce:

Kód Stav Kód chyby Popis
200 OK Požadavek byl úspěšně přijat.
400 Chybný požadavek Neaktivní zákazník Pracovní prostor byl zavřený.
400 Chybný požadavek Neplatná verze API Zadaná verze rozhraní API nebyla službou rozpoznána.
400 Chybný požadavek NeplatnéIDZákazníka Zadané ID pracovního prostoru je neplatné.
400 Chybný požadavek Neplatný formát dat Byl odeslán neplatný kód JSON. Tělo odpovědi může obsahovat další informace o tom, jak chybu vyřešit.
400 Chybný požadavek NeplatnýTypProtokolu Zadaný typ protokolu obsahoval speciální znaky nebo číslice.
400 Chybný požadavek Chybí verze rozhraní API Verze rozhraní API nebyla zadána.
400 Chybný požadavek ChybějícíTypObsahu Typ obsahu nebyl zadán.
400 Chybný požadavek MissingLogType Nebyl zadán požadovaný typ protokolu hodnot.
400 Chybný požadavek Nepodporovaný typ obsahu Typ obsahu nebyl nastaven na application/json .
403 Zakázaný NeplatnéOprávnění Službě se nepodařilo ověřit požadavek. Ověřte, že ID pracovního prostoru a klíč připojení jsou platné.
404 Nenalezena Zadaná adresa URL je nesprávná nebo je požadavek příliš velký.
429 Příliš mnoho požadavků U služby dochází k velkému objemu dat z vašeho účtu. Zkuste žádost zopakovat později.
500 Vnitřní chyba serveru Nezadaná chyba Služba zjistila vnitřní chybu. Zkuste žádost zopakovat.
503 Služba není k dispozici Služba nedostupná Služba momentálně není k dispozici pro příjem požadavků. Zkuste prosím žádost zopakovat.

Dotazování dat

Pokud chcete dotazovat data odesílaná rozhraním API kolektoru dat HTTP služby Azure Monitor, vyhledejte záznamy, jejichž Typ se rovná hodnotě LogType, kterou jste zadali a připojili pomocí _CL. Pokud jste například použili MyCustomLog, vrátíte všechny záznamy s MyCustomLog_CL.

Ukázkové požadavky

V této části jsou ukázky, které ukazují, jak odesílat data do rozhraní API kolektoru dat HTTP služby Azure Monitor pomocí různých programovacích jazyků.

Pro každou ukázku nastavte proměnné pro autorizační hlavičku následujícím způsobem:

  1. Na webu Azure Portal vyhledejte pracovní prostor služby Log Analytics.
  2. Vyberte Agenti.
  3. Napravo od Pracovní ID prostoruvyberte ikonu Kopírovat a poté ID vložte jako hodnotu proměnné ID zákazníka.
  4. Napravo od primárního klíče vyberte ikonu kopírování , a poté vložte ID jako hodnotu proměnné sdíleného klíče .

Případně můžete změnit proměnné pro typ protokolu a data JSON.

# Replace with your Workspace ID
$CustomerId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"  

# Replace with your Primary Key
$SharedKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

# Specify the name of the record type that you'll be creating
$LogType = "MyRecordType"

# Optional name of a field that includes the timestamp for the data. If the time field is not specified, Azure Monitor assumes the time is the message ingestion time
$TimeStampField = ""

# Create two records with the same set of properties to create
$json = @"
[{  "StringValue": "MyString1",
    "NumberValue": 42,
    "BooleanValue": true,
    "DateValue": "2019-09-12T20:00:00.625Z",
    "GUIDValue": "9909ED01-A74C-4874-8ABF-D2678E3AE23D"
},
{   "StringValue": "MyString2",
    "NumberValue": 43,
    "BooleanValue": false,
    "DateValue": "2019-09-12T20:00:00.625Z",
    "GUIDValue": "8809ED01-A74C-4874-8ABF-D2678E3AE23D"
}]
"@

# Create the function to create the authorization signature
Function Build-Signature ($customerId, $sharedKey, $date, $contentLength, $method, $contentType, $resource)
{
    $xHeaders = "x-ms-date:" + $date
    $stringToHash = $method + "`n" + $contentLength + "`n" + $contentType + "`n" + $xHeaders + "`n" + $resource

    $bytesToHash = [Text.Encoding]::UTF8.GetBytes($stringToHash)
    $keyBytes = [Convert]::FromBase64String($sharedKey)

    $sha256 = New-Object System.Security.Cryptography.HMACSHA256
    $sha256.Key = $keyBytes
    $calculatedHash = $sha256.ComputeHash($bytesToHash)
    $encodedHash = [Convert]::ToBase64String($calculatedHash)
    $authorization = 'SharedKey {0}:{1}' -f $customerId,$encodedHash
    return $authorization
}

# Create the function to create and post the request
Function Post-LogAnalyticsData($customerId, $sharedKey, $body, $logType)
{
    $method = "POST"
    $contentType = "application/json"
    $resource = "/api/logs"
    $rfc1123date = [DateTime]::UtcNow.ToString("r")
    $contentLength = $body.Length
    $signature = Build-Signature `
        -customerId $customerId `
        -sharedKey $sharedKey `
        -date $rfc1123date `
        -contentLength $contentLength `
        -method $method `
        -contentType $contentType `
        -resource $resource
    $uri = "https://" + $customerId + ".ods.opinsights.azure.com" + $resource + "?api-version=2016-04-01"

    $headers = @{
        "Authorization" = $signature;
        "Log-Type" = $logType;
        "x-ms-date" = $rfc1123date;
        "time-generated-field" = $TimeStampField;
    }

    $response = Invoke-WebRequest -Uri $uri -Method $method -ContentType $contentType -Headers $headers -Body $body -UseBasicParsing
    return $response.StatusCode

}

# Submit the data to the API endpoint
Post-LogAnalyticsData -customerId $customerId -sharedKey $sharedKey -body ([System.Text.Encoding]::UTF8.GetBytes($json)) -logType $logType  

Alternativy a důležité informace

I když by rozhraní API kolektoru dat mělo pokrýt většinu vašich potřeb při shromažďování bezplatných dat do protokolů Azure, můžete vyžadovat alternativní přístup k překonání některých omezení rozhraní API. Možnosti, včetně důležitých aspektů, jsou uvedené v následující tabulce:

Alternativa Popis Nejvhodnější pro
Vlastní události: Nativní příjem dat založený na SDK v Application Insights Application Insights, obvykle instrumentované prostřednictvím sady SDK v rámci vaší aplikace, umožňuje odesílat vlastní data prostřednictvím vlastních událostí.
  • Data vygenerovaná v rámci vaší aplikace, ale nevybíraná sadou SDK prostřednictvím jednoho z výchozích datových typů (požadavky, závislosti, výjimky atd.).
  • Data, která nejčastěji korelují s jinými aplikačními daty v Application Insights
Rozhraní API pro sběr dat ve službě Azure Monitor Logs Rozhraní API kolektoru dat v protokolech služby Azure Monitor je zcela otevřený způsob, jak ingestovat data. Sem se dají odeslat všechna data formátovaná v objektu JSON. Po odeslání se zpracuje a zpřístupní v protokolech monitorování, aby bylo možné korelovat s dalšími daty v protokolech monitorování nebo s jinými daty Application Insights.

Je poměrně snadné nahrát data jako soubory do objektu blob služby Azure Blob Storage, kde se soubory zpracují a pak nahrají do Log Analytics. Ukázkovou implementaci najdete v tématu Vytvoření datového kanálu pomocí rozhraní API kolektoru dat.
  • Data, která nejsou nutně generována v rámci aplikace instrumentované v Rámci Application Insights.
    Mezi příklady patří vyhledávací tabulky a tabulky faktů, referenční data, předem agregované statistiky atd.
  • Data, která budou křížově odkazována na jiná data služby Azure Monitor (Application Insights, další datové typy protokolů monitorování, Defender for Cloud, Přehledy kontejnerů a virtuální počítače atd.).
Azure Data Explorer Azure Data Explorer, nyní obecně dostupný pro veřejnost, je datová platforma, která využívá Application Insights Analytics a protokoly služby Azure Monitor. Díky použití datové platformy v nezpracované podobě máte úplnou flexibilitu (ale vyžaduje režii při správě) clusteru (řízení přístupu na základě role Kubernetes (RBAC), rychlost uchovávání, schéma atd.). Azure Data Explorer nabízí mnoho možností příjmu dat, včetně souborů CSV, TSV a JSON.
  • Data, která nebudou korelována s žádnými dalšími daty v rámci Application Insights nebo Monitor Logs.
  • Data, která vyžadují pokročilé možnosti příjmu dat nebo zpracování, které nejsou dnes k dispozici v protokolech služby Azure Monitor.

Další kroky