도커 & 포테이너 새로운

연결하다 컨테이너 로그 엑셀, 스프레드시트 및 AI로

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

아니요. json-file은 Docker의 기본 드라이버이며 지원되는 드라이버입니다. 로깅을 구성한 적이 없다면 파일은 이미 존재하며 올바른 형식으로 되어 있습니다. 다른 드라이버로 변경했다면 `docker logs --timestamps export` 명령어를 사용하면 됩니다. CLI는 데몬을 통해 로그를 읽기 때문에 드라이버 종류와 관계없이 작동합니다.

Q: 컨테이너의 ID뿐만 아니라 이름까지 어떻게 아는 걸까요?

Docker는 로그 파일과 동일한 폴더에 컨테이너에 대한 자체 기록을 저장합니다. Query Streams는 해당 파일에서 컨테이너 이름을 읽어와 ID 열로 사용하고, 이미지, Compose 프로젝트 및 서비스는 그 옆에 열로 유지합니다. 64자리의 폴더 ID는 container_id로 유지되므로 데이터 손실은 없습니다. 해당 기록이 없거나 읽을 수 없거나 이름이 없는 경우 폴더 이름이 대신 사용되며, 이러한 현상이 발생한 빈도를 집계합니다. 따라서 대체는 눈에 띄지 않는 대체가 아니라 확인할 수 있는 숫자로 표시됩니다.

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

JSON 파일 로그 자체를 직접적으로 공격하는 것은 아닙니다. Docker Desktop은 로그를 자체 가상 머신 내부에 저장하며, 호스트에서 서비스로 실행되는 에이전트는 해당 로그에 접근할 수 없습니다. 접근 방법은 `docker logs --timestamps` 명령어를 사용하여 로그를 내보내고, 에이전트가 읽을 수 있는 폴더에 파일로 저장하는 것입니다. 이는 그 자체로 지원되는 형식이며, 임시방편이 아닙니다. 컨테이너가 종료된 후에도 로그 사본을 보관하기 위해 이미 많은 사람들이 사용하고 있는 방식입니다.

Q: 이거 실시간인가요?

이는 스트리밍 방식이 아니라 온디맨드 방식입니다. 쿼리가 실행되는 시점에 파일이 생성되는 대로 읽어오기 때문에 컨테이너에서 새 줄이 기록되고 파일이 로드될 때마다 새로운 줄이 나타납니다. 고정된 야간 스케줄에 따라 기록되는 것도 아니고, 실시간 로그를 제공하는 것도 아닙니다. 모든 컨테이너에 걸쳐 지난 몇 주간의 데이터를 조회하고 그 결과를 스프레드시트로 가져오는 데에는 이러한 방식이 유용하며, 로그 스택 방식보다 훨씬 간편합니다.

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

현재 두 서비스 모두 자체 프로필이 없으며, 지원한다고 암시하기보다는 그렇게 밝히는 것이 낫다고 생각합니다. 적용되는 것은 내보내기 형식입니다. 프로필은 `docker logs --timestamps` 명령으로 기록되는 파일의 정확한 형식에 맞춰져 있습니다. 이 형식은 RFC 3339 나노초 타임스탬프, 공백, 그리고 컨테이너 자체의 줄이 뒤따르며, 서비스당 하나의 파일이 생성됩니다. 동일한 형식으로 기록하는 도구는 동일한 형식으로 읽습니다. 자신의 파일에 대한 형식을 확인하는 가장 확실한 방법은 연결 테스트를 실행하는 것입니다. 이 테스트는 작업을 시작하기 전에 어떤 형식을 인식했는지 보고합니다.

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

네, JSON 파일 로그의 경우 그렇습니다. 데몬의 엔벨로프가 압축 해제되고 그 안에 있는 컨테이너 자체의 JSON 데이터가 레벨, 로거, 메시지, 호스트, 서비스(해당되는 경우)와 같은 열로 평면화됩니다. 명명된 열에 매핑되지 않는 모든 데이터는 버려지지 않고 데이터 열에 유지되므로 특이한 필드도 쿼리할 수 있습니다. 컨테이너의 JSON에서 가져오지 않는 유일한 항목은 타임스탬프입니다. 타임스탬프는 데몬에서 가져오는데, 애플리케이션 자체의 타임스탬프 형식이 다양할 수 있고, 형식이 잘못되면 해당 행의 시간 위치가 오류 없이 잘못 표시되기 때문입니다.

Docker는 모든 컨테이너에 대한 로그를 기록합니다. 따라서 모든 로그를 한 번에 조회할 수 있습니다. JSON 파일에는 데몬이 기록하는 로그와 도커 로그 수동으로 저장한 내보내기 파일과 Portainer 자체 서버 로그를 참조하세요. 폴더를 대상으로 쿼리 스트림을 지정하면 모든 줄이 컨테이너의 실제 이름, 이미지 및 Compose 서비스를 포함하는 행으로 변환됩니다. 64자 ID로 가득 찬 디렉터리 대신 이러한 정보가 표시됩니다.

무료로 시작하세요 11개 목적지

1연결

0입국항

읽기 전용강제된

3가지 컨테이너 로그 형식 도커 · 포테이너 컨테이너, 이미지 및 서비스로 명명됨 읽기 전용 · 컨테이너에 아무것도 설치되어 있지 않음

핵심 아이디어

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

쿼리 스트림은 데몬이 이미 작성한 파일을 읽고 형식을 고정한 다음, 각 행 옆에 컨테이너 이름이 표시된 형식화된 열을 제공합니다. 사이드카도, 전송 파이프라인도, 유지 관리해야 할 인덱스도 필요 없습니다. 또한 파서가 읽을 수 없는 행은 조용히 삭제되는 대신 이유와 함께 행으로 유지됩니다.

로그 폴더호스트에서

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가지 도구

도커JSON 파일 로깅 드라이버

하나 {"로그","스트림","시간"} 데몬이 작성한 줄별 봉투
컨테이너 이름은 Docker 자체에서 가져온 것입니다. config.v2.json 통나무 옆
이미지 및 구성 프로젝트/서비스는 칼럼 형식으로 함께 제공됩니다.
대개 /var/lib/docker/containers
부록; 번호가 매겨진 회전 및 .gz 뒤따랐다

도커Docker 로그 내보내기

저장한 파일 docker logs --timestamps
RFC 3339 나노초 스탬프, 그리고 컨테이너 자체 라인
컨테이너 배너 라인은 우연이 아니라 선언에 따라 건너뛰어집니다.
내보내기 파일을 저장하는 폴더
서비스당 하나의 파일이며, 파일 이름은 파일 이름의 어근에서 따왔습니다.

포르테이너서버 로그, 제로로그 콘솔

포테이너.log 또는 컨테이너 자체의 출력
ANSI 색상 코드는 파싱 전에 제거되므로 레벨은 레벨입니다.
그만큼 키=값 꼬리는 기둥이 되고, 나머지는 다음과 같이 됩니다. 데이터
내장 터널 서버의 다양한 형태의 회선도 읽힙니다.
분 단위의 스탬프, UTC로 읽음

더 많은 정보 제공이것은 시작일 뿐, 한계가 아닙니다.

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

세 가지 파서 모두 실제 컨테이너 로그(JSON 파일 로그, 대용량 로그 등)를 기반으로 구축 및 테스트되었습니다. 도커 로그 Swarm 호스트에서 내보낸 로그와 Portainer CE 2.39.1 서버 로그입니다. 미리 알아두어야 할 점은 Windows 및 Mac용 Docker Desktop에서 JSON 파일 로그는 가상 머신 내부에 저장되므로 서비스로 실행되는 에이전트는 해당 로그에 접근할 수 없다는 것입니다. 로그를 내보내려면 다음 명령어를 사용하십시오. docker logs --timestamps 두 번째 프로필을 사용하세요.

어디에서든 작동합니다

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

컨테이너는 대개 한 곳에서 모두 실행되지 않습니다. 사무실의 호스트, 한 클라우드 지역의 Swarm 클러스터, 또는 다른 국가의 단일 서버 등 다양한 위치에서 실행될 수 있습니다. 각 위치에서는 네트워크 에이전트가 실행되어 기존 로그 파일을 읽고 쿼리 스트림으로 연결합니다. 방화벽 입장에서는 일반적인 아웃바운드 연결로 간주되므로, 별도로 열거나 VPN을 구축할 필요가 없습니다.

본점 로컬 디스크에 설치된 Docker 호스트의 JSON 파일 로그는 데몬 폴더 아래에 저장됩니다. 전화를 걸다

eu-서쪽 스웜 클러스터, 하나 도커 로그 서비스별 수출 전화를 걸다

미국 동부 Portainer는 몇 개의 호스트를 관리하며 자체 서버 로그를 함께 제공합니다. 전화를 걸다

세 개의 외부 연결을 한 곳에서 조회할 수 있습니다. 인바운드 포트, VPN, 방화벽 변경은 필요 없습니다.

지역당 담당자 1명

에이전트는 단일 폴더가 아닌 사이트 전체를 관리합니다. 원하는 각 로그 형식은 해당 에이전트에서 각각 별도의 파일 세트 커넥터로 사용됩니다. 일반적으로 위치당 하나의 에이전트가 사용됩니다. 무료 등급에서는 에이전트가 하나만 실행되고, 상위 등급에서는 더 많은 에이전트가 실행됩니다.

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

열 내용이 없습니다

에이전트는 암호화된 아웃바운드 연결을 하나만 생성하며, 요청과 응답 모두 해당 연결을 통해 전송됩니다. 인바운드 포트도, VPN도, 방화벽 설정 변경도 필요 없으며, 자격 증명은 네트워크 내부에 안전하게 보관됩니다.

하나의 연결, 양방향

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

모든 출처 연합 쿼리 자체 에이전트를 지정하므로 단일 명령으로 한 국가의 로그와 다른 국가의 로그를 읽어 하나의 결과를 반환하거나 두 로그를 데이터베이스에 결합할 수 있습니다. 비즈니스 및 엔터프라이즈 버전에 포함되어 있습니다.

2개 국가 → 1개 결과 세트

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

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

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

어려운 부분

이름, 시계 및 색상 코드

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

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

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

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

악마의 시계

컨테이너가 에포크 초 단위로 자체 타임스탬프를 출력하면, 그 내용이 사실이라면 1970년에 도달하게 됩니다. 이벤트 시간은 데몬이 캡처한 시간이며, 컨테이너 자체의 타임스탬프는 신뢰할 수 있는 값이 아니라 별도의 열로 저장됩니다.

봉투 시간 → 이벤트 시간

파일 내 색상 코드

콘솔 로거는 터미널 이스케이프 시퀀스를 로그에 그대로 기록합니다. 파싱 전에 이스케이프 시퀀스가 제거되므로 레벨은 이스케이프 문자로 감싸진 레벨이 아니라 레벨 자체로 읽히며, 원래 바이트는 그대로 유지됩니다.

이스케이프 코드 제거됨 → 레벨 = 무한대

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

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

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

스키마

실제로 얻게 되는 열

단순히 타임스탬프가 붙어 있는 텍스트 덩어리가 아닙니다. 각 형식은 필터링, 그룹화 및 집계가 직접 가능한 유형별 열로 파싱되며, 컨테이너가 구조화된 JSON을 로깅하는 경우 해당 컨테이너의 필드도 열로 풀립니다.

JSON 파일 컨테이너 로그도커 데몬

개울수준나무꾼메시지주인서비스데이터

Docker 로그 내보내기Docker CLI

메시지

제로로그 콘솔 로그포르테이너

수준방문객메시지오류데이터

각 행에는 또한 다음이 포함됩니다. 이벤트 시간읽어온 원본 스탬프와 해당 스탬프가 나온 파일 정보가 포함됩니다. 각 형식은 고유 식별 열을 추가합니다. 앱 json-file 및 Portainer의 경우, 컨테이너 내보내기의 경우 — 그리고 JSON 파일의 행에는 추가 정보가 포함됩니다. 영상, compose_project, compose_service 그리고 컨테이너 ID싱글 메시지 수출 컨테이너의 해당 열은 의도적인 것입니다. 컨테이너 자체의 라인은 추측에 의존하지 않고 그대로 유지됩니다.

파워 쿼리 M

생성된 Power Query M을 Power BI 고급 편집기에 붙여넣으면 보고서가 HTTPS를 통해 실시간 컨테이너 로그 결과를 읽어옵니다. ODBC 드라이버도 필요 없고 데이터베이스 포트도 열 필요가 없습니다.

Power BI 작동 방식

지원됨

컨테이너 로그 경고 및 보고서

슬랙 · 디스코드 · 이메일 · 웹훅

컨테이너 로그 쿼리를 예약하고 결과를 Slack, Discord, 이메일 또는 서명된 웹훅으로 전송하거나, 설정한 행 수, 임계값 또는 백분율 변화 기준선을 넘을 때까지 메시지 전송을 보류할 수 있습니다.

알림 및 보고서 작동 방식

컨테이너 관련해서는 알림 카드를 다시 한번 살펴보는 것이 좋습니다. 오류 횟수에 대한 예약된 쿼리는 터미널을 계속 보고 있을 필요가 없으므로 재시작 루프가 발생하면 Slack에 자동으로 알림이 전송됩니다. 로그 관련 단계별 가이드는 아직 작성되지 않았으며, 링크된 페이지에서 각 기능의 작동 방식을 확인할 수 있습니다.

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

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

컨테이너의 출력은 자유 형식이며, 이로 인해 다음과 같은 결과가 발생합니다. 애플리케이션에서 출력하는 내용이 그대로 테이블에 저장됩니다. 예를 들어 토큰이나 고객 이메일을 로그에 기록하는 경우, 해당 문자열은 이미 로그 파일에 있으므로 해당 열에도 저장됩니다. 웹 서버 로그처럼 헤더 맵을 사용하여 제외할 수 있는 기능이 없으므로, 생성된 테이블을 로그 파일과 동일하게 주의해서 다루어야 합니다.

두 개의 작은 제한 사항이 숨겨져 있는 것이 아니라 명시되어 있습니다. 도커 로그 컨테이너 자체의 라인은 하나로 온전히 유지된 채 수출됩니다. 메시지 컬럼의 경우, 해당 내부 행을 자체 형식으로 다시 구문 분석하는 기능은 아직 구축되지 않았습니다. 또한 Docker가 로깅 태그에 첨부할 수 있는 선택적 속성은 형태만으로 인식됩니다. 캡처된 코퍼스의 컨테이너 중 어느 것도 해당 속성을 사용하지 않았으므로 해당 경로는 선언된 것일 뿐 입증된 것은 아닙니다.

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

작동 방식

세 단계만 거치면 컨테이너에 아무것도 설치되지 않습니다.

로그 폴더를 가리키세요

Query Streams 에이전트에게 로그가 이미 저장된 위치에 대한 읽기 권한을 부여하세요. /var/lib/docker/containers Docker 호스트, 저장된 내보내기 폴더 또는 내보내기 파일을 모아둔 공유 폴더.

형식을 인식합니다

쿼리 스트림은 파일 이름이 아닌 행의 내용에서 형식을 식별합니다. 따라서 이름이 변경된 복사본도 계속 읽을 수 있으며, 고정된 형식과 일치하지 않는 파일은 테이블을 손상시키는 대신 이유와 함께 보류됩니다.

쿼리하거나 참여하세요

포털에서 SQL을 실행하고, 결과를 Microsoft Excel 또는 Google Sheets에 바로 표시하거나, 통합 쿼리를 사용하여 컨테이너 로그를 애플리케이션 데이터베이스의 사용자 및 주문과 결합할 수 있습니다. 이 모든 작업을 하나의 명령으로 처리할 수 있습니다.

컨테이너 로그 FAQ

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 <컨테이너> 에이전트가 읽을 수 있는 모든 폴더의 파일로 리디렉션됩니다. 이는 임시방편이 아니라 그 자체로 지원되는 형식이며, 컨테이너가 사라진 후에도 로그 사본을 보관하기 위해 사람들이 이미 사용하고 있는 방식과 동일합니다.

이거 실시간인가요?

스트리밍 방식이 아니라 온디맨드 방식입니다. 쿼리가 실행되는 시점에 파일이 생성되므로 컨테이너가 새 줄을 작성하고 파일을 가져오는 즉시 새 줄이 나타납니다. 고정된 야간 일정에 따라 업데이트되는 것도 아니고, 실시간으로 파일을 가져오는 방식도 아닙니다.

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

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

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

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

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

네, JSON 파일 로그의 경우 그렇습니다. 데몬의 봉투가 압축 해제되고 그 안에 있는 컨테이너 자체의 JSON은 레벨, 로거, 메시지, 호스트 및 서비스(해당되는 경우)와 같은 열로 평면화됩니다. 명명된 열에 매핑되지 않는 모든 내용은 별도의 열에 저장됩니다. 데이터 삭제되는 대신 열로 유지되므로 특이한 필드도 여전히 조회할 수 있습니다.

컨테이너의 JSON에서 가져오지 않는 유일한 항목은 타임스탬프입니다. 이는 데몬에서 가져오는데, 애플리케이션 자체의 타임스탬프는 형식이 다양할 수 있고, 잘못될 경우 해당 행의 시간 위치가 오류 없이 잘못 표시될 수 있기 때문입니다.

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

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

컨테이너들이 이미 서로 소통하고 있습니다.

로그 폴더를 연결하고 몇 분 안에 첫 번째 쿼리를 실행해 보세요. 무료 티어이며, 신용 카드 정보가 필요 없고, 컨테이너에 아무것도 설치하지 않아도 됩니다.

무료로 시작하기 모든 커넥터 보기

읽기 전용 · 외부 연결 전용 · 로그는 호스트에 저장됩니다