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 efter bästa möjliga resultat. Det innebär att de flesta begäranden resulterar i en loggpost, men fullständigheten och tidslinjerna för de Storage Analytics-loggarna är inte garanterade.

Lagringsanalysloggning är inte aktiverat som standard för ditt lagringskonto. Du kan aktivera det i Azure Portal eller med hjälp av PowerShell eller Azure CLI. Stegvisa anvisningar finns i Aktivera och hantera Azure Storage Analytics-loggar (klassisk).

Du kan också aktivera Storage Analytics-loggar programmatiskt via REST API eller klientbiblioteket. Använd åtgärderna Get Blob Service Properties (Hämta egenskaper för Blob Service), Get Queue Service Properties(Hämta egenskaper för kötjänst) och Get Table Service Properties (Hämta tabelltjänstegenskaper) för att aktivera Storage Analytics för varje tjänst. Om du vill se ett exempel som Storage Analytics-loggar med hjälp av .NET kan du se Aktivera loggar

Loggposter skapas bara om det finns begäranden som görs mot tjänstslutpunkten. Om ett lagringskonto till exempel har aktivitet i sin blobslutpunkt, men inte i dess tabell- eller köslutpunkter, skapas endast loggar som hör till blobtjänsten.

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 Storage Analytics, till exempel skapande eller borttagning av loggar, loggas inte. En fullständig lista över loggade data finns dokumenterad i avsnitten Storage Analytics Logged Operations and Status Messages (Loggade åtgärder och statusmeddelanden i Analytics och Storage Analytics Log Format).

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 finns dokumenterad i avsnitten Storage Analytics Logged Operations and Status Messages (Loggade åtgärder och statusmeddelanden i Analytics och Storage Analytics Log Format).

Hur loggar lagras

Alla loggar lagras i blockblobar i en container med namnet , som skapas automatiskt $logs när Storage Analytics har aktiverats för ett lagringskonto. Containern $logs finns i blobnamnrymden för lagringskontot, till exempel: http://<accountname>.blob.core.windows.net/$logs . Den här containern kan inte tas bort när Storage Analytics har aktiverats, även om dess innehåll kan tas bort. Om du använder ditt verktyg för lagringssurfning för att navigera till containern direkt visas alla blobar som innehåller dina loggningsdata.

När begäranden loggas laddar Storage Analytics upp mellanliggande resultat som block. Med jämna mellanrum Storage Analytics dessa block och gör dem tillgängliga som en blob. Det kan ta upp till en timme innan loggdata visas i blobarna i $logs-containern eftersom lagringstjänsten rensar loggförfattarna med. 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ärdsnummer.

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 som loggen innehåller genom att undersöka fälten med blobmetadata. Detta är också användbart eftersom det ibland kan finnas 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 lagringssurfning kan du visa metadata för blobar. du kan också läsa den här informationen med hjälp av PowerShell eller programmässigt. Följande PowerShell-kodfragment är ett exempel på filtrering av listan över loggblobar efter namn för att ange en tid och 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 visar 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:

Följande är ett fullständigt exempel på loggnamn som kombinerar ovanstående exempel:

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 korreleras det resulterande loggnamnet med timmen då den begärda åtgärden slutfördes. Om en GetBlob-begäran till exempel slutfördes kl. 18:30 den 2011-07-31 skrivs loggen 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 som bloben innehåller. I följande tabell beskrivs varje metadataattribut:

I följande lista visas fullständiga exempelmetadata med hjälp av ovanstående exempel:

• LogType=write
• StartTime=2011-07-31T18:21:46Z
• EndTime=2011-07-31T18:22:09Z
• LogVersion=1.0

Nästa steg

• Aktivera och hantera Azure-lagringsanalysloggar (klassisk)
• Storage Analysloggformat
• Storage Analytics-loggade åtgärder och statusmeddelanden
• Storage Analysmått (klassisk)