Przekształcenia danych w usłudze Container Insights
W tym artykule opisano sposób implementowania przekształceń danych w usłudze Container Insights. Przekształcenia w usłudze Azure Monitor umożliwiają modyfikowanie lub filtrowanie danych przed ich pozyskiwaniem w obszarze roboczym usługi Log Analytics. Umożliwiają one wykonywanie takich akcji, jak filtrowanie danych zebranych z klastra w celu zaoszczędzenia kosztów lub przetwarzania danych przychodzących w celu ułatwienia zapytań dotyczących danych.
Ważne
Artykuły Konfigurowanie zbierania dzienników w usłudze Container Insights i Filtrowanie zbierania dzienników w usłudze Container Insights opisują standardowe ustawienia konfiguracji służące do konfigurowania i filtrowania zbierania danych na potrzeby szczegółowych informacji o kontenerze. Przed użyciem przekształceń należy wykonać dowolną wymaganą konfigurację przy użyciu tych funkcji. Użyj przekształcenia, aby wykonać filtrowanie lub inną konfigurację danych, której nie można wykonać przy użyciu standardowych ustawień konfiguracji.
Reguła zbierania danych
Przekształcenia są implementowane w regułach zbierania danych (DCR), które są używane do konfigurowania zbierania danych w usłudze Azure Monitor. Konfigurowanie zbierania danych przy użyciu kontrolera DCR opisuje kontroler domeny, który jest automatycznie tworzony podczas włączania szczegółowych informacji o kontenerze w klastrze. Aby utworzyć przekształcenie, należy wykonać jedną z następujących akcji:
- Nowy klaster. Użyj istniejącego szablonu usługi ARM, aby dołączyć klaster usługi AKS do usługi Container Insights. Zmodyfikuj kontroler domeny w tym szablonie przy użyciu wymaganej konfiguracji, w tym przekształcenia podobnego do jednego z poniższych przykładów.
- Istniejący kontroler domeny. Po dołączeniu klastra do skonfigurowanych szczegółowych informacji o kontenerze i zbieraniu danych zmodyfikuj jego kontroler domeny, aby uwzględnić przekształcenie przy użyciu dowolnej z metod w temacie Edytowanie reguł zbierania danych.
Uwaga
Obecnie istnieje minimalny interfejs użytkownika do edycji kontrolerów domeny, który jest wymagany do dodawania przekształceń. W większości przypadków należy ręcznie edytować kontroler domeny. W tym artykule opisano strukturę dcR do zaimplementowania. Aby uzyskać wskazówki dotyczące implementowania tej struktury, zobacz Tworzenie i edytowanie reguł zbierania danych (DCR) w usłudze Azure Monitor .
Źródła danych
Sekcja Źródła danych w kontrolerze domeny definiuje różne typy danych przychodzących, które będą przetwarzane przez kontroler domeny. W przypadku szczegółowych informacji o kontenerze jest to rozszerzenie usługi Container Insights, które zawiera co najmniej jedno wstępnie zdefiniowane streams
, począwszy od prefiksu Microsoft-.
Lista strumieni usługi Container Insights w kontrolerze domeny zależy od ustawienia wstępnego kosztu wybranego dla klastra. Jeśli zbierzesz wszystkie tabele, funkcja DCR będzie używać strumienia Microsoft-ContainerInsights-Group-Default
, który jest strumieniem grupy zawierającym wszystkie strumienie wymienione w wartościach strumienia. Jeśli zamierzasz użyć przekształcenia, musisz zmienić tę zmianę na poszczególne strumienie. Wszystkie inne ustawienia ustawień ustawień wstępnych kosztów będą już używać poszczególnych strumieni.
Poniższy przykład przedstawia Microsoft-ContainerInsights-Group-Default
strumień. Zobacz Przykładowe kontrolery DCR, aby zapoznać się z przykładami korzystającymi z poszczególnych strumieni.
"dataSources": {
"extensions": [
{
"streams": [
"Microsoft-ContainerInsights-Group-Default"
],
"name": "ContainerInsightsExtension",
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"namespaces": null,
"enableContainerLogV2": true
}
}
}
]
}
Przepływy danych
Sekcja Przepływy danych dcR pasuje do strumieni z miejscami docelowymi zdefiniowanymi w destinations
sekcji dcR. Nazwy tabel nie muszą być określone dla znanych strumieni, jeśli dane są wysyłane do tabeli domyślnej. Strumienie, które nie wymagają przekształcenia, można grupować razem w jednym wpisie zawierającym tylko miejsce docelowe obszaru roboczego. Każda z nich zostanie wysłana do swojej tabeli domyślnej.
Utwórz oddzielny wpis dla strumieni, które wymagają przekształcenia. Powinno to obejmować miejsce docelowe obszaru roboczego transformKql
i właściwość . Jeśli wysyłasz dane do tabeli alternatywnej, musisz dołączyć outputStream
właściwość określającą nazwę tabeli docelowej.
W poniższym przykładzie przedstawiono sekcję dataFlows
pojedynczego strumienia z przekształceniem. Zobacz Przykładowe kontrolery DCR dla wielu przepływów danych w jednym kontrolerze domeny.
"dataFlows": [
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where PodNamespace == 'kube-system'"
}
]
Przykładowe kontrolery domeny
Filtrowanie danych
Pierwszy przykład filtruje dane z ContainerLogV2
kolumny na podstawie kolumny LogLevel
. Zbierane są tylko rekordy z wartością LogLevel
error
lub critical
, ponieważ są to wpisy, których można użyć do zgłaszania alertów i identyfikowania problemów w klastrze. Zbieranie i przechowywanie innych poziomów, takich jak info
i debug
generowanie kosztów bez znaczącej wartości.
Te rekordy można pobrać przy użyciu następującego zapytania dziennika.
ContainerLogV2 | where LogLevel in ('error', 'critical')
Ta logika jest pokazana na poniższym diagramie.
W transformacji nazwa source
tabeli jest używana do reprezentowania danych przychodzących. Poniżej przedstawiono zmodyfikowane zapytanie do użycia w transformacji.
source | where LogLevel in ('error', 'critical')
W poniższym przykładzie pokazano tę transformację dodaną do usługi Container Insights DCR. Należy pamiętać, że jest używany oddzielny przepływ danych, Microsoft-ContainerLogV2
ponieważ jest to jedyny przychodzący strumień, do którego należy zastosować przekształcenie. Dla innych strumieni jest używany oddzielny przepływ danych.
{
"properties": {
"location": "eastus2",
"kind": "Linux",
"dataSources": {
"syslog": [],
"extensions": [
{
"streams": [
"Microsoft-ContainerLogV2",
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"enableContainerLogV2": true
}
},
"name": "ContainerInsightsExtension"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
"workspaceId": "00000000-0000-0000-0000-000000000000",
"name": "ciworkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"destinations": [
"ciworkspace"
],
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel in ('error', 'critical')"
}
],
},
}
Wysyłanie danych do różnych tabel
W powyższym przykładzie zbierane są tylko rekordy z wartością LogLevel
error
lub critical
. Alternatywna strategia zamiast zbierania tych rekordów w ogóle polega na zapisaniu ich w alternatywnej tabeli skonfigurowanej dla dzienników podstawowych.
W przypadku tej strategii potrzebne są dwa przekształcenia. Pierwsze przekształcenie wysyła rekordy z wartością LogLevel
error
lub critical
do tabeli domyślnej. Drugie przekształcenie wysyła inne rekordy do tabeli niestandardowej o nazwie ContainerLogV2_CL
. Zapytania dla każdego z nich są wyświetlane poniżej przy użyciu source
danych przychodzących zgodnie z opisem w poprzednim przykładzie.
# Return error and critical logs
source | where LogLevel in ('error', 'critical')
# Return logs that aren't error or critical
source | where LogLevel !in ('error', 'critical')
Ta logika jest pokazana na poniższym diagramie.
Ważne
Przed zainstalowaniem kontrolera DCR w tym przykładzie należy utworzyć nową tabelę z tym samym schematem co ContainerLogV2
. Nadaj mu ContainerLogV2_CL
nazwę i skonfiguruj ją pod kątem dzienników podstawowych.
W poniższym przykładzie pokazano tę transformację dodaną do usługi Container Insights DCR. W tym kontrolerze domeny istnieją dwa przepływy Microsoft-ContainerLogV2
danych, po jednym dla każdej transformacji. Pierwsza metoda wysyła do tabeli domyślnej, która nie musi określać nazwy tabeli. Drugi wymaga outputStream
, aby właściwość określała tabelę docelową.
{
"properties": {
"location": "eastus2",
"kind": "Linux",
"dataSources": {
"syslog": [],
"extensions": [
{
"streams": [
"Microsoft-ContainerLogV2",
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"extensionName": "ContainerInsights",
"extensionSettings": {
"dataCollectionSettings": {
"interval": "1m",
"namespaceFilteringMode": "Off",
"enableContainerLogV2": true
}
},
"name": "ContainerInsightsExtension"
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/microsoft.operationalinsights/workspaces/my-workspace",
"workspaceId": "00000000-0000-0000-0000-000000000000",
"name": "ciworkspace"
}
]
},
"dataFlows": [
{
"streams": [
"Microsoft-KubeEvents",
"Microsoft-KubePodInventory"
],
"destinations": [
"ciworkspace"
],
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel in ('error', 'critical')"
},
{
"streams": [
"Microsoft-ContainerLogV2"
],
"destinations": [
"ciworkspace"
],
"transformKql": "source | where LogLevel !in ('error','critical')",
"outputStream": "Custom-ContainerLogV2_CL"
}
],
},
}
Następne kroki
- Przeczytaj więcej na temat przekształceń i reguł zbierania danych w usłudze Azure Monitor.