Typowe schematy specyficzne dla usługi dla dzienników zasobów platformy Azure
Uwaga
Dzienniki zasobów były wcześniej znane jako dzienniki diagnostyczne. Nazwa została zmieniona w październiku 2019 r., ponieważ typy dzienników zebranych przez usługę Azure Monitor zostały przeniesione tak, aby zawierały więcej niż tylko zasób platformy Azure.
W tym artykule przedstawiono listę kategorii dzienników zasobów, które można zbierać. Ta lista znajduje się teraz w kategorii dzienników zasobów.
Dzienniki zasobów usługi Azure Monitor to dzienniki emitowane przez usługi platformy Azure, które opisują działanie tych usług lub zasobów. Wszystkie dzienniki zasobów dostępne za pośrednictwem usługi Azure Monitor mają wspólny schemat najwyższego poziomu. Każda usługa ma elastyczność emitowania unikatowych właściwości dla własnych zdarzeń.
Kombinacja typu zasobu (dostępnego resourceId we właściwości) i kategorii jednoznacznie identyfikują schemat. W tym artykule opisano schematy najwyższego poziomu dla dzienników zasobów i linki do schematu dla każdej usługi.
Wspólny schemat najwyższego poziomu
Uwaga
Schemat opisany tutaj jest prawidłowy, gdy dzienniki zasobów są wysyłane do usługi Azure Storage lub do centrum zdarzeń. Gdy dzienniki są wysyłane do obszaru roboczego usługi Log Analytics, nazwy kolumn mogą być inne. Zobacz Kolumny standardowe w dziennikach usługi Azure Monitor, aby uzyskać kolumny wspólne dla wszystkich tabel w obszarze roboczym usługi Log Analytics i dokumentacji danych usługi Azure Monitor, aby zapoznać się z dokumentacją różnych tabel.
| Nazwisko | Wymagane lub opcjonalne | opis |
|---|---|---|
time |
Wymagania | Sygnatura czasowa (UTC) rejestrowanego zdarzenia. |
resourceId |
Wymagania | Identyfikator zasobu, który emitował zdarzenie. W przypadku usług dzierżawy jest to forma /tenants/tenant-id/providers/provider-name. |
tenantId |
Wymagane dla dzienników dzierżawy | Identyfikator dzierżawy dzierżawy usługi Active Directory, z którą jest powiązane to zdarzenie. Ta właściwość jest używana tylko w przypadku dzienników na poziomie dzierżawy. Nie jest on wyświetlany w dziennikach na poziomie zasobów. |
operationName |
Wymagania | Nazwa operacji rejestrowania tego zdarzenia, na przykład Microsoft.Storage/storageAccounts/blobServices/blobs/Read. Operacja OperationName jest zwykle modelowana w postaci operacji usługi Azure Resource Manager, Microsoft.<providerName>/<resourceType>/<subtype>/<Write|Read|Delete|Action>nawet jeśli nie jest to udokumentowana operacja usługi Resource Manager. |
operationVersion |
Opcjonalnie | Wersja interfejsu API skojarzona z operacją, jeśli operationName została wykonana za pośrednictwem interfejsu API (na przykład http://myservice.windowsazure.net/object?api-version=2016-06-01). Jeśli żaden interfejs API nie odpowiada tej operacji, wersja reprezentuje wersję tej operacji w przypadku, gdy właściwości skojarzone ze zmianą operacji w przyszłości. |
category lub type |
Wymagania | Kategoria dziennika rejestrowanego zdarzenia. Kategoria to stopień szczegółowości, w którym można włączać lub wyłączać dzienniki w określonym zasobie. Właściwości wyświetlane we właściwościach obiektu blob zdarzenia są takie same w określonej kategorii dziennika i typie zasobu. Typowe kategorie dzienników to Audit, , OperationalExecutioni Request. W przypadku zasobu type usługi Application Insights oznacza kategorię wyeksportowanego dziennika. |
resultType |
Opcjonalnie | Stan zarejestrowanego zdarzenia, jeśli ma to zastosowanie. Wartości obejmują Started, , In Progress, FailedSucceeded, Active, i Resolved. |
resultSignature |
Opcjonalnie | Podstatu zdarzenia. Jeśli ta operacja odpowiada wywołaniu interfejsu API REST, to pole jest kodem stanu HTTP odpowiedniego wywołania REST. |
resultDescription |
Opcjonalnie | Statyczny opis tekstu tej operacji; na przykład Get storage file. |
durationMs |
Opcjonalnie | Czas trwania operacji w milisekundach. |
callerIpAddress |
Opcjonalnie | Adres IP obiektu wywołującego, jeśli operacja odpowiada wywołaniu interfejsu API pochodzącemu z jednostki z publicznie dostępnym adresem IP. |
correlationId |
Opcjonalnie | Identyfikator GUID używany do grupowania zestawu powiązanych zdarzeń. Zazwyczaj jeśli dwa zdarzenia mają tę samą operationName wartość, ale dwa różne stany (na przykład Started i Succeeded), mają tę samą correlationID wartość. Może to również reprezentować inne relacje między zdarzeniami. |
identity |
Opcjonalnie | Obiekt blob JSON opisujący tożsamość użytkownika lub aplikacji, która wykonała operację. Zazwyczaj to pole zawiera autoryzację i oświadczenia lub token JWT z usługi Active Directory. |
level |
Opcjonalnie | Poziom ważności zdarzenia. Musi być jednym z Informationalelementów , Warning, Errorlub Critical. |
location |
Opcjonalnie | Region zasobu emitujący zdarzenie; na przykład East US lub France South. |
properties |
Opcjonalnie | Wszelkie właściwości rozszerzone związane z tą kategorią zdarzeń. Wszystkie właściwości niestandardowe lub unikatowe muszą być umieszczone w tej części B schematu. |
Schematy specyficzne dla usługi
Schemat dzienników zasobów różni się w zależności od kategorii zasobów i dziennika. Na poniższej liście przedstawiono usługi platformy Azure, które udostępniają dzienniki zasobów i łączą się z usługą i schematami specyficznymi dla kategorii (jeśli są dostępne). Lista zmienia się w miarę dodawania nowych usług. Jeśli nie widzisz potrzebnych informacji, możesz otworzyć problem z usługą GitHub w tym artykule, abyśmy mogli go zaktualizować.
Następne kroki
- Zobacz kategorie dzienników zasobów, które można zbierać
- Dowiedz się więcej o dziennikach zasobów
- Przesyłanie strumieniowe dzienników zasobów do usługi Event Hubs
- Zmienianie ustawień diagnostycznych dziennika zasobów przy użyciu interfejsu API REST usługi Azure Monitor
- Analizowanie dzienników z usługi Azure Storage przy użyciu usługi Log Analytics