nginx, Apache, IIS 새로운
연결하다 웹 서버 로그 엑셀, 스프레드시트 및 AI로
액세스 로그는 이미 테이블 형태입니다. 이제 쿼리를 시작해 보세요. Nginx, Apache, Caddy, IIS는 수십 년 동안 안정적인 형식으로 모든 요청을 디스크에 기록하지만, 실제로 쿼리하는 사람은 거의 없습니다. 로그 폴더에 쿼리 스트림을 지정하면 해당 파일이 SQL 테이블로 변환되어 상태 코드, 응답 시간, 클라이언트 IP, 경로, 사용자 에이전트 등의 정보를 얻을 수 있습니다. 로그 순환 및 .gz 보관소 포함, 중간에 통나무 운송업체 없음.
로그 폴더는 그룹화 및 조인할 수 있는 테이블이 됩니다.
쿼리 스트림은 웹 서버가 이미 작성한 파일을 읽고 형식을 고정하여 형식이 지정된 열을 제공합니다. 서버에 에이전트가 필요 없고, 전송 파이프라인도 필요 없으며, 유지 관리해야 할 인덱스도 없습니다. 또한 파서가 읽을 수 없는 줄은 조용히 삭제되는 대신 이유와 함께 행으로 유지됩니다.
접근 로그캐디
액세스 로그 2.gznginx
u_ex260909.logIIS파일 회전, 압축 아카이브 및 재읽기 파일 처리
선택 길,
세다(*) AS 히트,
둥근(평균(지속 시간(초) * 1000) AS ms
FROM 파일셋.이벤트
어디 상태 >= 500
그룹 기준 길
주문 기준 히트 DESC동일한 쿼리에서 애플리케이션 데이터베이스에 조인하세요.
서버가 이미 기록하는 파일들을 이제 표 형식으로 보고할 수 있습니다.
서버 4개, 형식 4개, 설정 불필요
각 카드에는 Query Streams가 해당 서버에서 읽는 정확한 파일 이름과 해당 파일의 위치가 표시됩니다. 이 기능을 사용하기 위해 로깅 구성을 변경할 필요는 없으며, 기본 형식이 지원되는 형식입니다.
지원되는 웹 서버 로그
4가지 형식 · 4개의 서버
nginx접근 및 오류
접근 로그기본 결합 형식오류.log레벨, PID, 연결 및 메시지- 대개
/var/log/nginx - 부록; 번호가 매겨진 회전이 이어집니다.
Apache HTTP 서버액세스
액세스 로그결합 및 공통 형식- 하나의 파서로 Apache와 Nginx를 모두 처리할 수 있습니다. 접근 형식은 동일합니다.
/var/log/apache2, 또는httpdRHEL에서- 부록; 번호가 매겨진 회전이 이어집니다.
캐디Caddy 2 JSON
접근 로그요청당 하나의 JSON 객체- TLS 서버 이름, 버전 및 세션 재개 기능이 포함되어 있습니다.
- 응답 시간(마이크로초 단위)
- 롤스 투
액세스-<타임스탬프>.log.gz각 구성원은 한 번씩 읽었습니다.
Microsoft IISW3C 확장
u_ex*.logW3C 확장 형식- 그만큼
#전지:헤더가 열을 결정하므로 필드 선택이 적용됩니다. C:\inetpub\logs\LogFiles\W3SVC<사이트>- 매일 새로운 날짜가 지정된 파일이 생성되며, 파일 이름은 변경되지 않습니다.
에이전트 릴리스마다 새로운 웹 서버 및 프록시 로그 형식이 추가됩니다. 에이전트는 자체적으로 최신 상태를 유지하므로, 나중에 추가된 형식은 서버를 수정하지 않아도 커넥터에 표시됩니다.
모든 엣지에서의 액세스 로그, 그들이 어디에 착륙하는지 읽어보세요
요청이 항상 같은 대륙에 두 번 도달하는 것은 아닙니다. 엣지 서버는 한 지역에 있고, 오리진 서버는 다른 지역에 있으며, 사무실에는 더 오래된 시스템이 실행되고 있습니다. 각 위치에서는 네트워크 에이전트가 실행되어 요청이 도착하는 로그 파일을 읽고 쿼리 스트림으로 전화를 겁니다. 방화벽 입장에서는 이는 일반적인 아웃바운드 연결이므로, 열어야 할 포트도 없고, VPN을 구축해야 할 필요도 없고, 로그 전송 서버를 유지해야 할 필요도 없습니다.
.gz 아카이브
전화를 걸다
세 개의 외부 연결을 한 곳에서 조회할 수 있습니다. 인바운드 포트, VPN, 방화벽 변경은 필요 없습니다.
지역당 담당자 1명
에이전트는 단일 로그 파일이 아닌 전체 위치를 관리하며, 하나의 위치 내에서 여러 호스트로 구성된 폴더 트리는 단일 커넥터가 됩니다. 각 행은 해당 위치의 정보를 담고 있습니다. 대지무료 티어에서는 에이전트 한 명이 운영되고, 상위 티어에서는 더 많은 에이전트가 운영됩니다.
1개 지역 = 1개 에이전트 = 여러 호스트
열 내용이 없습니다
에이전트는 암호화된 아웃바운드 연결을 하나만 생성하며, 요청과 응답 모두 해당 연결을 통해 전송됩니다. 인바운드 포트도, VPN도, 방화벽 설정 변경도 필요 없으며, 로그가 제3자에게 전달되는 일도 없습니다.
하나의 연결, 양방향
여러 지역에 걸친 단일 쿼리
모든 출처 연합 쿼리 자체 에이전트 이름을 지정하므로 단일 명령으로 한 지역의 엣지를 다른 지역의 오리진 옆에 배치하거나 둘 중 하나를 애플리케이션 데이터베이스에 조인할 수 있습니다. Business 및 Enterprise 버전에 포함되어 있습니다.
2개 지역 → 1개 결과 집합
그들은 최신 정보를 계속 습득합니다.
에이전트는 자체적으로 업데이트되므로, 이후 릴리스에 추가된 로그 형식은 별도의 배포 없이 모든 지역에 적용됩니다. 따라서 위의 목록은 고정된 목록이 아니라 시작점에 불과합니다.
에이전트와 함께 새로운 형식들이 등장합니다.
회전 기능 때문에 이것은 단순한 CSV 가져오기가 아닙니다.
웹 로그는 가만히 있지 않습니다. 로그는 순환되고, 이름이 바뀌고, 압축되고, 다시 생성되는 등 끊임없이 변화합니다. 이러한 과정을 누락 없이, 그리고 같은 줄이 두 번 계산되지 않도록 정확하게 처리하는 것이 대부분의 작업입니다.
번호가 매겨진 회전
기존의 logrotate 방식은 오늘의 파일은 이름을 유지하고 어제의 파일은 숫자가 하나씩 내려가는 방식입니다. 하지만 Query Streams는 파일이 아닌 콘텐츠를 기준으로 이름을 변경합니다.
access.log → access.log.1 → access.log.2.gz
날짜가 표시된 파일 이름
IIS는 파일 이름을 변경하지 않습니다. 매일 날짜가 포함된 새 파일을 엽니다. 기존 파일은 원래 이름 그대로 유지되므로 한 번 읽고 나면 더 이상 변경되지 않습니다.
u_ex260909.log · u_ex260910.log
압축 아카이브
순환된 로그는 일반적으로 gzip으로 압축됩니다. Query Streams는 다음을 읽습니다. .gz 구성품은 제자리에 있습니다. 압축을 풀거나 다른 곳으로 옮길 필요가 없습니다.
access-2026-09-08T03-00-00.000.log.gz
아무것도 두 번 계산되지 않습니다
각 파일은 처음 4KB로 식별되는 고유한 특징을 가지고 있어, 파일 이름이 변경되더라도 동일한 파일로 인식됩니다. 롤링 복제 기능은 쓰기 작업이 파일의 끝부분을 다시 재생할 때 발생하는 중복을 감지합니다.
4KB 접두사 해시 · 20,000개 레코드 윈도우
실제로 얻게 되는 열
단순히 타임스탬프가 붙어 있는 텍스트 덩어리가 아닙니다. 각 형식은 직접 필터링, 그룹화 및 집계할 수 있는 유형별 열로 파싱됩니다.
각 행에는 또한 다음이 포함됩니다. 이벤트 시간 그리고 대지따라서 하나의 쿼리가 여러 호스트에 걸쳐 실행될 수 있으며, 해당 쿼리가 어디에서 왔는지에 대해서는 절대 의심할 여지가 없습니다.
웹 서버 로그 데이터가 저장될 수 있는 위치
로그 파일은 더 이상 활용되지 않는 막다른 길이 아닙니다. 폴더를 한 번만 연결하면 동일한 읽기 전용 연결을 통해 Query Streams가 지원하는 모든 표면에 데이터를 제공할 수 있습니다. 별도의 설정이나 데이터 복사본이 필요 없으며, 데이터베이스 커넥터와 동일한 방식으로 처리됩니다.
웹 서버 로그를 엑셀에 저장
마이크로소프트 엑셀 · 엑셀 추가 기능
웹 서버 로그 결과를 실시간으로 워크시트에 바로 가져오고 필요에 따라 새로 고칠 수 있습니다. (데스크톱 Excel, Excel Online, Microsoft 365 지원)
엑셀 작동 방식
웹 서버 로그를 Google Sheets에 기록
스프레드시트 추가 기능
사이드바에서 저장된 웹 서버 로그 쿼리를 실행하고 결과를 시트에 드래그 앤 드롭하세요. 공동 작업자는 직접 시트를 새로 고칠 수 있습니다.
Google Sheets 작동 방식
웹 서버 로그 MCP 서버
Claude, Cursor 및 MCP 클라이언트 · MCP 서버
AI 비서에게 올바른 SQL 쿼리를 작성하는 데 필요한 스키마가 포함된 웹 서버 로그에 대한 읽기 전용 액세스 권한을 부여하세요. 채팅에서 자격 증명을 입력할 필요는 없습니다.
MCP 작동 방식
웹 서버 로그 REST API
HTTP 엔드포인트
인증된 JSON 엔드포인트 형태로 웹 서버 로그 쿼리를 게시하여 모든 애플리케이션에서 호출할 수 있도록 합니다. OpenAPI 3.1 사양을 준수하며 Postman, Insomnia, Hoppscotch 컬렉션을 바로 사용할 수 있습니다. 데이터베이스 포트는 열지 않습니다.
REST API 작동 방식
웹 서버 로그를 Airtable에 기록
자동화 플랫폼
웹 서버 로그 행을 예약된 시간에 Airtable 데이터베이스에 동기화하거나 Airtable 자동화 스크립트 내에서 가져올 수 있습니다.
Airtable 작동 방식
웹 서버 로그를 Baserow에 기록합니다.
자동화 플랫폼
웹 서버 로그에서 Baserow 테이블로 데이터를 REST 엔드포인트를 통해 전송합니다. (자체 호스팅 또는 Baserow 클라우드 환경 모두 해당)
Baserow의 작동 방식
웹 서버 로그가 SeaTable에 기록됩니다.
자동화 플랫폼
파일을 내보내거나 데이터베이스를 노출하지 않고 웹 서버 로그 데이터를 사용하여 SeaTable 데이터베이스를 최신 상태로 유지하세요.
SeaTable 작동 방식
웹 서버 로그가 Smartsheet에 기록됩니다.
자동화 플랫폼
웹 서버 로그 결과를 스마트시트 그리드에 추가하여 계획 및 보고서가 지난주 내보내기가 아닌 원본 시스템의 데이터를 읽도록 합니다.
Smartsheet 작동 방식
웹 서버 로그를 Anvil에 기록합니다.
앤빌 웍스 · 앱 플랫폼
Anvil Python 앱을 웹 서버 로그를 사용하여 백업할 때 앱에 데이터베이스 자격 증명을 직접 포함하는 대신 REST 엔드포인트를 이용합니다.
Anvil의 작동 방식
웹 서버 로그를 Power BI로 전송
파워 쿼리 M
생성된 Power Query M을 Power BI 고급 편집기에 붙여넣으면 보고서가 HTTPS를 통해 실시간 웹 서버 로그 결과를 읽어옵니다. ODBC 드라이버나 데이터베이스 포트를 열 필요가 없습니다.
Power BI 작동 방식
웹 서버 로그 경고 및 보고서
슬랙 · 디스코드 · 이메일 · 웹훅
웹 서버 로그 쿼리를 예약하고 결과를 Slack, Discord, 이메일 또는 서명된 웹훅으로 전송하거나, 설정한 행 수, 임계값 또는 백분율 변화 기준치를 초과할 때까지 메시지 전송을 보류할 수 있습니다.
알림 및 보고서 작동 방식우리가 의도적으로 읽지 않는 것
운영 환경 액세스 로그에는 보고서 표에 포함하기에는 너무 많은 정보가 담겨 있을 수 있습니다. Caddy의 JSON 형식은 전체 요청 및 응답 헤더 맵을 기록하며, 여기에는 일반적으로 세션 쿠키와 베어러 토큰이 포함됩니다. Caddy 프로필은 이러한 정보를 제외합니다. 요청 헤더 그리고 resp_headers 선언을 통해 처리되며, 따로 설정해야 하는 필터나 사후 처리 방식이 아닙니다. 해당 필드들은 절대 파싱되지 않으므로 테이블, 내보내기 파일 또는 스프레드시트에 포함되지 않습니다.
나머지 설계도 동일한 원칙을 따릅니다. 에이전트는 외부 연결을 통해 파일을 읽습니다. 웹 서버에는 아무것도 설치되지 않고, 아무것도 기록되지 않으며, 접근은 읽기 전용입니다.
작동 방식
세 단계만 거치면 웹 서버에 아무것도 설치되지 않습니다.
로그 폴더를 가리키세요
쿼리 스트림 에이전트에게 서버가 이미 로그를 기록하는 폴더에 대한 읽기 권한을 부여하세요. /var/log/nginx, /var/log/caddyIIS 로그 파일 디렉터리 또는 동기화하는 공유 폴더입니다.
형식을 인식합니다
쿼리 스트림은 파일 이름이 아닌 행의 내용에서 형식을 식별합니다. 따라서 파일 이름이 이상하더라도 파일을 읽을 수 있으며, 고정된 형식과 일치하지 않는 파일은 테이블을 손상시키는 대신 이유와 함께 보류됩니다.
쿼리하거나 참여하세요
포털에서 SQL을 실행하고, 결과를 Microsoft Excel이나 Google Sheets에 바로 표시하거나, 통합 쿼리를 사용하여 요청 로그를 애플리케이션 데이터베이스의 사용자 및 주문과 결합할 수 있습니다. 이 모든 작업을 하나의 명령으로 처리할 수 있습니다.
웹 서버 로그 FAQ
로깅 설정을 변경해야 하나요?
아니요. 지원되는 각 형식은 해당 서버의 기본 형식입니다. Nginx와 Apache의 경우 통합 액세스 로그, Caddy 2의 경우 JSON 액세스 로그, IIS의 경우 W3C 확장 형식입니다. 로그 형식을 변경한 적이 없다면 이미 지원되는 형식을 사용하고 있는 것입니다.
IIS는 유연한 경우이며, 적절하게 처리됩니다. #전지: W3C 파일 맨 위에 있는 지시문은 열 이름을 지정하므로 IIS 관리자에서 선택한 필드가 해당 열로 표시됩니다.
이거 실시간인가요?
이는 스트리밍 방식이 아닌 주문형 방식입니다. 쿼리 스트림은 쿼리를 실행할 때 디스크에 있는 파일을 읽어오므로, 새 요청은 서버에서 파일을 기록하고 가져오는 즉시 표시됩니다. 즉, 고정된 야간 일정에 따라 업데이트되는 것도 아니고, 실시간 스트리밍 방식도 아닙니다.
요청 발생 즉시 1초 이내의 빠른 알림이 필요한 경우 로그 파이프라인이 적합한 도구입니다. 하지만 최근 몇 주간의 트래픽 데이터를 분석하여 스프레드시트로 답변을 얻고자 하는 경우에는 훨씬 간단한 방식이면 충분합니다.
회전 및 압축된 로그는 어떻게 되나요?
이 파일들은 읽힙니다. Query Streams는 이러한 서버에서 사용하는 세 가지 순환 방식(logrotate의 번호 매기기 셔플, IIS의 매일 새 파일 순환, Caddy의 타임스탬프 순환)을 이해하고 읽습니다. .gz 압축을 풀지 않아도 아카이브 파일이 제자리에 저장됩니다.
파일은 이름이 아닌 처음 4KB의 해시 값으로 매칭되므로, 순환된 파일은 이미 존재하는 파일로 인식됩니다. 이것이 순환 과정에서 하루가 손실되거나 중복 계산되는 것을 방지하는 원리입니다.
내 로그는 여러 서버에 분산되어 있습니다. 이 로그들을 한꺼번에 조회할 수 있을까요?
네. 각 행마다 하나씩 있습니다. 대지 열을 기준으로 검색할 수 있으므로 하나의 쿼리로 여러 호스트를 처리하고 원하는 기준으로 그룹화할 수 있습니다. 환경별 또는 지역별로 에이전트를 배포할 수 있으며, 모든 에이전트는 동일한 목록에 폴더를 표시합니다.
일반 SQL이기 때문에 더 나아가 요청 로그를 실제 데이터베이스와 조인할 수 있습니다. 예를 들어 500 응답 수의 급증을 배포 테이블과 비교하거나 느린 결제 요청을 해당 주문과 대조할 수 있습니다.
쿠키나 인증 헤더를 읽나요?
아니요. Caddy의 JSON 형식은 네 가지 형식 중 유일하게 헤더 맵을 기록하는 형식이며, 프로필은 이를 제외합니다. 요청 헤더 그리고 resp_headers 선언상 헤더가 없으므로 열로 파싱되지 않습니다. 결합형, 오류형 및 W3C 형식에는 애초에 헤더가 포함되어 있지 않습니다.
클라이언트 IP 주소와 사용자 에이전트는 액세스 로그의 핵심 정보이므로 분석됩니다. 따라서 생성된 표는 원본 로그 파일과 동일한 주의를 기울여 처리해야 합니다.
파서가 읽을 수 없는 줄은 어떻게 되나요?
해당 데이터는 삭제되지 않고 유지됩니다. 고정된 형식과 일치하지 않는 행은 이유가 첨부된 원시 행으로 유지되므로, 형식이 잘못된 입력이나 예기치 않은 형식 변경이 발생하더라도 숫자에 공백으로 남지 않고 확인하고 조회할 수 있습니다.
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish