syslog 및 journald

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

두 RFC 형식의 syslog와 텍스트로 내보낸 systemd 저널을 지원합니다. 각 줄은 호스트, 프로그램, 프로세스 ID를 포함하는 행이 되므로 SSH 세션 네 번과 grep으로 처리하던 질문을 하나의 문장으로 해결할 수 있습니다.

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

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

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

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

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

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

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

Query Streams는 syslog 파일을 Microsoft Excel, Google Sheets, MCP를 통한 AI 어시스턴트, REST API 및 Power BI에서 읽을 수 있는 실시간 SQL 테이블로 바꿉니다. 두 syslog RFC를 모두 지원하며, 텍스트로 내보낸 systemd 저널도 지원합니다. 각 행에는 해당 로그가 나온 호스트, 로그를 작성한 프로그램, 프로세스 ID가 포함됩니다. 여러 시스템의 로그를 모으는 폴더를 커넥터에 지정하면 쿼리 하나로 모든 로그에 답을 얻을 수 있습니다. 중앙 로그 서버를 운영할 필요도, 기가바이트별 수집 요금을 낼 필요도 없으며, 쿼리 결과 외에는 아무것도 업로드되지 않습니다.

  • 두 syslog RFC 모두 지원
  • 호스트, 프로그램, PID를 열로 제공
  • 중앙 로그 서버가 필요하지 않음

적절한 설정으로 System Logs를 연결하세요.

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

접는 사람
컴퓨터의 로그 디렉터리 또는 로그를 모아 두는 폴더입니다. 로컬 디스크나 `\\server\share` 형식의 네트워크 공유를 입력하세요(매핑된 드라이브 문자는 사용하지 마세요. Linux 또는 Mac에서는 먼저 마운트해야 합니다). 하위 폴더도 포함됩니다.
형식
두 RFC 형식의 syslog와 텍스트로 내보낸 systemd 저널
연도 처리
로그 줄에서 가져오거나 파일의 수정 시간 또는 파일 이름에서 추론합니다. 행마다 추측하는 것이 아니라 한 번 선택합니다.
로테이션
이름이 지정된 10가지 로테이션 패턴과 로테이션되지 않은 일반 파일을 지원합니다. 압축 아카이브도 그대로 읽습니다.
형식이 일치하지 않는 줄
events_raw_lines에 원문 그대로 보존되며, 삭제되지 않습니다.
자격 증명
없습니다. 서버가 없으며 에이전트가 파일이 있는 위치에서 파일을 읽습니다.
SQL 방언
DuckDB - 표준 SQL을 사용하므로 syslog 전용으로 배울 내용이 없습니다.

실시간 Windows Event Log를 읽는 것은 별개의 문제입니다. 줄이 모인 폴더가 아니라 구조화된 채널이므로 별도의 커넥터가 필요합니다. 하지만 이미 해당 이벤트를 일정에 따라 텍스트나 CSV로 내보내고 있다면, 지금도 그 폴더를 읽을 수 있습니다. Custom Logs 커넥터에서 레이아웃을 한 번 설명하면 내보낸 파일이 여기의 다른 데이터와 마찬가지로 테이블이 됩니다.

System Logs의 작동 방식에 맞춰 설계했습니다.

출력 데이터

  • 줄마다 한 행으로 처리하며 타임스탬프, 호스트, 프로그램, 프로세스 ID, 메시지를 나중에 문자열에서 따로 추출할 필요 없이 실제 열로 제공합니다.
  • 구형 BSD 스타일 형식과 최신 구조화 형식, 두 syslog RFC를 모두 지원하므로 서로 다른 형식이 혼재한 환경에서도 테이블 하나로 처리할 수 있습니다.
  • systemd 저널은 텍스트로 내보낸 뒤 지원됩니다. 저널 자체의 바이너리 형식은 로그 파일이 아니라 데이터베이스이므로 먼저 내보내야 합니다.
  • _source_file에는 각 행이 나온 파일 이름이 표시되므로, 50대 시스템의 로그를 모으는 폴더도 테이블 하나로 조회할 수 있습니다.
-- 호스트별 경고 이상 로그가 가장 많은 프로그램
SELECT   host, program, COUNT(*) AS lines
FROM     fileset.events
WHERE    severity <= 4
GROUP BY host, program
ORDER BY lines DESC

syslog 날짜와 누락된 연도

구형 syslog 형식은 월과 일은 기록하지만 연도는 기록하지 않습니다. 그래서 1월의 로그가 11개월 뒤에 발생한 것처럼 보이기도 합니다. 로그 드라이버는 임의로 추정하지 않고 이를 명시적으로 처리합니다. 형식에 연도가 포함되어 있으면 로그 줄에서 가져오거나, 파일의 수정 시간 또는 파일 이름에서 추론할 수 있습니다. 사용할 방식을 한 번 선택하면 됩니다.

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

System Logs에 필요한 참조 문서를 여세요.

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

시스템 로그 폴더가 하나의 테이블로 통합됩니다.

Query Streams는 rsyslog, syslog-ng 또는 systemd가 이미 기록한 파일을 읽고 형식을 고정해 모든 행 옆에 호스트 이름이 표시된 유형 지정 열을 제공합니다. 수집기를 실행하거나 인덱스를 유지하거나 데이터를 복사할 필요가 없습니다. 파서가 읽지 못하는 줄도 조용히 버리지 않고 이유와 함께 행으로 보존합니다.

로그 폴더서버에서
syslogRFC 3164
인증 로그 2.gz회전된
저널.export저널d

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

시끄러운 프로그램.sqlSQL
선택 호스트, 프로그램,
       세다(*) AS 윤곽
FROM   파일셋.이벤트
어디  메시지 좋다 '%오류%'
그룹 기준 호스트, 프로그램
주문 기준 윤곽 DESC
결과호스트 오류
주인프로그램윤곽
db-01포스트그레스412
웹-01sshd288
앱-01systemd96
메일-01크론11

하나의 결과에 서버가 4개 포함된 이유는 다음과 같습니다. 주인 열입니다

예시 수치 — 답변의 형태를 보여 주는 것으로, 벤치마크가 아닙니다.

두 개의 RFC와 저널
소스

두 개의 RFC와 저널

각 카드에는 Query Streams가 읽는 정확한 파일과 해당 파일의 위치가 명시되어 있습니다. 이 기능을 사용하기 위해 rsyslog를 다시 구성할 필요는 없습니다. 서버에 이미 기록되고 있는 형식을 선택하면 됩니다.

지원되는 시스템 로그

3가지 형식
시스템 로그 아이콘 - Query Streams는 rsyslog 및 syslog-ng에서 작성한 RFC 3164 syslog 파일을 읽습니다. 시스템로그RFC 3164, BSD 파일 형식
  • 대부분의 Linux 서버에서 기본으로 사용하는 형식 — 월 일 시:분:SS 호스트 프로그램[pid]: 메시지
  • 호스트, 프로그램 및 프로세스 ID는 각각 별도의 열로 표시됩니다.
  • /var/log/syslog, 인증 로그, 케른.로그 — 메시지 RHEL에서
  • 주기적인 -- 표시 -- 필러는 작성하는 필터가 아니라 선언에 의해 제거됩니다.
  • 부록; 날짜와 번호가 매겨진 회전 및 .gz 뒤따랐다
시스템 로그 아이콘 - Query Streams는 RFC 5424 구조화된 syslog 파일을 읽습니다. 시스템로그RFC 5424, 구조화된 버전
  • 최신 형식 — 실제 ISO 8601 타임스탬프이므로 연도를 추측할 필요가 없습니다.
  • 우선순위, 앱, 프로세스 ID 및 메시지 ID는 각각 별도의 열에 저장됩니다.
  • 구조화된 데이터 블록은 평면화되지 않고 그대로 유지됩니다.
  • RFC의 nil 값은 텍스트가 아니라 null로 읽힙니다. -
  • RFC 규격에 맞춰 제작되었지만, 실제 공격에 대한 성능 검증은 아직 이루어지지 않았습니다.
Linux 로고 - Query Streams는 journalctl이 작성한 systemd 저널 내보내기를 읽습니다. systemd 저널journalctl -o export
  • 만든 파일 journalctl -o export
  • 마이크로초 단위의 타임스탬프를 사용하므로 주문은 바쁜 순간에도 유지됩니다.
  • 단위와 운송 정보는 텍스트가 아닌 열 형식으로 표시됩니다.
  • 다른 모든 저널 필드는 여기에 보관됩니다. 데이터 버려지는 것보다
  • 레코드당 하나의 항목만 입력 가능하며, 해당 항목이 여러 줄에 걸쳐 입력되더라도 상관없습니다.
더 많은 정보 제공이것은 시작일 뿐, 한계가 아닙니다.

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

이 중 어떤 것이 실제 파일을 대상으로 테스트되었는지 알아두는 것이 중요합니다. RFC 3164 파서와 저널 내보내기 파서는 모두 실제 캡처된 로그, 로그 순환 및 압축 아카이브를 대상으로 구축 및 테스트되었습니다. RFC 5424는 아직 발표되지 않았습니다. — 사양에 명시되어 있고 테스트도 거쳤지만, 아직 실제 캡처 데이터가 이 형식으로 들어온 적은 없습니다. 이 형식을 사용한다면 연결 테스트에서 확정하기 전에 인식된 내용을 알려 드립니다. 지금 미리 알아두시는 편이 좋습니다.
한 번의 쿼리로 모든 머신을 조회하세요
모든 서버

한 가지 질문이 있습니다. 당신이 운영하는 모든 기계

시스템 로그는 이 기능이 만들어진 목적입니다. 모든 행에는 로그를 기록한 호스트가 포함되므로, 서버 네 대에서 수집한 폴더만으로도 네 서버 전체를 대상으로 질문에 답할 수 있습니다. 추가하는 각 사이트에서는 Network Agent가 파일이 있는 위치에서 파일을 읽고 Query Streams에 연결합니다. 방화벽 입장에서는 일반적인 아웃바운드 연결일 뿐이므로 열어야 할 포트도, 구축할 VPN도 없습니다.

본점 리눅스 서버 랙이 평문으로 글을 쓰고 있습니다. /var/log/syslog 전화를 걸다
eu-서쪽 클라우드 인스턴스, 저널 내보내기는 정해진 일정에 따라 작성됩니다. 전화를 걸다
미국 동부 두 번째 영역에는 동일한 파일들이 동일한 형태로 저장됩니다. 전화를 걸다

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

지역당 담당자 1명

Agent 하나가 단일 서버가 아니라 사이트 전체를 담당하며, 여러 호스트에서 수집한 폴더 트리도 커넥터 하나로 처리합니다. 모든 행에 이미 해당 호스트의 정보가 포함되어 있습니다. 주인Free 플랜에서는 Agent 하나를 실행하고, 유료 플랜에서는 더 많은 Agent를 실행합니다.

사이트 1개 = 에이전트 1개 = 여러 호스트

열 내용이 없습니다

Agent는 암호화된 아웃바운드 연결을 하나 만들고, 요청과 응답 행은 모두 이 연결을 통해 전송됩니다. 인바운드 포트도, VPN도, 방화벽 변경 요청도 필요 없습니다. 이미 로그를 수집 중인 서버에 수집 데몬을 추가할 필요도 없습니다.

하나의 연결, 양방향

여러 지역에 걸친 단일 쿼리

모든 출처 연합 쿼리 각 사이트마다 고유한 Agent가 있으므로 단일 SQL 문으로 한 지역의 인증 로그를 다른 지역의 인증 로그와 나란히 조회하거나, 해당 로그인 중 어떤 것이 중요한지 알려 주는 애플리케이션 데이터베이스와 함께 조회할 수 있습니다. Business 및 Enterprise에서 이용할 수 있습니다.

리전 2곳 → 결과 집합 1개

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

에이전트는 자체적으로 업데이트되므로, 나중에 추가된 로그 형식은 SSH 연결 없이도 모든 서버에 적용됩니다. 따라서 위의 목록은 고정된 목록이 아니라 시작점에 불과합니다.

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

연도, 시간대 및 바이트
어려운 부분

연도, 시간대 및 바이트

Syslog는 여전히 일상적으로 사용되는 가장 오래된 형식 중 하나이며, 그 점이 여실히 드러납니다. Syslog를 데이터로 취급하려고 할 때 흔히 발생하는 네 가지 문제점이 있는데, 여기서는 추측이 아닌 선언을 통해 각 문제점을 처리합니다.

해당 라인에는 연도가 없습니다.

RFC 3164 스탬프는 9월 10일 04:11:07 — 월, 일, 시각만 있으며 연도는 없습니다. 이를 그대로 읽으면 보관된 모든 행에 현재 연도가 지정됩니다. Query Streams는 대신 파일 자체의 수정 시각을 바탕으로 연도를 추론하므로, 12월에 순환된 로그는 12월 날짜로 처리됩니다.

Sep 10 04:11:07 → 파일에서 연도 추론

시간대도 필요 없고요.

이전 형식에는 시간대 오프셋이 없으므로 타임스탬프는 이를 기록한 머신과 함께 봐야 의미가 있습니다. Agent의 현지 시간으로 읽고 원본 텍스트도 함께 보존합니다. RFC 5424와 journal에는 실제 UTC 시간이 포함되어 있으므로 그대로 처리합니다.

RFC 3164는 현지 시간 · RFC 5424와 journald는 UTC

텍스트 파일의 이진 값

journal 내보내기 형식은 줄바꿈 문자가 포함된 값을 이름, 바이트 길이, 원시 바이트 순으로 기록합니다. Query Streams는 끝을 찾아 읽는 대신 지정된 길이만큼 읽으므로, 줄바꿈이 포함된 메시지도 여러 항목으로 나뉘지 않고 하나의 항목으로 유지됩니다.

내용이 아니라 길이로 읽는다.

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

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

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

실제로 얻게 되는 열
스키마

실제로 얻게 되는 열

타임스탬프가 붙은 텍스트 덩어리가 아닙니다. 각 형식은 직접 필터링, 그룹화 및 집계할 수 있는 유형 지정 열로 파싱됩니다. 형식이 최신일수록 사용할 수 있는 열이 더 많습니다.

시스템 로그 아이콘
Syslog, RFC 3164BSD 파일 형식
프로그램피디메시지
시스템 로그 아이콘
Syslog, RFC 5424구조화된 시스템 로그
프리앱프로시드메시지sd메시지
리눅스 로고
systemd 저널 내보내기journalctl -o export
프로그램피디우선 사항단위수송메시지데이터

각 행에는 또한 다음이 포함됩니다. 이벤트 시간원본 타임스탬프와 로그를 가져온 파일도 포함됩니다. 세 형식 모두 동일한 식별 열을 사용합니다 — 주인 — 덕분에 폴더 내 모든 서버를 대상으로 단일 쿼리를 실행할 수 있습니다. 두 syslog 형식은 로그 행에서, journal은 자체 항목에서 이 값을 가져옵니다. _호스트이름 분야. 모든 것이 하나의 표에 모입니다. 파일셋.이벤트.

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

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

가장 큰 것부터 말해볼게요: 시스템 로그에는 개인 정보가 포함되어 있습니다.. 인증 로그 사용자 이름과 연결에 사용한 IP 주소를 기록합니다. 이메일 주소를 기록하는 프로그램은 이를 메시지 텍스트에 넣습니다. 파일에 있는 내용이 그대로 열에 들어갑니다. 웹 서버 로그와 달리 헤더 매핑을 사용해 필드를 제외할 수는 없습니다. 결과 테이블은 파일을 다룰 때와 똑같이 신중하게 취급하고, 쿼리를 누구와 공유할지 고려하세요.

이는 실시간 로그 추적이 아닙니다. 쿼리 스트림은 쿼리를 실행할 때 디스크에 저장된 파일을 그대로 읽어오기 때문에, 서비스 오류가 발생하면 스트림 형태로 나타나는 것이 아니라 로그 행으로 표시됩니다. 로그가 출력되는 즉시 초 단위 미만의 알림을 받으려면 로그 파이프라인이 적합한 도구입니다.

우리는 바이너리 저널을 읽지 않습니다. systemd 프로필은 다음 사용자가 작성한 파일을 읽습니다. journalctl -o export, 아니다 /var/log/journal 직접 처리되므로 내보내기는 자동으로 이뤄지는 작업이 아니라 일정을 정해 실행해야 하는 단계입니다.

사양서에는 실제 파일에 대한 검증이 아닌 명시적인 내용만 담겨 있지만, 언급할 가치가 있는 세 가지 사항이 있습니다. 바로 RFC 5424 프로파일 전체, rsyslog 및 syslog-ng가 기존 방식 대신 사용할 수 있는 ISO-8601 스탬프 변형, 그리고 여러 줄에 걸쳐 있는 저널 값 처리 방식입니다. 이 세 가지 모두 테스트 대상에 포함되어 있지만, 아직 실제 캡처 환경에서는 검증되지 않았습니다.

마지막으로, 이 범주는 시스템 로그라고 불리지만 오늘날에는 리눅스와 유닉스를 의미합니다. 윈도우 이벤트 로그 프로필이나 macOS 이벤트 로그 프로필은 없습니다. 로그 표시 프로필이라고 부르는 것이 더 적절할 것 같고, 이름만으로 의미를 짐작하게 하는 것보다는 직접 설명하는 것이 좋겠습니다. 나머지는 일반적인 설계와 동일합니다. 에이전트는 외부 연결을 통해 파일을 읽고, 서버에 아무것도 설치되지 않으며, 아무것도 기록되지 않고, 액세스는 읽기 전용입니다. 보존 기간은 이 사전 설정에서 60일부터 시작하며, 사용자가 변경할 수 있습니다.

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

  1. 로그에 접근할 수 있는 위치에 Network Agent를 설치하세요. 한 머신의 /var/log 또는 기존 수집 시스템이 이미 기록하는 폴더면 됩니다.
  2. 커넥터가 해당 폴더를 가리키도록 설정하고 프로필을 선택하세요. 두 가지 syslog RFC 형식과 systemd journal의 내보낸 텍스트 형식이 기본 제공됩니다.
  3. 프로필에 레이아웃이 고정되어 있어 첫 동기화부터 호스트, 프로그램, 프로세스 ID 및 메시지가 이름이 지정된 열로 들어옵니다.
  4. 압축된 아카이브를 포함해 로그 순환을 처리하며, 동기화할 때마다 새로 추가된 바이트만 읽습니다.
  5. 쿼리해 보세요. 호스트 하나든 50개든 프로그램별로 그룹화하고 심각도별로 필터링할 수 있습니다. ssh와 grep 대신 일반 SQL을 사용하세요.

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

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

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

System Logs를 Excel로

실시간 System Logs 결과를 워크시트로 바로 가져와 필요할 때 새로 고치세요. 데스크톱 Excel, Excel Online, Microsoft 365를 지원합니다.

Excel 살펴보기

System Logs를 Data Viewer로

동료, 공급업체, 파트너 등 누구와든 실시간 System Logs 결과를 공유하세요. 휴대폰, 태블릿 또는 데스크톱에서 열면 최신 데이터를 다시 불러오는 북마크 가능한 그리드로 제공됩니다. 상대방은 결과만 볼 수 있으며 SQL이나 파일은 볼 수 없습니다.

데이터 뷰어 작동 방식

앱 및 시스템용

시스템 로그 REST API

System Logs 쿼리를 인증된 JSON 엔드포인트로 게시해 모든 애플리케이션에서 호출할 수 있습니다. OpenAPI 3.1 사양과 바로 사용할 수 있는 Postman, Insomnia, Hoppscotch 컬렉션도 제공됩니다. 데이터베이스 포트를 열 필요가 없습니다.

REST API 살펴보기

System Logs를 Power BI로

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

Power BI 살펴보기

AI 도구의 경우

System Logs MCP 서버

AI 어시스턴트에 올바른 SQL을 작성하는 데 필요한 스키마와 함께 System Logs에 대한 읽기 전용 접근 권한을 제공하세요. 채팅에 자격 증명을 입력할 필요가 없습니다.

MCP 살펴보기

사람들에게 전달됨

System Logs를 다른 데이터와 조인하세요.

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

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

페더레이션 쿼리 살펴보기
소스 간 쿼리 예시
-- 아무것도 복사되지 않았고, 아무것도 병합되지 않았으며, 아무것도 예약되지 않았습니다.
선택   c.region, COUNT(*) AS orders, SUM(i.amount_due) AS invoiced
FROM     syslogfiles.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과 동일합니다.

System Logs에 관한 질문

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

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

System Logs를 사용하려면 인바운드 포트를 열어야 하나요?

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

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

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

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

폴더: 컴퓨터의 로그 디렉터리 또는 로그를 수집할 폴더입니다. 로컬 디스크나 \\server\share 형식으로 입력한 네트워크 공유를 사용할 수 있습니다(매핑된 드라이브 문자는 사용할 수 없으며, Linux 또는 Mac에서는 먼저 마운트해야 함). 하위 폴더도 포함됩니다. 형식: 두 RFC의 Syslog 형식과 텍스트로 내보낸 systemd 저널을 지원합니다. 연도 처리: 로그 줄에서 가져오거나 파일의 수정 시간 또는 파일 이름에서 추론합니다. 한 번 선택하며 행마다 추측하지 않습니다. 로테이션: 이름이 지정된 10가지 로테이션 패턴과 로테이션되지 않은 일반 파일을 지원하며, 압축된 아카이브도 압축을 푼 위치에서 읽습니다.

System Logs를 연결된 다른 데이터 원본과 조인할 수 있나요?

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

제가 가지고 있는 형식은 무엇인가요?

줄의 시작 부분을 보세요 /var/log/syslog 또는 /var/log/messages로 시작한다면 — 9월 10일 04:11:07 — RFC 3164 형식이며, 대부분의 Linux 서버가 아직 기본적으로 기록하는 형식입니다. 꺾쇠괄호 안의 숫자 뒤에 전체 ISO 8601 타임스탬프가 이어지면 RFC 5424 형식입니다.

시작하기 전에 확신할 필요는 없습니다. 연결 테스트는 어떤 프로필을 인식했는지, 파일의 어느 부분이 일치하는지 보고하므로, 답은 추측이 아닌 실제 파일에서 얻을 수 있습니다.

rsyslog 또는 syslog-ng를 다시 구성해야 하나요?

아니요. 두 형식 모두 지원되므로 서버가 이미 기록하는 형식을 선택하면 됩니다. 전통적인 기본 형식은 가장 많은 테스트를 거친 형식입니다.

고려해 볼 만한 변경 사항은 형식과 관련이 없습니다. 이미 여러 컴퓨터의 로그를 하나의 수집기로 전달하고 있다면 Agent가 해당 수집기의 폴더를 가리키도록 설정하세요. 각 행에 출처 호스트가 포함되므로 모든 호스트를 하나의 커넥터에서 확인할 수 있습니다.

오래된 syslog 라인에서 연도가 누락된 경우 어떻게 처리해야 할까요?

연도는 파일의 수정 시간에서 가져옵니다. 12월에 마지막으로 기록된 로테이션 아카이브는 12월로 읽히므로, 단순한 파서처럼 모든 행을 현재 연도로 처리하지 않습니다.

알아둘 제한 사항이 있습니다. 백업 복원 과정에서 타임스탬프가 보존되지 않았거나 타임스탬프를 초기화하는 방식으로 복사해 파일의 타임스탬프가 모두 바뀌었다면, 추론은 파일 시스템에 표시된 정보를 바탕으로 이뤄집니다. 파싱된 값 옆에는 항상 원본 텍스트가 보존되므로 실제 로그 줄의 내용을 확인할 수 있습니다.

systemd 저널을 직접 읽을 수 있나요?

아니요, 사람들이 간과하는 설정 단계가 바로 이 부분입니다. 디스크에 저장된 저널은 바이너리 데이터베이스이며, Query Streams는 이를 열지 않습니다. Query Streams가 읽는 것은 내보내기 형식입니다. journalctl -o export > journal.export에이전트가 읽을 수 있는 모든 폴더에 있습니다.

실제로는 서버에서 예약 작업을 설정하면 됩니다. 타이머나 cron 항목이 내보낸 파일을 Agent가 이미 확인하는 위치에 기록하도록 하세요. 그 이후 과정은 모두 자동이며, gzip 압축된 내보내기 파일도 읽을 수 있습니다.

윈도우 이벤트 로그나 macOS는 어떤가요?

여기에는 어떤 형식도 제공되지 않습니다. 이 페이지의 세 가지 형식은 Linux와 Unix용입니다. “시스템 로그”라는 표현으로 지원 범위를 과장하기보다, 지원하지 않는 부분을 명확히 밝히는 편이 낫습니다.

다만 Windows 로그를 처리하는 방법은 있습니다. 실시간 Event Log를 읽는 것은 텍스트 파일을 읽는 것과는 다른 문제입니다. Event Log는 줄로 된 폴더가 아니라 구조화된 채널이므로 별도의 커넥터에서 처리해야 합니다. 하지만 이미 해당 이벤트를 일정에 따라 텍스트나 CSV로 내보내고 있다면, 지금 바로 그 폴더를 읽을 수 있습니다. 다음을 사용해 레이아웃을 한 번만 설명하세요. 사용자 지정 로그 커넥터와 내보내기는 이 페이지의 다른 항목처럼 표 형식으로 표시됩니다.

로그에 사용자 이름과 IP 주소가 있는데, 걱정해야 할까요?

네, 그리고 질문을 공유하기 전에 생각해 보는 것이 질문을 공유한 후에 생각하는 것보다 훨씬 좋습니다. 인증 로그 접속 기록은 누가 어디에서 접속했는지에 대한 기록으로, 대부분의 관할권에서 개인 정보에 해당하며, 시스템 로그 메시지는 프로그램이 출력하기로 선택한 모든 내용을 포함할 수 있는 자유 형식 텍스트입니다.

Query Streams는 파일의 내용을 바꾸지 않으므로, 이 테이블은 파일의 민감도 수준을 그대로 따른다고 보는 것이 정확합니다. 두 가지 방법이 도움이 됩니다. 저장된 쿼리는 연결이 아니라 결과를 공유하므로 수신자가 전체 로그를 볼 수 없으며, 필터를 사용하면 공유하기 전에 필요한 프로그램의 데이터만 쿼리에 포함할 수 있습니다.

여러 서버의 로그를 하나의 폴더에 모아둡니다. 이렇게 하면 괜찮을까요?

이런 상황에 가장 적합합니다. 세 형식 모두 호스트를 열로 포함합니다. 두 Syslog 형식은 로그 줄에서 호스트를 읽고, 저널 내보내기 형식은 자체 hostname 필드에서 가져옵니다. 따라서 40대의 컴퓨터에서 수집한 폴더도 하나의 커넥터로 처리할 수 있으며, 호스트별 그룹화는 일반적인 작업입니다. 그룹 기준.

다른 건물이나 지역에 있는 서버도 작동합니다. 각 위치에서 자체 에이전트가 실행되며, 비즈니스 및 엔터프라이즈 요금제에서는 연합 쿼리를 통해 단일 명령문으로 모든 위치의 데이터를 읽을 수 있습니다.

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

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

형식이 이진수로 표시하는 저널 값에도 동일하게 적용됩니다. 해당 값은 추측되는 대신 이유와 함께 항목 옆에 표시되며, 항목 자체는 그대로 유지됩니다.

작업이 이루어지는 곳에서 System Logs를 사용하세요.

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

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