Couchbase를 사용한 로그 전달 및 처리 가 그 어느 때보다 쉬워졌습니다.
다음을 지원합니다. 카우치베이스 자율 운영자(즉, 쿠버네티스)에 대한 로그 포워딩 및 감사 로그 관리를 지원합니다. 그리고 온프레미스 카우치베이스 서버 배포. 두 경우 모두 로그 처리는 유창한 비트.
플루언트 비트를 선택한 이유는 무엇인가요? Couchbase 사용자는 동적 구성이 가능한 공통 형식의 로그가 필요했고, 저희는 오버헤드를 최소화하는 업계 표준을 사용하고 싶었습니다. 플루언트 비트는 당연한 선택이었습니다.
이 문서에서는 Couchbase에서 로그 포워딩을 위해 Fluent Bit를 최대한 활용하기 위한 팁과 요령을 다룹니다. 저는 카우치베이스 자율 운영자 의 배포 예시를 살펴보았습니다. (이 게시물에 대한 자세한 내용은 다음 블로그에서 발표할 예정입니다. 다음 플루언트콘.)
플루언트 비트 이전에는 Couchbase 로그 형식이 여러 파일에 걸쳐 다양했습니다. 아래는 네 개의 서로 다른 로그 파일에 있는 한 줄입니다:
|
1 2 3 4 |
2021-03-09T17:32:25.520+00:00 DEBU CBAS.util.MXHelper [main] ignoring exception calling RuntimeMXBean.getBootClassPath; returning null java.lang.UnsupportedOperationException: Boot class path mechanism is not supported at sun.management.RuntimeImpl.getBootClassPath(Unknown Source) ~[?:?] at org.apache.hyracks.util.MXHelper.getBootClassPath(MXHelper.java:111) [hyracks-util.jar:6.6.0-7909] |
|
1 2 3 |
{"bucket":"default","description":"The specified bucket was selected","id":20492,"name":"select bucket","peername":"127.0.0.1:56021","real_userid":{"domain":"local","user":"@ns_server"},"sockname":"127.0.0.1:11209","timestamp":"2021-03-09T20:12:17.445039Z"} [ns_server:warn,2021-03-09T17:31:55.401Z,babysitter_of_ns_1@cb.local:ns_crash_log<0.102.0>:ns_crash_log:read_crash_log:148]Couldn't load crash_log from /opt/couchbase/var/lib/couchbase/logs/crash_log_v2.bin (perhaps it's first startup): {error, enoent} |
|
1 2 3 |
[error_logger:info,2021-03-09T17:31:55.401Z,babysitter_of_ns_1@cb.local:error_logger<0.32.0>:ale_error_logger_handler:do_log:203] =========================PROGRESS REPORT========================= supervisor: {local,ns_babysitter_sup} |
|
1 |
127.0.0.1 - @ [09/Mar/2021:17:32:02 +0000] "RPCCONNECT /goxdcr-cbauth HTTP/1.1" 200 0 - Go-http-client/1.1 |
이제 플루언트 비트로 업그레이드하면 다음과 같은 로그 보기를 실시간으로 스트리밍할 수 있습니다. 표준 쿠버네티스 로그 아키텍처 이는 또한 Grafana 대시보드와의 간단한 통합 및 기타 업계 표준 도구를 사용할 수 있습니다. 아래는 다음에서 가져온 스크린샷입니다. 플루언트 비트 리포지토리에 있는 로키 스택의 예시입니다..
플루언트 비트를 처음 사용하든 숙련된 전문가든, 이 문서가 Couchbase를 사용한 로그 처리의 복잡한 사용법을 탐색하는 데 도움이 되기를 바랍니다.
플루언트 비트에 대한 주요 질문이나 도전 과제는 무엇인가요?
아래 링크를 사용하여 플루언트 비트의 특정 과제나 질문으로 바로 이동하거나 더 아래로 스크롤하여 모든 팁과 요령을 읽어보세요.
플루언트 비트에 대해 질문하거나 안내를 받거나 제안을 하려면 어떻게 해야 하나요? OSS 커뮤니티에 참여하고 기여하기.
플루언트 비트에 어떤 문제가 있는지 어떻게 알 수 있나요? 사용 stdout 플러그인 및 디버깅 시 로그 레벨 업.
구문 분석기가 실패했는지 어떻게 알 수 있나요? 기본값이 표시되는 경우 로그 키를 입력하면 구문 분석에 실패했음을 알 수 있습니다..
정규식 구문 분석기가 작동하지 않는 이유는 무엇인가요? 특히 여러 줄 구문 분석을 위한 검증 및 간소화.
필드(예: 로그 수준)를 알려진 값으로 제한하려면 어떻게 하나요? 몇 가지 간단한 필터를 사용하여 출력 값을 제한하고 표준화하세요..
존재하지 않을 수 있는 선택적 정보를 추가하려면 어떻게 해야 하나요? 사용 record_modifier 필터가 아닌 수정 필터 - 선택적 정보를 포함하려는 경우.
어떤 플러그인이나 필터가 메트릭 또는 로그 메시지를 트리거하는지 식별하려면 어떻게 해야 하나요? 별칭 사용.
특수 또는 맞춤형 처리(예: 부분 삭제)를 완료하려면 어떻게 해야 하나요? Lua 필터를 사용하세요: 모든 것을 할 수 있습니다!.
변경 사항을 확인하거나 새 버전이 여전히 작동하는지 테스트하려면 어떻게 하나요? 자동화된 회귀 테스트 제공.
구성의 각 부분을 테스트하려면 어떻게 하나요? 구성을 더 작은 덩어리로 분리하세요. (보너스: 이렇게 하면 사용자 지정 재사용이 더 간단해집니다).
Red Hat OpenShift에서 Fluent Bit를 사용하려면 어떻게 해야 하나요?
아래 글에서 이러한 질문과 다른 많은 질문에 대한 답변을 드립니다. 자세히 살펴보겠습니다.
플루언트 비트란 무엇이며 왜 필요한가요?
그렇다면 플루언트 비트는 무엇인가요? 플루언트 비트는 플루언트의 더 예쁜 자매입니다.를 모두 클라우드 네이티브 컴퓨팅 재단(CNCF) 플루언트 조직의 프로젝트입니다.
플루언트 비트는 기본적으로 다양한 유형의 입력를 사용하여 구성 가능한 파이프라인 의 처리 를 입력한 다음 라우팅 해당 데이터를 여러 유형의 엔드포인트.
플루언트드와 플루언트 비트의 경우, 특히 다음과 같은 간단한 작업에만 필요한 경우 후자가 플루언트드보다 더 나은 선택입니다. 최소한의 처리로 로그 포워딩 더 복잡한 것은 없습니다.
Fluent Bit를 사용하기 전에 Logstash, Promtail, rsyslog 등 여러 가지 다른 옵션을 검토했지만, 몇 가지 이유로 결국 Fluent Bit로 결정했습니다. 첫째, CNCF에서 지원하는 OSS 솔루션이며 이미 온프레미스 및 클라우드 제공업체에서 널리 사용되고 있다는 점입니다. 둘째, 가볍고 OpenShift에서도 실행됩니다. 셋째, 가장 중요한 것은 광범위한 구성 옵션이 있어 다음을 수행할 수 있다는 점입니다. 필요한 모든 엔드포인트를 타겟팅하세요..
(참조 플루언트 비트에 대한 이전 기사 또는 심층적인 로그 포워딩 문서 를 참조하세요.)
팁 #1: OSS 커뮤니티와 연결하기
플루언트 비트를 사용할 때 가장 먼저 추천하는 것은 오픈 소스 커뮤니티에 기여하고 참여하는 것입니다.
이 글의 거의 모든 내용은 다음과 같이 다른 사람의 것을 뻔뻔스럽게 재사용한 것입니다. 유창한 여유블로그 게시물, GitHub 리포지토리 등입니다. 동시에 Couchbase를 위해 구축한 다양한 파서를 기여했습니다. 공식 리포지토리로 돌아가기를 통해 몇 가지 유용한 문제를 제기했기를 바랍니다!
플루언트 비트 OSS 커뮤니티는 활발하게 운영되고 있습니다. 유지 관리자는 정기적으로 소통하고 문제를 해결하며 해결책을 제안합니다. 예를 들어 플루언트콘 EU 2021 를 통해 플루언트 비트 사용에 대한 유용한 제안과 피드백을 많이 받았으며, 이후 후속 릴리스에 통합했습니다. (플루언트콘 는 일반적으로 큐브콘 이벤트에서 함께 진행됩니다.)
팁 #2: 모든 것이 고장났을 때 디버깅하기
Fluent Bit 커뮤니티 Slack 채널에서 가장 자주 묻는 질문은 무언가가 작동하지 않을 때 디버깅하는 방법에 관한 것입니다. 제가 추천하는 두 가지 방법은 다음과 같습니다:
- 사용
stdout플러그인. - 플루언트 비트의 로그 레벨을 높입니다.
제가 먼저 제안하는 것은 단순화입니다. 대부분의 Fluent Bit 사용자는 로그를 더 큰 스택(예: Elastic-Fluentd-Kibana(EFK) 또는 프로메테우스-로키-그라파나 (PLG). 우선, 선택한 스택에 배관할 때 발생할 수 있는 모든 문제를 제거하기 전까지는 Kibana 또는 Grafana가 알려주는 내용을 보지 마세요.
사용 stdout 플러그인 를 사용하여 Fluent Bit가 생각하는 출력을 결정합니다. 그런 다음 예상했던 Fluent Bit의 여러 출력을 얻을 때까지 반복합니다. EFK 또는 PLG 스택의 모든 움직이는 부분을 처리하는 것보다 여기서 시작하는 것이 훨씬 쉽습니다.
두 번째 디버깅 팁은 다음과 같습니다. 로그 레벨 업. 이 단계를 통해 Fluent Bit가 무엇을 찾거나 구문 분석하려고 하는지 명확하게 알 수 있습니다. 대부분의 경우 로그 수준을 높이면 권한 문제나 잘못된 와일드카드/경로와 같은 간단한 수정 사항이 강조됩니다.
헬름 상태 점검 시 고려 사항
헬름을 사용하는 경우 해당 프로브를 활성화한 경우 상태 확인을 위해 HTTP 서버를 켜세요.
헬름은 간단한 설치에는 좋지만, 일반적인 도구이므로 헬름 구성이 허용되는지 확인해야 합니다. Kubernetes에서 상태 확인 프로브를 활성화하는 경우, Fluent Bit 구성에서 해당 프로브에 대한 엔드포인트도 활성화해야 합니다.
플루언트 비트의 최신 버전에는 다음과 같은 기능이 있습니다. 전용 건강 체크 (다음 릴리즈의 Couchbase Autonomous Operator에서도 사용할 예정입니다).
팁 #3: 파싱으로 물을 와인으로 바꾸기
일반적으로 로그를 읽은 후 로그를 구문 분석하고 싶을 것입니다. 저는 꼬리 입력 플러그인 를 사용하여 비정형 데이터를 정형 데이터로 변환합니다( 공식 용어).
실패는 선택 사항이 아닙니다
플루언트 비트 문제 해결과 관련하여 기억해야 할 핵심 사항은 다음과 같습니다. 구문 분석에 실패해도 여전히 출력을 얻습니다.. Fluent Bit 구문 분석기는 전체 로그 행을 단일 레코드로만 제공합니다. 이러한 폴백은 정보를 잃지 않고 다른 다운스트림 도구에서 언제든지 다시 구문 분석할 수 있다는 점에서 Fluent Bit의 좋은 기능입니다.
여기서 유용한 한 가지 요령은 기본값인 로그 키를 입력하여 구문 분석 후 레코드에 입력합니다. 레코드에 로그 키를 입력하면 구문 분석이 실패한 것입니다. 그렇지 않은 경우 항상 분명한 것은 아닙니다.
팁 #4: (다중 줄 구문 분석) 진실을 감당할 수 없습니다.
다중 줄 구문 분석 플루언트 비트의 핵심 기능입니다. 일부 로그는 이를 광범위하게 사용하는 Erlang 또는 Java 프로세스에서 생성됩니다.
그리고 여러 줄 구문 분석을 통한 목표 는 공통된 정보 집합을 추출하기 위해 초기 패스를 수행하는 것입니다. Couchbase 로그의 경우, 우리는 모든 로그 항목이 타임스탬프, 레벨 그리고 메시지 (함께 메시지 앞의 두 항목에서 캡처되지 않은 내용이 포함되어 있기 때문에 상당히 개방적입니다).
로그 파일의 이름은 또한 유창한 비트 태그. 다음과 같은 이유로 이 관행을 구현했습니다. 다른 로그를 별도의 대상으로 라우팅예를 들어 감사 로그 는 다음과 같은 경향이 있습니다. 보안 요구 사항:
|
1 2 3 4 5 |
@include /fluent-bit/etc/fluent-bit.conf [OUTPUT] Name s3 Match couchbase.log.audit ... |
위와 같이 (그리고 자세한 내용은 여기에서 확인하세요.), 이 코드는 기본적으로 모든 로그를 표준 출력으로 출력하지만 감사 로그도 AWS S3로 전송합니다.
아래 안내를 통해 또 다른 여러 줄 구문 분석 예제를 살펴보겠습니다(그리고 깃허브에서):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
[INPUT] Name tail Alias erlang_tail # ^See note 1 below Path ${COUCHBASE_LOGS}/babysitter.log,${COUCHBASE_LOGS}/couchdb.log,${COUCHBASE_LOGS}/debug.log,${COUCHBASE_LOGS}/json_rpc.log,${COUCHBASE_LOGS}/metakv.log,${COUCHBASE_LOGS}/ns_couchdb.log,${COUCHBASE_LOGS}/reports.log Multiline On Parser_Firstline couchbase_erlang_multiline Refresh_Interval 10 # ^See note 2 Skip_Long_Lines On # ^See note 3 Skip_Empty_Lines On # ^See note 4 Path_Key filename # ^See note 5 # We want to tag with the name of the log so we can easily send named logs to different output destinations. # This requires a bit of regex to extract the info we want. Tag couchbase.log. Tag_Regex ${COUCHBASE_LOGS}/(?[^.]+).log$ # ^See note 6 |
참고:
[1] 이 입력 플러그인에 대한 별칭을 지정합니다. 문제가 있거나 메트릭을 추적할 때 매우 유용합니다.
[2] 로그 목록은 10초마다 새로 고쳐서 새 로그를 표시합니다.
[3] 긴 줄에 닿으면 더 이상 입력을 중지하지 않고 건너뜁니다. 플루언트 비트는 임베디드 솔루션으로 시작했기 때문에 기본적으로 많은 정적 제한이 지원된다는 점을 기억하세요.
[4] 최근 1.8에 추가된 기능은 빈 줄을 건너뛸 수 있는 기능입니다. 이 옵션을 켜면 노이즈를 줄이고 자동화된 테스트가 계속 통과할 수 있습니다.
[5] 레코드에 유창한 비트 파일명 태그를 추가해야 합니다. 이는 다운스트림에서 필터링할 때 유용합니다.
[6] 파일 이름별로 태그를 지정합니다. 이 경우 여러 파일로 작업하기 때문에 정규식을 사용하여 파일 이름을 추출합니다.
한 가지 확실한 권장 사항은 테스트를 통해 정규식이 작동하는지 확인하는 것입니다. 다음과 같은 온라인 도구를 사용할 수 있습니다:
-
- 루뷸러
- RegEx101
- 칼립티아 (Calyptia에는 시각화 도구도 있습니다. 포함된 파일을 처리하는 스크립트를 사용하여 모든 파일을 하나의 붙여넣기 가능한 파일로 스크랩합니다..)
플루언트 비트에서 사용하는 정규식 엔진에는 항상 특정 측면이 있으므로 궁극적으로 이 부분도 테스트해야 한다는 점에 유의하세요. 예를 들어 다음 사항을 확인하세요. 그룹 이름을 적절하게 지정 (영숫자 + 밑줄만, 하이픈은 포함하지 않음)을 입력하면 문제가 발생할 수 있습니다.
팁: 정규식이 작동하지 않는 경우 - 정규식이 작동하더라도 should - 될 때까지 단순화하세요.
이전의 Fluent Bit 다중 줄 구문 분석기 예제에서는 다음과 같은 Erlang 메시지를 처리했습니다:
|
1 2 |
[ns_server:info,2021-03-09T17:31:55.351Z,babysitter_of_ns_1@cb.local:<0.92.0>:ns_babysitter:init_logging:136]Brought up babysitter logging [ns_server:debug,2021-03-09T17:31:55.373Z,babysitter_of_ns_1@cb.local:<0.92.0>:dist_manager:configure_net_kernel:293]Set net_kernel vebosity to 10 -> 0 |
위의 스니펫은 간결성을 위해 한 줄 메시지만 보여 주지만 다음과 같은 메시지도 있습니다. 대형, 여러 줄 예제 를 테스트합니다. 다음 사항을 기억하세요. 구문 분석기는 대괄호를 찾습니다. 를 사용하여 여러 줄로 구성된 각 로그 메시지의 시작을 표시할 수 있습니다:
|
1 2 3 4 5 6 7 |
[PARSER] Name couchbase_erlang_multiline Format regex Regex \[(?\w+):(?\w+),(?\d+-\d+-\d+T\d+:\d+:\d+.\d+Z),(?.*)$ Time_Key timestamp Time_Format %Y-%m-%dT%H:%M:%S.%L Time_Keep On |
타임스탬프 구문 분석의 복잡성 및 고려 사항
안타깝게도 전체 정규식을 사용할 수 없습니다. 타임스탬프 필드에 입력합니다. 날짜/시간 형식이 다양하면 대처하기 어려울 수 있습니다. 예를 들어 다음 타임스탬프 형식을 사용할 수 있습니다. 를 동일한 로그 파일 내에 저장합니다:
|
1 2 |
2021-03-09T17:32:15.545+00:00 [INFO] Using ... 2021/03/09 17:32:15 audit: ... |
1.7 릴리즈 당시에는 타임스탬프 형식을 한 번에 구문 분석할 수 있는 좋은 방법이 없었습니다. 그래서 Couchbase 로그의 경우, 로그 타임스탬프 구문 분석 실패를 무시하고 구문 분석 시간을 Fluent Bit의 값으로 사용하도록 설계했습니다. 실제 시간은 중요하지 않으며, 충분히 근접해야 합니다.
Fluent Bit 1.8 시리즈의 다중 형식 구문 분석은 더 나은 타임스탬프 구문 분석을 지원할 수 있어야 합니다. 하지만 이 글을 쓰는 현재 Couchbase는 아직 이 기능을 사용하고 있지 않습니다. 아래 스니펫은 다중 형식 구문 분석의 예를 보여줍니다:
|
1 2 3 4 5 6 7 8 9 10 |
# Cope with two different log formats, e.g.: # 2021/03/09 17:32:15 cbauth: ... # 2021-03-09T17:32:15.303+00:00 [INFO] ... # https://rubular.com/r/XUt7xQqEJnrF2M [PARSER] Name couchbase_simple_log_mixed Format regex Regex ^(?\d+(-|/)\d+(-|/)\d+(T|\s+)\d+:\d+:\d+(\.\d+(\+|-)\d+:\d+|))\s+((\[)?(?\w+)(\]|:))(?.*)$ Time_Key timestamp Time_Keep On |
여기서 주목해야 할 또 다른 사항은 자동화된 회귀 테스트가 필수라는 것입니다!
팁 #5: 필터링으로 골드 패닝하기
저는 다음의 열렬한 팬입니다. 로키/그라파나 스택로 로그 포워딩을 테스트할 때 광범위하게 사용했습니다.
Couchbase 컨테이너의 원래 릴리즈의 한 가지 문제는 로그 수준이 표준화되지 않았다는 점입니다. 정보, 정보, 정보 다른 케이스 또는 DEBU, 디버그 등 동일한 레벨에 대해 서로 다른 실제 문자열을 사용합니다. 이러한 표준화의 부재로 인해 추가 처리 없이 Grafana(또는 선택한 도구) 내에서 시각화하고 필터링하는 것이 어려웠습니다.
Slack 사용자의 제안을 기반으로 합니다, 다음 열거형을 사용하여 모든 다양한 레벨을 하나의 레벨로 효과적으로 제한하는 몇 가지 필터를 추가했습니다.: 알 수 없음, DEBUG, 정보, 경고, 오류. 이러한 유창한 비트 필터는 먼저 다양한 코너 케이스에서 시작하여 모든 레벨을 일관성 있게 만들기 위해 적용됩니다.
작동 방식은 다음과 같습니다: 필드가 고정 를 알려진 값으로 설정합니다, 추가 임시 키가 추가됩니다. 를 추가합니다. 이 임시 키는 이 필터 세트의 모든 추가 일치 항목에서 제외됩니다. 이 임시 키는 임시 키가 제거됩니다. 를 추가합니다. 예는 아래를 참조하세요:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
[FILTER] Name modify Alias handle_levels_uppercase_error_modify Match couchbase.log.* Condition Key_value_matches level (?i:ERRO\w*) Set level ERROR # Make sure we don't re-match it Condition Key_value_does_not_equal __temp_level_fixed Y Set __temp_level_fixed Y … # Remove all "temp" vars here [FILTER] Name modify Alias handle_levels_remove_temp_vars_modify Match couchbase.log.* Remove_regex __temp_.+ |
결국, 제한된 출력 세트가 훨씬 사용하기 쉽습니다.
팁 #6: 선택적 정보를 추가하는 방법
사용 가능한 추가 데이터가 있다면 Couchbase 로그에 포함시키고 싶을 것입니다.
제 프로젝트의 경우 처음에는 유창한 비트 수정 필터 를 사용하여 레코드에 추가 키를 추가할 수 있습니다. 그러나 특정 변수가 정의되지 않은 경우에는 수정 필터가 종료됩니다.
나중에 알게 된 사실이지만 를 사용하여 record_modifier 필터 대신 사용할 수 있습니다. 이 필터는 변수가 정의되지 않은 경우 경고를 표시하므로 포함하려는 정보의 상위 집합과 함께 사용할 수 있습니다.
요약하자면 로그 전달에 선택적 정보를 추가하려면 다음을 사용하세요. record_modifier 대신 수정.
다음과 같은 예시를 포함했습니다. record_modifier 아래에 있습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
[FILTER] Name record_modifier Alias common_info_modifier Match couchbase.log.* Record hostname ${HOSTNAME} Record logshipper couchbase.sidecar.fluentbit # These should be built into the container Record couchbase.logging.version ${COUCHBASE_FLUENTBIT_VERSION} Record fluentbit.version ${FLUENTBIT_VERSION} # The following are set by the operator from the pod meta-data, they may not exist on normal containers Record pod.namespace ${POD_NAMESPACE} Record pod.name ${POD_NAME} Record pod.uid ${POD_UID} # The following come from kubernetes annotations and labels set as env vars so also may not exist Record couchbase.cluster ${couchbase_cluster} Record couchbase.operator.version ${operator.couchbase.com/version} Record couchbase.server.version ${server.couchbase.com/version} Record couchbase.node ${couchbase_node} Record couchbase.node-config ${couchbase_node_conf} Record couchbase.server ${couchbase_server} # These are config dependent so will trigger a failure if missing but this can be ignored Record couchbase.analytics ${couchbase_service_analytics} Record couchbase.data ${couchbase_service_data} Record couchbase.eventing ${couchbase_service_eventing} Record couchbase.index ${couchbase_service_index} Record couchbase.query ${couchbase_service_query} Record couchbase.search ${couchbase_service_search} |
또한 네스트 필터 를 통합하여 모든 couchbase.* 그리고 pod.* 정보를 중첩된 JSON 구조로 변환하여 출력합니다. Nest 필터를 사용하면 모든 로그 레코드에 대해 전체 로그 레코드를 구문 분석할 필요 없이 Couchbase 관련 정보가 하나의 중첩된 구조에 있기 때문에 모든 다운스트림 작업이 간소화됩니다. 이는 온프레미스 정보에서 누락될 수 있는 포드 정보에서도 비슷합니다.
팁 #7: 별칭 사용
지금까지의 예제에서 이미 눈치챘을 수도 있는 또 다른 유용한 팁입니다: 별칭 사용.
특정 필터(또는 입력/출력)에 별칭을 사용하면 이해하기 어려운 숫자 대신 가독성이 좋은 이름을 Fluent Bit 로그와 메트릭에 사용할 수 있습니다. 파일 위치와 기능에 따라 별칭을 지정하는 프로세스를 만드는 것이 좋습니다.
플루언트 비트 문서는 다음을 보여줍니다. Prometheus 형식의 메트릭에 액세스하는 방법 다양한 예시와 함께.
Couchbase Fluent Bit 이미지로 실행하면 다음과 같은 출력이 표시됩니다. tail.0, tail.1 또는 이와 유사한 필터를 사용하세요:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
# HELP fluentbit_filter_drop_records_total Fluentbit metrics. # TYPE fluentbit_filter_drop_records_total counter fluentbit_filter_drop_records_total{name="common_info_modifier"} 0 1629194033696 fluentbit_filter_drop_records_total{name="couchbase_common_info_nest"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_filenames_add_missing_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_levels_add_info_missing_level_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_levels_add_unknown_missing_level_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_levels_check_for_incorrect_level"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_levels_remove_temp_vars_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_levels_uppercase_debug_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_levels_uppercase_error_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_levels_uppercase_info_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_levels_uppercase_warn_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_logfmt_filename_in_log_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_logfmt_message_unknown_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_logfmt_msg_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_logfmt_tail_filename_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="handle_logfmt_ts_modify"} 0 1629194033696 fluentbit_filter_drop_records_total{name="parser.16"} 0 1629194033696 fluentbit_filter_drop_records_total{name="pod_common_info_nest"} 0 1629194033696 # HELP fluentbit_input_bytes_total Number of input bytes. # TYPE fluentbit_input_bytes_total counter fluentbit_input_bytes_total{name="audit_tail"} 0 1629194033696 fluentbit_input_bytes_total{name="erlang_tail"} 691360 1629194033696 fluentbit_input_bytes_total{name="http_tail"} 4302 1629194033696 fluentbit_input_bytes_total{name="java_tail"} 0 1629194033696 fluentbit_input_bytes_total{name="memcached_tail"} 10623 1629194033696 fluentbit_input_bytes_total{name="prometheus_tail"} 0 1629194033696 fluentbit_input_bytes_total{name="rebalance_process_tail"} 0 1629194033696 fluentbit_input_bytes_total{name="simple_mixed_tail"} 0 1629194033696 fluentbit_input_bytes_total{name="simple_tail"} 0 1629194033696 fluentbit_input_bytes_total{name="xdcr_tail"} 26544 1629194033696 |
또한 로그에 문제가 발생하면 숫자 ID를 기반으로 어떤 플러그인이 문제를 일으켰는지 파악하는 데 시간을 낭비할 필요가 없습니다.
별칭에 대한 또 다른 고려 사항
저처럼 로키를 사용하는 경우 별칭과 관련된 또 다른 문제가 발생할 수 있습니다.
제 경우에는 파일명을 사용하여 로그 파일을 필터링하고 있었습니다. 테일 플러그인이 파일 이름을 자동으로 입력해 주지만, 안타깝게도 파일 이름에 전체 경로 를 추가할 수 있습니다. 하지만 Grafana는 파일 이름 문자열의 첫 부분만 잘라낼 때까지 표시하므로 모든 로그가 같은 위치에 있기 때문에 특히 유용하지 않습니다.
최종 결과는 아래에서 볼 수 있듯이 실망스러운 경험입니다.
이 문제를 해결하기 위해 파일 이름을 단축하고 원본도 유지하는 추가 필터를 추가했습니다.. 이 필터에는 간단한 구문 분석기가 필요하며, 아래에 이를 포함했습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[PARSER] Name couchbase_filename_shortener Format regex Regex ^(?.*)/(?.*)$ [FILTER] Name parser Match couchbase.log.* Key_Name filename Parser couchbase_filename_shortener # Do not overwrite original field Preserve_Key On # Keep everything else Reserve_Data On |
이 구문 분석기를 사용하면 다음과 같은 항목이 포함된 간단한 필터를 사용할 수 있습니다. audit.log, babysitter.log와 같은 전체 경로 접두사 대신 /옵트/카우치베이스/변/라이브/카우치베이스/로그/.
팁 #8: 루아 필터: 모든 (소파)기반은 우리의 것입니다.
유창한 비트 루아 필터 는 거의 모든 문제를 해결할 수 있습니다. 하지만 문제는 문제입니다, 해야 하나요?
카우치베이스 플루언트 비트 이미지 에는 약간의 루아 코드가 포함되어 있습니다. 를 사용하여 카우치베이스 로그의 특정 필드에 대한 해싱을 통한 삭제 지원. 이 리댁션의 목표는 원본 정보를 유출하지 않고 디버깅 목적으로 식별 가능한 데이터를 로그 간에 상호 연관시킬 수 있는 해시로 대체하는 것입니다. Couchbase는 Lua 필터를 사용하여 로그 메시지에서 ... 태그로 둘러싸인 모든 내용을 SHA-1 해싱하여 로그를 인플라이트에서 삭제합니다.
올해 플루언트콘 EU에서, 마이크 마샬이 플루언트 비트와 함께 Lua 필터를 사용하기 위한 몇 가지 유용한 팁을 소개했습니다. 포함 특별한 루아 티 필터 를 사용하면 파이프라인의 여러 지점을 탭하여 무슨 일이 일어나고 있는지 확인할 수 있습니다. 파이프라인의 해당 지점에서 모든 키-값 쌍을 덤프하는 일반 필터로, 특정 필드의 전후 보기를 만드는 데 유용합니다.
팁 #9: 테스트하고, 테스트하고, 또 테스트하기
이러한 다양한 기능을 모두 고려할 때, Couchbase Fluent Bit 구성은 매우 큰 규모입니다. 아래 이미지에서 Calyptia 비주얼라이저를 사용한 1.1.0 릴리스 구성을 확인하세요.
이 구성 규모를 감안하여 Couchbase 팀은 모든 것이 예상대로 작동하는지 확인하기 위해 많은 테스트를 수행했습니다. 이 모든 테스트를 통해 문제가 있는 메시지 예시 세트 및 각 로그 파일의 다양한 형식 로 사용하려면 예상 출력에 대한 자동화된 테스트 세트. 또한 이 모든 테스트를 실행하는 테스트 컨테이너를 만들었는데, 이 컨테이너는 스크립트와 테스트 데이터가 모두 계층화되어 있는 프로덕션 컨테이너입니다. 팀에서 새로운 문제를 발견하면 테스트 케이스를 확장할 것입니다.
이러한 도구는 결과물을 개선하기 위한 테스트에도 도움이 됩니다. 예를 들어 다음과 같은 경우 파일 이름 단축이러한 도구를 사용하여 직접 확인하고 올바르게 작동하는지 확인할 수 있습니다.
팁 #10: 관심 영역 분리하기
각 부분의 카우치베이스 플루언트 비트 구성은 별도의 파일로 분리됩니다.. 꼬리 플러그인당 하나의 파일, 각 공통 필터 세트당 하나의 파일, 각 출력 플러그인당 하나의 파일이 있습니다. 이 방식으로 설계한 이유는 크게 두 가지입니다:
- 다양한 구성의 간편한 재사용
- 테스트
Couchbase는 기본 구성을 제공하지만, 구문 분석할 로그와 방법을 조정하고 싶을 수 있습니다. 다음과 같이 하면 됩니다. @include 의 특정 부분 원하는 구성예를 들어 감사 로그 구문 분석 및 출력만 원하는 경우 해당 항목만 포함하면 됩니다. 구성을 직접 작성할 필요가 없으므로 모든 옵션을 학습하는 데 드는 노력을 절약하고 실수를 줄일 수 있습니다.
이러한 분할 구성은 자동화된 테스트도 간소화합니다. 예를 들어 다음과 같이 할 수 있습니다. 에 테일 구성을 포함시킨 다음 READ_From_HEAD 를 눌러 모든 입력을 읽도록 합니다.. 아래에서 이를 보여드렸습니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
cat > "$testConfig" << __FB_EOF @include /fluent-bit/test/conf/test-service.conf # Now we include the configuration we want to test which should cover the logfile as well. # We cannot exit when done as this then pauses the rest of the pipeline so leads to a race getting chunks out. # https://github.com/fluent/fluent-bit/issues/3274 # Instead we rely on a timeout ending the test case. @include $i Read_from_head On @include /fluent-bit/test/conf/test-filters.conf @include /fluent-bit/test/conf/test-output.conf __FB_EOF |
하지만 여기서 한 가지 경고가 있습니다: 전체 구성도 함께 테스트해야 합니다.. 최근에 포함 이름에 오타가 발생한 문제 를 전체 구성에 사용할 때 사용합니다. 다음에 호출 추가하기 --드라이런 는 아래와 같이 자동화된 테스트에서 이를 포착했습니다:
|
1 |
if "${COUCHBASE_LOGS_BINARY}" --dry-run --config="$i"; then |
이렇게 하면 구성이 정적 검사를 통과할 수 있을 만큼 올바른지 확인합니다. 해당 구성으로 특정 플러그인을 로드할 때 런타임 중에 여전히 오류가 발생할 수 있다는 점에 유의하세요. 이러한 경우 로그 수준을 높이면 일반적으로 도움이 됩니다(위의 팁 #2 참조).
테스트 중 예상치 못한 상황 예상하기
플루언트 비트에서 테스트하거나 문제를 해결할 때 모든 로그 메시지에는 특정 필드(예 메시지, 레벨및 타임스탬프) 및 기타(예 로그).
이 구분은 새 로그 입력에 대해 테스트하고 싶지만 차이점을 비교할 기준 출력이 없는 경우에 특히 유용합니다. 예를 들어, 다음을 테스트하는 경우 카우치베이스 서버의 새 버전 약간 다른 로그를 생성하고 있습니다. 제 추천은 다음과 같습니다. 를 사용하여 기대 플러그인을 사용하여 실패 조건이 발견되면 종료하고 해당 방식으로 테스트 실패를 트리거합니다..
안타깝게도 플루언트 비트는 현재 실패 시에도 코드 0으로 종료됩니다., 따라서 출력을 구문 분석해야 합니다. 를 클릭하여 종료된 이유를 확인합니다. 또한 이 경우 타임아웃을 사용하여 실행해야 합니다. exit_when_done. 그렇지 않으면 입력 파일이 끝나는 즉시 종료를 트리거합니다. 모든 출력을 비교 대상으로 플러시하기 전일 수 있습니다:
|
1 2 3 4 |
timeout -s 9 "${EXPECT_TEST_TIMEOUT}" "${COUCHBASE_LOGS_BINARY}" --config "$testConfig" > "$testLog" 2>&1 # Currently it always exits with 0 so we have to check for a specific error message. # https://github.com/fluent/fluent-bit/issues/3268 if grep -iq -e "exception on rule" -e "invalid config" "$testLog" ; then |
또한 테스트 스크립트를 Busybox(공식 디버그 컨테이너)와 UBI (Red Hat 컨테이너)로 인해 때때로 사용되는 Bash 기능이나 추가 바이너리가 제한될 수 있습니다.
팁 #11: 레드햇 오픈시프트에서 플루언트 비트를 사용하는 방법
다음이 있습니다. 레드햇 오픈시프트용 카우치베이스 자율 운영자 모든 컨테이너는 인증을 위해 다양한 검사를 통과해야 합니다. 이러한 검사 중 하나는 기본 이미지가 UBI 또는 RHEL인지 여부입니다.
Couchbase 팀은 OpenShift를 제외한 모든 작업에 공식 Fluent Bit 이미지를 사용합니다. UBI 기본 이미지의 소스에서 빌드합니다. 를 추가합니다. 현재 Yum 리포지토리는 가장 최신 버전만 제공하므로 버전 번호가 지정되도록 소스에서 빌드합니다. 또한 CentOS 7 대상 UBI 8에서 실행하기 위해 추가로 지원되는 모든 RPM과 함께 배포된 경우 이미지를 부풀리는 RPM입니다.
리포지토리에 다음과 같은 예제가 있습니다. RPM을 직접 사용하는 방법 도 마찬가지입니다.
결론
이 팁과 요령이 Couchbase의 로그 전달 및 감사 로그 관리를 위해 Fluent Bit를 더 잘 사용하는 데 도움이 되었기를 바랍니다.
플루언트 비트를 선택한 이유는 Couchbase 로그가 동적 구성이 가능한 공통 형식을 갖도록 하기 위해서였습니다. 또한 여러분과 같은 사용자가 쉽게 사용할 수 있도록 오버헤드를 최소화하는 업계 표준을 사용하고 싶었습니다.
더 자세히 알고 싶으시다면 다음에서 동일한 내용을 더 자세히 소개할 예정입니다. 다가오는 플루언트콘. 그곳에서 뵙기를 바랍니다.
지금 Couchbase Server 7 다운로드
