Najlepsze rozwiązania dotyczące monitorowania usługi Azure Blob Storage
Ten artykuł zawiera kolekcję typowych scenariuszy monitorowania magazynu i zawiera wskazówki dotyczące najlepszych rozwiązań, które można z nimi osiągnąć.
Identyfikowanie kont magazynu bez użycia lub z niskim użyciem
Usługa Storage Szczegółowe informacje to pulpit nawigacyjny na podstawie metryk i dzienników usługi Azure Storage. Możesz użyć usługi Storage Szczegółowe informacje, aby zbadać wolumin transakcji i używać pojemności wszystkich kont. Te informacje mogą pomóc w podjęciu decyzji o tym, które konta mogą chcieć wycofać. Aby skonfigurować Szczegółowe informacje usługi Storage, zobacz Monitorowanie usługi Storage za pomocą szczegółowych informacji usługi Azure Monitor Storage.
Analizowanie woluminu transakcji
W widoku Szczegółowe informacje usługi Storage w usłudze Azure Monitor posortuj konta w kolejności rosnącej przy użyciu kolumny Transakcje. Na poniższej ilustracji przedstawiono konto z niskim wolumenem transakcji w określonym przedziale czasu.
Kliknij link konta, aby dowiedzieć się więcej o tych transakcjach. W tym przykładzie większość żądań jest wysyłana do usługi Blob Storage.
Aby określić, jakie żądania są wykonywane, przejdź do szczegółów wykresu Transakcje według nazwy interfejsu API.
W tym przykładzie wszystkie żądania zawierają listę operacji lub żądań dotyczących informacji o właściwości konta. Brak transakcji odczytu i zapisu. Może to prowadzić do przekonania, że konto nie jest używane w znaczący sposób.
Analizowanie używanej pojemności
Na karcie Pojemność widoku Szczegółowe informacje usługi Storage w usłudze Azure Monitor posortuj konta w kolejności rosnącej przy użyciu kolumny Konto używanej pojemności. Na poniższej ilustracji przedstawiono konto z niższym woluminem pojemności niż inne konta.
Aby zbadać obiekty blob skojarzone z tą używaną pojemnością, możesz użyć Eksplorator usługi Storage. W przypadku dużej liczby obiektów blob rozważ wygenerowanie raportu przy użyciu zasad spisu obiektów blob.
Monitorowanie użycia kontenera
Jeśli partycjonujesz dane klienta według kontenera, możesz monitorować ilość pojemności używanej przez każdego klienta. Spis obiektów blob usługi Azure Storage umożliwia utworzenie spisu obiektów blob z informacjami o rozmiarze. Następnie można agregować rozmiar i liczbę na poziomie kontenera. Aby zapoznać się z przykładem, zobacz Calculate blob count and total size per container using Azure Storage inventory (Obliczanie liczby obiektów blob i łączny rozmiar na kontener przy użyciu spisu usługi Azure Storage).
Możesz również ocenić ruch na poziomie kontenera, wykonując zapytania dotyczące dzienników. Aby dowiedzieć się więcej na temat pisania zapytań analitycznych dzienników, zobacz Log Analytics. Aby dowiedzieć się więcej na temat schematu dzienników magazynu, zobacz Dokumentacja danych monitorowania usługi Azure Blob Storage.
Oto zapytanie, aby uzyskać liczbę transakcji odczytu i liczbę bajtów odczytanych w każdym kontenerze.
StorageBlobLogs
| where OperationName == "GetBlob"
| extend ContainerName = split(parse_url(Uri).Path, "/")[1]
| summarize ReadSize = sum(ResponseBodySize), ReadCount = count() by tostring(ContainerName)
Poniższe zapytanie używa podobnego zapytania, aby uzyskać informacje o operacjach zapisu.
StorageBlobLogs
| where OperationName == "PutBlob" or
OperationName == "PutBlock" or
OperationName == "PutBlockList" or
OperationName == "AppendBlock" or
OperationName == "SnapshotBlob" or
OperationName == "CopyBlob" or
OperationName == "SetBlobTier"
| extend ContainerName = split(parse_url(Uri).Path, "/")[1]
| summarize WriteSize = sum(RequestBodySize), WriteCount = count() by tostring(ContainerName)
Powyższe zapytanie odwołuje się do nazw wielu operacji, ponieważ więcej niż jeden typ operacji może być liczone jako operacja zapisu. Aby dowiedzieć się więcej o tym, które operacje są uznawane za operacje odczytu i zapisu, zobacz cennik usługi Azure Blob Storage lub cennik usługi Azure Data Lake Storage.
Inspekcja aktywności konta
W wielu przypadkach należy przeprowadzić inspekcję działań kont magazynu pod kątem zabezpieczeń i zgodności. Operacje na kontach magazynu należą do dwóch kategorii: Płaszczyzna sterowania i Płaszczyzna danych.
Operacja płaszczyzny sterowania to dowolne żądanie usługi Azure Resource Manager dotyczące utworzenia konta magazynu lub zaktualizowania właściwości istniejącego konta magazynu. Aby uzyskać więcej informacji, zobacz Azure Resource Manager.
Operacja płaszczyzny danych to operacja na danych na koncie magazynu, która wynika z żądania do punktu końcowego usługi magazynu. Na przykład operacja płaszczyzny danych jest wykonywana podczas przekazywania obiektu blob na konto magazynu lub pobierania obiektu blob z konta magazynu. Aby uzyskać więcej informacji, zobacz Interfejs API usługi Azure Storage.
W sekcji pokazano, jak zidentyfikować "kiedy", "who", "what" i "how" informacji o operacjach kontroli i płaszczyzny danych.
Inspekcja operacji płaszczyzny sterowania
Operacje usługi Resource Manager są przechwytywane w dzienniku aktywności platformy Azure. Aby wyświetlić dziennik aktywności, otwórz konto magazynu w witrynie Azure Portal, a następnie wybierz pozycję Dziennik aktywności.
Otwórz dowolny wpis dziennika, aby wyświetlić kod JSON opisujący działanie. Poniższy kod JSON przedstawia informacje "when", "what" i "how" operacji płaszczyzny sterowania:
Dostępność informacji "kto" zależy od metody uwierzytelniania, która została użyta do wykonania operacji płaszczyzny sterowania. Jeśli autoryzacja została wykonana przez podmiot zabezpieczeń firmy Microsoft Entra, identyfikator obiektu tego podmiotu zabezpieczeń będzie również wyświetlany w tych danych wyjściowych JSON (na przykład: "http://schemas.microsoft.com/identity/claims/objectidentifier": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"). Ponieważ nie zawsze widzisz inne informacje dotyczące tożsamości, takie jak adres e-mail lub nazwa, identyfikator obiektu jest zawsze najlepszym sposobem unikatowego identyfikowania podmiotu zabezpieczeń.
Przyjazną nazwę tego podmiotu zabezpieczeń można znaleźć, przyjmując wartość identyfikatora obiektu i wyszukując podmiot zabezpieczeń na stronie Identyfikator entra firmy Microsoft w witrynie Azure Portal. Poniższy zrzut ekranu przedstawia wynik wyszukiwania w identyfikatorze Entra firmy Microsoft.
Inspekcja operacji płaszczyzny danych
Operacje płaszczyzny danych są przechwytywane w dziennikach zasobów platformy Azure dla usługi Storage. Możesz skonfigurować ustawienie diagnostyczne, aby wyeksportować dzienniki do obszaru roboczego usługi Log Analytics na potrzeby natywnego środowiska zapytań.
Oto zapytanie usługi Log Analytics, które pobiera informacje "when", "who", "what" i "how" na liście wpisów dziennika.
StorageBlobLogs
| where TimeGenerated > ago(3d)
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
W przypadku części "when" inspekcji pole pokazuje, TimeGenerated kiedy zarejestrowano wpis dziennika.
W przypadku części "co" inspekcji pole pokazuje, Uri że element został zmodyfikowany lub odczytany.
W przypadku części "how" inspekcji pole pokazuje, OperationName która operacja została wykonana.
Napiwek
Jeśli na przykład podejrzewasz, że obiekt blob lub kontener został usunięty przez pomyłkę, dodaj klauzulę zwracającą where tylko wpisy dziennika, w których OperationName ustawiono opcję Usuń obiekt blob lub Usuń kontener.
W przypadku części "kto" inspekcji pokazuje, AuthenticationType który typ uwierzytelniania został użyty do wykonania żądania. To pole może wyświetlać dowolne typy uwierzytelniania obsługiwane przez usługę Azure Storage, w tym użycie klucza konta, tokenu SAS lub uwierzytelniania entra firmy Microsoft.
Jeśli żądanie jest autoryzowane przy użyciu identyfikatora Entra firmy Microsoft, możesz użyć RequestObjectId pola , aby zidentyfikować "kto". Uwierzytelnianie za pomocą klucza współdzielonego i sygnatury dostępu współdzielonego nie zapewnia możliwości inspekcji poszczególnych tożsamości. W takich przypadkach callerIPAddress pola i userAgentHeader mogą ułatwić zidentyfikowanie źródła operacji. Jeśli token SAS został użyty do autoryzowania operacji, możesz zidentyfikować ten token, a jeśli tokeny zostały zamapowane na adresatów tokenów na końcu, możesz określić, który użytkownik, organizacja lub aplikacja wykonała operację. Zobacz Identyfikowanie tokenu SAS używanego do autoryzowania żądania.
Identyfikowanie podmiotu zabezpieczeń używanego do autoryzowania żądania
Jeśli żądanie zostało uwierzytelnione przy użyciu identyfikatora Firmy Microsoft Entra, RequesterObjectId pole zapewnia najbardziej niezawodny sposób identyfikowania podmiotu zabezpieczeń. Przyjazną nazwę tego podmiotu zabezpieczeń można znaleźć, przyjmując wartość RequesterObjectId pola i wyszukując podmiot zabezpieczeń na stronie Microsoft Entra ID w witrynie Azure Portal. Poniższy zrzut ekranu przedstawia wynik wyszukiwania w identyfikatorze Entra firmy Microsoft.
W niektórych przypadkach główna nazwa użytkownika lub nazwa UPN może być wyświetlana w dziennikach. Jeśli na przykład podmiot zabezpieczeń jest użytkownikiem firmy Microsoft Entra, prawdopodobnie zostanie wyświetlona nazwa UPN. W przypadku innych typów podmiotów zabezpieczeń, takich jak tożsamości zarządzane przypisane przez użytkownika, lub w niektórych scenariuszach, takich jak uwierzytelnianie między dzierżawami firmy Microsoft Entra, nazwa UPN nie będzie wyświetlana w dziennikach.
To zapytanie pokazuje wszystkie operacje odczytu wykonywane przez podmioty zabezpieczeń OAuth.
StorageBlobLogs
| where TimeGenerated > ago(3d)
and OperationName == "GetBlob"
and AuthenticationType == "OAuth"
| project TimeGenerated, AuthenticationType, RequesterObjectId, OperationName, Uri
Uwierzytelnianie za pomocą klucza współdzielonego i sygnatury dostępu współdzielonego nie zapewnia możliwości inspekcji poszczególnych tożsamości. W związku z tym, jeśli chcesz zwiększyć możliwość inspekcji na podstawie tożsamości, zalecamy przejście do identyfikatora Entra firmy Microsoft i uniemożliwienie uwierzytelniania współużytkowanego i sygnatury dostępu współdzielonego. Aby dowiedzieć się, jak zapobiec uwierzytelnianiu za pomocą klucza współdzielonego i sygnatury dostępu współdzielonego, zobacz Zapobieganie autoryzacji klucza współdzielonego dla konta usługi Azure Storage. Aby rozpocząć pracę z identyfikatorem Entra firmy Microsoft, zobacz Autoryzowanie dostępu do obiektów blob przy użyciu identyfikatora Entra firmy Microsoft.
Identyfikowanie tokenu SAS używanego do autoryzowania żądania
Zapytania dotyczące operacji, które zostały autoryzowane, można wykonywać zapytania przy użyciu tokenu SAS. Na przykład to zapytanie zwraca wszystkie operacje zapisu, które zostały autoryzowane przy użyciu tokenu SAS.
StorageBlobLogs
| where TimeGenerated > ago(3d)
and OperationName == "PutBlob"
and AuthenticationType == "SAS"
| project TimeGenerated, AuthenticationType, AuthenticationHash, OperationName, Uri
Ze względów bezpieczeństwa tokeny SAS nie są wyświetlane w dziennikach. Jednak skrót SHA-256 tokenu SAS pojawi się w AuthenticationHash polu zwróconym przez to zapytanie.
Jeśli rozproszono kilka tokenów SAS i chcesz wiedzieć, które tokeny SYGNATURy dostępu współdzielonego są używane, musisz przekonwertować każdy token SAS na skrót SHA-256, a następnie porównać ten skrót z wartością skrótu wyświetlaną w dziennikach.
Najpierw zdekoduj każdy ciąg tokenu SAS. Poniższy przykład dekoduje ciąg tokenu SAS przy użyciu programu PowerShell.
[uri]::UnescapeDataString("<SAS token goes here>")
Następnie możesz przekazać ten ciąg do polecenia cmdlet Get-FileHash programu PowerShell. Aby zapoznać się z przykładem, zobacz Przykład 4: Obliczanie skrótu ciągu.
Alternatywnie możesz przekazać dekodowany ciąg do funkcji hash_sha256() w ramach zapytania podczas korzystania z usługi Azure Data Explorer.
Tokeny SAS nie zawierają informacji o tożsamości. Jednym ze sposobów śledzenia działań użytkowników lub organizacji jest zachowanie mapowania użytkowników lub organizacji na różne skróty tokenów SAS.
Optymalizowanie kosztów dla rzadko wykonywanych zapytań
Dzienniki można wyeksportować do usługi Log Analytics, aby uzyskać zaawansowane natywne możliwości zapytań. Jeśli masz ogromne transakcje na koncie magazynu, koszt korzystania z dzienników z usługą Log Analytics może być wysoki. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Log Analytics. Jeśli planujesz wykonywać zapytania dotyczące dzienników tylko od czasu do czasu (na przykład zapytania dotyczące inspekcji zgodności), możesz rozważyć zmniejszenie całkowitego kosztu przez wyeksportowanie dzienników na konto magazynu, a następnie użycie rozwiązania do zapytań bezserwerowych na podstawie danych dziennika, na przykład usługi Azure Synapse.
Za pomocą usługi Azure Synapse możesz utworzyć pulę SQL bezserwerową w celu wykonywania zapytań dotyczących danych dziennika w razie potrzeby. Może to znacznie obniżyć koszty.
Eksportowanie dzienników do konta magazynu. Aby uzyskać więcej informacji, zobacz Tworzenie ustawienia diagnostycznego.
Tworzenie i konfigurowanie obszaru roboczego usługi Synapse. Aby uzyskać więcej informacji, zobacz Szybki start: tworzenie obszaru roboczego usługi Synapse.
Dzienniki zapytań. Aby uzyskać więcej informacji, zobacz Query JSON files using serverless SQL pool in Azure Synapse Analytics (Wykonywanie zapytań o pliki JSON przy użyciu bezserwerowej puli SQL w usłudze Azure Synapse Analytics).
Oto przykład:
select JSON_VALUE(doc, '$.time') AS time, JSON_VALUE(doc, '$.properties.accountName') AS accountName, JSON_VALUE(doc, '$.identity.type') AS identityType, JSON_VALUE(doc, '$.identity.requester.objectId') AS requesterObjectId, JSON_VALUE(doc, '$.operationName') AS operationName, JSON_VALUE(doc, '$.callerIpAddress') AS callerIpAddress, JSON_VALUE(doc, '$.uri') AS uri doc from openrowset( bulk 'https://demo2uswest4log.blob.core.windows.net/insights-logs-storageread/resourceId=/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/mytestrp/providers/Microsoft.Storage/storageAccounts/demo2uswest/blobServices/default/y=2021/m=03/d=19/h=*/m=*/PT1H.json', format = 'csv', fieldterminator ='0x0b', fieldquote = '0x0b' ) with (doc nvarchar(max)) as rows order by JSON_VALUE(doc, '$.time') desc