로그 수집 기능은 TKE에서 제공하는 클러스터 로그 수집 툴로, 지정된 클러스터 서비스 또는 노드 경로의 로그를 CLS로 전달할 수 있습니다. Kubernetes 클러스터에 서비스 로그를 저장하고 분석하려는 사용자에게 적합합니다.
각 클러스터마다 로그 수집을 수동으로 활성화하고 수집 규칙을 구성해야 합니다. 클러스터에 대한 로그 수집이 활성화되면 로그 수집 Agent가 클러스터 내에서 DaemonSet으로 실행되며, 수집 소스, CLS 로그 토픽 및 로그 파싱 방법에 따라 사용자가 구성한 로그 수집 규칙에 따라 수집된 로그를 소비자에게 전송합니다.
2. 기능 관리 페이지 상단에서 리전 및 등록된 클러스터를 선택하고 대상 클러스터를 선택한 다음 생성을 클릭합니다.
3. 로그 수집 규칙 생성 페이지에서 수집 유형을 선택하고 로그 소스를 구성합니다. 현재 로그 수집 유형에는 컨테이너 표준 출력, 컨테이너 파일 경로 및 노드 파일 경로가 포함됩니다.
컨테이너의 표준 출력 로그 수집
컨테이너에서 파일 로그 수집
노드에서 파일 로그 수집
수집 유형으로 컨테이너 표준 출력을 선택하고 필요에 따라 로그 소스를 구성하십시오. 이 유형의 로그 소스를 사용하면 다음과 같이 한 번에 여러 Namespace의 워크로드를 선택할 수 있습니다.
수집 유형으로 컨테이너 파일 경로를 선택하고 다음과 같이 로그 소스를 구성합니다.
파일 경로를 지정하거나 수집 경로에 와일드카드를 사용할 수 있습니다. 예를 들어 컨테이너 파일 경로가 /opt/logs/*.log인 경우 수집 경로를 /opt/logs로 지정하고 파일 이름을 *.log로 지정할 수 있습니다.
주의사항:
수집 유형을 ‘컨테이너 파일 경로’로 선택한 경우 해당 경로는 소프트 링크가 될 수 없습니다. 그렇지 않으면 소프트 링크의 실제 경로가 수집기 컨테이너에 존재하지 않아 로그 수집이 실패합니다.
수집 유형으로 노드 파일 경로를 선택합니다. 필요에 따라 사용자 지정 ‘metadata’를 추가할 수 있습니다. 수집된 로그 정보에 지정된 Key-Value 쌍으로 ‘metadata’를 첨부하여 첨부된 metadata를 로그 기록에 추가합니다.
참고
각 노드 로그 파일은 하나의 로그 토픽에만 수집될 수 있습니다.
파일 경로를 지정하거나 와일드카드를 사용할 수 있습니다. 예를 들어, 수집의 컨테이너 파일 경로가 /opt/logs/service1/*.log 및 /opt/logs/service2/*.log인 경우, 수집 경로의 폴더를 /opt/logs/service*로 지정하고 파일 이름을 *.log로 지정할 수 있습니다.
설명:
컨테이너 표준 출력 및 컨테이너 파일(hostPath에 마운트되지 않음)의 경우 원본 로그 콘텐츠 외에 컨테이너 또는 Kubernetes와 관련된 메타데이터(예: 로그를 생성한 컨테이너의 ID)도 CLS에 보고됩니다. 따라서 사용자는 로그를 볼 때 로그 소스를 추적하거나 컨테이너 식별자 또는 특성(예시: 컨테이너 이름 및 labels)을 기반으로 검색할 수 있습니다.
컨테이너 또는 Kubernetes와 관련된 메타데이터는 아래 표에 나와 있습니다.
필드 이름
설명
container_id
로그가 속한 컨테이너의 ID.
container_name
로그가 속한 컨테이너의 이름.
image_name
로그가 속한 컨테이너의 이미지 이름 IP.
namespace
로그가 속한 pod의 namespace.
pod_uid
로그가 속한 pod의 UID.
pod_name
로그가 속한 pod의 이름.
pod_lable_{label name}
로그가 속한 pod의 label(예를 들어 pod에 label: app=nginx, env=prod라는 두 개의 레이블이 있는 경우 보고된 로그에는 두 개의 메타데이터 항목 metedata: pod_label_app:nginx, pod_label_env:prod이 첨부됩니다).
4. CLS 소비자를 구성합니다. 대상 로그셋 및 로그 토픽을 선택합니다. 다음과 같이 로그 토픽을 생성하거나 기존 항목을 선택할 수 있습니다.
로그셋에 이미 500개의 로그 토픽이 있는 경우 더 이상 로그 토픽을 생성할 수 없습니다.
5. 고급 설정에서 Key 값을 지정하여 로그를 지정된 파티션으로 전달할 수 있습니다. 이 기능은 기본적으로 비활성화되어 있으며 로그는 임의 파티션으로 전달됩니다. 활성화되면 동일한 Key를 가진 로그가 동일한 파티션으로 전달됩니다. 다음과 같이 TimestampKey(기본적으로 @timestamp)를 입력하고 타임스탬프 형식을 지정할 수 있습니다.
6. 다음 이미지와 같이 다음을 클릭하고 로그 추출 모드를 선택합니다.
참고
현재 CLS로 전달된 로그에 대해서만 로그 파싱 방법을 구성할 수 있습니다.
파싱 모드
설명
관련 문서
단일 행 텍스트
로그에는 한 행의 내용만 포함되며 로그의 끝을 표시하는 줄 바꿈 \\n이 있습니다. 각 로그는 CONTENT를 키 값으로 사용하여 완전한 문자열로 구문 분석됩니다. 로그 인덱스가 활성화되면 전체 텍스트 검색을 통해 로그 콘텐츠를 검색할 수 있습니다. 로그의 시간 속성은 수집 시간에 의해 결정됩니다.
여러 행의 전체 텍스트가 있는 로그는 여러 행에 걸쳐 있으며 일치를 위해 첫 번째 행 정규식이 사용됩니다. 행의 로그가 미리 설정된 정규식과 일치하면 로그의 시작으로 간주되며 일치하는 다음 행은 로그의 끝 표시가 됩니다. 기본 키 값인 CONTENT도 설정됩니다. 로그의 시간 속성은 수집 시간에 의해 결정됩니다. 정규식은 자동으로 생성될 수 있습니다.
한 행 전체 정규식 모드는 전체 로그에서 여러 key-value 쌍을 추출할 수 있는 로그 파싱 모드입니다. 단일 행 전체 정규식 모드를 구성할 때 먼저 샘플 로그를 입력한 다음 정규식을 사용자 지정해야 합니다. 구성이 완료되면 시스템은 정규식의 캡처 그룹에 따라 해당 key-value 쌍을 추출합니다. 정규식은 자동으로 생성될 수 있습니다.
다중 행 - 전체 정규식 모드는 Java 프로그램 로그와 같이 여러 행에 걸쳐 완전한 로그 데이터가 있는 로그 텍스트 파일에서 정규식을 기반으로 여러 개의 key-value 쌍을 추출할 수 있는 로그 파싱 모드입니다. 다중 행 - 전체 정규식 모드를 구성할 때는 먼저 샘플 로그를 입력한 다음 정규식을 사용자 지정해야 합니다. 구성이 완료되면 시스템은 정규식의 캡처 그룹에 따라 해당하는 key-value 쌍을 추출합니다. 정규식은 자동으로 생성할 수 있습니다.
지정된 세퍼레이터를 사용하여 로그의 데이터를 구조화하고 각 전체 로그는 줄 바꿈 \\n으로 끝납니다. CLS가 세퍼레이터 형식의 로그를 처리할 때, 개별 필드마다 고유 key를 정의해야 합니다. 수집할 필요가 없으면 필드를 비워 둡니다. 모든 필드를 비워둘 수는 없습니다.
