도커 & 포테이너

Container Logs를 쿼리 가능한 테이블로 바꾸세요.

데몬이 실행하는 모든 컨테이너는 로그를 기록합니다. 64자 ID가 나열된 디렉터리 대신 컨테이너의 실제 이름, 이미지, Compose 서비스를 함께 표시해 모든 로그를 한 번에 쿼리하세요.

결과를 Excel, Google Sheets, AI 도구 및 Database REST API를 통한 앱에서 사용하세요.

모든 커넥터 유형을 Free에서 사용할 수 있습니다. 데이터 소스 2개와 에이전트 1개로 시작하세요.

Container Logs 무료로 연결하기연결 정보
컨테이너 로그파일이 저장된 위치에서 읽기
네트워크 내부쿼리 스트림 네트워크 에이전트

내 머신에서 읽고, 정리하고, 쿼리하세요.

읽기 전용 쿼리 · 아웃바운드 연결
ExcelGoogle 스프레드시트사용자의 AI사용자의 앱

원본 파일은 제자리에 그대로 둡니다. 도구에는 쿼리 결과가 전달됩니다.

소스 → 에이전트 → 허용된 결과

Query Streams는 Docker의 json-file 로그, 수동으로 저장한 docker logs 내보내기 파일, Portainer 자체 서버 로그를 Microsoft Excel, Google Sheets, MCP를 통한 AI 어시스턴트, REST API 및 Power BI에서 읽을 수 있는 라이브 SQL 테이블로 바꿉니다. 해결하는 어려운 문제는 식별입니다. 디스크의 파일은 컨테이너 ID를 이름으로 사용하므로, 행을 가져오기 전에 에이전트가 각 파일을 컨테이너의 실제 이름, 이미지 및 Compose 서비스에 대응시킵니다. 데이터를 업로드하지 않습니다. 에이전트는 호스트에서 파일을 읽고 쿼리 결과만 네트워크 밖으로 나갑니다.

  • ID가 아닌 실제 컨테이너 이름
  • 행마다 이미지 및 Compose 서비스 표시
  • stdout과 stderr를 별도로 유지

올바른 설정으로 Container Logs에 연결하세요.

Network Agent에서 연결을 유지하세요. 다음은 Container Logs에만 해당하는 세부 정보입니다.

접는 사람
컨테이너 호스트의 데몬 로그 디렉터리 또는 내보낸 로그가 들어 있는 폴더
소스
Docker json-file 로그, 저장된 docker logs 내보내기 파일, Portainer 서버 로그
식별 정보
데몬에서 컨테이너 이름, 이미지 및 Compose 서비스를 확인하므로 행을 64자 ID로 식별하지 않습니다.
로테이션
데몬의 로그 로테이션을 따르며, 내보낸 파일을 위한 이름 지정 로테이션 패턴 10개도 지원합니다.
형식이 일치하지 않는 줄
events_raw_lines에 원문 그대로 보존되며, 삭제되지 않습니다.
자격 증명
없음 - 에이전트가 호스트에 있는 파일을 그대로 읽습니다.
SQL 방언
DuckDB - 표준 SQL을 사용하며 컨테이너 전용 문법을 새로 익힐 필요가 없습니다.

에이전트는 데몬이 이미 기록한 로그 파일을 읽습니다. 컨테이너에 연결하거나 스트리밍을 위해 데몬 소켓을 계속 열어 두지 않으며, 파일에 직접 쓰거나 파일을 로테이션하지도 않습니다. 따라서 커넥터를 계속 실행해도 호스트의 동작은 바뀌지 않습니다.

Container Logs의 작동 방식에 맞춰 설계되었습니다.

어려운 문제는 파싱이 아니라 식별입니다.

Docker의 json-file 드라이버는 각 컨테이너의 로그를 64자 ID를 이름으로 하는 디렉터리에 기록합니다. JSON 파싱은 쉽지만, 어느 컨테이너의 로그인지 알아내는 일은 그렇지 않습니다. 그리고 이것이 테이블을 유용하게 만드는 핵심입니다.

  • 각 행에는 경로에서 추측한 값이 아니라 데몬에서 확인한 컨테이너의 실제 이름, 이미지 및 Compose 서비스가 포함됩니다.
  • 따라서 "오늘 아침 api 서비스의 오류"는 직접 관리하는 조회 테이블이 아니라 WHERE 절로 찾을 수 있습니다.
  • 스트림 정보도 보존되므로 stdout과 stderr를 하나의 텍스트 열에 합치지 않고 구분할 수 있습니다.
  • 컨테이너를 삭제해도 이미 생성된 행은 남습니다. 컨테이너와 함께 기록이 사라지지 않습니다.
-- 지금 로그가 가장 많은 서비스는?
SELECT   service, stream, COUNT(*) AS lines
FROM     fileset.events
WHERE    stream = 'stderr'
GROUP BY service, stream
ORDER BY lines DESC

하나가 아니라 세 가지

데몬의 json-file 로그가 주된 대상이지만, 쿼리할 만한 컨테이너 로그는 그것만이 아닙니다. 수동으로 저장한 docker logs 내보내기 파일은 형식이 다르고, Portainer도 자체 서버 로그를 기록합니다. 세 형식 모두에 프로필이 있으므로, 하나의 파서가 전부 처리하기를 기대하는 대신 읽을 대상을 선택할 수 있습니다.

형식과 동작에 대한 자세한 설명입니다.

Container Logs에 필요한 참고 자료를 확인하세요.

컨테이너 로그 폴더 하나가 하나의 테이블로 통합됩니다.
핵심 아이디어

컨테이너 로그 폴더 하나가 하나의 테이블로 통합됩니다.

Query Streams는 데몬이 이미 기록한 파일을 읽고 형식을 지정해, 각 행 옆에 컨테이너 이름이 표시되는 형식화된 열을 제공합니다. 사이드카도, 로그 전송 파이프라인도, 관리해야 할 인덱스도 없습니다. 파서가 읽지 못하는 줄도 조용히 버리지 않고 이유를 표시한 행으로 보존합니다.

로그 폴더호스트에서
a3f9c1…-json.log도커
도커shopfront-stack_api.log내보내다
포테이너.log포르테이너

로테이션, 압축 아카이브 및 다시 읽는 파일까지 처리

시끄러운 컨테이너.sqlSQL
선택 앱, compose_service,
       세다(*) AS 윤곽
FROM   파일셋.이벤트
어디  스트림 = 'stderr'
그룹 기준 앱, compose_service
주문 기준 윤곽 DESC
결과컨테이너의 stderr
앱서비스윤곽
샵프론트 APIAPI1,284
매장 직원노동자417
샵프론트-웹편물62
매장 전면 캐시은닉처3

동일한 쿼리에서 애플리케이션 데이터베이스에 조인하세요.

데몬이 이미 기록한 파일들을 표 형식으로 보고서로 만들 수 있습니다.

두 가지 도구, 세 가지 형식, 사이드카 없음
소스

두 가지 도구, 세 가지 형식, 사이드카 없음

각 카드에는 Query Streams가 읽는 정확한 파일과 파일 위치가 나와 있습니다. 이 기능을 사용하기 위해 로깅 드라이버를 변경할 필요가 없습니다 — JSON 파일 Docker의 기본값이며, 기본값은 지원되는 값입니다.

지원되는 컨테이너 로그

형식 3개 · 도구 2개
Docker 로고 - Query Streams는 Docker JSON 파일 컨테이너 로그 및 Docker 로그 내보내기를 읽습니다. 도커JSON 파일 로깅 드라이버
  • 하나 {"로그","스트림","시간"} 데몬이 작성한 줄별 봉투
  • 컨테이너 이름은 Docker 자체에서 가져옵니다. config.v2.json 통나무 옆
  • 이미지 및 구성 프로젝트/서비스는 칼럼 형식으로 함께 제공됩니다.
  • 대개 /var/lib/docker/containers
  • 부록; 번호가 매겨진 회전 및 .gz 뒤따랐다
Docker 로고 - Query Streams는 `docker logs --timestamps export files` 명령어를 사용하여 로그를 읽습니다. 도커Docker 로그 내보내기
  • 저장한 파일 docker logs --timestamps
  • RFC 3339 나노초 타임스탬프 다음에 컨테이너 자체 로그가 이어집니다.
  • 컨테이너 배너 라인은 우연이 아니라 선언에 따라 건너뛰어집니다.
  • 내보내기 파일을 저장하는 폴더
  • 서비스당 하나의 파일이며, 파일 이름은 파일 이름의 어근에서 따왔습니다.
Portainer 로고 - Query Streams는 Portainer 서버 zerolog 콘솔 로그를 읽습니다. 포르테이너서버 로그, 제로로그 콘솔
  • 포테이너.log 또는 컨테이너 자체 출력
  • ANSI 색상 코드는 파싱 전에 제거되므로 레벨은 레벨입니다.
  • 그만큼 키=값 꼬리는 기둥이 되고, 나머지는 다음과 같이 됩니다. 데이터
  • 내장 터널 서버의 형식이 다른 로그 줄도 읽습니다.
  • 분 단위의 스탬프, UTC로 읽음
더 많은 정보 제공이것은 시작일 뿐, 한계가 아닙니다.

각 에이전트 릴리스마다 새로운 컨테이너 로그 형식이 추가됩니다. 에이전트는 자체적으로 최신 상태를 유지하므로, 나중에 추가된 형식은 서버에 접속하지 않아도 커넥터에 표시됩니다.

세 파서는 모두 실제 컨테이너 로그, 즉 json-file 로그와 대용량 로그를 대상으로 구축하고 테스트했습니다. 도커 로그 Swarm 호스트에서 내보내는 로그와 Portainer CE 2.39.1의 서버 로그입니다. 미리 알아둘 점이 하나 있습니다. Windows 및 Mac용 Docker Desktop에서는 json-file 로그가 가상 머신 내부에 저장되므로 서비스로 실행되는 Agent가 접근할 수 없습니다. 다음을 사용해 내보내세요. docker logs --timestamps 두 번째 프로필을 사용하세요.
모든 리전의 컨테이너, 각 위치에서 읽는 로그
어디에서든 작동합니다

모든 지역의 컨테이너, 로그 읽기 그들이 앉는 곳

컨테이너가 한곳에서만 모두 실행되는 경우는 드뭅니다. 사무실의 호스트, 한 클라우드 리전의 Swarm 클러스터, 다른 국가의 단일 서버 등 각 위치에서 Network Agent가 로그 파일이 있는 곳에서 로그를 읽고 Query Streams로 아웃바운드 연결을 시작합니다. 방화벽 관점에서는 일반적인 아웃바운드 연결일 뿐입니다. 열어야 할 포트도, 구축할 VPN도 없습니다.

본점 로컬 디스크의 Docker 호스트, 데몬 폴더 아래의 json-file 로그 전화를 걸다
eu-서쪽 스웜 클러스터, 하나 도커 로그 서비스별 수출 전화를 걸다
미국 동부 Portainer는 몇 개의 호스트를 관리하며 자체 서버 로그를 함께 제공합니다. 전화를 걸다

아웃바운드 연결 세 개를 한곳에서 쿼리하세요. 인바운드 포트도, VPN도, 방화벽 변경도 필요 없습니다.

지역당 담당자 1명

Agent 하나가 단일 폴더가 아니라 사이트 전체를 담당합니다. 해당 위치에서 사용하려는 로그 형식마다 같은 Agent에 별도의 File Set 커넥터를 설정합니다. 일반적으로 위치당 Agent 하나를 사용합니다. Free 플랜에서는 Agent 하나를 실행하고, 유료 플랜에서는 더 많이 실행할 수 있습니다.

사이트 1개 = 에이전트 1개 = 여러 커넥터

열 내용이 없습니다

Agent는 암호화된 아웃바운드 연결 하나를 설정하며, 요청과 응답 데이터가 모두 이 연결을 통해 이동합니다. 인바운드 포트도, VPN도, 방화벽 변경 요청도 필요 없습니다. 자격 증명은 네트워크 내부에 그대로 유지됩니다.

하나의 연결, 양방향

여러 사이트에 걸쳐 하나의 쿼리

모든 출처 연합 쿼리 각자 고유한 Agent 이름을 사용하므로 단일 문 하나로 한 국가의 로그와 다른 국가의 로그를 읽어 하나의 결과로 반환하거나 둘 중 하나를 데이터베이스와 조인할 수 있습니다. Business 및 Enterprise에 포함됩니다.

국가 2곳 → 결과 집합 1개

그들은 최신 정보를 계속 습득합니다.

에이전트는 자체적으로 업데이트되므로, 이후 릴리스에서 추가된 컨테이너 로그 형식은 사용자가 서버에 로그인하여 설치할 필요 없이 모든 사이트에 적용됩니다. 따라서 위의 목록은 고정된 목록이 아니라 시작점에 불과합니다.

에이전트와 함께 새로운 형식들이 등장합니다.

이름, 시계 및 색상 코드
어려운 부분

이름, 시계 및 색상 코드

컨테이너 로그는 날짜가 포함된 텍스트 파일이 아닙니다. 컨테이너 로그를 데이터처럼 취급하려고 하면 일반적으로 세 가지 문제가 발생하는데, 여기서는 추측이 아닌 선언을 통해 각 문제를 처리합니다.

이름이지 16진수 ID가 아닙니다.

Docker는 각 로그 폴더의 이름을 컨테이너 ID로 지정하기 때문에 그룹화된 쿼리에서는 내용을 읽기가 어렵습니다. Query Streams는 Docker가 로그 옆에 기록하는 레코드를 읽어 실제 이름을 가져오고 ID는 별도의 열로 유지합니다.

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

데몬의 시각

자체 타임스탬프를 epoch 초 단위로 출력하는 컨테이너의 로그는 그 값을 그대로 믿으면 1970년으로 표시됩니다. 이벤트 시간은 데몬이 캡처한 시간입니다. 컨테이너 자체의 타임스탬프는 신뢰하지 않고 별도의 열에 보존합니다.

봉투 시간 → event_time

파일 내 색상 코드

콘솔 로거는 터미널 이스케이프 시퀀스를 로그에 그대로 기록합니다. 파싱 전에 이를 제거하므로 레벨이 이스케이프 문자로 둘러싸인 형태가 아니라 레벨 자체로 읽힙니다. 원본 바이트는 변경하지 않습니다.

이스케이프 코드 제거됨 → level = INF

아무것도 두 번 계산되지 않습니다

각 파일은 처음 4KB로 식별되므로, 회전된 파일은 처음부터 다시 읽는 대신 동일한 파일로 인식됩니다. 롤링 복제 창은 쓰기 작업이 끝부분을 다시 재생할 때 겹치는 부분을 포착합니다.

4KB 접두부 해시 · 20,000개 레코드 윈도우

실제로 얻게 되는 열
스키마

실제로 얻게 되는 열

타임스탬프가 옆에 붙은 텍스트 덩어리가 아닙니다. 각 형식은 직접 필터링, 그룹화 및 집계할 수 있는 형식이 지정된 열로 파싱됩니다. 컨테이너가 구조화된 JSON을 기록하는 경우에는 자체 필드도 풀어서 열로 만듭니다.

도커 로고
JSON 파일 컨테이너 로그도커 데몬
개울수준나무꾼메시지주인서비스데이터
도커 로고
Docker 로그 내보내기Docker CLI
메시지
포르테이너 로고
제로로그 콘솔 로그포르테이너
수준방문객메시지오류데이터

각 행에는 또한 다음이 포함됩니다. 이벤트 시간그리고 원시 타임스탬프, 로그를 읽어 온 파일도 포함됩니다. 각 형식에는 식별 열이 추가됩니다. — 앱 json-file 및 Portainer의 경우, 컨테이너 내보내기용이며, json-file 행에는 추가로 다음이 포함됩니다. 영상, compose_project, compose_service 그리고 컨테이너 ID싱글 메시지 내보내기에서 이 열을 의도적으로 둔 이유는 컨테이너 자체의 로그 행을 추측해 해석하지 않고 온전하게 보존하기 위해서입니다.

이것이 의도적으로 하지 않는 것은 무엇인가

이것이 의도적으로 하지 않는 것은 무엇인가

이는 실시간 로그 추적이 아닙니다. 쿼리 스트림은 쿼리를 실행할 때 디스크에 저장된 파일을 그대로 읽어오기 때문에, 재시작 루프가 발생하면 스트림 형태로 표시되는 것이 아니라 행 단위로 기록됩니다. 출력되는 모든 줄에 대해 초 단위 미만의 알림을 받으려면 로그 파이프라인을 사용하는 것이 적합합니다.

컨테이너의 출력은 자유 형식이며, 이로 인해 반드시 분명히 짚고 넘어가야 할 점이 있습니다. 애플리케이션이 출력하는 내용은 그대로 테이블에 들어갑니다. 토큰이나 고객 이메일을 기록하면 해당 문자열은 이미 로그 파일에 있으며 열에도 들어갑니다. 웹 서버 로그처럼 제외할 항목을 지정하는 헤더 매핑은 없습니다. 결과 테이블은 로그 파일을 다룰 때와 똑같은 주의를 기울여 다루세요.

두 개의 작은 제한 사항이 숨겨져 있는 것이 아니라 명시되어 있습니다. 도커 로그 내보내기에서 컨테이너 자체의 로그 행은 하나의 열에 온전히 보존됩니다. 메시지 열입니다. 그 내부 행을 자체 형식으로 다시 파싱하는 기능은 아직 구현되지 않았습니다. 또한 Docker가 로깅 태그를 사용해 첨부할 수 있는 선택적 속성은 형태만 인식합니다. 캡처된 코퍼스에 해당 속성을 사용한 컨테이너가 없으므로, 이 경로는 지원 대상으로 명시되어 있지만 검증된 것은 아닙니다.

나머지는 일반적인 설계 방식을 따릅니다. 에이전트는 외부 연결을 통해 파일을 읽습니다. 컨테이너에는 아무것도 설치되지 않고, 아무것도 기록되지 않으며, Docker 소켓과 API는 전혀 건드리지 않고, 접근은 읽기 전용입니다. 보존 기간은 이 사전 설정에서 30일부터 시작하며, 사용자가 변경할 수 있습니다.

연결부터 유용한 결과까지.

  1. 컨테이너 호스트에 Network Agent를 설치하여 데몬의 로그 디렉터리에 접근할 수 있게 합니다.
  2. 커넥터가 해당 디렉터리를 가리키도록 설정합니다. 모든 컨테이너의 json-file 로그가 매칭되며, 패턴을 사용해 범위를 좁힐 수 있습니다.
  3. Agent는 64자 디렉터리를 해당 컨테이너의 실제 이름, 이미지 및 Compose 서비스로 역참조하므로 SQL을 작성하기 전부터 행을 알아보기 쉽습니다.
  4. 모든 로그 행이 stdout 또는 stderr 스트림과 데몬 타임스탬프를 포함한 행으로 변환되며, 데몬이 로그를 로테이션할 때도 이를 계속 추적합니다.
  5. 쿼리를 실행하세요. 모든 컨테이너의 오류를 한 번에 확인하거나, 단일 서비스만 따로 살펴보거나, 배포 전후를 비교할 수 있습니다.

Container Logs 결과를 활용해 보세요.

하나의 연결로 스프레드시트, 앱, AI 도구를 사용할 수 있습니다. 저장된 쿼리를 실행할 권한을 공유하세요. 수신자는 허용된 결과만 볼 수 있으며 SQL과 소스 로그인 정보는 숨겨집니다.

귀사 팀, 협력업체 및 파트너 여러분께

Container Logs를 Excel로

실시간 Container Logs 결과를 워크시트로 바로 가져와 필요할 때 새로 고치세요. 데스크톱 Excel, Excel Online, Microsoft 365에서 사용할 수 있습니다.

Excel 살펴보기

Container Logs를 Data Viewer로

동료, 공급업체, 파트너 등 누구와도 실시간 Container Logs 결과를 공유하세요. 북마크할 수 있는 표로 제공되며, 휴대폰, 태블릿, 데스크톱에서 열 때 최신 결과를 다시 가져옵니다. 상대방에게는 결과만 보이고 SQL이나 파일은 보이지 않습니다.

데이터 뷰어 작동 방식

앱 및 시스템용

컨테이너 로그 REST API

Container Logs 쿼리를 인증이 필요한 JSON 엔드포인트로 게시하여 어떤 애플리케이션에서든 호출할 수 있습니다. OpenAPI 3.1 사양과 바로 사용할 수 있는 Postman, Insomnia, Hoppscotch 컬렉션이 제공됩니다. 데이터베이스 포트를 열지 않습니다.

REST API 살펴보기

Container Logs를 Power BI로

생성된 Power Query M을 Power BI 고급 편집기에 붙여넣으면 HTTPS를 통해 실시간 Container Logs 결과를 가져옵니다. ODBC 드라이버도, 데이터베이스 포트를 여는 작업도 필요 없습니다.

Power BI 살펴보기

AI 도구의 경우

Container Logs MCP 서버

AI 어시스턴트에 Container Logs에 대한 읽기 전용 접근 권한과 올바른 SQL 작성에 필요한 스키마를 제공하세요. 채팅에 자격 증명을 넣을 필요가 없습니다.

MCP 살펴보기

사람들에게 전달됨

Container Logs를 나머지 데이터와 조인하세요.

데이터베이스, 비즈니스 API, 파일, 로그를 하나의 읽기 전용 쿼리로 가져오세요. 모든 커넥터에서 페더레이션 쿼리를 지원합니다.

연결과 테이블의 이름을 지정하세요. Query Streams가 소스 쿼리를 처리하고 결과를 결합합니다.

페더레이션 쿼리 살펴보기
소스 간 쿼리 예시
-- 아무것도 복사되지 않았고, 아무것도 병합되지 않았으며, 아무것도 예약되지 않았습니다.
선택   c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
FROM     containerlogs.fileset.orders1 f
JOIN     pg_crm.공개.고객2      c ON c.id = f.customer_id
JOIN     청구.stripe.invoices3      i ON i.customer = c.stripe_id
그룹 기준 c.지역
주문 기준 청구서 발행 DESC;

사용자 연결, 스키마, 테이블 및 열 이름을 사용하세요.

커넥터 제품군 전반에 공통으로 적용됩니다.

모든 로그 커넥터는 다음 항목도 제공합니다.

  • events — 파싱된 각 줄을 한 행으로 제공하며, 타임스탬프, 문법에 지정된 필드, 해당 줄이 들어 있던 파일을 나타내는 _source_file을 포함합니다.
  • events_raw_lines — 문법에 일치하지 않은 줄을 버리지 않고 원문 그대로 보관합니다. 예상하지 못한 형식도 여전히 쿼리로 답을 찾을 수 있습니다.
  • files_current 및 files_events — 현재 파일 목록과 감사 추적 정보입니다. 어떤 파일이 나타났고, 로테이션되었고, 사라졌는지, 또 보류된 항목이 있는지와 파일명 및 사유를 보여 줍니다.
  • 회전을 우회하는 대신 이해합니다 — 이름이 지정된 회전 패턴 10가지와 회전되지 않은 일반 파일을 지원하므로, 어제의 로그와 압축 아카이브도 오늘의 로그와 동일한 테이블로 조회할 수 있습니다.

알아두면 좋겠네요.

  • 읽기 전용이 강제됩니다 — 한 번에 하나의 문장만 실행하며 SELECT와 관련 문장만 허용됩니다. 당사는 로그를 쓰거나, 이동하거나, 회전하거나, 잘라내지 않습니다.
  • 업로드되는 항목은 없습니다 — 에이전트 옆의 사용자 컴퓨터에서 로그 행을 파싱하고 암호화된 상태로 캐시합니다. 쿼리 결과만 네트워크 밖으로 나갑니다.
  • 새 바이트만 읽습니다 — 에이전트는 파일을 다시 읽는 대신 각 파일에서 이전에 읽은 위치부터 계속 처리하므로, 로그가 바쁘게 기록되어도 매일 추가 비용이 발생하지 않습니다.
  • SQL 방언은 DuckDB입니다. 다른 커넥터에서 작성하는 SQL과 동일합니다.

Container Logs 관련 질문

Container Logs 쿼리 결과는 어디에서 사용할 수 있나요?

Container Logs 결과를 Excel, Google Sheets, Data Viewer에서 사용하고, Database REST API를 통해 앱에서, MCP 또는 Nova를 통해 AI 도구에서 사용할 수 있습니다. 저장된 결과는 지원되는 Automation 대상, 보고서 및 알림에도 제공할 수 있습니다. 대상의 이용 가능 여부와 허용량은 요금제에 따라 다릅니다.

Container Logs를 위해 인바운드 포트를 열어야 하나요?

아니요. Container Logs에 연결할 수 있는 컴퓨터에 Network Agent를 설치하세요. 에이전트는 Query Streams에 외부로 연결하므로 인바운드 포트나 VPN이 필요하지 않습니다. 다만 소스는 자체 액세스 규칙에 따라 에이전트 컴퓨터의 연결을 허용해야 합니다.

Container Logs 파일이 업로드되나요?

Network Agent는 파일이 있는 위치에서 파일을 읽고 에이전트 머신에 캐시를 보관합니다. 원본 파일은 업로드되거나 이동되거나 다시 쓰이지 않습니다. 요청된 쿼리 결과만 아웃바운드 암호화 연결을 통해 네트워크 밖으로 전송됩니다.

Container Logs에 연결하려면 무엇이 필요한가요?

폴더: 컨테이너 호스트의 데몬 로그 디렉터리 또는 내보낸 로그가 저장된 폴더입니다. 소스: Docker json-file 로그, 저장된 docker logs 내보내기 파일, Portainer 서버 로그입니다. 식별 정보: 데몬에서 확인한 컨테이너 이름, 이미지, Compose 서비스이므로 행의 키로 64자 ID를 사용하지 않습니다. 로테이션: 데몬의 로테이션을 따라가며, 내보낸 파일에는 이름이 지정된 10가지 로테이션 패턴을 지원합니다.

Container Logs를 연결된 다른 소스와 조인할 수 있나요?

예. 페더레이션 쿼리는 데이터베이스, 비즈니스 API, 파일, 로그를 포함한 모든 커넥터 유형을 지원합니다. 하나의 읽기 전용 쿼리에서 연결과 테이블의 이름을 지정하세요. Query Streams가 필요에 따라 각 소스에 맞게 쿼리를 변환하고 결과를 결합합니다. 페더레이션 쿼리 작동 방식 알아보기.

Docker 로깅 드라이버를 변경해야 하나요?

아니요. JSON 파일 는 Docker의 기본 드라이버이며 지원되는 드라이버입니다. 로깅을 설정한 적이 없다면 파일은 이미 생성되어 있고 형식도 올바릅니다.

다른 드라이버로 변경하셨다면, docker logs --timestamps export는 경로입니다. CLI가 데몬을 통해 읽기 때문에 드라이버와 관계없이 작동합니다.

컨테이너 ID가 아니라 이름을 어떻게 알아내나요?

Docker는 로그 파일과 동일한 폴더에 컨테이너에 대한 자체 기록을 작성합니다. Query Streams는 해당 파일에서 이름을 읽어와 ID 열로 사용하고, 이미지, Compose 프로젝트 및 서비스는 그 옆 열에 유지합니다. 64자 폴더 ID는 그대로 유지됩니다. 컨테이너 ID그러므로 잃는 것은 아무것도 없습니다.

해당 레코드가 없거나, 읽을 수 없거나, 이름이 포함되어 있지 않으면 대신 폴더 이름을 사용하고 스윕에서 그런 경우가 몇 번 발생했는지 집계합니다. 따라서 대체 사용 여부가 조용히 바뀌는 대신 확인할 수 있는 숫자로 표시됩니다.

저는 Windows 또는 Mac용 Docker Desktop을 사용하고 있습니다. 이렇게 하면 작동할까요?

JSON 파일 로그에 직접 접근하는 것은 아닙니다. Docker Desktop은 로그를 자체 가상 머신 내부에 저장하며, 호스트에서 서비스로 실행되는 에이전트는 해당 로그에 접근할 수 없습니다.

해결 방법은 내보내기 프로필을 이용하는 것입니다. docker logs --timestamps <컨테이너> Agent가 읽을 수 있는 어떤 폴더의 파일로든 리디렉션하면 됩니다. 이는 그 자체로 지원되는 형식이지 우회 방법이 아닙니다. 컨테이너가 사라진 뒤에도 로그 사본을 보관하기 위해 사람들이 이미 사용하는 바로 그 방식입니다.

이거 실시간인가요?

스트리밍이 아니라 요청 시 실행됩니다. 쿼리가 실행될 때 파일의 현재 내용이 읽히므로 컨테이너가 새 줄을 기록하고 파일이 검색되면 해당 줄이 나타납니다. 매일 밤 정해진 일정에 실행되는 것도 아니지만, 실시간으로 로그를 따라가는 방식도 아닙니다.

지난 몇 주 동안 모든 컨테이너에 걸쳐 질문을 던지고 그 답을 스프레드시트에 입력하는 데 있어, 이는 통나무 더미를 쌓아두는 것보다 훨씬 효율적이고 기계적인 작업도 덜 필요한 유용한 방식입니다.

쿠버네티스나 포드맨은 어때요?

현재 두 유형 모두 자체 프로필이 없으며, 저희는 이를 암시하기보다는 차라리 그렇게 말하는 편이 낫다고 생각합니다. 다만 적용되는 것은 내보내기 형식입니다. 프로필은 정확한 형태에 맞춰져 있습니다. docker logs --timestamps 를 기록합니다. RFC 3339 나노초 타임스탬프, 공백, 그다음 컨테이너 자체의 한 줄이 서비스당 파일 하나에 기록됩니다. 동일한 형식으로 기록하는 도구는 이 형식으로 읽을 수 있습니다.

자신의 파일에 대한 연결 상태를 확인하는 가장 확실한 방법은 '연결 테스트'를 사용하는 것입니다. 이 테스트는 작업을 시작하기 전에 어떤 파일이 인식되었는지 알려줍니다.

컨테이너 로그가 JSON 형식으로 출력됩니다. 필드들이 컬럼 형태로 출력되는 건가요?

예, json-file 로그에 해당합니다. 데몬의 봉투 구조를 풀고 그 안에 있는 컨테이너 자체의 JSON을 열로 평탄화합니다. level, logger, message, host, service가 있는 경우 해당 값이 열로 표시됩니다. 이름이 지정된 열에 매핑되지 않는 항목은 데이터 삭제되는 대신 열로 유지되므로 특이한 필드도 여전히 조회할 수 있습니다.

컨테이너 JSON에서 가져오지 않는 값은 타임스탬프 하나입니다. 타임스탬프는 데몬에서 가져옵니다. 애플리케이션 자체의 타임스탬프는 형식이 제각각일 수 있고, 잘못 해석하면 행의 시간 위치가 눈에 띄지 않게 어긋나기 때문입니다.

파서가 읽을 수 없는 줄은 어떻게 되나요?

해당 데이터는 삭제되지 않고 유지됩니다. 고정된 형식과 일치하지 않는 행은 이유가 첨부된 원시 행으로 유지되므로, 형식이 잘못된 입력이나 예기치 않은 형식 변경이 발생하더라도 숫자에 공백으로 남지 않고 확인하고 조회할 수 있습니다.

업무가 이루어지는 곳에서 Container Logs를 사용하세요.

Free로 시작하세요. 모든 커넥터 유형, 데이터 소스 2개, Network Agent 1개를 이용할 수 있습니다. 필요에 따라 요금제 이용 한도를 추가하세요.

무료 플랜을 받으세요요금제 이용 한도 보기