Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Wiele aplikacji i usług na maszynie wirtualnej będzie rejestrować informacje w plikach tekstowych zamiast standardowych usług rejestrowania, takich jak dziennik zdarzeń systemu Windows lub dziennik syslog. Niestandardowe dzienniki tekstowe z maszyn wirtualnych można zbierać przy użyciu reguły zbierania danych (DCR) ze źródłem danych Niestandardowe Dzienniki Tekstowe.
Szczegółowe informacje na temat tworzenia reguły zbierania danych (DCR) znajdują się w temacie Zbieranie danych z klienta maszyny wirtualnej za pomocą usługi Azure Monitor. Ten artykuł zawiera dodatkowe szczegóły dotyczące typu źródła danych Dzienniki tekstu niestandardowego.
Uwaga / Notatka
Aby pracować bezpośrednio z definicją DCR lub wdrażać przy użyciu innych metod, takich jak szablony usługi ARM, zobacz Przykłady reguł zbierania danych (DCR) w usłudze Azure Monitor.
Wymagania wstępne
Oprócz wymagań wstępnych wymienionych w artykule Zbieranie danych z klienta maszyny wirtualnej za pomocą usługi Azure Monitor potrzebna jest tabela niestandardowa w obszarze roboczym usługi Log Analytics w celu odbierania danych. Zobacz tabelę obszarów roboczych usługi Log Analytics , aby uzyskać szczegółowe informacje o wymaganiach tej tabeli. Pamiętaj, że usługa Aarch64 nie jest obsługiwana.
Konfigurowanie niestandardowego źródła danych pliku tekstowego
Utwórz DCR przy użyciu procesu opisanego w temacie Zbieranie danych z klienta maszyny wirtualnej za pomocą usługi Azure Monitor. Na karcie Collect and deliver w DCR wybierz Niestandardowe dzienniki tekstowe z listy rozwijanej Typ źródła danych.
Opcje dostępne w konfiguracji niestandardowych dzienników tekstowych zostały opisane w poniższej tabeli.
Ustawienia | Opis |
---|---|
Wzorzec pliku | Identyfikuje lokalizację i nazwę plików dziennika na dysku lokalnym. Użyj symbolu wieloznakowego dla nazw plików, które różnią się, na przykład podczas tworzenia nowego pliku każdego dnia z nową nazwą. Można wprowadzić wiele wzorców plików rozdzielonych przecinkami. Przykłady: - C:\Logs\MyLog.txt - C:\Logs\MyLog*.txt - C:\App01\AppLog.txt, C:\App02\AppLog.txt - /var/mylog.log - /var/mylog*.log |
Nazwa tabeli | Nazwa tabeli docelowej w obszarze roboczym usługi Log Analytics. Ta tabela musi już istnieć. |
Ogranicznik rekordów | Wskazuje ogranicznik między wpisami dziennika.
TimeStamp jest jedyną bieżącą dozwoloną wartością. Szuka daty w formacie określonym w pliku , timeFormat aby zidentyfikować początek nowego rekordu. Jeśli nie znaleziono daty w określonym formacie, używany jest koniec wiersza. Aby uzyskać więcej informacji, zobacz Formaty czasu . |
Format znacznika czasu | Format czasu używany w pliku dziennika zgodnie z opisem w poniższych formatach czasu . |
Przekształć |
Transformacja w czasie pozyskiwania w celu filtrowania rekordów lub formatowania danych przychodzących dla tabeli przeznaczenia. Użyj polecenia source , aby pozostawić dane przychodzące bez zmian i wysłać je do kolumny RawData . Sprawdź Rozdzielane pliki dziennika aby zapoznać się z przykładem wykorzystania transformacji. |
Dodawanie miejsc docelowych
Niestandardowe dzienniki tekstowe można wysyłać tylko do obszaru roboczego usługi Log Analytics, w którym są przechowywane w utworzonej tabeli niestandardowej . Dodaj lokalizację docelową typu Dzienniki usługi Azure Monitor i wybierz obszar roboczy usługi Log Analytics. Można dodać tylko jeden obszar roboczy do DCR dla niestandardowego źródła danych dziennika tekstowego. Jeśli potrzebujesz wielu miejsc docelowych, utwórz wiele kontrolerów domeny. Należy jednak pamiętać, że spowoduje to wysłanie zduplikowanych danych do każdego, co spowoduje dodatkowe koszty.
Formaty czasu
W poniższej tabeli opisano formaty czasu obsługiwane w timeFormat
ustawieniu kontrolera domeny. Jeśli w wpisie dziennika zostanie uwzględniony czas z określonym formatem, zostanie użyty do zidentyfikowania nowego wpisu dziennika. Jeśli nie zostanie znaleziona żadna data w określonym formacie, jako ogranicznik zostanie użyty koniec wiersza. Aby uzyskać szczegółowy opis sposobu użycia tego ustawienia, zobacz Pliki dziennika wielowierszowego .
Format czasu | Przykład |
---|---|
ISO 8601
1 |
2024-10-29T18:28:34Z |
yyyy-MM-ddTHH:mm:ssk |
2024-10-29T18:28:34Z 2024-10-29T18:28:34+01:11 |
YYYY-MM-DD HH:MM:SS |
2024-10-29 18:28:34 |
M/D/YYYY HH:MM:SS AM/PM |
29.10.2024 18:28:34 |
Mon DD, YYYY HH:MM:SS |
29 października 2024 r. 18:28:34 |
yyMMdd HH:mm:ss |
241029 18:28:34 |
ddMMyy HH:mm:ss |
291024 18:28:34 |
MMM d HH:mm:ss |
29 października 18:28:34 |
dd/MMM/yyyy:HH:mm:ss zzz |
14/10/2024:18:28:34 -00 |
1 Znaczniki czasowe ISO 8601 z ułamkiem dziesiętnym / dokładnością do części sekund nie są obsługiwane.
Wymagania dotyczące plików tekstowych i najlepsze rozwiązania
Plik zbierany przez usługę Azure Monitor musi spełniać następujące wymagania:
- Plik musi być przechowywany na dysku lokalnym maszyny agenta w monitorowanym katalogu.
- Plik musi używać kodowania ASCII lub UTF-8. Inne formaty, takie jak UTF-16, nie są obsługiwane.
- Nowe rekordy powinny być dołączane na końcu pliku i nie zastępować starych rekordów. Zastępowanie spowoduje utratę danych.
Poniżej przedstawiono przykład typowego niestandardowego pliku tekstowego, który można zebrać przez usługę Azure Monitor. Mimo że każdy wiersz zaczyna się od daty, nie jest to wymagane, ponieważ koniec wiersza będzie używany do identyfikowania każdego wpisu, jeśli nie zostanie znaleziona data.
2024-06-21 19:17:34,1423,Error,Sales,Unable to connect to pricing service.
2024-06-21 19:18:23,1420,Information,Sales,Pricing service connection established.
2024-06-21 21:45:13,2011,Warning,Procurement,Module failed and was restarted.
2024-06-21 23:53:31,4100,Information,Data,Nightly backup complete.
Zastosuj się do poniższych zaleceń, aby upewnić się, że nie występują problemy z utratą danych ani wydajnością:
- Nie należy kierować do więcej niż 10 katalogów z plikami dziennika. Sondowanie zbyt wielu katalogów prowadzi do niskiej wydajności.
- Ciągłe czyszczenie plików dziennika w monitorowanym katalogu. Śledzenie wielu plików dziennika może zwiększyć użycie procesora i pamięci agenta. Poczekaj co najmniej dwa dni, aby umożliwić przetworzenie wszystkich dzienników systemowych.
- Nie zmieniaj nazwy pliku zgodnego ze wzorcem skanowania plików na inną nazwę zgodną ze wzorcem skanowania plików. To spowoduje wczytywanie zduplikowanych danych.
- Nie zmieniaj nazwy ani nie kopiuj dużych plików dziennika, które są zgodne ze wzorcem skanowania plików do monitorowanego katalogu. Jeśli musisz, nie przekrocz 50 MB na minutę.
Tabela obszarów roboczych usługi Log Analytics
Każdy wpis w pliku dziennika jest zbierany podczas jego tworzenia i wysyłania do określonej tabeli w obszarze roboczym usługi Log Analytics. Tabela niestandardowa w obszarze roboczym usługi Log Analytics, która będzie otrzymywać dane, musi istnieć przed utworzeniem kontrolera domeny.
W poniższej tabeli opisano wymagane i opcjonalne kolumny w tabeli obszarów roboczych. Tabela może zawierać inne kolumny, ale nie zostaną wypełnione, chyba że dane zostaną przeanalizowane za pomocą przekształcenia zgodnie z opisem w sekcji Rozdzielane pliki dziennika.
Kolumna | Typ | Wymagane? | Opis |
---|---|---|---|
TimeGenerated |
data i godzina | Tak | Ta kolumna zawiera godzinę wygenerowania rekordu i jest wymagana we wszystkich tabelach. Ta wartość zostanie automatycznie wypełniona wraz z czasem dodania rekordu do obszaru roboczego usługi Log Analytics. Można zastąpić tę wartość korzystając z przekształcenia, aby ustawić TimeGenerated na wartość z wpisu do dziennika. |
RawData |
sznurek | Tak 1 | Cały wpis dziennika w jednej kolumnie. Możesz użyć przekształcenia, jeśli chcesz podzielić te dane na wiele kolumn przed wysłaniem do tabeli. |
Computer |
sznurek | Nie. | Jeśli tabela zawiera tę kolumnę, zostanie wypełniona nazwą komputera, z którego został zebrany wpis dziennika. |
FilePath |
sznurek | Nie. | Jeśli tabela zawiera tę kolumnę, zostanie wypełniona ścieżką do pliku dziennika, z którego został zebrany wpis dziennika. |
1 Tabela nie musi zawierać RawData
kolumny, jeśli używasz przekształcenia do analizowania danych w wielu kolumnach.
Podczas zbierania przy użyciu ustawień domyślnych dane z przykładowego pliku dziennika, pokazanego powyżej, będą wyglądały następująco po pobraniu za pomocą zapytania do dziennika.
Tworzenie tabeli niestandardowej
Jeśli tabela docelowa jeszcze nie istnieje, trzeba ją utworzyć przed utworzeniem żądania zmiany danych. Zobacz Tworzenie tabeli niestandardowej , aby uzyskać informacje o różnych metodach tworzenia tabeli.
Na przykład możesz użyć następującego skryptu programu PowerShell, aby utworzyć tabelę niestandardową do odbierania danych z niestandardowego dziennika tekstowego. W tym przykładzie dodano również opcjonalne kolumny.
$tableParams = @'
{
"properties": {
"schema": {
"name": "{TableName}_CL",
"columns": [
{
"name": "TimeGenerated",
"type": "DateTime"
},
{
"name": "Computer",
"type": "string"
},
{
"name": "FilePath",
"type": "string"
},
{
"name": "RawData",
"type": "string"
}
]
}
}
}
'@
Invoke-AzRestMethod -Path "/subscriptions/{subscription}/resourcegroups/{resourcegroup}/providers/microsoft.operationalinsights/workspaces/{workspace}/tables/MyTable_CL?api-version=2021-12-01-preview" -Method PUT -payload $tableParams
Pliki dziennika wielowierszowego
Niektóre pliki dziennika mogą zawierać wpisy obejmujące wiele wierszy. Jeśli każdy wpis dziennika rozpoczyna się od daty, można użyć tej daty jako ogranicznika do zdefiniowania każdego wpisu dziennika. W takim przypadku dodatkowe wiersze zostaną połączone w kolumnie RawData
.
Na przykład plik tekstowy w poprzednim przykładzie może być sformatowany w następujący sposób:
2024-06-21 19:17:34,1423,Error,Sales,
Unable to connect to pricing service.
2024-06-21 19:18:23,1420,Information,Sales,
Pricing service connection established.
2024-06-21 21:45:13,2011,Warning,Procurement,
Module failed and was restarted.
2024-06-21 23:53:31,4100,Information,Data,
Nightly backup complete.
Jeśli w DCR jest używany format sygnatury czasowej YYYY-MM-DD HH:MM:SS
, dane będą zbierane w taki sam sposób jak w poprzednim przykładzie. Dodatkowe wiersze zostaną uwzględnione w kolumnie RawData
. Jeśli użyto innego formatu sygnatury czasowej, który nie pasuje do daty we wpisie dziennika, każdy wpis zostanie zebrany jako dwa oddzielne rekordy.
Rozdzielane pliki dziennika
Wiele plików dziennika tekstu zawiera wpisy z kolumnami rozdzielanymi znakami, takimi jak przecinek. Zamiast wysyłać cały wpis do RawData
kolumny, można przeanalizować dane w osobnych kolumnach, aby każdy z nich mógł zostać wypełniony w tabeli docelowej. Użyj przekształcenia z funkcją split, aby wykonać tę analizę.
Przykładowy plik tekstowy pokazany powyżej jest rozdzielany przecinkami, a pola można opisać jako: Time
, , Code
Severity
, Module
, i Message
. Aby podzielić te dane na oddzielne kolumny, dodaj każdą z kolumn do tabeli docelowej i dodaj następującą transformację do DCR.
Ważne
Przed dodaniem tej transformacji do DCR, należy dodać te kolumny do tabeli docelowej. Możesz zmodyfikować powyższy skrypt programu PowerShell, aby uwzględnić dodatkowe kolumny podczas tworzenia tabeli. Możesz też użyć witryny Azure Portal zgodnie z opisem w artykule Dodawanie lub usuwanie kolumny niestandardowej , aby dodać kolumny do istniejącej tabeli.
Istotne szczegóły zapytania przekształcenia obejmują następujące elementy:
- Zapytanie zwraca właściwości, które są zgodne z nazwą kolumny w tabeli docelowej.
- W tym przykładzie zmienia się nazwę właściwości
Time
w pliku dziennika, aby ta wartość była używana dla elementuTimeGenerated
. Jeśli ta wartość nie została podana,TimeGenerated
zostałoby wypełnione czasem pozyskiwania. - Ponieważ
split
zwraca dane dynamiczne, należy użyć funkcji, takich jaktostring
itoint
, aby przekonwertować dane na poprawny typ skalarny.
source | project d = split(RawData,",") | project TimeGenerated=todatetime(d[0]), Code=toint(d[1]), Severity=tostring(d[2]), Module=tostring(d[3]), Message=tostring(d[4])
Pobranie tych danych za pomocą zapytania dziennika zwróci następujące wyniki.
Rozwiązywanie problemów
Wykonaj poniższe kroki, jeśli nie zbierasz danych z oczekiwanego dziennika tekstowego.
- Sprawdź, czy dane są zapisywane w zbieranym pliku dziennika.
- Sprawdź, czy nazwa i lokalizacja pliku dziennika są zgodne z określonym wzorcem pliku.
- Sprawdź, czy schemat tabeli docelowej jest zgodny ze strumieniem przychodzącym lub że masz przekształcenie, które przekonwertuje strumień przychodzący na prawidłowy schemat.
- Zobacz Weryfikowanie operacji , aby sprawdzić, czy agent działa, a dane są odbierane.
Dalsze kroki
- Dowiedz się więcej o Agencie Azure Monitor.
- Dowiedz się więcej o zasadach zbierania danych.