tencent cloud

Tencent Kubernetes Engine

소식 및 공지 사항
릴리스 노트
제품 릴리스 기록
제품 소개
제품 장점
제품 아키텍처
시나리오
제품 기능
리전 및 가용존
빠른 시작
신규 사용자 가이드
표준 클러스터를 빠르게 생성
Demo
클라우드에서 컨테이너화된 애플리케이션 배포 Check List
TKE 표준 클러스터 가이드
Tencent Kubernetes Engine(TKE)
클러스터 관리
네트워크 관리
스토리지 관리
Worker 노드 소개
Kubernetes Object Management
워크로드
클라우드 네이티브 서비스 가이드
Tencent Managed Service for Prometheus
TKE Serverless 클러스터 가이드
TKE 클러스터 등록 가이드
실습 튜토리얼
Serverless 클러스터
네트워크
로그
모니터링
유지보수
DevOps
탄력적 스케일링
자주 묻는 질문
클러스터
TKE Serverless 클러스터
유지보수
서비스
이미지 레지스트리
원격 터미널

YAML을 통한 로그 수집 구성

PDF
포커스 모드
폰트 크기
마지막 업데이트 시간: 2025-09-29 14:34:23
본문은 CRD를 사용하여 YAML을 통해 TKE Serverless 클러스터의 로그 수집 기능을 구성하는 방법을 설명합니다.

전제 조건

TKE 콘솔에 로그인하고 Serverless 클러스터에 대한 로그 수집 기능을 활성화합니다. 자세한 내용은 로그 수집 활성화를 참고하십시오.

CRD 생성

컬렉션 구성을 만들려면 LogConfig CRD만 정의하면 됩니다. 컬렉션 컴포넌트는 LogConfig CRD의 변경 사항에 따라 해당 CLS 로그 테마를 수정하고 바인딩된 서버 그룹을 설정합니다. CRD 형식은 다음과 같습니다.

clsDetail 필드 설명

주의사항:
topic을 지정한 후에는 주제를 수정할 수 없습니다.
컬렉션 유형을 ‘컨테이너 파일 경로’로 선택한 경우 해당 경로는 소프트 링크가 될 수 없습니다. 그렇지 않으면 소프트 링크의 실제 경로가 수집기 컨테이너에 존재하지 않아 로그 수집이 실패합니다.
clsDetail:
## 로그 테마가 자동으로 생성되면 로그셋과 토픽의 name을 동시에 지정해야 합니다.
logsetName: test   ## CLS 로그셋 name입니다. name에 대한 로그셋이 없으면 자동으로 생성됩니다. 로그셋이 있으면 그 아래에 로그 테마가 생성됩니다.
topicName: test   ## CLS 로그 테마 name입니다. name에 대한 로그 테마가 없으면 자동으로 생성됩니다.

# 기존 로그셋 로그 테마를 선택합니다. 로그셋이 지정되었지만 로그 테마가 지정되지 않은 경우 자동으로 로그 테마가 생성됩니다.
logsetId: xxxxxx-xx-xx-xx-xxxxxxxx  ## CLS 로그셋 ID입니다. 로그셋은 CLS에서 미리 생성해야합니다.
topicId: xxxxxx-xx-xx-xx-xxxxxxxx   ## CLS 로그 테마 ID입니다. 로그 테마는 CLS에서 미리 생성해야 하며 다른 컬렉션 구성에서 점유하면 안 됩니다.

logType: json_log  ## 로그 수집 형식. json_log: json 형식, delimiter_log: 세퍼레이터 기반 형식. minimalist_log: 단일 행 전체 텍스트. multiline_log: 다중 행 전체 텍스트. fullregex_log: 완전 정규식. 기본은 minimalist_log
logFormat: xxx   ## 로그 형식화 방법
period: 30  ## 라이프사이클, 일 단위이며, 1~3600 사이의 값을 가질 수 있습니다. 값이 3640이면 영구 보관을 나타냅니다.
partitionCount:  ## Integer 유형. 로그 테마의 파티션 수입니다. 기본값은 1이며, 최대 10개의 파티션을 생성할 수 있습니다.
tags:  ## 태그 설명 목록. 이 매개변수는 태그를 로그 주제에 바인딩하는 데 사용됩니다. 최대 9개의 태그 키-값 쌍이 지원되며 리소스는 하나의 태그 키에만 바인딩될 수 있습니다.
- key: xxx  ## 태그 key
value: xxx  ## 태그 value
autoSplit: false  ## boolean 유형, 자동으로 분할 기능 활성화 여부를 나타냅니다. 기본값은 true입니다.
maxSplitPartitions:
storageType: hot   ## 로그 테마의 스토리지 유형, hot(표준 저장)와 cold(저주파 저장) 중에서 선택할 수 있습니다. 기본값은 hot입니다.
excludePaths:  ## 블록리스트 경로 목록 수집
- type: File  ## 유형, 선택 사항: File 또는 Path 
value: /xx/xx/xx/xx.log   ## type에 해당하는 값
indexs:  ## topic 생성 시 인덱스 방법 및 필드를 사용자 정의할 수 있습니다
- indexName:  ## 필드에 대해 키 값 또는 메타 필드 인덱스를 구성해야 할 때, 메타 필드 Key는 __TAG__.로 접두사를 추가할 필요가 없으며 로그를 업로드할 때와 일치하면 됩니다. 콘솔에서 표시할 때 __TAG__.가 자동으로 접두사로 추가됩니다.
indexType:  ## 필드 유형, 현재 지원되는 유형: long, text, double
tokenizer:  ## 필드 구분자. 각 문자는 구분 기호를 나타냅니다. 영문 기호 및 \\n\\t\\r만 지원됩니다. long 및 double 필드의 경우 비워 둡니다. text 필드의 경우 @&?|#()='",;:<>[]{}/ \\n\\t\\r\\를 구분 기호로 사용하는 것이 좋습니다.
sqlFlag:  ## 필드에 대한 분석 기능 활성화 여부(boolean)
containZH:  ## 한자 포함 여부(boolean)
region: ap-xxx   ## 리전 간 배송에 대한 topic 리전
userDefineRule: xxxxxx   ## 직렬화된 Json 문자열인 사용자 정의 수집 규칙
extractRule: {}  ## 추출 및 필터 규칙. ExtractRule이 설정되면 LogType도 설정해야 합니다


inputDetail 필드 설명

inputDetail:
type: container_stdout  ## container_stdout(컨테이너 표준 출력), container_file(컨테이너 파일) 및 host_file(호스트 파일)을 포함한 로그 수집 유형

containerStdout:  ## 컨테이너 표준 출력
namespace: default   ## 수집할 컨테이너의 Kubernetes 네임스페이스입니다. 여러 네임스페이스는 ","로 구분합니다(예: default,namespace). 이 필드를 지정하지 않으면 모든 네임스페이스를 나타냅니다. excludeNamespace가 지정된 경우 이 필드를 지정할 수 없습니다.
excludeNamespace: nm1,nm2  ## 제외할 컨테이너의 Kubernetes 네임스페이스입니다. 여러 네임스페이스를 ","로 구분합니다(예: nm1,nm2). 이 필드를 지정하지 않으면 모든 네임스페이스를 나타냅니다. namespace가 지정된 경우 이 필드를 지정할 수 없습니다.
nsLabelSelector: environment in (production),tier in (frontend) ## 네임스페이스 label로 namespace 필터링
allContainers: false  ## 지정된 네임스페이스에 있는 모든 컨테이너의 표준 출력을 수집할지 여부입니다. allContainers=true인 경우 workloa, includeLabels 및 excludeLabels를 동시에 지정할 수 없습니다.
container: xxx   ## 로그가 수집될 컨테이너의 이름입니다. 이름이 비어 있으면 일치하는 모든 컨테이너의 로그 이름이 수집됨을 나타냅니다. 
excludeLabels:  ## 지정된 label이 있는 Pod가 제외됩니다. workload, namespace 및 excludeNamespace가 지정된 경우 이 필드를 지정할 수 없습니다.
key2: value2  ## 동일한 key의 여러 value를 가진 pod를 일치시킬 수 있습니다. 예를 들어 enviroment = production,qa를 입력하면 enviroment key의 production 또는 qa value를 가진 pod가 제외됩니다. 여러 value를 쉼표로 구분합니다. includeLabels도 지정하면 교차에 있는 pod가 일치합니다.

includeLabels:  ## 지정된 label이 있는 Pod가 수집됩니다. workload, namespace 및 excludeNamespace가 지정된 경우 이 필드를 지정할 수 없습니다.
key: value1  ## metadata는 수집 규칙에 따라 수집된 로그와 함께 소비자에게 보고됩니다. 동일한 key의 여러 value가 있는 pod를 일치시킬 수 있습니다. 예를 들어 enviroment = production,qa를 입력하면 enviroment key의 production 또는 qa value가 있는 pod가 일치합니다. 여러 value를 쉼표로 구분합니다. excludeLabels도 지정하면 교차에 있는 pod가 일치합니다.

metadataLabels:  ## 메타데이터로 수집할 pod label을 지정합니다. 이 필드를 지정하지 않으면 모든 pod label이 메타데이터로 수집됩니다.
- label1
customLabels:  ## 사용자 정의 metadata
label: l1

workloads:
- container: xxx  ## 수집할 컨테이너의 이름입니다. 이 매개변수를 지정하지 않으면 workload Pod의 모든 컨테이너가 수집됨을 나타냅니다.
kind: deployment  ## workload 유형입니다. 지원되는 값에는 deployment, daemonset, statefulset, job 및 cronjob이 포함됩니다.
name: sample-app  ## workload 이름
namespace: prod  ## workload 네임스페이스

containerFile:  ## 컨테이너의 파일
namespace: default   ## 수집할 컨테이너의 Kubernetes 네임스페이스입니다. 네임스페이스를 지정해야 합니다.
excludeNamespace: nm1,nm2   ## 제외할 컨테이너의 Kubernetes 네임스페이스입니다. 여러 네임스페이스를 ","로 구분합니다(예: nm1,nm2). 이 필드를 지정하지 않으면 모든 네임스페이스를 나타냅니다. namespace가 지정된 경우 이 필드를 지정할 수 없습니다.
nsLabelSelector: environment in (production),tier in (frontend) ## 네임스페이스 label로 namespace 필터링
container: xxx   ## 로그를 수집할 컨테이너의 이름. *는 일치하는 모든 컨테이너의 로그 이름이 수집됨을 나타냅니다.
logPath: /var/logs   ## 로그 폴더. 와일드카드는 지원되지 않습니다.
filePattern: app_*.log  ## 로그 파일 이름. 와일드카드 * 및 ?를 지원합니다. *는 여러 임의의 문자와 일치하고 ?는 임의의 단일 문자와 일치합니다.
customLabels:  ## 사용자 정의 metadata
key: value
excludeLabels:  ## 지정된 label이 있는 Pod가 제외됩니다. workload가 지정된 경우 이 필드를 지정할 수 없습니다.
key2: value2  ## 동일한 key의 여러 value를 가진 pod를 매칭할 수 있습니다. 예를 들어 enviroment = production,qa를 입력하면 enviroment key의 production 또는 qa value를 가진 pod가 제외됩니다. 여러 value를 쉼표로 구분합니다. includeLabels도 지정하면 교차에 있는 pod가 일치합니다.

includeLabels:  ## 지정된 label이 있는 Pod가 수집됩니다. workload가 지정된 경우 이 필드를 지정할 수 없습니다.
key: value1  ## metadata는 수집 규칙에 따라 수집된 로그에 담겨 소비자에게 보고됩니다. 동일한 key의 여러 value가 있는 pod를 일치시킬 수 있습니다. 예를 들어 enviroment = production,qa를 입력하면 enviroment key의 production 또는 qa value가 있는 pod가 일치합니다. 여러 value를 쉼표로 구분합니다. excludeLabels도 지정하면 교차에 있는 pod가 일치합니다.
metadataLabels:  ## 메타데이터로 수집할 pod label을 지정합니다. 이 필드를 지정하지 않으면 모든 pod label이 메타데이터로 수집됩니다.
- label1   ## pod label
workload:
container: xxx   ## 수집할 컨테이너의 이름. 이 매개변수를 지정하지 않으면 workload Pod의 모든 컨테이너가 수집됨을 나타냅니다.
name: sample-app  ## workload 이름

로그 구문 분석 형식

단일 행 전체 텍스트
다중 행의 전체 텍스트
단일 행-전체 정규식
다중 행-전체 정규식
JSON 형식
세퍼레이터 형식
단일 행에 전체 텍스트가 있는 로그는 전체 로그가 한 행을 차지함을 의미합니다. CLS는 로그를 수집할 때 \\n을 줄 바꿈으로 사용하여 로그를 종료합니다. 더 쉬운 구조 관리를 위해 각 로그에는 기본 키 값 __CONTENT__가 제공됩니다. 그러나 로그 데이터 자체는 더 이상 구조화되지 않으며 로그 필드는 추출되지 않습니다. 시간 로그 속성은 로그가 수집되는 시간에 따라 다릅니다. 자세한 내용은 단일 행 전체 텍스트를 참고하십시오.
로그의 원시 데이터가 다음과 같다고 가정합니다.
Tue Jan 22 12:08:15 CST 2019 Installed: libjpeg-turbo-static-1.2.90-6.el7.x86_64
LogConfig 구성 샘플은 다음과 같습니다.
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
# 단일 행 로그
logType: minimalist_log
CLS에 수집된 데이터는 다음과 같습니다.
__CONTENT__:Tue Jan 22 12:08:15 CST 2019 Installed: libjpeg-turbo-static-1.2.90-6.el7.x86_64
다중 행에 전체 텍스트가 있는 로그는 전체 로그가 다중 행을 차지할 수 있음을 의미합니다(예: Java stacktrace). 이 형식에서 줄바꿈 \\n은 로그의 끝 표시로 사용할 수 없습니다. CLS 시스템에서 로그를 구별할 수 있도록 첫 행 정규 표현식이 일치에 사용됩니다. 행의 로그가 미리 설정된 정규 표현식과 일치하면 로그의 시작으로 간주되며 일치하는 다음 행은 로그의 끝 표시가 됩니다. 이 형식에서는 기본 키 값 __CONTENT__도 설정됩니다. 그러나 로그 데이터 자체는 더 이상 구조화되지 않으며 로그 필드는 추출되지 않습니다. 시간 로그 속성은 로그가 수집되는 시간에 따라 다릅니다. 자세한 내용은 다중 행의 전체 텍스트를 참고하십시오.
여러 행 로그의 원시 데이터가 다음과 같다고 가정합니다.
2019-12-15 17:13:06,043 [main] ERROR com.test.logging.FooFactory:
java.lang.NullPointerException
at com.test.logging.FooFactory.createFoo(FooFactory.java:15)
at com.test.logging.FooFactoryTest.test(FooFactoryTest.java:11)

LogConfig의 샘플은 다음과 같습니다.
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
#다중 행 로그
logType: multiline_log
extractRule:
#날짜 시간으로 시작하는 행만 새 로그의 시작으로 간주됩니다. 그렇지 않으면 현재 로그 끝에 줄 바꿈 \\n을 추가합니다.
beginningRegex: \\d{4}-\\d{2}-\\d{2}\\s\\d{2}:\\d{2}:\\d{2},\\d{3}\\s.+

CLS에 수집된 데이터는 다음과 같습니다.
\\_\\_CONTENT__:2019-12-15 17:13:06,043 [main] ERROR com.test.logging.FooFactory:\\njava.lang.NullPointerException\\n at com.test.logging.FooFactory.createFoo(FooFactory.java:15)\\n at com.test.logging.FooFactoryTest.test(FooFactoryTest.java:11)

완전한 정규식은 구조화된 로그를 처리하는 데 자주 사용됩니다. 정규식을 기반으로 여러 key-value 쌍을 추출하여 전체 로그를 구문 분석합니다. 자세한 내용은 완전한 정규식 로그 수집을 참고하십시오. 로그의 원시 데이터가 다음과 같다고 가정합니다.
10.135.46.111 - - [22/Jan/2019:19:19:30 +0800] "GET /my/course/1 HTTP/1.1" 127.0.0.1 200 782 9703 "http://127.0.0.1/course/explore?filter%5Btype%5D=all&filter%5Bprice%5D=all&filter%5BcurrentLevelId%5D=all&orderBy=studentNum" "Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0" 0.354 0.354

LogConfig의 샘플은 다음과 같습니다.
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
# 완전한 정규식
logType: fullregex_log
extractRule:
# () 캡처 그룹을 기준으로 해당 value를 추출하는 정규 표현식
logRegex: (\\S+)[^\\[]+(\\[[^:]+:\\d+:\\d+:\\d+\\s\\S+)\\s"(\\w+)\\s(\\S+)\\s([^"]+)"\\s(\\S+)\\s(\\d+)\\s(\\d+)\\s(\\d+)\\s"([^"]+)"\\s"([^"]+)"\\s+(\\S+)\\s(\\S+).*
beginningRegex: (\\S+)[^\\[]+(\\[[^:]+:\\d+:\\d+:\\d+\\s\\S+)\\s"(\\w+)\\s(\\S+)\\s([^"]+)"\\s(\\S+)\\s(\\d+)\\s(\\d+)\\s(\\d+)\\s"([^"]+)"\\s"([^"]+)"\\s+(\\S+)\\s(\\S+).*
# 추출된 value와 일대일 대응하는 추출된 key 목록
keys: ['remote_addr','time_local','request_method','request_url','http_protocol','http_host','status','request_length','body_bytes_sent','http_referer','http_user_agent','request_time','upstream_response_time']

CLS에 수집된 데이터는 다음과 같습니다.
body_bytes_sent: 9703
http_host: 127.0.0.1
http_protocol: HTTP/1.1
http_referer: http://127.0.0.1/course/explore?filter%5Btype%5D=all&filter%5Bprice%5D=all&filter%5BcurrentLevelId%5D=all&orderBy=studentNum
http_user_agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0
remote_addr: 10.135.46.111
request_length: 782
request_method: GET
request_time: 0.354
request_url: /my/course/1
status: 200
time_local: [22/Jan/2019:19:19:30 +0800]
upstream_response_time: 0.354

다중 행-전체 정규 표현식 모드는 정규 표현식을 기반으로 로그 텍스트 파일(예시: Java 프로그램 로그)의 다중 행에 걸쳐 있는 완전한 로그 데이터 조각에서 여러 key-value 쌍을 추출할 수 있는 로그 구문 분석 모드입니다. key-value 쌍을 추출할 필요가 없다면 다중 행에 있는 전체 텍스트의 지시에 따라 구성하십시오. 자세한 내용은 다중 행-전체 텍스트를 참고하십시오.
로그의 원시 데이터가 다음과 같다고 가정합니다.
[2018-10-01T10:30:01,000] [INFO] java.lang.Exception: exception happened
at TestPrintStackTrace.f(TestPrintStackTrace.java:3)
at TestPrintStackTrace.g(TestPrintStackTrace.java:7)
at TestPrintStackTrace.main(TestPrintStackTrace.java:16)

LogConfig의 샘플은 다음과 같습니다.
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
#다중 행-전체 정규식
logType: multiline_fullregex_log
extractRule:
#첫 행 전체 정규 표현식: 날짜 시간으로 시작하는 행만 새 로그의 시작으로 간주됩니다. 그렇지 않으면 현재 로그 끝에 줄 바꿈 \\n을 추가합니다.
beginningRegex: \\[\\d+-\\d+-\\w+:\\d+:\\d+,\\d+\\]\\s\\[\\w+\\]\\s.*
#() 캡처 그룹을 기준으로 해당 value를 추출하는 정규 표현식
logRegex: \\[(\\d+-\\d+-\\w+:\\d+:\\d+,\\d+)\\]\\s\\[(\\w+)\\]\\s(.*)
# 추출된 value와 일대일 대응하는 추출된 key 목록
keys:
- time
- level
- msg

추출된 key를 기반으로 CLS에 수집되는 데이터는 다음과 같습니다.
time: 2018-10-01T10:30:01,000`
level: INFO`
msg:java.lang.Exception: exception happened
at TestPrintStackTrace.f(TestPrintStackTrace.java:3)
at TestPrintStackTrace.g(TestPrintStackTrace.java:7)
at TestPrintStackTrace.main(TestPrintStackTrace.java:16)

JSON 로그는 첫 번째 레이어의 key를 필드 이름으로, 첫 번째 레이어의 value를 필드 값으로 자동 추출하여 전체 로그의 구조화된 처리를 구현합니다. 각 전체 로그는 줄 바꿈 \\n으로 끝납니다. 자세한 내용은 JSON 형식을 참고하십시오.
JSON 로그의 원시 데이터가 다음과 같다고 가정합니다.
{"remote_ip":"10.135.46.111","time_local":"22/Jan/2019:19:19:34 +0800","body_sent":23,"responsetime":0.232,"upstreamtime":"0.232","upstreamhost":"unix:/tmp/php-cgi.sock","http_host":"127.0.0.1","method":"POST","url":"/event/dispatch","request":"POST /event/dispatch HTTP/1.1","xff":"-","referer":"http://127.0.0.1/my/course/4","agent":"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0","response_code":"200"}

LogConfig의 샘플은 다음과 같습니다.
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
# JSON 형식 로그
logType: json_log

CLS에 수집된 데이터는 다음과 같습니다.
agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0
body_sent: 23
http_host: 127.0.0.1
method: POST
referer: http://127.0.0.1/my/course/4
remote_ip: 10.135.46.111
request: POST /event/dispatch HTTP/1.1
response_code: 200
responsetime: 0.232
time_local: 22/Jan/2019:19:19:34 +0800
upstreamhost: unix:/tmp/php-cgi.sock
upstreamtime: 0.232
url: /event/dispatch
xff: -

세퍼레이터 로그에서 전체 로그 데이터는 지정된 세퍼레이터에 따라 구조화될 수 있으며 각 전체 로그는 줄 바꿈 \\n으로 끝납니다. CLS에서 세퍼레이터 로그를 처리할 때 개별 필드마다 고유 key를 정의해야 합니다. 자세한 내용은 세퍼레이터 형식을 참고하십시오.
원시 로그가 다음과 같다고 가정합니다.
10.20.20.10 ::: [Tue Jan 22 14:49:45 CST 2019 +0800] ::: GET /online/sample HTTP/1.1 ::: 127.0.0.1 ::: 200 ::: 647 ::: 35 ::: http://127.0.0.1/

LogConfig의 샘플은 다음과 같습니다.
apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
clsDetail:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
#세퍼레이터 로그
logType: delimiter_log
extractRule:
#세퍼레이터
delimiter: ':::'
#분리된 필드에 일대일로 대응되는 추출된 key 목록
keys: ['IP','time','request','host','status','length','bytes','referer']

CLS에 수집된 데이터는 다음과 같습니다.
IP: 10.20.20.10
bytes: 35
host: 127.0.0.1
length: 647
referer: http://127.0.0.1/
request: GET /online/sample HTTP/1.1
status: 200
time: [Tue Jan 22 14:49:45 CST 2019 +0800]

로그 수집 유형

컨테이너 표준 출력

샘플1: default 네임스페이스에 있는 모든 컨테이너의 표준 출력 수집

apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
inputDetail:
type: container_stdout
containerStdout:
namespace: default
allContainers: true
...

샘플2: production 네임스페이스의 ingress-gateway deployment에 속하는 pod에서 컨테이너 표준 출력 수집

apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
inputDetail:
type: container_stdout
containerStdout:
allContainers: false
workloads:
- namespace: production
name: ingress-gateway
kind: deployment
...

샘플3: pod 레이블에 production 네임스페이스 아래에 "k8s-app=nginx"가 포함된 pod에서 컨테이너 표준 출력 수집

apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
inputDetail:
type: container_stdout
containerStdout:
namespace: production
allContainers: false
includeLabels:
k8s-app: nginx
...

컨테이너 파일

샘플1: production 네임스페이스 아래의 ingress-gateway deployment에 속하는 pod의 nginx 컨테이너에 있는 /data/nginx/log/ 경로에서 access.log 파일 수집

apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
topicId: xxxxxx-xx-xx-xx-xxxxxxxx
inputDetail:
type: container_file
containerFile:
namespace: production
workload:
name: ingress-gateway
type: deployment
container: nginx
logPath: /data/nginx/log
filePattern: access.log
...

샘플2: production 네임스페이스 아래 “k8s-app=ingress-gateway”가 포함된 pod 레이블이 있는 pod의 nginx 컨테이너에 있는 /data/nginx/log/ 경로에서 access.log 파일 수집

apiVersion: cls.cloud.tencent.com/v1
kind: LogConfig
spec:
inputDetail:
type: container_file
containerFile:
namespace: production
includeLabels:
k8s-app: ingress-gateway
container: nginx
logPath: /data/nginx/log
filePattern: access.log
...

메타데이터(Metadata)

컨테이너 표준 출력(container_stdout) 및 컨테이너 파일(container_file)의 경우 원시 로그 콘텐츠 외에도 컨테이너 메타데이터(예시: 로그를 생성한 컨테이너의 ID)도 전달되어 CLS에 보고되어야 합니다. 이러한 방식으로 사용자는 로그를 볼 때 로그 소스를 추적하거나 컨테이너 식별자 또는 특성(예: 컨테이너 이름 및 labels)을 기반으로 검색할 수 있습니다.
다음 표에는 메타데이터가 나열되어 있습니다.
필드 이름
의미
cluster_id
로그가 속한 클러스터의 ID.
container_name
로그가 속한 컨테이너의 이름.
image_name
로그가 속한 컨테이너의 이미지 이름 IP.
namespace
로그가 속한 pod의 namespace.
pod_uid
로그가 속한 pod의 UID.
pod_name
로그가 속한 pod의 이름.
pod_ip
로그가 속한 pod의 IP.
pod_lable_{label name}
로그가 속한 pod의 label(예를 들어 pod에 label: app=nginx, env=prod라는 두 개의 레이블이 있는 경우 보고된 로그에는 두 개의 메타데이터 항목 metedata: pod_label_app:nginx, pod_label_env:prod이 첨부됩니다).


도움말 및 지원

문제 해결에 도움이 되었나요?

피드백