INNORIX | Enterprise File Orchestration Platform

시작하기

기본 개념

파일 전송 상태를 Datadog 이벤트와 모니터링 환경으로 연결하기

파일 전송 작업은 실행 결과에 따라 완료, 진행 중, 실패 등 서로 다른 상태를 가질 수 있습니다.

특히 자동으로 실행되는 Flow는 운영자가 작업이 시작될 때마다 직접 상태를 확인하기 어렵기 때문에, 문제가 발생한 시점에 기존 모니터링 환경으로 상태 정보를 전달하도록 구성할 수 있습니다.

전체 흐름은 다음과 같이 연결할 수 있습니다.

text

File Transfer Flow
        │
        ▼
Run Started
        │
        ├───────────────┐
        ▼               │
Transfer Processing     │
        │               │
        ├── Completed ──┼──▶ Normal Result
        │               │
        └── Failed ─────┘
                │
                ▼
          Datadog Event
                │
                ▼
             Monitor
                │
                ▼
        Alert / Recovery Check

이렇게 하면 파일 전송 시스템과 모니터링 환경을 별도로 확인하는 대신 전송 실행 → 상태 변화 → Datadog 이벤트 → 모니터 확인 → 복구 결과 확인까지 하나의 운영 흐름으로 연결할 수 있습니다.

알림 흐름

실패한 Run을 감지하고 필요한 운영 확인으로 이어가기

전송 작업에서 문제가 발생하면 먼저 해당 Run의 상태를 기준으로 실패 여부를 확인합니다.

실패한 Run이 감지되면 관련 정보를 Datadog으로 전달하고, 운영 환경에서는 이벤트와 모니터를 통해 문제 발생 사실을 확인할 수 있습니다.

예를 들어 다음과 같은 흐름으로 구성할 수 있습니다.

전송 상태	Datadog 처리	운영 확인
Started	실행 이벤트 기록	작업 시작 확인
Running	필요 시 상태 확인	진행 상태 확인
Failed	실패 이벤트 전달	모니터 및 알림 확인
Retrying	재시도 상태 전달	복구 진행 확인
Completed	완료 또는 복구 이벤트 전달	최종 결과 확인

실패 이후 재시도가 진행되는 경우에는 단순히 실패 알림만 남기는 것이 아니라, 문제가 발생한 Run이 이후 정상적으로 복구되었는지까지 같은 흐름에서 확인할 수 있습니다.

text

Transfer Failed
       │
       ▼
Datadog Event
       │
       ▼
Failure Monitor
       │
       ▼
Run Investigation
       │
       ▼
Retry
       │
       ├── Failed ──────▶ Additional Alert
       │
       └── Completed ───▶ Recovery Event

이를 통해 운영자는 최초 실패와 이후 복구 상태를 분리하지 않고 전송 작업의 전체 상태 변화를 확인할 수 있습니다.

운영 변화

파일 전송 결과와 시스템 모니터링을 함께 관리하기

파일 전송 결과를 확인하는 방식은 운영 환경에 따라 달라질 수 있습니다.

전송 시스템의 Runs 화면에서 직접 상태를 확인할 수도 있지만, 여러 서버와 서비스, 애플리케이션을 함께 운영하는 환경에서는 기존 모니터링 도구에서 파일 전송 상태까지 함께 확인하는 방식이 필요할 수 있습니다.

구분	개별 확인	Datadog 연동
상태 확인	전송 화면에서 직접 확인	이벤트와 모니터에서 함께 확인
실패 인지	Run 확인 후 문제 파악	실패 상태 발생 시 운영 환경으로 전달
복구 확인	재실행 결과를 다시 확인	복구 상태와 최종 결과 확인
운영 범위	파일 전송 중심	서비스·인프라와 함께 모니터링
이력 관리	전송 실행 기록 확인	이벤트 흐름과 모니터링 기록 활용

이처럼 Datadog 연동은 파일 전송 기능 자체를 대체하는 것이 아니라, 파일 전송에서 발생하는 중요한 상태 변화를 기존 운영 및 모니터링 흐름 안으로 가져오는 방식으로 활용할 수 있습니다.

IT 엔지니어

이벤트 연결

전송 Flow의 상태 변화를 Datadog으로 전달하기

먼저 파일 전송 작업과 Datadog 사이의 이벤트 전달 경로를 구성합니다.

전송 작업이 시작되거나 실패, 재시도, 완료되는 과정에서 필요한 상태 정보를 외부 모니터링 환경으로 전달하도록 연결할 수 있습니다.

text

┌─────────────────────┐
│    Transfer Flow    │
└──────────┬──────────┘
           │
           │ Run Status
           ▼
┌─────────────────────┐
│   Event Condition   │
│                     │
│ Failed / Retrying   │
│ Completed           │
└──────────┬──────────┘
           │
           ▼
┌─────────────────────┐
│       Datadog       │
│                     │
│ Event / Monitor     │
└─────────────────────┘

모든 실행 상태를 동일하게 전달할 수도 있지만, 실제 운영에서는 확인이 필요한 상태를 중심으로 연결할 수 있습니다.

예를 들어 실패와 재시도 상태만 Datadog으로 전달하고, 정상 완료는 별도의 조건에서만 기록하도록 구성할 수 있습니다.

상태 선별

운영에 필요한 실패와 복구 이벤트를 구분해 전달하기

모든 파일 전송 이벤트를 동일한 방식으로 전달하면 운영 환경에 불필요한 정보가 많이 쌓일 수 있습니다.

따라서 전송 상태와 처리 결과를 기준으로 실제 모니터링이 필요한 이벤트를 선택할 수 있습니다.

예를 들어 다음과 같이 구분할 수 있습니다.

text

Run Status
    │
    ├── Started
    │      └── Event Record
    │
    ├── Failed
    │      └── Datadog Alert Event
    │
    ├── Retrying
    │      └── Recovery Progress
    │
    └── Completed
           │
           ├── Normal Completion
           │
           └── Recovery Completed
                  └── Recovery Event

이때 실패 이벤트에는 전송 작업을 식별하고 원인을 확인하는 데 필요한 정보를 함께 전달할 수 있습니다.

전달 정보	활용
Flow 이름	어떤 전송 작업에서 발생했는지 확인
Run 상태	실패·재시도·완료 상태 구분
Source	파일을 가져오는 시스템과 경로 확인
Target	파일을 저장하는 대상 환경 확인
발생 시간	문제 발생 시점 확인
파일 정보	문제가 발생한 전송 대상 확인
실행 결과	실패 원인과 처리 상태 확인

이렇게 구성하면 Datadog 이벤트를 확인한 뒤 필요한 경우 해당 전송 작업의 상세 정보로 돌아가 문제 발생 위치를 이어서 확인할 수 있습니다.

모니터 구성

반복되거나 계속되는 전송 실패를 모니터링하기

단일 파일 전송 실패는 일시적인 네트워크 문제나 대상 환경의 상태에 따라 발생할 수 있습니다.

하지만 동일한 Flow에서 실패가 반복되거나 일정 시간 동안 정상적인 전송 결과가 발생하지 않는 경우에는 추가 확인이 필요할 수 있습니다.

따라서 Datadog에서는 전달된 이벤트를 기준으로 반복적인 실패 패턴을 확인하는 모니터링 흐름을 구성할 수 있습니다.

text

Transfer Events
       │
       ▼
Failed Events
       │
       ▼
┌───────────────────┐
│ Failure Pattern   │
│                   │
│ • Single Failure  │
│ • Repeated Failure│
│ • Continuous Fail │
└─────────┬─────────┘
          │
          ▼
       Monitor
          │
          ▼
    Operational Alert

[제품UI_반복되는 파일 전송 실패 이벤트를 Datadog 모니터링 조건으로 연결하는 화면]

모니터링 기준은 실제 운영 방식에 따라 구분할 수 있습니다.

확인 상황	모니터링 기준 예시	대응
단일 실패	특정 Run 실패 발생	상세 결과 확인
반복 실패	동일 Flow에서 연속 실패	Source·Target 환경 점검
장시간 미완료	일정 시간 내 완료되지 않음	실행 상태 확인
재시도 반복	Retry 이후에도 실패 발생	전송 환경 조정
복구 완료	실패 후 정상 완료	복구 결과 확인

이를 통해 모든 실패를 동일한 중요도로 처리하는 대신 반복 여부와 복구 상태를 기준으로 운영 우선순위를 구분할 수 있습니다.

복구 확인

재시도 이후 정상 전송이 완료되었는지 확인하기

파일 전송 실패 이후 환경을 조정하거나 자동 재시도가 실행될 수 있습니다.

이 경우 최초 실패 이벤트만 확인하면 실제 문제가 해결되었는지 알기 어렵기 때문에, 재시도 이후의 새로운 Run 결과까지 함께 확인할 수 있습니다.

text

① Failure Detected
        │
        ▼
② Datadog Event
        │
        ▼
③ Run Details 확인
        │
        ▼
④ Source / Target 점검
        │
        ▼
⑤ Retry
        │
        ▼
⑥ New Run
        │
        ├── Failed
        │      │
        │      └────▶ Failure Event
        │
        └── Completed
               │
               ▼
          Recovery Event

예를 들어 Source 시스템의 연결이 일시적으로 끊어진 경우 연결 상태를 확인한 뒤 재시도할 수 있습니다.

Target 스토리지의 접근이나 저장 경로에 문제가 있었다면 해당 환경을 조정한 후 새로운 Run을 실행하고, 최종적으로 파일이 정상적으로 반영되었는지 확인할 수 있습니다.

이렇게 하면 실패 감지 → 원인 확인 → 환경 조정 → 재시도 → 복구 완료 확인까지 하나의 운영 흐름으로 관리할 수 있습니다.

결과 추적

전송 Run과 Datadog 이벤트를 함께 확인해 문제 발생 위치 파악하기

실제 문제 대응이 필요한 경우에는 Datadog에서 이벤트를 확인한 뒤 해당 파일 전송 작업의 Run 상세 정보로 연결해 처리 결과를 확인할 수 있습니다.

Run에서는 어떤 Source에서 파일을 가져왔는지와 어떤 Target으로 전송했는지, 전체 파일 중 어느 단계에서 추가 확인이 필요한지를 확인할 수 있습니다.

text

Datadog Alert
      │
      ▼
Transfer Flow
      │
      ▼
Run Details
      │
      ├── Source Status
      │
      ├── Target Status
      │
      ├── File Results
      │
      └── Activity History
              │
              ▼
        Problem Location

확인 과정에서는 다음 항목을 함께 살펴볼 수 있습니다.

확인 항목	확인 내용
Run 상태	실패·재시도·완료 상태
Source	원본 시스템과 파일 경로
Target	대상 스토리지와 저장 위치
파일 결과	성공·실패 파일별 처리 상태
실행 시간	문제 발생과 복구 시점
Activity	실행 과정과 상태 변화 기록

Datadog 이벤트와 Run 상세 정보를 함께 활용하면 단순히 전송이 실패했다는 사실만 확인하는 것이 아니라 실제 어느 전송 구간에서 문제가 발생했고 이후 정상적으로 복구되었는지까지 추적할 수 있습니다.

운영 대응

전송 실패와 복구 상태를 기존 모니터링 환경에서 관리하기

파일 전송이 실패한 경우에는 Datadog의 이벤트나 모니터를 통해 문제 발생 사실을 확인하고, 실제 파일 전송 환경에서는 Run 상세 정보를 통해 원인을 확인합니다.

문제가 발생한 구간에 따라 Source와 Target을 나누어 점검할 수 있습니다.

text

                    Transfer Failure
                           │
                           ▼
                    Datadog Monitor
                           │
                           ▼
                     Run Details
                           │
                ┌──────────┴──────────┐
                ▼                     ▼
          Source Check           Target Check
                │                     │
        Connection / Path      Storage / Permission
                │                     │
                └──────────┬──────────┘
                           ▼
                    Environment Fix
                           │
                           ▼
                         Retry
                           │
                           ▼
                    New Run Result
                           │
                ┌──────────┴──────────┐
                ▼                     ▼
             Failed               Completed
                │                     │
                ▼                     ▼
          Failure Event         Recovery Event

이 가이드를 적용하면 파일 전송 실행 → 상태 변화 감지 → Datadog 이벤트 전달 → 실패 모니터링 → Run 상세 확인 → Source·Target 점검 → 재시도 → 복구 이벤트 확인까지 하나의 운영 흐름으로 구성할 수 있습니다.

이를 통해 파일 전송 시스템의 실행 결과를 별도로 확인하는 대신, 전송 실패와 반복 오류, 재시도와 정상 복구 결과를 Datadog의 기존 모니터링 환경과 연결해 파일 전송 운영 상태를 함께 관리할 수 있습니다.

개발자

전송 실패·복구 이벤트를 Datadog으로 자동 전달하는 연동 등록하기

Datadog 연동을 한 번 등록하고 보낼 이벤트를 켭니다. Datadog 타입의 설정 필드는 GET /api/integrations/rules/datadog로 확인합니다. 시작 전에 다음 항목을 준비합니다.

준비물	내용
INNORIX 인증	`INNORIX_ACCESS_TOKEN` (`Authorization: Bearer`)
Datadog 설정	Datadog 타입 규칙(`GET /api/integrations/rules/datadog`)이 요구하는 설정 값(API Key·Site 등)
이벤트 선택	전달할 이벤트: `error`(실패)·`recovered`·`completed` 등
런타임	Python 3 + `requests` · Java 17+ · Node.js 18+ · .NET 8+

Python·Node.js는 REST를 직접 호출하는 최소 api() 헬퍼를 API 호출 레시피의 것을 재사용합니다. Java·C#은 번들 소스의 InnorixClient와 Json(C#은 J) 헬퍼를 사용합니다. Datadog 연동의 정확한 설정 필드 이름은 GET /api/integrations/rules/datadog 응답을 따릅니다.

Datadog 연동 등록

type: "datadog"으로 연동을 만들고, notificationConfig.events에서 보낼 이벤트를 켭니다. Datadog 설정 값(API Key·Site 등)은 규칙에 맞춰 config에 넣습니다.

def create_datadog_alert(name, config, events=("error", "recovered")):
    # config: values required by GET /api/integrations/rules/datadog (e.g. apiKey, site)
    result = api("POST", "/api/integrations", {
        "name": name,
        "type": "datadog",
        "category": "monitoring",
        "config": config,
        # enabled events are delivered automatically for every transfer/automation in the workspace
        "notificationConfig": {"events": {e: True for e in events}},
    }) or {}
    return result.get("integrationId")


integration_id = create_datadog_alert(
    "transfer-failures",
    {"apiKey": "<DATADOG_API_KEY>", "site": "datadoghq.com"},
    events=("error", "recovered"))
print("Datadog integration:", integration_id)

설정 필드는 규칙을 따릅니다 유형별 필수 설정은 GET /api/integrations/rules/datadog에서 확인합니다. 예제의 config 키는 예시이므로 규칙 응답에 맞춰 채웁니다. 필수 설정이 누락된 연동은 생성되더라도 이벤트가 전달되지 않을 수 있습니다.

API Key 보관 Datadog API Key는 예제처럼 코드에 직접 넣지 말고 환경 변수나 Secret 저장소에서 읽어 config에 주입합니다.

이벤트는 워크스페이스 전체 적용 notificationConfig.events에서 켠 이벤트는 해당 워크스페이스의 모든 전송·자동화에 적용됩니다. 전송마다 연동을 연결하지 않으며 /api/transfers/manual에 integrationId를 넘기지 않습니다. 유효 이벤트: started·completed·paused·resumed·recovered·canceled·error(실패)·skipped, 모니터링 연동은 deviceConnected·deviceDisconnected도 받습니다.

구현 결과

이 레시피를 적용하면 다음 흐름으로 전송 이벤트를 Datadog으로 전달할 수 있습니다.

text

전송·자동화 이벤트 (error / recovered 등)
   ↓  워크스페이스 전체 자동 통지  

INNORIX Datadog 연동
   ↓  

Datadog 이벤트·모니터·알림

Datadog 연동을 한 번 등록하고 보낼 이벤트를 켜 두면, 전송 실패·복구 이벤트가 워크스페이스 전체에서 Datadog으로 자동 전달됩니다.

Datadog으로 파일 전송 실패와 복구 알림 받기

시작하기

기본 개념

알림 흐름

운영 변화

IT 엔지니어

이벤트 연결

상태 선별

모니터 구성

복구 확인

결과 추적

운영 대응

개발자

Datadog 연동 등록

구현 결과

회사

기타 INNORIX 제품