11. 로깅 및 집계¶

11.1.1. 로그 메시지 스키마¶

모든 로거의 공통 스키마:

• cluster_host_id: 컨트롤러 클러스터 내에서 호스트의 고유 식별자입니다.

• level: 표준 Python 로그 수준으로, 이 기능의 일부인 모든 데이터 로거는 INFO 수준을 사용하지만 다른 컨트롤러 로그는 필요에 따라 다른 수준을 사용하는 경우의 중요성을 대략적으로 반영합니다.

• logger_name: 설정에서 사용하는 로거의 이름입니다(예: “activity_stream”).

• @timestamp: 로그의 시간입니다.

• path: 로그가 생성된 코드의 파일 경로입니다.

11.1.2. 활동 스트림 스키마¶

• (공통): 위에 나열된 모든 로거에 공통된 모든 필드를 사용합니다.

• actor: 로그에 문서화된 작업을 수행한 사용자의 사용자 이름입니다.

• changes: 변경된 필드와 이전/새 값에 대한 JSON 요약입니다.

• operation: 활동 스트림에 로깅된 변경 사항의 기본 카테고리입니다(예: “associate”).

• object1: 작업 중인 기본 오브젝트에 대한 정보로, 활동 스트림에 표시되는 내용과 일치합니다.

• object2: 적용 가능한 경우 작업과 관련된 두 번째 오브젝트입니다.

11.1.3. 작업 이벤트 스키마¶

이 로거는 로거에서 예상되는 표준 필드와 충돌하여 필드가 중첩되는 경우를 제외하고 작업 이벤트에 저장되는 데이터를 반영합니다. 특히, job_event 모델의 호스트 필드는 ``event_host``로 제공됩니다. 페이로드에는 Ansible 이벤트의 세부 사항에 따라 다양한 필드를 포함하는 하위 사전 필드인 ``event_data``도 있습니다.

이 로거에는 공통 필드도 포함됩니다.

11.1.4. 검사/사실/시스템 추적 데이터 스키마¶

여기에는 서비스, 패키지 또는 파일 중 하나인 자세한 사전 유형 필드가 포함됩니다.

• (공통): 위에 나열된 모든 로거에 공통된 모든 필드를 사용합니다.

• services: 서비스 검사의 경우 이 필드가 포함되어 있으며 서비스 이름을 기반으로 하는 키가 있습니다. 참고: 이름에 대한 탄력적인 검색에서는 마침표를 사용할 수 없으며, 로그 포맷터에 의해 “_”로 대체됩니다.

• package: 패키지 검사의 로그 메시지를 위해 포함됩니다.

• files: 파일 검사의 로그 메시지를 위해 포함됩니다.

• host: 검사가 적용되는 호스트의 이름입니다.

• inventory_id: 호스트가 속하는 인벤토리 ID입니다.

11.1.5. 작업 상태 변경¶

작업 이벤트에 비해 더 적은 볼륨의 작업 상태 변경 정보 소스로 사용되며, 작업 템플릿 기반 작업 이외의 통합 작업 유형에 대한 변경 사항을 캡처하는 데에도 사용됩니다.

이러한 로그에는 공통 필드 외에도 작업 모델에 있는 필드가 포함됩니다.

11.1.6. 컨트롤러 로그¶

일반 필드 외에도 로그 메시지가 있는 msg 필드가 포함됩니다. 오류에는 별도의 traceback 필드가 포함됩니다. 로깅 설정 페이지의 ENABLE EXTERNAL LOGGING 옵션을 사용하여 로그를 활성화하거나 비활성화할 수 있습니다.

11.1.7. 로깅 수집기 서비스¶

로깅 수집기 서비스는 다음과 같은 모니터링 및 데이터 분석 시스템에서 작동합니다.

11.1.7.1. Splunk¶

|At|의 Splunk 로깅 통합은 Splunk HTTP 수집기를 사용합니다. SPLUNK 로깅 수집기를 구성할 때 다음 예제와 같이 HTTP 이벤트 수집기 호스트의 전체 URL을 추가합니다.

https://yourcontrollerfqdn.com/api/v2/settings/logging

{
    "LOG_AGGREGATOR_HOST": "https://yoursplunk:8088/services/collector/event",
    "LOG_AGGREGATOR_PORT": null,
    "LOG_AGGREGATOR_TYPE": "splunk",
    "LOG_AGGREGATOR_USERNAME": "",
    "LOG_AGGREGATOR_PASSWORD": "$encrypted$",
    "LOG_AGGREGATOR_LOGGERS": [
        "awx",
        "activity_stream",
        "job_events",
        "system_tracking"
    ],
    "LOG_AGGREGATOR_INDIVIDUAL_FACTS": false,
    "LOG_AGGREGATOR_ENABLED": true,
    "LOG_AGGREGATOR_CONTROLLER_UUID": ""
}

Splunk HTTP 이벤트 수집기는 기본적으로 8088에서 수신 대기하므로 들어오는 요청이 성공적으로 처리되려면 전체 HEC 이벤트 URL(포트 포함)을 제공해야 합니다. 아래 예제에서는 다음 값을 입력합니다.

HTTP 이벤트 수집기 구성에 대한 자세한 내용은 `Splunk documentation`_를 참조하십시오.

11.1.7.2. Loggly¶

Loggly의 HTTP 끝점을 통해 로그 전송을 설정하려면 https://www.loggly.com/docs/http-endpoint/를 참조하십시오. Loggly는 http://logs-01.loggly.com/inputs/TOKEN/tag/http/에 설명된 URL 규칙을 사용합니다. 이 URL 규칙은 아래 예제의 로깅 수집기 필드에 입력되어 있습니다.

11.1.7.3. Sumologic¶

Sumologic에서 필요한 데이터를 수집하는 데 사용되는 매개변수를 제공하는 json 파일이 포함된 검색 기준을 생성합니다.

filter {
  json {
    source => "message"
  }
}

11.2.1. 로그 집계¶

수집기 유형 중 하나에 로깅하도록 설정하려면 다음을 수행합니다.

1. 왼쪽 탐색 모음에서 **설정**을 클릭합니다.

2. 시스템 옵션 목록에서 **로깅 설정**을 클릭하여 선택합니다.

3. 로깅 설정 화면 하단에서 **편집**을 클릭합니다.

4. 제공된 필드에서 구성 가능한 옵션을 설정합니다.

• 외부 로깅 활성화: 외부 로그 수집기에 로그를 전송하려면 토글 버튼을 클릭하여 **ON**으로 설정합니다.

• 로깅 수집기: 로그를 전송할 호스트 이름 또는 IP 주소를 입력합니다.

• 로깅 수집기 포트: 필요한 경우 수집기 포트를 지정합니다.

참고

연결 유형이 HTTPS인 경우 포트 번호를 포함하는 URL로 호스트 이름을 입력할 수 있으므로 포트를 다시 입력할 필요가 없습니다. 그러나 TCP 및 UDP 연결은 URL이 아닌 호스트 이름과 포트 번호의 조합으로 결정됩니다. 따라서 TCP/UDP 연결의 경우 지정된 필드에 포트를 제공합니다. 호스트 필드(로깅 수집기 필드)에 URL을 대신 입력하면 호스트 이름 부분이 실제 호스트 이름으로 추출됩니다.

• 로깅 수집기 유형: 드롭다운 메뉴에서 수집기 서비스를 클릭하여 선택합니다.

• 로깅 수집기 사용자 이름: 필요한 경우 로깅 수집기의 사용자 이름을 입력합니다.

• 로깅 수집기 암호/토큰: 필요한 경우 로깅 수집기의 암호를 입력합니다.

• 시스템 추적 사실을 개별적으로 로깅: 설정할지 또는 기본값인 해제 상태로 둘지 여부에 대한 추가 정보를 보려면 툴팁 아이콘을 클릭합니다.

• 로깅 수집기 프로토콜: 로깅 수집기와 통신할 연결 유형(프로토콜)을 클릭하여 선택합니다. 후속 옵션은 선택한 프로토콜에 따라 달라집니다.

• 로깅 수집기 수준 임계값: 로그 처리기에서 보고할 심각도 수준을 선택합니다.

• TCP 연결 시간 초과: 연결 시간 초과를 초 단위로 지정합니다. 이 옵션은 HTTPS 및 TCP 로그 수집기 프로토콜에만 적용할 수 있습니다.

• HTTPS 인증서 확인 활성화/비활성화: HTTPS 로그 프로토콜의 경우 기본적으로 인증서 확인이 활성화되어 있습니다. 로그 처리기에서 연결을 설정하기 전에 외부 로그 수집기가 전송한 HTTPS 인증서를 확인하지 않으려면 토글 버튼을 클릭하여 **OFF**로 설정합니다.

• 로그 수집기 양식에 데이터를 전송하는 로거: 기본적으로 네 가지 데이터 유형이 모두 미리 채워집니다. 각 데이터 유형에 대한 추가 정보를 보려면 필드 옆에 있는 툴팁 아이콘을 클릭합니다. 원하지 않는 데이터 유형을 삭제합니다.

• API 4XX 오류의 로그 형식: 특정 오류 메시지 구성. 자세한 내용은 :ref:`logging-api-400-error-config`를 참조하십시오.

5. 선택한 로깅 집계에 대한 입력을 검토합니다. 다음은 Splunk에 대해 설정된 로깅 집계 예제입니다.

7. 완료되면 **저장**을 클릭하여 설정을 적용하거나 **취소**를 클릭하여 변경 사항을 취소합니다.

8. 구성이 올바르게 설정되었는지 확인하려면 먼저 **저장**을 클릭하고 **테스트**를 클릭합니다. 이렇게 하면 |at|의 현재 로깅 구성을 사용하여 테스트 로그 메시지가 로그 수집기로 전송됩니다. 외부 로그 수집기가 테스트 메시지를 수신했는지 확인해야 합니다.

참고

테스트 버튼이 비활성화된 경우 필드가 초기 값과 다른 것이므로 먼저 변경 사항을 저장하고 외부 로깅 활성화 토글이 ON으로 설정되어 있는지 확인합니다.

11.2.2. API 4XX 오류 구성¶

API가 요청에 문제가 발생하면 일반적으로 400 범위의 HTTP 오류 코드를 오류와 함께 반환합니다. 이 경우 패턴을 따르는 로그에 오류 메시지가 생성됩니다.

` status {status_code} received by user {user_name} attempting to access {url_path} from {remote_addr} `

이러한 메시지는 필요에 따라 구성할 수 있습니다. 기본 API 4XX 오류 로그 메시지 형식을 수정하려면 다음을 수행하십시오.

1. 왼쪽 탐색 모음에서 **설정**을 클릭합니다.

2. 시스템 옵션 목록에서 **로깅 설정**을 클릭하여 선택합니다.

3. 로깅 설정 화면 하단에서 **편집**을 클릭합니다.

4. API 4XX 오류의 로그 형식 필드를 수정합니다.

{} 로 묶은 항목은 로그 오류가 생성될 때 대체됩니다. 다음 변수를 사용할 수 있습니다.

• status_code: API가 반환하는 HTTP 상태 코드

• user_name: API 요청을 수행할 때 인증된 사용자의 이름

• url_path: 호출 중인 URL의 경로 부분 (API 끝점 참조)

• remote_addr: 컨트롤러에서 수신한 원격 주소

• error: API에서 반환하거나 오류가 지정되지 않은 경우 HTTP 상태를 텍스트로 표시

11.3.1. 로깅 집계¶

http/https를 통해 구성된 로깅 서비스에 테스트 버튼이 있는 메시지를 전송했지만 메시지가 수신되지 않은 경우 /var/log/tower/rsyslog.err 로그 파일을 확인합니다. http/https 외부 로깅 서비스에서 rsyslog를 인증할 때 발생한 오류는 이 파일에 저장됩니다. 오류가 없는 경우에는 이 파일이 존재하지 않습니다.

11.3.2. API 4XX 오류¶

해당 메시지의 로그 형식을 수정하여 4XX 오류에 대한 API 오류 메시지를 포함할 수 있습니다. 자세한 내용은 API 4XX 오류 구성 섹션을 참조하십시오.

11.3.3. LDAP¶

LDAP 어댑터에 대한 로깅 메시지를 활성화할 수 있습니다. 자세한 내용은 LDAP에 로깅 활성화 섹션을 참조하십시오.

11.3.4. SAML¶

LDAP에 대한 로깅을 활성화할 수 있는 방식과 동일하게 SAML 어댑터의 로깅 메시지를 활성화할 수 있습니다. 자세한 내용은 LDAP에 로깅 활성화 섹션을 참조하십시오.