Skip to main content
이 제품의 최신 릴리즈를 사용할 수 있습니다.
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

StorageGRID에서 로그 관리 구성

PDF

필요에 따라 감사 수준, 프로토콜 헤더, 감사 메시지 및 로그의 위치를 구성하십시오.

모든 StorageGRID 노드는 시스템 활동 및 이벤트를 추적하기 위해 감사 메시지와 로그를 생성합니다. 감사 메시지와 로그는 모니터링 및 문제 해결에 필수적인 도구입니다.

선택적으로 "외부 syslog 서버 구성"감사 정보를 원격으로 저장할 수 있습니다. 외부 서버를 사용하면 감사 데이터의 완전성을 유지하면서 감사 메시지 로깅으로 인한 성능 영향을 최소화할 수 있습니다. 외부 syslog 서버는 대규모 그리드 환경을 구축했거나, 여러 유형의 S3 애플리케이션을 사용하거나, 모든 감사 데이터를 보존하려는 경우에 특히 유용합니다.

시작하기 전에

감사 메시지 수준 변경

감사 로그의 다음 각 메시지 범주에 대해 서로 다른 감사 수준을 설정할 수 있습니다.

감사 범주 기본 설정 추가 정보

시스템

정상

"시스템 감사 메시지"

스토리지

오류

"객체 저장소 감사 메시지"

관리

정상

"관리 감사 메시지"

클라이언트 읽기

정상

"클라이언트 읽기 감사 메시지"

클라이언트 쓰기

정상

"클라이언트 쓰기 감사 메시지"

ILM

정상

"ILM 감사 메시지"

교차 그리드 복제

오류

"CGRR: 그리드 간 복제 요청"
참고 업그레이드 중에는 감사 수준 구성이 즉시 적용되지 않습니다.
단계

  1. * 구성 * > * 모니터링 * > * 로그 관리 * 를 선택합니다.

  2. 각 감사 메시지 범주에 대해 드롭다운 목록에서 감사 수준을 선택하십시오.

    감사 수준 설명

    끄기

    해당 범주의 감사 메시지는 기록되지 않습니다.

    오류

    오류 메시지만 기록됩니다. 즉, 결과 코드가 "성공"(SUCS)이 아닌 감사 메시지만 기록됩니다.

    정상

    일반적인 거래 메시지는 로그에 기록됩니다. 이러한 메시지는 해당 범주에 대해 이 지침에 나열된 메시지입니다.

    디버그

    더 이상 사용되지 않습니다. 이 수준은 일반 감사 수준과 동일하게 작동합니다.

    특정 레벨에 포함되는 메시지는 상위 레벨에 기록되는 메시지들을 모두 포함합니다. 예를 들어, 일반 레벨에는 모든 오류 메시지가 포함됩니다.

    참고 S3 애플리케이션의 클라이언트 읽기 작업에 대한 자세한 기록이 필요하지 않은 경우, 선택적으로 클라이언트 읽기 설정을 *오류*로 변경하여 감사 로그에 기록되는 감사 메시지 수를 줄일 수 있습니다.

  3. *저장*을 선택하세요.

HTTP 요청 헤더 정의

클라이언트 읽기 및 쓰기 감사 메시지에 포함할 HTTP 요청 헤더를 선택적으로 정의할 수 있습니다.

단계

  1. 감사 프로토콜 헤더 섹션에서 클라이언트 읽기 및 쓰기 감사 메시지에 포함할 HTTP 요청 헤더를 정의합니다.

    별표(*)를 와일드카드로 사용하여 0개 이상의 문자와 일치시킬 수 있습니다. 이스케이프 시퀀스(\*)를 사용하여 문자 그대로의 별표와 일치시킬 수 있습니다.

  2. 필요한 경우 *다른 헤더 추가*를 선택하여 추가 헤더를 생성합니다.

    요청에서 HTTP 헤더가 발견되면 해당 헤더는 감사 메시지의 HTRH 필드에 포함됩니다.

    참고 감사 프로토콜 요청 헤더는 클라이언트 읽기 또는 *클라이언트 쓰기*에 대한 감사 수준이 *끔*이 아닌 경우에만 기록됩니다.

  3. *저장*을 선택합니다

로그 위치 구성

기본적으로 감사 메시지와 로그는 생성된 노드에 저장됩니다. 과도한 디스크 공간을 사용하지 않도록 주기적으로 교체되고 결국 삭제됩니다. 감사 메시지와 로그의 일부를 외부에 저장하려면 외부 syslog 서버 사용.

로그 파일을 내부적으로 저장하려면 로그 저장소용 테넌트와 버킷을 선택하고 로그 아카이빙을 활성화하세요.

외부 syslog 서버 사용

선택적으로 외부 syslog 서버를 구성하여 감사 로그, 애플리케이션 로그 및 보안 이벤트 로그를 그리드 외부 위치에 저장할 수 있습니다.

참고 외부 syslog 서버를 사용하지 않으려면 이 단계를 건너뛰고 로그 위치 선택으로 이동하세요.
팁 이 절차에서 제공되는 구성 옵션이 요구 사항을 충족할 만큼 유연하지 않은 경우, audit-destinations 엔드포인트를 사용하여 추가 구성 옵션을 적용할 수 있습니다. 이 엔드포인트는 "그리드 관리 API"의 비공개 API 섹션에 있습니다. 예를 들어, 노드 그룹별로 다른 syslog 서버를 사용하려면 해당 API를 사용할 수 있습니다.

syslog 정보 입력

외부 syslog 서버 구성 마법사에 액세스하여 StorageGRID가 외부 syslog 서버에 액세스하는 데 필요한 정보를 제공하십시오.

단계

  1. 로컬 노드 및 외부 서버 탭에서 *외부 syslog 서버 구성*을 선택합니다. 또는 이전에 외부 syslog 서버를 구성한 경우 *외부 syslog 서버 편집*을 선택합니다.

    외부 syslog 서버 구성 마법사가 나타납니다.

  2. 마법사의 syslog 정보 입력 단계에서 호스트 필드에 외부 syslog 서버에 대한 유효한 정규화된 도메인 이름 또는 IPv4 또는 IPv6 주소를 입력하십시오.

  3. 외부 syslog 서버의 대상 포트를 입력하십시오(1에서 65535 사이의 정수여야 함). 기본 포트는 514입니다.

  4. 외부 syslog 서버로 감사 정보를 전송하는 데 사용되는 프로토콜을 선택하십시오.

    TLS 또는 RELP/TLS 사용을 권장합니다. 이러한 옵션을 사용하려면 서버 인증서를 업로드해야 합니다. 인증서를 사용하면 그리드와 외부 syslog 서버 간의 연결을 안전하게 보호할 수 있습니다. 자세한 내용은 "보안 인증서 관리"을 참조하십시오.

    모든 프로토콜 옵션은 외부 syslog 서버의 지원 및 구성이 필요합니다. 외부 syslog 서버와 호환되는 옵션을 선택해야 합니다.

    참고 신뢰할 수 있는 이벤트 로깅 프로토콜(RELP)은 syslog 프로토콜의 기능을 확장하여 이벤트 메시지를 안정적으로 전달합니다. RELP를 사용하면 외부 syslog 서버가 재시작될 경우 감사 정보 손실을 방지할 수 있습니다.

  5. *Continue*를 선택합니다.

  6. TLS 또는 *RELP/TLS*를 선택한 경우 서버 CA 인증서, 클라이언트 인증서 및 클라이언트 개인 키를 업로드하십시오.

    1. 사용할 인증서 또는 키에 대해 *찾아보기*를 선택합니다.

    2. 인증서 또는 키 파일을 선택하십시오.

    3. 파일을 업로드하려면 *열기*를 선택합니다.

      인증서 또는 키 파일 이름 옆에 녹색 체크 표시가 나타나면 업로드가 성공적으로 완료된 것입니다.

  7. *Continue*를 선택합니다.

syslog 콘텐츠 관리

외부 syslog 서버로 전송할 정보를 선택할 수 있습니다.

단계

  1. 마법사의 syslog 콘텐츠 관리 단계에서 외부 syslog 서버로 전송할 각 감사 정보 유형을 선택하십시오.

    • 감사 로그 전송: StorageGRID 이벤트 및 시스템 활동을 전송합니다.

    • 보안 이벤트 전송: 권한이 없는 사용자가 로그인을 시도하거나 사용자가 루트 권한으로 로그인하는 등의 보안 이벤트를 전송합니다.

    • 애플리케이션 로그 전송: 문제 해결에 유용한 "StorageGRID 소프트웨어 로그 파일"을 전송합니다. 여기에는 다음이 포함됩니다.

      • bycast-err.log

      • bycast.log

      • jaeger.log

      • nms.log (관리자 노드 전용)

      • prometheus.log

      • raft.log

      • hagroups.log

    • 액세스 로그 전송: Grid Manager, Tenant Manager, 구성된 로드 밸런서 엔드포인트 및 원격 시스템의 그리드 페더레이션 요청에 대한 외부 요청의 HTTP 액세스 로그를 전송합니다.

  2. 드롭다운 메뉴를 사용하여 전송하려는 각 감사 정보 범주에 대한 심각도와 기능(메시지 유형)을 선택하십시오.

    심각도 및 시설 값을 설정하면 로그를 사용자 지정 방식으로 집계하여 분석을 더 쉽게 할 수 있습니다.

    1. *심각도*의 경우 *통과*를 선택하거나 0에서 7 사이의 심각도 값을 선택하십시오.

      값을 선택하면 선택한 값이 해당 유형의 모든 메시지에 적용됩니다. 심각도 값을 고정된 값으로 재정의하면 심각도별 정보가 손실됩니다.

      심각성 설명

      패스스루

      외부 시스템 로그로 전송되는 각 메시지는 해당 노드에 로컬로 기록될 때와 동일한 심각도 값을 갖습니다.

      • 감사 로그의 경우 심각도는 "info"입니다.

      • 보안 이벤트의 경우 심각도 값은 노드의 Linux 배포판에서 생성됩니다.

      • 애플리케이션 로그의 경우, 심각도 등급은 문제 유형에 따라 "info"에서 "notice"까지 다양합니다. 예를 들어, NTP 서버를 추가하고 HA 그룹을 구성하는 경우에는 "info" 등급이 부여되는 반면, SSM 또는 RSM 서비스를 의도적으로 중지하는 경우에는 "notice" 등급이 부여됩니다.

      • 액세스 로그의 경우 심각도는 "info"입니다.

      0

      긴급 상황: 시스템을 사용할 수 없습니다

      1

      경고: 즉시 조치를 취해야 합니다

      2

      위급: 위급한 상황

      3

      오류: 오류 조건

      4

      경고: 경고 상황

      5

      주의: 일반적이지만 중요한 상태입니다

      6

      정보성: 정보성 메시지

      7

      디버그: 디버그 수준 메시지

    2. *Facilty*의 경우 *Passthrough*를 선택하거나 0에서 23 사이의 시설 값을 선택하십시오.

      값을 선택하면 해당 유형의 모든 메시지에 적용됩니다. 시설 정보를 고정 값으로 덮어쓰면 각 시설에 대한 정보가 손실됩니다.

    시설 설명

    패스스루

    외부 syslog로 전송되는 각 메시지는 해당 메시지가 노드에 로컬로 기록될 때와 동일한 facility 값을 갖습니다.

    • 감사 로그의 경우 외부 syslog 서버로 전송되는 시설은 "local7"입니다.

    • 보안 이벤트의 경우, 시설 값은 노드의 Linux 배포판에서 생성됩니다.

    • 애플리케이션 로그의 경우, 외부 syslog 서버로 전송되는 애플리케이션 로그에는 다음과 같은 facility 값이 있습니다.

      • bycast.log: 사용자 또는 데몬

      • bycast-err.log: 사용자, 데몬, local3 또는 local4

      • jaeger.log: local2

      • nms.log: local3

      • prometheus.log: local4

      • raft.log: local5

      • hagroups.log: local6

    • 액세스 로그의 경우 외부 syslog 서버로 전송되는 시설은 "local0."입니다.

    0

    kern(커널 메시지)

    1

    사용자(사용자 수준 메시지)

    2

    메일

    3

    데몬(시스템 데몬)

    4

    인증(보안/권한 부여 메시지)

    5

    syslog(syslogd에서 내부적으로 생성되는 메시지)

    6

    lpr (라인 프린터 서브시스템)

    7

    뉴스 (네트워크 뉴스 하위 시스템)

    8

    UUCP

    9

    cron(클록 데몬)

    10

    보안 (보안/인증 메시지)

    11

    FTP

    12

    NTP

    13

    logaudit(log audit)

    14

    logalert (로그 알림)

    15

    clock(클록 데몬)

    16

    local0

    17

    local1

    18

    local2

    19

    local3

    20

    local4

    21

    local5

    22

    local6

    23

    local7

  3. *Continue*를 선택합니다.

테스트 메시지 보내기

외부 syslog 서버를 사용하기 전에 그리드의 모든 노드가 외부 syslog 서버로 테스트 메시지를 전송하도록 요청해야 합니다. 이러한 테스트 메시지를 사용하여 외부 syslog 서버로 데이터를 전송하기 전에 전체 로그 수집 인프라를 검증해야 합니다.

주의 그리드의 각 노드에서 외부 syslog 서버가 테스트 메시지를 수신하고 해당 메시지가 예상대로 처리되었는지 확인하기 전까지는 외부 syslog 서버 구성을 사용하지 마십시오.
단계

  1. 외부 syslog 서버가 올바르게 구성되어 그리드의 모든 노드에서 감사 정보를 수신할 수 있다고 확신하여 테스트 메시지를 보내지 않으려면 *건너뛰고 완료*를 선택하십시오.

    녹색 배너는 구성이 저장되었음을 나타냅니다.

  2. 그렇지 않으면 *테스트 메시지 보내기*를 선택합니다(권장).

    테스트 결과는 테스트를 중지할 때까지 페이지에 계속 표시됩니다. 테스트가 진행되는 동안 감사 메시지는 이전에 구성된 대상으로 계속 전송됩니다.

  3. syslog 서버 구성 또는 실행 중에 오류가 발생하면 오류를 수정하고 *테스트 메시지 보내기*를 다시 선택하십시오.

    "외부 syslog 서버 문제 해결"을 참조하여 오류를 해결하십시오.

  4. 모든 노드가 테스트를 통과했음을 나타내는 녹색 배너가 나타날 때까지 기다리십시오.

  5. 테스트 메시지가 예상대로 수신 및 처리되는지 확인하려면 syslog 서버를 확인하십시오.

    참고 UDP를 사용하고 있다면 전체 로그 수집 인프라를 점검하십시오. UDP 프로토콜은 다른 프로토콜만큼 엄격한 오류 감지 기능을 제공하지 않습니다.

  6. *중지 후 완료*를 선택합니다.

    감사 및 syslog 서버 페이지로 돌아갑니다. 녹색 배너는 syslog 서버 구성이 저장되었음을 나타냅니다.

    참고 StorageGRID 감사 정보는 외부 syslog 서버를 포함하는 대상을 선택하기 전까지는 외부 syslog 서버로 전송되지 않습니다.

로그 위치 선택

감사 로그, 보안 이벤트 로그, "StorageGRID 애플리케이션 로그" 및 액세스 로그가 전송될 위치를 지정할 수 있습니다.

참고

StorageGRID 기본적으로 로컬 노드 감사 대상을 사용하며 감사 정보를 `/var/local/log/localaudit.log`에 저장합니다.

`/var/local/log/localaudit.log`를 사용할 때 Grid Manager 및 Tenant Manager 감사 로그 항목이 스토리지 노드로 전송될 수 있습니다.  `run-each-node --parallel "zgrep MGAU /var/local/log/localaudit.log | tail"` 명령을 사용하여 가장 최근 항목이 있는 노드를 찾을 수 있습니다.

일부 대상은 외부 syslog 서버를 구성한 경우에만 사용할 수 있습니다.
단계

  1. 로그 위치 > *로컬 노드 및 외부 서버*를 선택하십시오.

  2. 로그 유형별 로그 위치를 변경하려면 다른 옵션을 선택하십시오.

    팁 일반적으로 *로컬 노드만 사용*하고 *외부 syslog 서버*를 사용하는 것이 더 나은 성능을 제공합니다.
    옵션 설명

    로컬 노드만(기본값)

    감사 메시지, 보안 이벤트 로그 및 애플리케이션 로그는 관리 노드로 전송되지 않습니다. 대신, 이러한 로그는 해당 로그를 생성한 노드("로컬 노드")에만 저장됩니다. 각 로컬 노드에서 생성된 감사 정보는 `/var/local/log/localaudit.log`에 저장됩니다.

    참고: StorageGRID는 공간 확보를 위해 주기적으로 로컬 로그를 순환 방식으로 삭제합니다. 노드의 로그 파일 크기가 1GB에 도달하면 기존 파일이 저장되고 새 로그 파일이 시작됩니다. 로그의 순환 제한은 21개 파일입니다. 22번째 버전의 로그 파일이 생성되면 가장 오래된 로그 파일이 삭제됩니다. 평균적으로 각 노드에는 약 20GB의 로그 데이터가 저장됩니다. 로그를 장기간 저장하려면 로그 스토리지에 테넌트 및 버킷 사용.

    관리자 노드/로컬 노드

    감사 메시지는 관리 노드의 감사 로그로 전송되며, 보안 이벤트 로그 및 애플리케이션 로그는 해당 메시지를 생성한 노드에 저장됩니다. 감사 정보는 다음 파일에 저장됩니다.

    • 관리자 노드(기본 및 보조 노드): /var/local/audit/export/audit.log

    • 모든 노드: 해당 /var/local/log/localaudit.log 파일은 일반적으로 비어 있거나 없습니다. 일부 메시지의 추가 복사본과 같은 보조 정보가 포함될 수 있습니다.

    외부 syslog 서버

    감사 정보는 외부 syslog 서버로 전송되어 로컬 노드에 저장됩니다 (/var/local/log/localaudit.log). 전송되는 정보의 유형은 외부 syslog 서버 구성 방식에 따라 다릅니다. 이 옵션은 외부 syslog 서버를 구성했습니다.을 완료한 후에만 활성화됩니다.

    관리 노드 및 외부 syslog 서버

    감사 메시지는 감사 로그 (/var/local/audit/export/audit.log)로 관리 노드에 전송되고, 감사 정보는 외부 syslog 서버로 전송되어 로컬 노드에 저장됩니다 (/var/local/log/localaudit.log). 전송되는 정보의 유형은 외부 syslog 서버 구성 방식에 따라 다릅니다. 이 옵션은 외부 syslog 서버를 구성했습니다.을 완료한 후에만 활성화됩니다.

  3. *저장*을 선택하세요.

    경고 메시지가 나타납니다.

  4. 감사 정보의 대상을 변경하려면 *확인*을 선택하십시오.

    새로운 로그는 사용자가 선택한 대상으로 전송됩니다. 기존 로그는 현재 위치에 그대로 유지됩니다.

버킷 사용

로그는 주기적으로 순환됩니다. 장기간 로그를 저장하려면 동일한 그리드 내의 S3 버킷을 사용하십시오.

  1. 로그 위치 > *버킷 사용*을 선택합니다.

  2. 보관 로그 활성화 확인란을 선택하십시오.

  3. 표시된 테넌트와 버킷이 사용하려는 것이 아닌 경우 테넌트 및 버킷 변경*을 선택한 다음 *테넌트 및 버킷 생성 또는 *테넌트 및 버킷 선택*을 선택하십시오.

    테넌트 및 버킷 생성

    1. 새 테넌트 이름을 입력하세요.

    2. 새 테넌트의 암호를 입력하고 확인합니다.

    3. 새 버킷 이름을 입력합니다.

    4. *생성 및 활성화*를 선택합니다.

    테넌트 및 버킷 선택

    1. 드롭다운 메뉴에서 테넌트 이름을 선택합니다.

    2. 드롭다운 메뉴에서 버킷을 선택합니다.

    3. *선택 후 활성화*를 선택합니다.

  4. *저장*을 선택하세요.

    로그는 사용자가 지정한 테넌트 및 버킷에 저장됩니다. 로그의 객체 키 이름은 다음 형식입니다.

    system-logs/{node_hostname}/{absolute_path_to_log_file_on_node}--{last_modified_time}.gz

    예를 들면 다음과 같습니다.

    system-logs/DC1-SN1/var/local/log/localaudit.log--2025-05-12_13:41:44.gz