Docker i Portainer

Zamień Container Logs w tabele, których można używać w zapytaniach.

Każdy kontener uruchamiany przez demona zapisuje dziennik. Wykonuj zapytania dotyczące wszystkich naraz — z prawdziwą nazwą kontenera, jego obrazem i usługą Compose, zamiast katalogu pełnego 64-znakowych identyfikatorów.

Korzystaj z wyników w Excelu, Arkuszach Google, narzędziach AI i aplikacjach za pośrednictwem Database REST API.

Każdy typ konektora jest dostępny w planie Free. Zacznij od 2 źródeł danych i 1 agenta.

Połącz Container Logs bezpłatnieSzczegóły połączenia
Dzienniki kontenerowePliki są odczytywane z miejsca, w którym się znajdują
W Twojej sieciAgent sieciowy strumieni zapytań

Odczytuj, porządkuj i odpytuj dane na swojej maszynie.

Zapytania tylko do odczytu · połączenie wychodzące
ExcelArkusze GoogleTwoje AITwoje aplikacje

Pliki źródłowe pozostają na miejscu. Twoje narzędzia otrzymują wyniki zapytań.

Źródło → agent → dozwolone wyniki

Query Streams przekształca dzienniki Docker json-file, ręcznie zapisywane eksporty docker logs oraz własny dziennik serwera Portainer w tabele SQL na żywo, dostępne do odczytu z Microsoft Excel, Google Sheets, asystentów AI przez MCP, REST API i Power BI. Rozwiązuje problem identyfikacji: pliki na dysku są nazywane identyfikatorem kontenera, dlatego agent przed załadowaniem wierszy ustala na podstawie każdego z nich prawdziwą nazwę kontenera, jego obraz i usługę Compose. Żadne dane nie są przesyłane — agent odczytuje pliki na hoście, a poza sieć wychodzą tylko wyniki zapytań.

  • Prawdziwe nazwy kontenerów, nie identyfikatory
  • Obraz i usługa Compose w każdym wierszu
  • stdout i stderr pozostają rozdzielone

Połącz Container Logs, używając odpowiednich ustawień.

Pozostaw połączenie w agencie sieciowym. Poniżej znajdują się szczegóły dotyczące Container Logs.

Falcówka
Katalog dzienników demona na hoście kontenera lub folder zawierający wyeksportowane dzienniki
Źródła
Dzienniki Docker json-file, zapisane eksporty docker logs i dziennik serwera Portainer
Identyfikacja
Nazwa kontenera, obraz i usługa Compose ustalane na podstawie demona, dzięki czemu kluczem wierszy nie jest 64-znakowy identyfikator
Rotacja
Śledzenie rotacji wykonywanej przez demona oraz dziesięć nazwanych wzorców rotacji dla wyeksportowanych plików
Niedopasowane wiersze
Zachowywane dosłownie w events_raw_lines, nigdy nie są odrzucane
Dane uwierzytelniające
Brak — agent odczytuje pliki na hoście, bez przenoszenia ich
Dialekt SQL
DuckDB — standardowy SQL, bez konieczności poznawania czegokolwiek specyficznego dla kontenerów

Agent odczytuje pliki dzienników już zapisane przez demona. Nie dołącza do kontenerów, nie utrzymuje otwartego gniazda demona w celu strumieniowego przesyłania danych i nigdy sam nie zapisuje tych plików ani nie wykonuje ich rotacji — więc działające połączenie nie może zmienić sposobu działania hosta.

Stworzone z myślą o sposobie działania Container Logs.

Najtrudniejsza jest identyfikacja, nie parsowanie

Sterownik json-file w Dockerze zapisuje dziennik każdego kontenera w katalogu nazwanym jego 64-znakowym identyfikatorem. Parsowanie JSON-a jest proste; ustalenie, którego kontenera dotyczy, już nie — a właśnie to sprawia, że tabela jest użyteczna.

  • Każdy wiersz zawiera prawdziwą nazwę kontenera, jego obraz i usługę Compose, ustalone na podstawie demona, a nie zgadywane na podstawie ścieżki.
  • Dzięki temu „błędy w usłudze api dziś rano” to warunek WHERE, a nie tabela mapowań, którą trzeba ręcznie utrzymywać.
  • Informacja o strumieniu również jest zachowywana, dzięki czemu stdout i stderr pozostają rozróżnialne, zamiast trafiać do jednej kolumny tekstowej.
  • Po usunięciu kontenera zachowane zostają wiersze, które już wygenerował — historia nie znika razem z kontenerem.
-- Które usługi generują teraz najwięcej wpisów
SELECT   service, stream, COUNT(*) AS lines
FROM     fileset.events
WHERE    stream = 'stderr'
GROUP BY service, stream
ORDER BY lines DESC

Trzy rzeczy, a nie jedna

Głównym źródłem są dzienniki json-file demona, ale nie są one jedynymi dziennikami kontenerów wartymi przeszukiwania: ręcznie zapisany eksport docker logs ma inny format, a Portainer zapisuje własny dziennik serwera. Wszystkie trzy mają profile, więc wybierasz, co odczytujesz, zamiast liczyć na to, że jeden parser poradzi sobie ze wszystkim.

Szczegółowe informacje o formatach i działaniu.

Otwórz potrzebną dokumentację referencyjną dotyczącą Container Logs.

Jeden folder dzienników kontenerów staje się jedną tabelą.
Wielki pomysł

Jeden folder dzienników kontenerów staje się jedną tabelą.

Query Streams odczytuje pliki, które demon już zapisuje, jednoznacznie określa ich format i udostępnia typowane kolumny z nazwą kontenera przy każdym wierszu. Bez sidecara, potoku przesyłania danych ani indeksu wymagającego utrzymania — a wiersz, którego parser nie potrafi odczytać, jest zachowywany wraz z uzasadnieniem, zamiast po cichu odrzucany.

Folder dziennikana hoście
a3f9c1…-json.logDoker
Dokershopfront-stack_api.logeksport
portainer.logPortainer

Rotacje, skompresowane archiwa i ponownie odczytywane pliki — wszystko obsłużone

hałaśliwe-kontenery.sqlSQL
SELECT aplikacja, usługa tworzenia,
       liczyć(*) AS kwestia
Z   zestaw_plików.zdarzenia
GDZIE  strumień = 'stderr'
GROUP BY aplikacja, usługa tworzenia
ORDER BY kwestia DESC
Wynikstderr według kontenera
aplikacjapracakwestia
interfejs API witryny sklepowejAPI1,284
pracownik witryny sklepowejpracownik417
witryna sklepowa-internetsieć62
pamięć podręczna witryny sklepowejkryjówka3

Połącz go z bazą danych swojej aplikacji w tym samym zapytaniu

Pliki, które demon już zapisuje, teraz w postaci tabeli, na podstawie której można generować raporty

Dwa narzędzia, trzy formaty, bez sidecara
Źródła

Dwa narzędzia, trzy formaty, bez sidecara

Każda karta podaje dokładne pliki odczytywane przez Query Streams i ich lokalizację. Nie musisz zmieniać sterownika rejestrowania, aby to działało — plik json jest ustawieniem domyślnym Dockera i jest ustawieniem domyślnym obsługiwanym.

Obsługiwane dzienniki kontenerów

3 formaty · 2 narzędzia
Logo Dockera — Query Streams odczytuje dzienniki kontenerów plików JSON Dockera i eksportuje dzienniki Dockera Dokersterownik rejestrowania plików json
  • Jeden {"log","strumień","czas"} koperta na wiersz, napisana przez demona
  • Nazwa kontenera pochodzi z własnych danych Dockera konfiguracja.v2.json obok kłody
  • Projekt/usługa „Image and Compose” w formie kolumn
  • Zazwyczaj /var/lib/docker/containers
  • Dołącza; ponumerowane obroty i .gz śledzony
Logo Dockera — strumienie zapytań odczytują logi Dockera i eksportują pliki znaczników czasu Dokereksport dzienników Dockera
  • Pliki, które zapisałeś dzienniki dokera --znaczniki czasu
  • Znacznik czasu RFC 3339 z nanosekundami, a następnie własny wiersz kontenera
  • Linie banerów kontenerowych są pomijane ze względu na deklarację, a nie szczęście
  • Dowolny folder, w którym przechowujesz eksporty
  • Jeden plik na usługę; nazwa pochodzi od rdzenia pliku
Logo Portainer — Query Streams odczytuje logi konsoli zerolog serwera Portainer PortainerDziennik serwera, konsola zerolog
  • portainer.log lub własne dane wyjściowe kontenera
  • Kody kolorów ANSI są usuwane przed analizą, więc poziom jest poziomem
  • Ten klucz=wartość ogon staje się kolumnami; reszta ląduje w dane
  • Odczytywane są również wiersze tunelowego serwera osadzonego w aplikacji, które mają inny format
  • Znaczki z rozdzielczością minutową, odczytywane jako UTC
Nadchodzi więcejto początek, a nie sufit

Nowe formaty dzienników kontenerów są dodawane z każdą wersją Agenta. Ponieważ Agenty są na bieżąco aktualizowane, format dodany później pojawia się w konektorze bez konieczności odwiedzania serwera.

Wszystkie trzy parsery zbudowano i przetestowano na rzeczywistych dziennikach kontenerów — dziennikach json-file, dużych dzienniki dokera eksporty z hosta Swarm oraz dziennik serwera Portainer CE 2.39.1. Warto wiedzieć z góry: w Docker Desktop dla Windows i Mac dzienniki json-file znajdują się wewnątrz maszyny wirtualnej, do której Agent działający jako usługa nie ma dostępu. Wyeksportuj je za pomocą dzienniki dokera --znaczniki czasu i użyj drugiego profilu.
Kontenery w każdym regionie, dzienniki odczytywane na miejscu
Gdziekolwiek to działa

Kontenery w każdym regionie, odczyt dzienników gdzie siedzą

Kontenery rzadko działają wszystkie w jednym miejscu. Host w biurze, klaster Swarm w jednym regionie chmury, pojedynczy serwer w innym kraju. W każdej lokalizacji działa Network Agent, który odczytuje pliki dzienników tam, gdzie się znajdują, i nawiązuje połączenie wychodzące z Query Streams. Z punktu widzenia zapory jest to zwykłe połączenie wychodzące — nie trzeba otwierać żadnych portów ani konfigurować VPN.

Siedziba główna Host Docker z logami json-file na dysku lokalnym, w katalogu demona wybiera numery
ue-zachód Klaster roju, jeden dzienniki dokera eksport na usługę wybiera numery
wschód USA Portainer zarządza garścią hostów, posiada własny dziennik serwera obok wybiera numery

Trzy połączenia wychodzące, jedno miejsce do wysyłania zapytań — bez portów przychodzących, VPN i zmian w zaporze

Jeden agent na lokalizację

Agent obsługuje całą lokalizację, a nie pojedynczy folder: każdy używany tam format dziennika staje się osobnym łącznikiem File Set na tym samym Agencie. Zazwyczaj w każdej lokalizacji działa jeden Agent. Plan Free obsługuje jednego Agenta, a płatne plany — większą ich liczbę.

1 witryna = 1 agent = wiele łączników

Nic do otwarcia

Agent nawiązuje jedno szyfrowane połączenie wychodzące, którym przesyłane są zarówno żądanie, jak i zwracane wiersze. Bez portu przychodzącego, bez VPN i bez konieczności wprowadzania zmian w zaporze — dane uwierzytelniające pozostają w Twojej sieci.

jedno połączenie, w obu kierunkach

Jedno zapytanie we wszystkich witrynach

Każde źródło w zapytanie federacyjne nazywa własnego Agenta, dzięki czemu pojedyncza instrukcja może odczytać dziennik w jednym kraju i dziennik w innym, a następnie zwrócić jeden wynik — lub połączyć dowolny z nich z bazą danych. Dostępne w planach Business i Enterprise.

2 kraje → 1 zestaw wyników

Utrzymują się na bieżąco

Agenci aktualizują się sami, więc format dziennika kontenerów dodany w późniejszej wersji dociera do każdej witryny bez konieczności logowania się na serwerze w celu jego instalacji. To właśnie sprawia, że ściana powyżej jest punktem początkowym, a nie stałą listą.

nowe formaty pojawiają się wraz z Agentem

Nazwy, zegary i kody kolorów
Najtrudniejsza część

Nazwy, zegary i kody kolorów

Log kontenera to nie plik tekstowy z datą. Trzy rzeczy rutynowo idą nie tak, gdy próbujesz traktować go jako dane, a każda z nich jest tutaj obsługiwana poprzez deklarację, a nie przez zgadywanie.

Nazwy, nie identyfikatory szesnastkowe

Docker nadaje nazwę każdemu folderowi logów na podstawie identyfikatora kontenera, co sprawia, że zapytanie grupowe jest nieczytelne. Strumienie zapytań odczytują rekord zapisany przez Dockera obok logu i przyjmują jego prawdziwą nazwę, zachowując identyfikator jako osobną kolumnę.

a3f9c1…-json.log → app = shopfront-api

Zegar demona

Jeśli uwierzysz kontenerowi, który wypisuje własny znacznik czasu w sekundach epoki, jego czas wyląduje w 1970 roku. Czasem zdarzenia jest czas przechwycenia przez demona; własny znacznik kontenera jest zachowywany jako kolumna, zamiast być uznawany za wiarygodny.

czas koperty → event_time

Kody kolorów w pliku

Rejestratory konsolowe zapisują sekwencje ucieczki terminala bezpośrednio w dzienniku. Są one usuwane przed parsowaniem, więc poziom jest odczytywany jako poziom, a nie poziom ujęty w sekwencje ucieczki — oryginalne bajty pozostają nietknięte.

kody ucieczki usunięte → level = INF

Nic nie liczyło się dwa razy

Każdy plik jest oznaczany odciskiem palca na podstawie pierwszych 4 KB, dzięki czemu obrócony plik jest rozpoznawany jako ten sam plik, a nie odczytywany ponownie od góry. Przesuwające się okno duplikatu wychwytuje nakładanie się, gdy zapisujący odtwarza jego ogon.

Skrót prefiksu 4 KB · okno 20 000 rekordów

Kolumny, które faktycznie otrzymujesz
Schemat

Kolumny, które faktycznie otrzymujesz

To nie jest blok tekstu ze znacznikiem czasu obok. Każdy format jest parsowany do kolumn o określonych typach, które można bezpośrednio filtrować, grupować i agregować — a gdy kontener rejestruje dane w postaci strukturalnego JSON, jego własne pola również są rozwijane do kolumn.

Logo Dockera
dziennik kontenera plików jsonDemon Dockera
strumieńpoziomdrwalwiadomośćgospodarzpracadane
Logo Dockera
eksport dzienników DockeraInterfejs wiersza poleceń Dockera
wiadomość
Logo Portainera
dziennik konsoli zerologPortainer
poziomgośćwiadomośćbłąddane

Każdy rząd również niesie czas_wydarzenia, surowy znacznik czasu, z którego został odczytany, oraz plik, z którego pochodzi. Każdy format dodaje kolumnę identyfikującą — aplikacja dla pliku json i Portainera, pojemnik na potrzeby eksportu — a wiersze json-file zawierają dodatkowo obraz, compose_project, usługa_kompozycji oraz identyfikator_kontenera. Singiel wiadomość kolumna w eksporcie jest celowa: własny wiersz kontenera zachowywany jest w całości, zamiast być odgadywany.

Czego to celowo nie robi

Czego to celowo nie robi

To nie jest żywy ogon. Query Streams odczytuje pliki w momencie ich obecności na dysku podczas uruchamiania zapytania, więc pętla restartu wyświetla się jako wiersze, a nie jako strumień, który można obserwować. Jeśli potrzebujesz alertów na temat wiersza w trakcie jego drukowania z dokładnością do mniej niż sekundy, odpowiednim narzędziem jest potok logów.

Dane wyjściowe kontenera mają dowolny format, co pociąga za sobą konsekwencję, którą warto jasno przedstawić: wszystko, co wypisuje aplikacja, trafia do tabeli. Jeśli rejestruje token lub adres e-mail klienta, ten ciąg znaków już znajduje się w pliku dziennika i trafi również do kolumny. Nie ma mapy nagłówków umożliwiającej wykluczenie danych, jak w przypadku dziennika serwera WWW — z tabelą wynikową obchodź się z taką samą ostrożnością jak z plikiem.

Dwa mniejsze limity, nazwane, a nie ukryte. Na dzienniki dokera w eksporcie własny wiersz kontenera jest zachowywany w całości w jednej wiadomość kolumnie; ponowne parsowanie tego wewnętrznego wiersza według jego własnego formatu nie jest jeszcze dostępne. Opcjonalne atrybuty, które Docker może dołączyć za pomocą tagu rejestrowania, są rozpoznawane wyłącznie na podstawie struktury — żaden kontener w przechwyconym zbiorze danych ich nie używał, więc ta ścieżka jest zadeklarowana, ale niepotwierdzona.

Reszta działa zgodnie ze standardową strukturą. Agent łączy się z serwerem wychodzącym i odczytuje pliki; nic nie jest instalowane w kontenerze, nic nie jest zapisywane z powrotem, gniazdo Dockera i API nie są modyfikowane, a dostęp jest tylko do odczytu. Okres przechowywania danych dla tego ustawienia wstępnego wynosi 30 dni i można go zmienić.

Od połączenia do przydatnych wyników.

  1. Zainstaluj Network Agent na hoście kontenera, gdzie będzie widział katalog dzienników demona'a.
  2. Skieruj łącznik na ten katalog. Dopasowywane są dzienniki json-file wszystkich kontenerów, a zakres można zawęzić za pomocą wzorców.
  3. Agent przyporządkowuje każdy 64-znakowy katalog do kontenera, do którego należy — jego rzeczywistej nazwy, obrazu i usługi Compose — dzięki czemu wiersze są czytelne, zanim napiszesz jakiekolwiek SQL.
  4. Każdy wiersz staje się rekordem zawierającym strumień (stdout lub stderr) i znacznik czasu demona; śledzona jest też rotacja dzienników wykonywana przez demona.
  5. Wykonaj zapytanie. Błędy ze wszystkich kontenerów naraz, pojedyncza usługa osobno albo porównanie stanu przed wdrożeniem i po nim.

Wykorzystaj wyniki Container Logs.

Jedno połączenie obsługuje arkusze kalkulacyjne, aplikacje i narzędzia AI. Udostępnij uprawnienie do uruchomienia zapisanego zapytania; odbiorcy zobaczą dozwolone wyniki, a SQL i dane logowania do źródła pozostaną ukryte.

Dla Twojego zespołu, dostawców i partnerów

Container Logs w Excelu

Pobieraj bieżące wyniki Container Logs bezpośrednio do arkusza i odświeżaj je na żądanie — w Excelu na komputerze, Excel Online i Microsoft 365.

Poznaj Excel

Zapytaj Nova o Container Logs

Zadaj pytanie prostym językiem. Nova zna już tabele Container Logs, pisze i uruchamia zapytania SQL, wyjaśnia odpowiedź i tworzy wykres — nie musisz pisać zapytania ani przekazywać danych uwierzytelniających.

Jak działa Nova

Container Logs w Data Viewer

Udostępnij komuś bieżący wynik Container Logs — współpracownikowi, dostawcy lub partnerowi — jako siatkę, do której można dodać zakładkę. Po otwarciu wynik jest pobierany na nowo na telefonie, tablecie lub komputerze. Odbiorcy widzą wyniki, nigdy zapytania SQL ani plików.

Jak działa Przeglądarka danych

Do aplikacji i systemów

Kontener Logs REST API

Opublikuj zapytanie Container Logs jako uwierzytelniony punkt końcowy JSON, z którego może korzystać dowolna aplikacja, wraz ze specyfikacją OpenAPI 3.1 i gotowymi kolekcjami Postman, Insomnia i Hoppscotch. Żaden port bazy danych nie jest otwierany.

Poznaj REST API

Container Logs w Power BI

Wklej wygenerowany kod Power Query M w Edytorze zaawansowanym Power BI, a raport będzie pobierał bieżące wyniki Container Logs przez HTTPS — bez sterownika ODBC i bez otwierania portu bazy danych.

Poznaj Power BI

Container Logs w Anvil

Zasilaj aplikację Anvil w Pythonie danymi Container Logs za pośrednictwem punktu końcowego REST, zamiast umieszczać dane uwierzytelniające bazy danych w aplikacji.

Poznaj Anvil

Dla narzędzi AI

Serwer MCP Container Logs

Przyznaj asystentowi AI dostęp tylko do odczytu do Container Logs oraz schemat potrzebny do pisania poprawnych zapytań SQL — bez danych uwierzytelniających w czacie.

Odkryj MCP

Dostarczone do ludzi

Połącz Container Logs z pozostałymi danymi.

Połącz bazy danych, biznesowe interfejsy API, pliki i dzienniki w jednym zapytaniu tylko do odczytu. Każdy konektor obsługuje zapytania federacyjne.

Podaj nazwy połączeń i tabel. Query Streams obsługuje zapytania do źródeł i łączy wyniki.

Poznaj zapytania federacyjne
Przykładowe zapytanie łączące źródła
-- nic nie zostało skopiowane, nic nie zostało połączone, nic nie zostało zaplanowane
SELECT   c.region, COUNT(*) AS zamówienia, SUM(i.amount_due) AS fakturowane
Z     containerlogs.fileset.orders1 f
JOIN     pg_crm.publiczni.klienci2      c WŁĄCZONY c.id = f.customer_id
JOIN     rozliczenia.stripe.invoices3      i WŁĄCZONY i.customer = c.stripe_id
GROUP BY c.region
ORDER BY fakturowany DESC;

Użyj własnych nazw połączeń, schematów, tabel i kolumn.

Wspólne dla całej rodziny konektorów.

Każde złącze dzienników udostępnia również

  • events — po jednym wierszu na każdą przeanalizowaną linię, z sygnaturą czasową, polami nazwanymi przez gramatykę oraz polem _source_file wskazującym plik, z którego pochodzi.
  • events_raw_lines — linie, które nie pasowały do gramatyki, zachowane w oryginalnej postaci zamiast odrzucenia, dzięki czemu nadal można uzyskać odpowiedź na pytanie dotyczące nieprzewidzianego formatu.
  • files_current i files_events — bieżący wykaz plików i ścieżka audytu: co się pojawiło, co podlegało rotacji, co zniknęło i co zostało wstrzymane, wraz z nazwą pliku i przyczyną.
  • Rotacja jest rozpoznawana, a nie obchodzona — dziesięć nazwanych wzorców rotacji oraz zwykłe pliki bez rotacji, dzięki czemu wczorajszy log i jego skompresowane archiwum są tą samą tabelą co log z dzisiaj.

Dobrze wiedzieć

  • Wymuszony tryb tylko do odczytu — jedno zapytanie naraz, wyłącznie SELECT i podobne polecenia. Nigdy nie zapisujemy, nie przenosimy, nie rotujemy ani nie skracamy Twoich logów.
  • Żadne dane nie są przesyłane — wiersze są analizowane i przechowywane w pamięci podręcznej w postaci zaszyfrowanej na Twoim komputerze, obok agenta. Twoją sieć opuszcza wyłącznie wynik zapytania.
  • Odczytywane są tylko nowe bajty — agent w każdym pliku wznawia pracę od miejsca, w którym ją przerwał, zamiast czytać go ponownie, więc intensywnie używany log nie kosztuje więcej każdego dnia.
  • Dialektem SQL jest DuckDB — ten sam SQL, którego używasz w przypadku dowolnego innego łącznika.

Pytania dotyczące Container Logs

Gdzie mogę używać wyników zapytań Container Logs?

Korzystaj z wyników Container Logs w Excelu, Google Sheets, Data Viewer, swoich aplikacjach za pośrednictwem Database REST API oraz narzędziach AI za pośrednictwem MCP lub Nova. Zapisane wyniki zasilają również obsługiwane miejsca docelowe automatyzacji, raporty i alerty. Dostępność miejsc docelowych i limity zależą od Twojego planu.

Czy muszę otworzyć port przychodzący dla Container Logs?

Nie. Zainstaluj Network Agent na maszynie, która ma dostęp do Container Logs. Agent łączy się wychodząco z Query Streams; nie jest potrzebny port przychodzący ani VPN. Źródło nadal musi zezwalać maszynie agenta na połączenie zgodnie z własnymi regułami dostępu.

Czy pliki Container Logs są przesyłane?

Network Agent odczytuje pliki w ich bieżącej lokalizacji, a pamięć podręczną przechowuje na maszynie agenta. Pliki źródłowe nie są przesyłane, przenoszone ani modyfikowane. Tylko żądane wyniki zapytań opuszczają Twoją sieć przez szyfrowane połączenie wychodzące.

Czego potrzebuję, aby połączyć się z Container Logs?

Folder: katalog logów demona na hoście kontenerów lub folder zawierający wyeksportowane logi. Źródła: logi Docker json-file, zapisane eksporty docker logs oraz log serwera Portainera. Tożsamość: nazwa kontenera, obraz i usługa Compose ustalane na podstawie demona, dzięki czemu wiersze nie są identyfikowane 64-znakowym identyfikatorem. Rotacja: śledzona zgodnie z rotacją demona, a także obsługiwanych jest dziesięć nazwanych wzorców rotacji dla wyeksportowanych plików

Czy mogę połączyć Container Logs z innymi podłączonymi źródłami?

Tak. Zapytania federacyjne obsługują wszystkie typy konektorów, w tym bazy danych, biznesowe interfejsy API, pliki i dzienniki. W jednym zapytaniu tylko do odczytu podaj nazwy połączeń i tabel. Query Streams w razie potrzeby tłumaczy części zapytania dotyczące źródeł i łączy ich wyniki. Zobacz, jak działają zapytania federacyjne.

Czy muszę zmienić sterownik rejestrujący Docker?

NIE. plik json to domyślny sterownik Dockera i jedyny obsługiwany. Jeśli nigdy nie konfigurowano rejestrowania, pliki już tam są i mają właściwy format.

Jeśli zmieniłeś sterownik, dzienniki dokera --znaczniki czasu export jest właściwą drogą: działa niezależnie od sterownika, ponieważ CLI odczytuje dane za pomocą demona.

Skąd wiadomo, jaka jest nazwa kontenera, a nie tylko jego identyfikator?

Docker zapisuje własny rekord kontenera w tym samym folderze co dziennik. Query Streams odczytuje nazwę z tego pliku i używa jej jako kolumny tożsamości, a obraz oraz projekt i usługa Compose są przechowywane jako kolumny obok. 64-znakowy identyfikator folderu jest zachowywany jako identyfikator_kontenera, więc nic nie jest stracone.

Jeśli brakuje tego rekordu, jest nieczytelny lub nie zawiera nazwy, zamiast niej używana jest nazwa folderu, a podczas skanowania zliczane jest, jak często się to zdarzyło — dzięki temu użycie wartości zastępczej jest widoczne jako liczba, którą można sprawdzić, a nie jako cicha podmiana.

Korzystam z Docker Desktop dla Windows lub Mac. Czy to działa?

Nie bezpośrednio w logach pliku json. Docker Desktop przechowuje je na własnej maszynie wirtualnej, a agent działający jako usługa na hoście nie ma do nich dostępu.

Drogą przez to jest profil eksportowy: docker logs --timestamps <kontener> przekierowany do pliku w dowolnym folderze, który Agent może odczytać. To obsługiwany format sam w sobie, a nie obejście — to ta sama metoda, której ludzie już używają, aby zachować kopię dziennika po usunięciu kontenera.

Czy to dzieje się w czasie rzeczywistym?

Odczyt odbywa się na żądanie, a nie strumieniowo. Pliki są odczytywane w takim stanie, w jakim znajdują się w chwili wykonania zapytania, więc nowe wiersze pojawiają się w miarę zapisywania ich przez kontenery i odczytania pliku — nie według stałego harmonogramu nocnego, ale też nie w trybie śledzenia na żywo.

Aby zadać pytanie dotyczące ostatnich kilku tygodni w każdym kontenerze i zapisać odpowiedź w arkuszu kalkulacyjnym, potrzebny jest przydatny kształt i znacznie mniej maszyn niż stos kłód.

A co z Kubernetesem lub Podmanem?

Żaden z nich nie ma dziś własnego profilu i wolimy o tym mówić, niż sugerować zasięg. Obowiązuje jednak format eksportu: profil jest kluczowany do dokładnego kształtu. dzienniki dokera --znaczniki czasu zapisuje — znacznik czasu z nanosekundową precyzją w formacie RFC 3339, spacja, a następnie własny wiersz kontenera; jeden plik na usługę. Narzędzia zapisujące dane w tym samym formacie mogą je odczytywać.

Niezawodną metodą sprawdzenia własnych plików jest polecenie Test połączenia, które raportuje rozpoznane dane przed podjęciem jakichkolwiek działań.

Moje kontenery logują dane JSON. Czy ich pola są wyświetlane jako kolumny?

Tak, w przypadku logów json-file. Obudowa demona jest rozpakowywana, a własny kod JSON kontenera zostaje rozłożony na kolumny — level, logger, message, host i service, jeśli występują. Wszystko, czego nie da się przypisać do nazwanej kolumny, jest zachowywane w dane kolumnę, a nie odrzuconą, więc nietypowe pole nadal może być przedmiotem zapytania.

Jedyną informacją, której nie pobiera się z kodu JSON kontenera, jest znacznik czasu. Pochodzi on od demona, ponieważ znacznik czasu aplikacji może mieć dowolny format, a błędna interpretacja po cichu umieściłaby wiersz w niewłaściwym czasie.

A co z wierszem, którego parser nie może odczytać?

Jest on zachowywany, a nie usuwany. Wiersz niezgodny z przypiętym formatem jest zachowywany jako surowy wiersz z dołączoną przyczyną, więc błędny wpis lub nieoczekiwana zmiana formatu jest widoczna i możliwa do sprawdzenia, a nie jako cicha luka w liczbach.

Umieść Container Logs tam, gdzie odbywa się praca.

Zacznij od planu Free: wszystkie typy konektorów, 2 źródła danych i 1 Network Agent. W miarę wzrostu potrzeb zwiększ limity planu.

Zdobądź darmowy planZobacz limity planów