로그·코어 덤프 중앙 수집

IT 엔지니어개발자

시작하기

기본 개념

여러 시스템에서 생성되는 로그와 진단 파일을 하나의 분석 환경으로 수집하기

서버와 애플리케이션에서는 운영 과정에서 로그, 코어 덤프, 오류 보고서와 다양한 진단 파일이 생성됩니다.

로그·코어 덤프 중앙 수집은 각 시스템에서 생성되는 파일을 설정한 기준에 따라 수집하고, 지정된 중앙 분석 환경으로 자동 전송하는 방식입니다.

여러 서버와 애플리케이션을 하나의 수집 흐름으로 연결하면 시스템별로 생성되는 진단 자료를 중앙에서 확인하고 분석 작업에 활용할 수 있습니다.

text
Server A ──┐
           │
Server B ──┼──→ Central Collection ──→ Analysis System
           │
App Server ─┤
           │
Edge Device ─┘

수집 흐름

파일 생성부터 중앙 분석 환경 반영까지 자동으로 이어가기

수집 대상 시스템에서 로그나 진단 파일이 생성되면 파일 유형과 경로, 설정한 실행 조건을 기준으로 수집 작업을 시작합니다.

수집된 파일은 중앙 저장 또는 분석 환경으로 전송하며, 파일 수집이 완료된 후에는 필요한 분석과 모니터링 작업으로 연결할 수 있습니다.

① 로그·진단 파일 생성

② 수집 대상 확인

③ 수집 기준 적용

④ 중앙 분석 환경으로 전송

⑤ 분석·모니터링 작업 연결

⑥ 실행 결과 확인

이 흐름을 통해 여러 시스템에서 생성되는 진단 파일의 수집과 이후 활용 과정을 하나의 운영 흐름으로 구성할 수 있습니다.

운영 효과

분산된 진단 자료를 중앙에서 확인하고 분석 흐름으로 활용하기

여러 시스템에서 생성되는 진단 파일을 중앙 수집 환경으로 연결하면 파일 생성 위치와 수집 상태, 분석 대상 파일을 하나의 흐름으로 관리할 수 있습니다.

구분개별 시스템 관리중앙 수집
파일 위치시스템별 경로 확인수집 환경에서 통합 관리
수집 실행시스템별 작업 진행조건에 따라 자동 수집
분석 준비필요한 파일을 개별 전송수집 후 분석 환경으로 연결
상태 확인시스템별 결과 확인전체 수집 현황 확인

이렇게 구성하면 파일 생성 → 중앙 수집 → 분석 연계 → 결과 확인까지 이어지는 진단 파일 운영 흐름을 구성할 수 있습니다.

IT 엔지니어

수집 환경

로그와 진단 파일이 생성되는 시스템 연결하기

먼저 로그와 코어 덤프, 진단 파일이 생성되는 서버와 애플리케이션 환경을 수집 흐름에 연결합니다.

각 시스템에서 파일이 생성되는 위치를 지정하면 중앙 수집 작업에서 사용할 원본 경로를 구성할 수 있습니다.

수집 환경주요 파일
애플리케이션 서버애플리케이션 로그와 오류 보고서
운영 서버시스템 로그와 진단 파일
처리 서버작업 로그와 처리 결과
장애 분석 환경코어 덤프와 오류 자료
엣지 장비현장 로그와 진단 데이터
text
Devices
   │
   ├── Application Server
   │       └── /var/log/application
   │
   ├── Linux Server
   │       └── /var/log/system
   │
   └── Edge Device
           └── /data/diagnostics

수집 정책

파일 유형과 중요도에 따라 수집 기준 구성하기

수집 환경을 연결한 후에는 어떤 파일을 어떤 기준으로 수집할지 설정합니다.

파일 확장자와 경로, 생성 또는 변경 조건을 기준으로 수집 대상을 지정하고, 파일 유형과 중요도에 따라 처리 순서와 실행 기준을 구성할 수 있습니다.

파일 유형수집 기준처리 흐름
일반 로그일정 또는 파일 변경정기 수집
오류 로그생성 또는 변경 감지분석 작업 연결
코어 덤프파일 생성우선 수집
진단 파일지정된 경로와 조건분석·모니터링 연계
text
File Event
    │
    ▼
Collection Policy
    │
    ├── Log File ──────→ Standard Collection
    │
    ├── Error Report ──→ Analysis Flow
    │
    └── Core Dump ─────→ Priority Collection

중앙 수집

여러 시스템의 진단 파일을 중앙 분석 환경으로 전송하기

설정한 수집 기준에 따라 각 시스템의 파일을 중앙 저장 위치로 전송합니다.

여러 시스템의 파일을 하나의 중앙 환경으로 모으고, 파일 유형이나 분석 목적에 따라 이후 작업을 연결할 수 있습니다.

text
Application ───┐
               │
Database ──────┼──→ Central Storage
               │           │
Server ────────┤           ├──→ Analysis
               │           │
Edge ──────────┘           └──→ Monitoring

분석 연계

수집된 파일을 다음 분석과 모니터링 작업으로 연결하기

중앙 환경에 파일이 수집되면 완료된 파일을 분석 시스템이나 모니터링 환경에서 바로 활용할 수 있습니다.

수집 작업의 완료 상태를 다음 작업의 실행 조건으로 연결하면 파일 전송 이후의 분석 과정까지 하나의 워크플로로 구성할 수 있습니다.

text
Collection Completed
        │
        ▼
   File Available
        │
   ┌────┴─────┐
   ▼          ▼
Analysis   Monitoring
   │          │
   └────┬─────┘
        ▼
   Result Tracking

운영 확인

수집 상태와 실행 결과를 확인하고 필요한 작업 다시 실행하기

수집 작업이 실행되면 Runs와 상세 실행 기록을 통해 시스템별 파일 처리 상태와 결과를 확인합니다.

수집 환경, 파일 경로, 연결 상태와 처리 결과를 함께 확인하고, 추가 확인이 필요한 작업은 상세 정보를 기준으로 필요한 조치를 진행한 후 다시 실행할 수 있습니다.

text
Collection Run
      │
      ▼
Status Check
      │
      ├── Completed ─────→ Result Check
      │
      └── Review Required
               │
               ▼
          View Details
               │
               ▼
   Source / Path / Connection Check
               │
               ▼
          Run Again
               │
               ▼
          Result Check
확인 항목확인 내용
수집 시스템파일이 생성된 서버 또는 장비
수집 대상로그, 코어 덤프, 진단 파일
실행 상태현재 작업 상태와 진행률
처리 결과수집된 파일 수와 전체 용량
대상 환경중앙 저장 및 분석 위치
실행 기록수집과 후속 작업의 처리 결과

개발자

로그와 코어 덤프를 유형별로 필터링해 중앙 호스트로 수집하기

연동 준비

공통 호출 코드와 경로 표기 준비하기

import os
import requests

BASE_URL = os.getenv("INNORIX_BASE_URL", "https://app.innorix.com").rstrip("/")
TOKEN = os.environ["INNORIX_ACCESS_TOKEN"]
WORKSPACE_ID = os.getenv("INNORIX_WORKSPACE_ID")   # optional; falls back to the current workspace

STATUS_COMPLETE = 2
TERMINAL = {2, 4, 5, 9, 99}          # complete / error / cancelled / partial / failed
NOT_SUCCEEDED = {4, 5, 9, 99}


def api(method, path, body=None, params=None):
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {TOKEN}",
    }

    if WORKSPACE_ID:
        headers["x-workspace-id"] = WORKSPACE_ID

    response = requests.request(
        method, BASE_URL + path,
        headers=headers, json=body, params=params, timeout=30,
    )

    payload = response.json() if response.content else {}

    if not response.ok:
        raise RuntimeError(payload.get("message") or f"HTTP {response.status_code}")

    return payload.get("data")


def is_terminal(detail):
    return detail.get("isTerminal", detail.get("status") in TERMINAL)
import base64
import time


def encode_path(device_id, raw_path):
    normalized = str(raw_path or "").replace("\\", "/")
    token = base64.b64encode(normalized.encode("utf-8")).decode("ascii")
    return f"{device_id}_ino_{token}"


def now_iso():
    return time.strftime("%Y-%m-%dT%H:%M:%S.000Z", time.gmtime())

전송 상태는 아래 값으로 판단합니다. 종료 상태는 다섯 개이고 성공에 해당하는 값은 완료(2)입니다.

상태 값의미종료
2완료
4오류
5취소
9부분 완료
99실패
1 · 6 · 12 · 13시작·전송 중·동기화 중·수신 중아니오

수집 대상 선별

확장자와 크기로 수집할 파일만 고르기

로그 폴더에는 수집할 필요가 없는 파일도 함께 저장됩니다. 조건을 지정해 필요한 것만 보냅니다.

def build_filter(exts=None, min_size=None, exclude=None):
    file_option = {}

    if exts:
        # extension whitelist, without the leading dot
        file_option["extension"] = {
            "extension": [e.lstrip(".").lower() for e in exts],
            "allow": True,
        }

    if min_size is not None:
        # over and equal both True means size or larger
        file_option["fileSize"] = {"size": min_size, "over": True, "equal": True}

    if exclude:
        # allow=False excludes files whose name contains this. Server matching is case sensitive.
        file_option["fileName"] = {"name": exclude, "allow": False}

    return {"send-fileoption": file_option} if file_option else {}

확장자 필터는 send-fileoption.extension을 씁니다. send-filetype-cus 정규식은 확장자를 뗀 파일명에만 매칭되므로 확장자 조건으로는 동작하지 않습니다.

필터위치동작
확장자send-fileoption.extensionallow: true 면 이 확장자만 전송
크기send-fileoption.fileSizeover·equal 로 이상·이하 지정
이름send-fileoption.fileNameallow: false 면 포함된 파일 제외

여러 필터를 함께 주면 AND로 결합됩니다. 모두 통과한 파일만 전송됩니다.

LOG_FILTER = build_filter(exts=["log", "gz"], exclude=".lck")
DUMP_FILTER = build_filter(exts=["core", "dmp", "hprof"])

로그는 회전되면서 .gz로 압축되는 경우가 많으므로 원본과 압축본을 함께 지정합니다. 잠금 파일은 이름 조건으로 걸러냅니다.

조건이 의도대로 걸리는지는 검색으로 미리 확인합니다.

page = api("POST", f"/api/devices/{device_id}/files/search",
           {"path": "/var/log/application", "pageSize": 500})

matched = [i for i in page["items"]
           if i["type"] == "file" and i["name"].endswith((".log", ".gz"))]

print(f"{len(matched)} matched")

정기 수집 등록

일반 로그를 정해진 시각에 모으기

def build_collection(name, source, source_path, target, target_path,
                     schedule, options):
    return {
        "name": name,
        "flowName": name,
        "transferType": "normal",
        "timezone": "Asia/Seoul",
        "step": 1,
        "isUpcoming": False,
        "details": [
            {
                "senderId": source,
                "receiverId": target,
                "sourceItem": [
                    {
                        "hash": encode_path(source, source_path),
                        "filePath": source_path,
                        "isDir": True,
                    }
                ],
                "targetPath": encode_path(target, target_path),
                "step": 1,
                "transferOptions": {
                    "noSchedule": False,
                    "target-action": "numbering",
                    "send-fileoption": {},
                    **options,
                },
            }
        ],
        "schedules": [schedule],
    }


DAILY_4AM = {
    "type": "day",
    "startDateType": "now",
    "hour": "04",
    "minute": "00",
    "ampm": "am",
    "startDate": now_iso(),
    "timezone": "Asia/Seoul",
}

api("POST", "/api/automations", build_collection(
    "daily log", "device-app-01", "/var/log/application",
    "device-central-01", "/collect/device-app-01",
    DAILY_4AM, LOG_FILTER))

자동화 요청에서 반드시 지켜야 하는 항목이 네 개 있습니다.

항목지정 방식
isUpcoming반드시 false. 서버 기본값 true는 요청에 담긴 일정을 무시하고 5분짜리 일회성 일정으로 대체합니다. triggerAutomation이 붙은 단계는 서버가 false로 강제하므로, 트리거가 없는 첫 단계에만 직접 지정하면 됩니다
step최상위와 details 양쪽에 넣습니다. 흐름 안에서의 홉 위치입니다
sourceItemhash(경로 토큰)와 filePath(평문 경로)를 함께 넣습니다
syncTypetransferOptions 안에 넣습니다. 1은 단방향, 2는 양방향입니다

네 항목 모두 누락해도 등록은 성공하고 실행 시점에 동작이 달라집니다. 반복 일정을 등록했는데 한 번만 실행되고 끝났다면 isUpcoming부터 확인합니다.

진단 파일은 회차를 남겨야 하므로 numbering을 씁니다. overwrite를 쓰면 같은 이름으로 회전되는 로그가 서로를 덮어씁니다.

즉시 수집 등록

코어 덤프가 생기면 바로 가져오기

코어 덤프는 장애 직후에 필요하므로 생성 즉시 수집합니다. 실시간 감시 자동화로 등록하며, transferTypesync로 두고 transferOptionssyncTypewatchFolderType을 넣습니다.

body = build_collection(
    "core dump", "device-app-01", "/var/crash",
    "device-central-01", "/collect/device-app-01/dump",
    {"type": "none", "startDateType": "now",
     "startDate": now_iso(), "timezone": "Asia/Seoul"},
    {**DUMP_FILTER, "syncType": 1, "watchFolderType": 1})

body["transferType"] = "sync"
body["details"][0]["transferOptions"]["noSchedule"] = True

api("POST", "/api/automations", body)

syncTypewatchFolderTypetransferOptions 안에 넣습니다. 감시 경로는 sourceItem[0].filePath에서 읽으므로 build_collection이 넣는 평문 경로가 감시 대상이 됩니다.

에이전트는 파일 크기 변화가 멈추면 쓰기 완료로 판단하고 이벤트를 전달합니다. 코어 덤프처럼 큰 파일은 감지에서 이벤트까지 시간이 더 걸리는데, 잘린 파일이 전송되지 않게 하기 위한 동작입니다.

여러 시스템 등록

수집 대상 서버를 목록으로 두고 일괄 등록하기

서버가 수십 대라면 화면에서 하나씩 만들기 어렵습니다. 목록을 두고 순회합니다.

SOURCES = [
    ("device-app-01", "/var/log/application"),
    ("device-app-02", "/var/log/application"),
    ("device-linux-01", "/var/log/system"),
    ("device-edge-01", "/data/diagnostics"),
]

for source, path in SOURCES:
    api("POST", "/api/automations", build_collection(
        f"collect {source}", source, path,
        "device-central-01", f"/collect/{source}",
        DAILY_4AM, LOG_FILTER))

도착 경로에 장비 식별자를 넣습니다. 서버마다 application.log처럼 이름이 같으므로 한 경로로 모으면 출처를 구분할 수 없습니다.

text
/collect/
    device-app-01/
        application.log
    device-app-02/
        application.log

분석 연계

수집이 끝나면 분석 작업 호출하기

body["processors"] = [{
    "category": "run",
    "type": "http",
    "config": {
        "url": "https://internal.example.com/analyze",
        "method": "POST",
    },
}]

categorytype을 지정하고, url·method·bodyconfig 안에 넣습니다.

호출은 전송 완료 후에 오며, 그 요청을 받는 엔드포인트는 다음과 같이 처리합니다.

def on_collect_hook(payload):
    monitor_id = payload.get("monitorId")

    # If you subscribed to the completed event only, this check can be skipped
    if monitor_id:
        detail = api("GET", f"/api/transfers/{monitor_id}")

        if detail["status"] != STATUS_COMPLETE:
            return skip_failed_collection(payload)

    start_analysis(payload)

수집 현황 확인

시스템별 수집 건수와 실패 조회하기

def wait(monitor_id, timeout=3600, interval=3):
    deadline = time.time() + timeout

    while time.time() < deadline:
        detail = api("GET", f"/api/transfers/{monitor_id}")

        if is_terminal(detail):
            return detail

        time.sleep(interval)

    raise TimeoutError(monitor_id)


def failed_files(monitor_id):
    result = api("GET", f"/api/transfers/{monitor_id}/files", params={
        "state": "any", "size": 500,
    }) or {}

    return [r for r in (result.get("children") or [])
            if r.get("status") in NOT_SUCCEEDED]


def retry_failed(monitor_id):
    rows = failed_files(monitor_id)

    if not rows:
        return 0

    api("POST", f"/api/transfers/{monitor_id}/retry", {
        "filesRetry": [
            {"filePath": r["sourceFilePath"], "isDir": bool(r.get("isFolder"))}
            for r in rows
        ]
    })

    return len(rows)
from collections import Counter
from datetime import datetime, timedelta, timezone


def history(device_id, days=1):
    end = datetime.now(timezone.utc)
    fmt = "%Y-%m-%dT%H:%M:%SZ"

    return list(paginate(f"/api/devices/{device_id}/transfer-history", params={
        "startDate": (end - timedelta(days=days)).strftime(fmt),
        "endDate": end.strftime(fmt),
    }))


for source, _ in SOURCES:
    rows = history(source)
    failed = [r for r in rows if r.get("status") in NOT_SUCCEEDED]
    mark = "" if not failed else "  <- needs attention"
    print(f"{source:20} collected {len(rows):>4} failed {len(failed):>3}{mark}")

진단 파일 수집은 장애 시점에 가장 필요하지만, 그 시점에 수집도 함께 실패하는 경우가 있습니다. 수집 자체의 실패를 별도로 감시합니다.

확인 항목확인 내용
수집 대상확장자와 이름 필터
수집 방식일정 실행 또는 생성 감지
도착 경로장비별로 구분된 저장 위치
분석 연계수집 후 호출되는 작업
수집 실패시스템별 실패 건수와 재전송