Analysloggning i Azure Storage
Lagringsanalys loggar detaljerad information om lyckade och misslyckade begäranden till en lagringstjänst. Den här informationen kan användas för att övervaka enskilda begäranden och för att diagnostisera problem med en lagringstjänst. Begäranden loggas på bästa sätt. Det innebär att de flesta begäranden resulterar i en loggpost, men fullständighet och aktualitet för Lagringsanalys loggar garanteras inte.
Anteckning
Vi rekommenderar att du använder Azure Storage-loggar i Azure Monitor i stället för Lagringsanalys loggar. Mer information finns i någon av följande artiklar:
Lagringsanalysloggning är inte aktiverat som standard för ditt lagringskonto. Du kan aktivera den i Azure Portal eller med hjälp av PowerShell eller Azure CLI. Stegvis vägledning finns i Aktivera och hantera Azure Lagringsanalys-loggar (klassisk).
Du kan också aktivera Lagringsanalys loggar programmatiskt via REST-API:et eller klientbiblioteket. Använd åtgärderna Hämta blobtjänstegenskaper, Hämta kötjänstegenskaper och Hämta egenskaper för tabelltjänsten för att aktivera Lagringsanalys för varje tjänst. Ett exempel som aktiverar Lagringsanalys loggar med hjälp av .NET finns i Aktivera loggar
Loggposter skapas endast om det görs begäranden mot tjänstslutpunkten. Om ett lagringskonto till exempel har aktivitet i blobslutpunkten, men inte i dess tabell- eller köslutpunkter, skapas endast loggar som hör till Blob-tjänsten.
Anteckning
Lagringsanalysloggning är för närvarande endast tillgängligt för blob-, kö- och tabelltjänsterna. Lagringsanalys loggning är också tillgängligt för BlockBlobStorage-konton med premiumprestanda. Den är dock inte tillgänglig för allmänna v2-konton med premiumprestanda.
Begäranden som loggas i loggning
Logga autentiserade begäranden
Följande typer av autentiserade begäranden loggas:
Lyckade begäranden
Misslyckade begäranden, inklusive timeout, begränsning, nätverk, auktorisering och andra fel
Begäranden med en signatur för delad åtkomst (SAS), inklusive misslyckade och lyckade begäranden
Begäranden om analysdata
Begäranden som görs av Lagringsanalys själv, till exempel skapande eller borttagning av loggar, loggas inte. En fullständig lista över loggade data dokumenteras i avsnitten Lagringsanalys Loggade åtgärder och Statusmeddelanden och Lagringsanalys Loggformat.
Logga anonyma begäranden
Följande typer av anonyma begäranden loggas:
Lyckade begäranden
Serverfel
Timeout-fel för både klient och server
Misslyckade GET-begäranden med felkoden 304 (har inte ändrats)
Alla andra misslyckade anonyma begäranden loggas inte. En fullständig lista över loggade data dokumenteras i avsnitten Lagringsanalys Loggade åtgärder och Statusmeddelanden och Lagringsanalys Loggformat.
Anteckning
Lagringsanalys loggar alla interna anrop till dataplanet. Anrop från Azure Storage-resursprovidern loggas också. Om du vill identifiera dessa begäranden letar du efter frågesträngen <sk=system-1>
i begärande-URL:en.
Så här lagras loggar
Alla loggar lagras i blockblobar i en container med namnet $logs
, som skapas automatiskt när Lagringsanalys aktiveras för ett lagringskonto. Containern $logs
finns i blobnamnområdet för lagringskontot, till exempel: http://<accountname>.blob.core.windows.net/$logs
. Det går inte att ta bort den här containern när Lagringsanalys har aktiverats, även om innehållet kan tas bort. Om du använder lagringsbläddringsverktyget för att navigera direkt till containern visas alla blobar som innehåller dina loggningsdata.
Anteckning
Containern $logs
visas inte när en containerlistningsåtgärd utförs, till exempel åtgärden Listcontainrar. Den måste nås direkt. Du kan till exempel använda åtgärden Listblobar för att komma åt blobarna i containern $logs
.
När begäranden loggas laddar Lagringsanalys upp mellanliggande resultat som block. Med jämna mellanrum checkar Lagringsanalys in dessa block och gör dem tillgängliga som en blob. Det kan ta upp till en timme innan loggdata visas i blobarna i den $logs containern eftersom frekvensen då lagringstjänsten rensar loggskrivarna. Dubblettposter kan finnas för loggar som skapats under samma timme. Du kan avgöra om en post är en dubblett genom att kontrollera RequestId och åtgärdsnumret .
Om du har en stor mängd loggdata med flera filer för varje timme kan du använda blobmetadata för att avgöra vilka data loggen innehåller genom att undersöka blobmetadatafälten. Detta är också användbart eftersom det ibland kan uppstå en fördröjning när data skrivs till loggfilerna: blobmetadata ger en mer exakt indikation på blobinnehållet än blobnamnet.
Med de flesta verktyg för lagringsbläddring kan du visa metadata för blobar. Du kan också läsa den här informationen med PowerShell eller programmatiskt. Följande PowerShell-kodfragment är ett exempel på filtrering av listan över loggblobar efter namn för att ange en tid och efter metadata för att identifiera bara de loggar som innehåller skrivåtgärder .
Get-AzStorageBlob -Container '$logs' |
Where-Object {
$_.Name -match 'blob/2014/05/21/05' -and
$_.ICloudBlob.Metadata.LogType -match 'write'
} |
ForEach-Object {
"{0} {1} {2} {3}" -f $_.Name,
$_.ICloudBlob.Metadata.StartTime,
$_.ICloudBlob.Metadata.EndTime,
$_.ICloudBlob.Metadata.LogType
}
Information om hur du listar blobar programmatiskt finns i Räkna upp blobresurser och ange och hämta egenskaper och metadata för blobresurser.
Namngivningskonventioner för loggar
Varje logg skrivs i följande format:
<service-name>/YYYY/MM/DD/hhmm/<counter>.log
I följande tabell beskrivs varje attribut i loggnamnet:
Attribut | Beskrivning |
---|---|
<service-name> |
Namnet på lagringstjänsten. Till exempel: blob , table eller queue |
YYYY |
Det fyrsiffriga året för loggen. Exempelvis: 2011 |
MM |
Den tvåsiffriga månaden för loggen. Exempelvis: 07 |
DD |
Den tvåsiffriga dagen för loggen. Exempelvis: 31 |
hh |
Den tvåsiffriga timmen som anger starttimmesen för loggarna, i UTC-format på 24 timmar. Exempelvis: 18 |
mm |
Det tvåsiffriga talet som anger startminuten för loggarna.
Observera: Det här värdet stöds inte i den aktuella versionen av Lagringsanalys och dess värde kommer alltid att vara 00 . |
<counter> |
En nollbaserad räknare med sex siffror som anger antalet loggblobar som genererats för lagringstjänsten under en timmesperiod. Den här räknaren börjar på 000000 . Exempelvis: 000001 |
Följande är ett fullständigt exempelloggnamn som kombinerar exemplen ovan:
blob/2011/07/31/1800/000001.log
Följande är en exempel-URI som kan användas för att komma åt loggen ovan:
https://<accountname>.blob.core.windows.net/$logs/blob/2011/07/31/1800/000001.log
När en lagringsbegäran loggas korrelerar det resulterande loggnamnet med timmen då den begärda åtgärden slutfördes. Om till exempel en GetBlob-begäran slutfördes kl. 18:30 den 31/31 2011 skulle loggen skrivas med följande prefix: blob/2011/07/31/1800/
Loggmetadata
Alla loggblobar lagras med metadata som kan användas för att identifiera vilka loggningsdata bloben innehåller. I följande tabell beskrivs varje metadataattribut:
Attribut | Beskrivning |
---|---|
LogType |
Beskriver om loggen innehåller information om läs-, skriv- eller borttagningsåtgärder. Det här värdet kan innehålla en typ eller en kombination av alla tre, avgränsade med kommatecken. Exempel 1: write Exempel 2: read,write Exempel 3: read,write,delete |
StartTime |
Den tidigaste tiden för en post i loggen, i form av YYYY-MM-DDThh:mm:ssZ . Exempelvis: 2011-07-31T18:21:46Z |
EndTime |
Den senaste tiden för en post i loggen, i form av YYYY-MM-DDThh:mm:ssZ . Exempelvis: 2011-07-31T18:22:09Z |
LogVersion |
Loggformatets version. |
I följande lista visas fullständiga exempelmetadata med hjälp av exemplen ovan:
LogType=write
StartTime=2011-07-31T18:21:46Z
EndTime=2011-07-31T18:22:09Z
LogVersion=1.0
Loggposter
I följande avsnitt visas en exempelloggpost för varje Azure Storage-tjänst som stöds.
Exempelloggpost för Blob Storage
2.0;2022-01-03T20:34:54.4617505Z;PutBlob;SASSuccess;201;7;7;sas;;logsamples;blob;https://logsamples.blob.core.windows.net/container1/1.txt?se=2022-02-02T20:34:54Z&sig=XXXXX&sp=rwl&sr=c&sv=2020-04-08&timeout=901;"/logsamples/container1/1.txt";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;71.197.193.44:53371;2019-12-12;654;13;337;0;13;"xxxxxxxxxxxxxxxxxxxxx==";"xxxxxxxxxxxxxxxxxxxxx==";""0x8D9CEF88004E296"";Monday, 03-Jan-22 20:34:54 GMT;;"Microsoft Azure Storage Explorer, 1.20.1, win32, azcopy-node, 2.0.0, win32, AzCopy/10.11.0 Azure-Storage/0.13 (go1.15; Windows_NT)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;
Exempelloggpost för Blob Storage (Data Lake Storage Gen2 aktiverad)
2.0;2022-01-04T22:50:56.0000775Z;RenamePathFile;Success;201;49;49;authenticated;logsamples;logsamples;blob;"https://logsamples.dfs.core.windows.net/my-container/myfileorig.png?mode=legacy";"/logsamples/my-container/myfilerenamed.png";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;73.157.16.8;2020-04-08;591;0;224;0;0;;;;Friday, 11-Jun-21 17:58:15 GMT;;"Microsoft Azure Storage Explorer, 1.19.1, win32 azsdk-js-storagedatalake/12.3.1 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;
Exempelloggpost för Queue Storage
2.0;2022-01-03T20:35:04.6097590Z;PeekMessages;Success;200;5;5;authenticated;logsamples;logsamples;queue;https://logsamples.queue.core.windows.net/queue1/messages?numofmessages=32&peekonly=true&timeout=30;"/logsamples/queue1";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;71.197.193.44:53385;2020-04-08;536;0;232;62;0;;;;;;"Microsoft Azure Storage Explorer, 1.20.1, win32 azsdk-js-storagequeue/12.3.1 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx";;;;;;;;
Exempelloggpost för Table Storage
1.0;2022-01-03T20:35:13.0719766Z;CreateTable;Success;204;30;30;authenticated;logsamples;logsamples;table;https://logsamples.table.core.windows.net/Tables;"/logsamples/Table1";xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx;0;71.197.193.44:53389;2018-03-28;601;22;339;0;22;;;;;;"Microsoft Azure Storage Explorer, 1.20.1, win32, Azure-Storage/2.10.3 (NODE-VERSION v12.16.3; Windows_NT 10.0.22000)";;"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"