최근 출시된 카우치베이스 자율 운영자(CAO) 2.2최근에 제공한 로그 처리 및 전달 를 사용하여 쿠버네티스 배포를 위한 OSS 플루언트 비트 툴링을 사용합니다. 이것은 또한 OSS와 GitHub에서 사용 가능 또는 컨테이너로.
유창한 비트 는 임베디드 대상용 네이티브 로그 포워딩 솔루션으로 시작되었으므로 다음과 같은 용도로 Kubernetes 솔루션을 재사용할 수 있습니다. 온프레미스 배포 또는 CAO 없이 Kubernetes를 사용하는 사용자도 마찬가지입니다.
이 블로그 게시물에서는 다양한 구성 요소에 대한 배경 설명과 함께 이를 수행하는 방법을 안내합니다. 자세한 내용을 보려면 로그 포워딩 섹션을 참조하세요. 완전히 작동하는 예는 다음과 같습니다. 이 깃허브 리포지토리에서 사용할 수 있습니다..
플루언트 비트는 무엇인가요?
플루언트 비트는 로그 처리 및 전송을 처리하는 데 널리 사용되는 고성능 OSS 솔루션입니다. 아직 중앙 집중식 로그 솔루션이 없는 경우, 이 포스팅에서는 이를 쉽게 제공할 수 있는 방법을 설명합니다. 특히 다음 중 어느 곳으로든 감사 로그를 전달할 때를 예로 들어보겠습니다. 플루언트 비트에서 제공하는 지원 대상 (예: S3).
플루언트 비트는 기본적으로 다음을 소비할 수 있는 구성 가능한 파이프라인입니다. 여러 입력 유형를 클릭하고 구문 분석, 필터링 또는 변환한 후 다음 주소로 전송합니다. 여러 출력 대상 최소한의 노력으로 S3, Splunk, Loki 및 Elasticsearch와 같은 것을 포함합니다. 다음이 있습니다. 사용 가능한 많은 문서 이 모든 것이 어떻게 작동하는지에 대해 자세히 설명합니다.
쿠버네티스 배포 내에서 널리 사용된다(예: GKE와 AWS는 기본적으로 배포한다). 데몬셋 이는 단지 애플리케이션( daemon) 클러스터를 구성하는 모든 쿠버네티스 노드에서 실행합니다. 플루언트 비트는 일반적으로 다양한 컨테이너 로그를 추적합니다(컨테이너 모범 사례는 stdout 를 생성하고 컨테이너 런타임이 이를 로컬로 회전된 파일로 푸시합니다.) 그리고 로컬 노드에서 중앙 집중식 로그 관리 도구로 전달할 수 있도록 지원합니다. 새로운 바이너리를 배포할 필요 없이 구성 변경만으로 모든 것이 관리됩니다.
플루언트 비트는 로그를 다음과 같이 변환합니다. 구조화된 데이터 를 공통 내부 형식(메시지팩바이너리에 최적화된 JSON 형식)을 사용하여 다양한 플러그인이 작업할 수 있도록 지원하거나(예: 일반 플러그인으로 무언가를 필터링하거나 변환하려면 공통 형식이 필요함) 해당 엔드포인트에 적합한 형식으로 특정 출력으로 전송할 수 있습니다. 이를 위해 플루언트 비트는 파서. 그러나 변환을 간소화하고 구문 분석에 실패할 경우 폴백으로 파일에서 전체 줄을 하나의 키-값 쌍으로 읽는 것을 지원합니다.
플루언트 비트가 포함된 카우치베이스 로깅 솔루션
OSS 플루언트 비트 솔루션은 다음을 만족하도록 확장되었습니다. 몇 가지 특정 카우치베이스 요구사항와 같이:
-
- 카우치베이스 서버를 다시 시작하거나 리밸런싱을 트리거하지 않고도 동적 구성 변경을 지원합니다. 이는 CAO 사용 사례에서는 중요하지만 온프레미스에서는 덜 중요할 수 있습니다.
- 비행 중 수정 지원 및 재조정 보고서의 사전 처리.
- 공통된 접근 방식으로 다양한 로그 파일을 처리합니다.
이 중 온프레미스 배포에서 가장 중요한 것은 다양한 로그 파일을 처리하는 것입니다.
다음에서 생성된 로그 파일 카우치베이스 서버 는 다양한 고유한 형식으로 되어 있고 일부 로그 문은 여러 줄에 걸쳐 있기 때문에 한 줄씩 전송하는 것은 이상적이지 않습니다. 대부분의 도구는 이를 처리할 수 있지만(예: PromTail은 여러 줄로 구성된 문도 구문 분석 가능), 특정 구성이 필요한 반면, 저희 솔루션은 이미 이 모든 것을 해결합니다.
기본 구문 분석기 세트는 다음과 같이 제작되었습니다. 다양한 로그 처리 이 또한 OSS Fluent Bit 프로젝트에 다시 기여했습니다: 릴리스 1.7.6+부터 파서는 다음과 같습니다. 공식 이미지 및 바이너리 설치에서 사용 가능. 즉, 여기에 제시된 모든 것이 완전히 OSS이며 Couchbase 전용 배포 없이도 사용할 수 있습니다.
그라파나, 프로메테우스 및 로키 사용
Grafana는 오픈 소스 통합 가시성 플랫폼입니다. 다양한 데이터 소스를 처리하여 플랫폼이 수행 중인 작업을 실시간으로 표시하고 특정 조건이 충족되면 알림을 트리거할 수 있습니다. 동일한 스택에는 다음이 포함될 수 있습니다. 프로메테우스 메트릭 모니터링 및 로키 를 사용하여 로그 저장 및 쿼리를 수행합니다.
이 블로그 게시물에서는 이러한 기술을 플루언트 비트가 목표로 삼을 수 있는 동등한 중앙 집중식 통합 가시성 플랫폼의 플레이스홀더로 사용하고 있습니다. 여기서는 데모 목적으로 로컬에서 테스트 스택으로 간단히 실행할 수 있습니다. 이와는 별도로, Couchbase는 이미 Prometheus 메트릭 모니터링 옵션 에서도 동일한 방식으로 통합할 수 있습니다.
이 스택을 대체할 수 있는 솔루션으로는 Splunk, Kibana가 포함된 Elasticsearch 또는 Amazon Cloudwatch 또는 Azure Log Analytics와 같은 관리형 솔루션이 있습니다.
이러한 모든 도구를 온프레미스에서 실행하는 방법
이 섹션에서는 온프레미스 배포에서 플루언트 비트를 사용하여 로그 포워딩 솔루션을 실행하는 방법에 대한 튜토리얼 형식의 세부 정보를 제공합니다.
온프레미스 배포에서 플루언트 비트 포 카우치베이스 서버용 로그 포워딩 솔루션을 실행하는 것은 공식적으로 지원되지 않는다는 점에 유의하세요.
권장 사항은 카우치베이스 플루언트 비트 컨테이너 (또는 공식 플루언트 비트)를 설치해야 합니다. 그러나 플루언트 비트는 직접 설치할 수도 있으며 Couchbase 플루언트 비트 이미지에서 제공하는 구성을 재사용하여 동일한 효과를 대부분(전부는 아님) 얻을 수 있습니다.
모든 카우치베이스 서버 6.6.2+에서 지원되는 플랫폼 컨테이너를 실행할 수 있습니다. 컨테이너 런타임 설치에 대한 설명서는 여기를 참조하세요.. Windows 플랫폼에서 Linux 컨테이너에 대한 지원을 사용 설정해야 합니다.
이 블로그 포스팅에서는 로컬 클러스터를 실행하기 위해 컨테이너화된 버전의 Couchbase Server를 사용하고, 그 다음 Couchbase 플루언트 비트 컨테이너를 로그에 연결하는 방법을 보여드리겠습니다. 네이티브 서버 바이너리를 직접 사용할 수도 있습니다.
Couchbase Server 컨테이너는 순전히 로그를 생성하기 위한 예제로 실행됩니다. 이미 실행 중인 서버가 있는 경우 해당 서버의 로그 디렉터리를 사용하세요. 로그 포워딩 섹션. 마찬가지로 Couchbase Server에 네이티브 바이너리를 사용하려는 경우에도 가능합니다.
1단계: Couchbase 서버 배포
이미 배포된 인스턴스가 있는 경우 이 섹션은 무시하세요. 컨테이너화된 버전인 경우 로그 디렉터리가 다음을 통해 노출되는지 확인하세요. 볼륨 또는 바인드 마운트 를 호스트에 추가합니다(아래 튜토리얼에서 설명하는 것처럼).
안내에 따라 컨테이너 세트를 배포하려면 다음과 같이 하세요. 를 Couchbase 클러스터로 사용하지만 로그용 볼륨이 있습니다:
|
1 2 3 |
mkdir -p /tmp/카우치베이스-로그 도커 실행 --rm -d --이름 db -p 8091-8096:8091-8096 -p 11210-11211:11210-11211 \ -v /tmp/카우치베이스-로그/:/opt/카우치베이스/var/lib/카우치베이스/로그/ 카우치베이스:6.6.2 |
여기서 가장 중요한 것은 다른 컨테이너가 로그를 가져올 수 있도록 Couchbase Server에서 생성된 로그를 노출하는 것입니다. 그렇지 않으면 모두 컨테이너 내부에 격리됩니다. 네이티브 바이너리 배포의 경우, 호스트의 디렉터리에 쓰기만 하므로 이 작업이 필요하지 않습니다.
카우치베이스 서버 문서에서 로그 디렉토리의 위치를 자세히 설명합니다..
이것은 다음과 같은 네임드 컨테이너를 사용한다는 점에 유의하십시오. db 와 충돌하여 오류가 발생하므로 이미 존재하지 않는지 확인해야 합니다. 도커 RM DB. 위의 명령은 종료 시 컨테이너를 자동으로 정리합니다.
이제 디렉터리에 로그가 생성되는 것을 확인할 수 있습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
ls -l /tmp/카우치베이스-로그 합계 1344 -rw-r----- 1 patrickstephens 휠 23330 4 Jun 11:11 베이비시터.로그 -rw-r----- 1 patrickstephens 휠 152 4 Jun 11:11 couchdb.로그 -rw-r----- 1 patrickstephens 휠 330926 4 Jun 11:11 debug.로그 -rw-r----- 1 patrickstephens 휠 0 4 Jun 11:11 오류.로그 -rw-r----- 1 patrickstephens 휠 6926 4 Jun 11:11 goxdcr.로그 -rw-r----- 1 patrickstephens 휠 0 4 Jun 11:11 http_access.로그 -rw-r----- 1 patrickstephens 휠 2073 4 Jun 11:11 http_access_internal.로그 -rw-r----- 1 patrickstephens 휠 73345 4 Jun 11:11 정보.로그 -rw-r----- 1 patrickstephens 휠 1928 4 Jun 11:11 json_rpc.로그 -rw-r----- 1 patrickstephens 휠 0 4 Jun 11:11 mapreduce_errors.로그 -rw-r----- 1 patrickstephens 휠 5303 4 Jun 11:11 멤캐시드.로그.000000.txt -rw-r----- 1 patrickstephens 휠 1389 4 Jun 11:11 metakv.로그 -rw-r----- 1 patrickstephens 휠 67103 4 Jun 11:11 NS_COUCHDB.로그 drwxr-x--- 2 patrickstephens 휠 64 4 Jun 11:11 재조정 -rw-r----- 1 patrickstephens 휠 144264 4 Jun 11:11 보고서.로그 -rw-r----- 1 patrickstephens 휠 4803 4 Jun 11:11 통계.로그 -rw-r----- 1 patrickstephens 휠 0 4 Jun 11:11 조회수.로그 -rw-r----- 1 patrickstephens 휠 0 4 Jun 11:11 xdcr_target.로그 |
이 배포의 목적상 클러스터를 실제로 구성할 필요는 없지만 적절한 로그와 데이터를 얻기 위해 클러스터를 구성하는 것이 유용합니다. 공식 문서의 지침을 따르세요. 를 사용하여 UI를 통해 클러스터를 구성하고 원하는 경우 일부 샘플 데이터도 가져올 수 있습니다.
동일한 노드에서 여러 컨테이너를 실행하여 다중 노드 Couchbase Server 클러스터를 시뮬레이션하려면 각 컨테이너에 대해 별도의 로그 디렉터리(또는 볼륨)를 사용해야 합니다. 그런 다음 로그 포워딩의 다음 섹션에 따라 각 디렉터리를 마운트하는 Couchbase Server 컨테이너당 Couchbase 플루언트 비트 이미지를 실행하세요.
2단계: 로그 포워딩
블로그 게시물의 핵심은 이 섹션에 있습니다: Couchbase 플루언트 비트에서 처리 및 전달하도록 Couchbase Server 로그를 구성하려면 어떻게 해야 하나요?
클러스터를 구성하고 선택적으로 일부 버킷, 샘플 데이터 등을 추가한 후에는 Fluent Bit 컨테이너를 실행할 수 있습니다. Couchbase Fluent Bit 이미지를 사용할 때 이 과정은 매우 간단합니다:
|
1 2 |
도커 실행 --rm -d --이름 logger -v /tmp/카우치베이스-로그/:/opt/카우치베이스/var/lib/카우치베이스/로그/:ro \ -e COUCHBASE_LOGS=/opt/카우치베이스/var/lib/카우치베이스/로그/ 카우치베이스/유창한-bit:1.0.1 |
여기에서 볼 수 있듯이 로컬 디렉터리를 마운트하고 환경 변수로 지정합니다(따라서 컨테이너의 다른 위치에 마운트하고 해당 위치를 가리키면 됩니다). 이것이 기본적으로 배포된 Couchbase Server에서 사용하는 방법입니다: 이 예제에서 사용한 임시 디렉터리 대신 로그에 대한 로컬 디렉터리를 컨테이너에 마운트합니다.
다음 공식 문서를 참조하세요. 카우치베이스 서버가 로그를 저장하는 위치에 대한 구체적인 세부 정보. 이 기본 디렉토리는 위와 같이 Couchbase Fluent Bit 이미지에 마운트해야 하는 디렉터리입니다. 권한 문제도 주의하세요.
그리고 카우치베이스 플루언트 비트 리포지토리 문서에는 다양한 구성 옵션이 명시되어 있습니다. 및 기본값을 변경할 수 있습니다. Couchbase Fluent Bit 1.0.1 버전의 이미지에서 처리할 로그의 기본 위치는 Couchbase Server 6.6.2에서 사용하는 위치와 약간 다르므로 위에서 이를 재정의하여 두 버전에서 동일한 위치를 사용합니다. (이후 버전의 Couchbase Fluent Bit 이미지는 Couchbase Server 위치와 일치하지만 이 글의 범위를 벗어난 다른 기능을 소개합니다.)
이제 컨테이너가 실행되고 로컬에 있는 디렉터리에서 로그를 처리하여 기본적으로 표준 출력 스트림으로 보내야 합니다. Fluent Bit를 사용하면 다음과 같이 호출하면 이를 확인할 수 있습니다. 도커 로그 로거 로 설정하면 로그가 업데이트될 때 출력되는 것을 볼 수 있습니다:
|
1 2 3 |
[0] 카우치베이스.로그.xdcr: [1622801916.603000000, {"파일 이름"=>"/옵트/카우치베이스/변/라이브/카우치베이스/로그//goxdcr.log", "timestamp"=>"2021-06-04T10:18:36.603Z", "level"=>"INFO", "메시지"=>" GOXDCR.ResourceMgr: 리소스 관리자 상태 = 전체TP: 0 높은TP: 0 높은Exist: 거짓 낮은Exist: 거짓 백로그Exist: 거짓 최대TP: 0 높은TPNeeded: 0 높은 토큰: 0 최대 토큰: 0 낮은 토큰 제한: 0 보정: 없음 dcpAction: 프로세스 재설정Cpu: 1 idleCpu: 95", "pod"=>"c901775dec2b", "logshipper"=>"couchbase.sidecar.fluentbit"}] [0] 카우치베이스.로그.debug: [1622801986.855000000, {"파일 이름"=>"/옵트/카우치베이스/변/라이브/카우치베이스/로그//debug.log", "logger"=>"ns_server", "level"=>"debug", "timestamp"=>"2021-06-04T10:19:46.855Z", "메시지"=>"ns_1@cb.local:compaction_daemon:압축_데몬:프로세스_스케줄러_메시지:1306]compact_views에 대해 압축할 버킷이 없습니다. 압축 일정을 다시 잡는 중입니다.", "pod"=>"c901775dec2b", "logshipper"=>"couchbase.sidecar.fluentbit"}] [0] 카우치베이스.로그.http_access_internal: [1622801986.000000000, {"파일 이름"=>"/opt/couchbase/var/lib/couchbase/logs//http_access_internal.log", "host"=>"127.0.0.1", "user"=>"@goxdcr-cbauth", "timestamp"=>"04/Jun/2021:10:19:46 +0000", "method"=>"GET", "경로"=>"/풀/노드", "code"=>"404", "size"=>"14", "client"=>"couchbase-goxdcr/6.6.2", "pod"=>"c901775dec2b", "logshipper"=>"couchbase.sidecar.fluentbit"}] |
이것은 여러분이 얻을 수 있는 결과물의 예일 뿐입니다.
각 로그 파일 플루언트 비트 태그를 사용하는 자체 스트림이 있습니다. 형식으로 입력합니다: couchbase.log.. 이를 통해 개별 로그의 다른 처리 또는 라우팅을 수행할 수 있습니다. 예를 들어, 감사 로그가 다른 로그와 다른 특정 엔드포인트로 이동해야 하거나 특정 로그에서 줄을 필터링해야 할 수 있습니다. 여러 항목 또는 동일한 항목을 서로 다른 출력에 일치시킬 수도 있습니다.
컨테이너 실행은 다음을 사용하여 시작 스크립트의 일부로 수행할 수 있습니다. systemd 또는 카우치베이스 서버와 유사합니다. 컨테이너 런타임은 또한 매번 지정된 컨테이너를 자동으로 시작.
3단계: Grafana에서 라이브 로그 시각화하기
컨테이너에서 제공하는 기본 구성은 모든 로그를 표준 출력으로 전송하는 것입니다. 그러나 다른 변경 없이 다른 작업을 수행하는 데 사용할 자체 구성 파일을 제공할 수 있습니다. 간단한 구성 변경만으로 로그 처리 및 전달을 수정할 수 있다는 점은 Fluent Bit의 주요 장점 중 하나입니다.
이를 강조하기 위해 로컬 버전의 로키 스택는 로그 캡처를 위한 Grafana와 Loki(그리고 메트릭 캡처를 위한 Prometheus)입니다. 그런 다음 로그를 Loki로 전송하도록 컨테이너를 구성하여 Grafana에서 그래픽으로 시각화할 수 있도록 합니다. Loki 및 Grafana 문서에는 Loki 스택을 배포하는 다른 방법이 나와 있으므로 자세한 내용은 위에 링크된 해당 문서를 참조하세요.
A 아래 섹션의 전체 작업 예제는 깃허브의 카우치베이스 플루언트 비트 리포지토리에 제공됩니다. 사용 도커 컴포즈 를 사용하여 컨테이너가 모두 올바르게 구성되도록 실행합니다.
이전에 구성한 로그 포워딩 컨테이너를 중지해야 합니다. 다른 컨테이너를 실행할 수도 있지만, 다음과 같이 다른 이름을 지정해야 합니다. 도커 스톱 로거.
이제 로키와 그라파나를 실행하여 각각에 필요한 포트가 노출되었는지 확인합니다(3100 그리고 3000 각각):
|
1 2 |
도커 실행 --rm -d --이름 loki -p 3100:3100 그라파나/loki:2.0.0 -구성.파일=/등/loki/local-구성.yaml 도커 실행 --rm -d --이름 그라파나 -p 3000:3000 -e gf_security_admin_password=비밀번호 그라파나/그라파나:7.5.2 |
다음 번호로 전화하여 둘 다 올바르게 시작되었는지 확인할 수 있습니다. 도커 PS 를 호출하여 플루언트 비트 로그를 확인하고 도커 로그.
Loki로의 포워딩을 지원하기 위해 이를 실행 중인 로컬 컨테이너의 IP 주소를 가져올 것입니다. 일반적으로는 확인 가능한 호스트 또는 서비스 이름으로 배포하지만 데모에서는 모든 것을 로컬 컨테이너로 실행합니다.
실행하는 경우 도커 검사 로키 를 입력하면 네트워킹 섹션과 함께 컨테이너에 대한 많은 정보가 출력됩니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
"네트워크": { "bridge": { "IPAMConfig": null, "링크": null, "별칭": null, "NetworkID": "eb681161db08003e6401b745b0a51c1e1183bee13462fae74ea68ab9736baf34", "엔드포인트ID": "28df33de36007bff0a00c14aa4617d235dadd882e5109feaf536fd1b9b980afd", "게이트웨이": "172.17.0.1", "IP주소": "172.17.0.4", "IPPrefixLen": 16, "IPv6게이트웨이": "", "GlobalIPv6Address": "", "GlobalIPv6PrefixLen": 0, "MacAddress": "02:42:AC:11:00:04", "DriverOpts": null } } |
IP 주소만 얻으려면 다음을 수행할 수 있습니다. 공식 문서에 따라 쿼리 형식을 지정합니다.:
|
1 2 |
도커 검사 --형식='{{범위 .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' loki 172.17.0.4 |
제 배포의 경우 IP 주소는 172.17.0.4이지만, 귀하의 배포는 다를 수 있으므로 나중에 대체하세요.
리포지토리에 제공된 예제에서는 Loki를 사용할 수 있도록 Grafana도 자동으로 프로비저닝하지만 여기서는 이 작업을 수동으로 수행해야 합니다. 다음 주소에 연결하면 http://localhost:3000/login 로 로그인한 다음, 그라파나에 관리자 사용자와 함께 비밀번호 를 위의 Grafana 컨테이너 실행 명령의 환경 변수에 추가합니다.
이제 로키를 데이터 소스로 추가해야 합니다: http://localhost:3000/datasources
Loki 컨테이너의 IP 주소와 포트를 사용하여 데이터 소스를 설정합니다. 3100 컨테이너를 처음 실행할 때 전달된 대로입니다:
4단계: 사용자 지정 구성
이제 로키와 그라파나가 올바르게 구성되었으므로 로그 전달자에 대한 새로운 구성을 만들어 로그를 전송해 보겠습니다.
Couchbase Fluent Bit 배포의 일부로 구성의 다양한 섹션을 재사용 가능한 파일로 분리하여 아래처럼 두 줄짜리 파일로 만들 수 있도록 했습니다:
|
1 2 |
@포함 /유창한-bit/등/유창한-bit.conf @포함 /유창한-bit/등/카우치베이스/out-loki.conf |
이제 이 파일에는 기존의 기본 구성과 함께 로키의 출력 기본적으로 사용되지는 않지만 포함되어 있습니다:
|
1 2 3 4 5 6 |
[출력] 이름 loki 일치 * 호스트 loki 레이블 job=카우치베이스-fluentbit 레이블_키 $파일 이름,$레벨 |
보시다시피 이 출력은 모든 입력과 일치하여 다음과 같은 호스트로 전송합니다. loki. 이 데모에서는 구성 파일에서 Loki를 실행하는 컨테이너의 특정 IP 주소를 사용하겠습니다:
|
1 2 3 4 5 6 7 8 9 10 11 |
cat < /tmp/유창한-bit.conf >> __EOF__ @포함 /유창한-bit/등/유창한-bit.conf [출력] 이름 loki 일치 * 호스트 172.17.0.4 레이블 job=카우치베이스-fluentbit 레이블_키 $파일 이름,$레벨 __EOF__ |
이제 로그 전달을 다시 실행하되 이 사용자 정의 구성을 사용하여 실행할 수 있습니다. 이름을 바꾸거나 이전 설정을 중지해야 합니다:
|
1 |
도커 실행 --rm -d --이름 logger -v /tmp/카우치베이스-로그/:/opt/카우치베이스/var/lib/카우치베이스/로그/:ro -e COUCHBASE_LOGS=/opt/카우치베이스/var/lib/카우치베이스/로그/ -v /tmp/유창한-bit.conf:/유창한-bit/구성/유창한-bit.conf:ro 카우치베이스/유창한-bit:1.0.1 |
또한 모든 것을 읽기 전용으로 마운트된 파일 시스템으로 실행하므로 컨테이너의 어떤 것도 수정할 수 없으며 원시 로그는 건드리지 않습니다.
5단계: 실시간 로그 보기
이제 로그가 로키와 그라파나로 전송되기 시작할 것입니다. 그런 다음 다음에서 로그를 볼 수 있습니다: http://localhost:3000/explore?orgId=1&left=%5B%22now-1h%22,%22now%22,%22Loki%22,%7B%22expr%22:%22%7Bjob%3D%5C%22couchbase-fluentbit%5C%22%7D%22%7D%5D
이제 대시보드를 만들고 Grafana에서 바로 실시간으로 로그를 볼 수 있습니다.
알려진 문제
잘못된 항목
Loki로 전송할 때 이와 같은 오류가 Fluent Bit 로그에 표시될 수 있습니다:
|
1 2 |
[2021/06/04 11:03:50] [오류] [출력:loki:loki.1] 172.17.0.4:3100, HTTP 상태=400 항목 와 함께 타임스탬프 2021-06-04 11:03:43.507 +0000 UTC 무시됨, 이유: '입력 오류' 에 대한 스트림: {job="카우치베이스-플루언트비트"} |
이것은 알려진 이슈 로키와 함께. 모든 스트림을 순서대로 수신해야 하지만 여러 스트림을 멀티플렉싱하려고 할 때 네트워크 지터로 인해 이것이 불가능할 때가 있습니다. 일반적으로 별도의 Loki 출력 플러그인을 사용하여 보낼 특정 스트림을 선택하고 각 플러그인에 대해 워커 스레드를 적용하는 것이 좋습니다. 이 블로그 게시물에서는 로그 출력 데모에만 Loki를 사용하므로 이 문제는 여기서 다루지 않습니다.
새로운 버전의 카우치베이스 플루언트 비트
이 블로그 게시물은 CAO 2.2에서 공식적으로 지원되는 버전인 Couchbase Fluent Bit 이미지의 1.0.1 버전을 다룹니다. 카우치베이스 자율 운영자는 완전히 다른 이미지를 포함하여 모든 버전을 사이드카로 사용할 수 있지만, 발생하는 문제에 대해서는 지원되지 않습니다.
이미지의 버전 1.0.2 및 1.0.3에는 특히 Loki와 통합할 때 몇 가지 추가적인 Kubernetes 통합 및 개선 사항이 포함되어 있습니다. 릴리스 노트 참조 에서 자세한 내용을 확인하세요.
안타깝게도 이러한 변경 사항 중 일부는 컨테이너를 실행할 때 추가 환경 변수를 지정해야 함을 의미합니다(CAO의 일부로 자동으로 수행됨). 이러한 변수가 없으면 실행에 실패하여 누락된 것으로 표시됩니다. 이러한 환경 변수는 명령줄에서 -e 키=값 구문을 사용할 수 없습니다. 이 문제는 다음 릴리즈의 Couchbase Fluent Bit 이미지 변경 사항에서 해결될 예정입니다. K8S-2171.
결론
이 글을 통해 Couchbase Server와 플루언트 비트에서 로그 포워딩을 사용하는 방법에 대한 좋은 맛보기가 되었기를 바랍니다.
이미 Couchbase Server에서 사용할 수 있는 Prometheus 모니터링 옵션이 있습니다. 카우치베이스 프로메테우스 익스포터 와 동일한 Grafana 스택을 하나의 통합 가시성 창으로 통합할 수 있습니다. Couchbase SDK는 Jaeger를 통해 다음과 같은 추적 지원을 제공합니다. 그라파나에 통합. 이러한 주제는 기존 블로그 게시물과 향후 블로그 게시물에서 다룰 주제이므로 계속 주시하세요.