현재 Kubernetes에 로그인하는 것(그뿐만 아니라): 기대와 현실

2019년인데 아직 Kubernetes의 로그 집계를 위한 표준 솔루션이 없습니다. 이 기사에서는 실제 사례를 사용하여 검색, 발생한 문제 및 해결 방법을 공유하고 싶습니다.

하지만 먼저 로그를 수집하여 고객마다 매우 다른 것을 이해하도록 예약하겠습니다.

• 누군가 보안 및 감사 로그를 보고 싶어합니다.
• 누군가 - 전체 인프라의 중앙 집중식 로깅;
• 일부의 경우 밸런서 등을 제외하고 애플리케이션 로그만 수집하는 것으로 충분합니다.

아래는 다양한 '위시리스트'를 구현한 방법과 어떤 어려움에 직면했는지에 대한 컷입니다.

이론: 로깅 도구에 대해

로깅 시스템의 구성 요소에 대한 배경

로깅은 많은 발전을 이루었고 그 결과 오늘날 우리가 사용하는 로그 수집 및 분석 방법론이 개발되었습니다. 1950년대에 Fortran은 프로그래머가 프로그램을 디버깅하는 데 도움이 되는 표준 입출력 스트림의 아날로그를 도입했습니다. 이것은 당시 프로그래머의 삶을 더 쉽게 만들어준 최초의 컴퓨터 로그였습니다. 오늘 우리는 로깅 시스템의 첫 번째 구성 요소를 볼 수 있습니다. 로그의 소스 또는 "생산자".

컴퓨터 과학은 가만히 있지 않았습니다. 컴퓨터 네트워크가 등장하고 첫 번째 클러스터... 여러 컴퓨터로 구성된 복잡한 시스템이 작동하기 시작했습니다. 이제 시스템 관리자는 여러 시스템에서 로그를 수집해야 하며 특별한 경우 시스템 오류를 조사해야 하는 경우 OS 커널 메시지를 추가할 수 있습니다. 중앙 집중식 로그 수집 시스템을 설명하기 위해 2000년대 초반에 출판되었습니다. RFC 3164, 이는 remote_syslog를 표준화했습니다. 또 다른 중요한 구성 요소가 나타난 방식은 다음과 같습니다. 로그 수집기 그리고 그들의 저장.

로그의 양이 늘어나고 웹 기술이 널리 보급되면서 사용자에게 어떤 로그를 편리하게 보여주어야 하는가에 대한 의문이 생겼습니다. 간단한 콘솔 도구(awk/sed/grep)가 고급 도구로 대체되었습니다. 로그 뷰어 - 세 번째 구성 요소.

로그 양의 증가로 인해 또 다른 사실이 분명해졌습니다. 로그가 필요하지만 전부는 아니라는 것입니다. 그리고 로그마다 보존 수준이 다릅니다. 일부는 하루 만에 손실될 수 있고 다른 일부는 5년 동안 저장해야 합니다. 따라서 데이터 흐름을 필터링하고 라우팅하는 구성 요소가 로깅 시스템에 추가되었습니다. 이를 호출하겠습니다. 필터.

스토리지도 일반 파일에서 관계형 데이터베이스로, 그리고 문서 중심 스토리지(예: Elasticsearch)로 큰 도약을 이루었습니다. 그래서 저장소가 수집기와 분리되었습니다.

궁극적으로 로그라는 개념 자체가 기록을 위해 보존하려는 일종의 추상적인 이벤트 스트림으로 확장되었습니다. 아니면 조사를 수행하거나 분석 보고서를 작성해야 하는 경우...

그 결과, 로그 수집은 비교적 짧은 시간 내에 빅데이터의 하위 섹션 중 하나라고 할 수 있는 중요한 하위 시스템으로 발전했습니다.

옛날에는 일반 인쇄만으로도 "로깅 시스템"에 충분할 수 있었지만 이제는 상황이 많이 바뀌었습니다.

Kubernetes 및 로그

Kubernetes가 인프라에 등장했을 때 이미 존재했던 로그 수집 문제도 이를 우회하지 못했습니다. 어떤 면에서는 훨씬 더 고통스러워졌습니다. 인프라 플랫폼 관리가 단순화되었을 뿐만 아니라 동시에 복잡해졌습니다. 많은 오래된 서비스가 마이크로서비스로 마이그레이션되기 시작했습니다. 로그의 맥락에서 이는 로그 소스의 증가, 특별한 수명 주기, 로그를 통해 모든 시스템 구성 요소의 관계를 추적해야 하는 필요성에 반영됩니다.

앞을 내다보면 안타깝게도 지금은 다른 모든 옵션과 비교하여 Kubernetes에 대한 표준화된 로깅 옵션이 없다고 말할 수 있습니다. 커뮤니티에서 가장 인기 있는 계획은 다음과 같습니다.

• 누군가가 스택을 펼칩니다. EFK (Elasticsearch, Fluentd, Kibana);
• 누군가 최근에 출시된 것을 시험해 보고 있어요 로키 또는 사용 로깅 연산자;
• 우리 (아마도 우리뿐만이 아닐지도?..) 나는 내 자신의 발전에 대체로 만족한다. 통나무 집...

일반적으로 K8s 클러스터에서는 다음 번들을 사용합니다(자체 호스팅 솔루션용).

• Fluentd + Elasticsearch + Kibana;
• Fluentd + ClickHouse + 로그하우스.

그러나 설치 및 구성에 대한 지침은 다루지 않겠습니다. 대신, 일반적인 로그 상황에 대한 단점과 보다 포괄적인 결론에 중점을 둘 것입니다.

K8s에서 로그 연습

"일상로그" 여러분은 몇 명 계시나요..

상당히 큰 인프라에서 로그를 중앙 집중식으로 수집하려면 상당한 리소스가 필요하며, 이는 로그 수집, 저장 및 처리에 사용됩니다. 다양한 프로젝트를 운영하는 동안 우리는 다양한 요구 사항과 이로 인해 발생하는 운영 문제에 직면했습니다.

ClickHouse를 사용해 보세요

초당 5000줄 이상의 로그를 매우 적극적으로 생성하는 애플리케이션이 있는 프로젝트의 중앙 집중식 저장소를 살펴보겠습니다. 그의 로그 작업을 시작하고 이를 ClickHouse에 추가해 보겠습니다.

최대 실시간이 요구되자마자 ClickHouse가 있는 4코어 서버는 이미 디스크 하위 시스템에 과부하가 걸릴 것입니다.

이러한 유형의 로딩은 ClickHouse에서 가능한 한 빨리 작성하려고 하기 때문입니다. 그리고 데이터베이스는 증가된 디스크 로드로 이에 반응하며, 이로 인해 다음과 같은 오류가 발생할 수 있습니다.

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

그건 사실입니다 MergeTree 테이블 ClickHouse(로그 데이터 포함)에서는 쓰기 작업 중에 자체적인 어려움이 있습니다. 여기에 삽입된 데이터는 임시 파티션을 생성한 다음 기본 테이블과 병합됩니다. 결과적으로 기록은 디스크에 매우 많은 것을 요구하는 것으로 나타났으며 위에서 언급한 제한 사항도 적용됩니다. 1초에 300개 이하의 하위 파티션을 병합할 수 있습니다(실제로 이는 300개의 삽입입니다). 초당).

이러한 동작을 방지하려면 ClickHouse에 작성해야 합니다 가능한 한 큰 조각으로 나누어야 하며 1초에 2회 이하입니다. 그러나 대량으로 작성하는 것은 ClickHouse에서 작성 빈도를 줄여야 한다는 것을 의미합니다. 이로 인해 버퍼 오버플로 및 로그 손실이 발생할 수 있습니다. 해결책은 Fluentd 버퍼를 늘리는 것입니다. 하지만 그러면 메모리 소비도 증가합니다.

주의: ClickHouse를 사용한 솔루션의 또 다른 문제 측면은 우리 사례(로그하우스)의 파티셔닝이 연결된 외부 테이블을 통해 구현된다는 사실과 관련이 있었습니다. 테이블 병합. 이는 긴 시간 간격을 샘플링할 때 메타테이블이 모든 파티션(분명히 필요한 데이터를 포함하지 않는 파티션이라도 포함)을 통해 반복되기 때문에 과도한 RAM이 필요하다는 사실로 이어집니다. 그러나 이제 이 접근 방식은 현재 버전의 ClickHouse(c)에서는 더 이상 사용되지 않는 것으로 안전하게 선언될 수 있습니다. 18.16).

결과적으로 ClickHouse에서 실시간으로 로그를 수집할 만큼 모든 프로젝트에 충분한 리소스가 있는 것은 아니라는 것이 분명해졌습니다(보다 정확하게는 배포가 적절하지 않습니다). 또한 다음을 사용해야 합니다. 축 압기, 나중에 다시 설명하겠습니다. 위에서 설명한 사례는 실제 사례입니다. 그리고 그 당시 우리는 고객에게 적합하고 최소한의 지연으로 로그를 수집할 수 있는 신뢰할 수 있고 안정적인 솔루션을 제공할 수 없었습니다...

엘라스틱서치는 어떻습니까?

Elasticsearch는 과도한 작업 부하를 처리하는 것으로 알려져 있습니다. 동일한 프로젝트에서 시도해 보겠습니다. 이제 로드는 다음과 같습니다.

Elasticsearch는 데이터 스트림을 소화할 수 있었지만, 그러한 볼륨을 기록하면 CPU를 크게 활용하게 됩니다. 이는 클러스터를 구성하여 결정됩니다. 기술적으로는 문제가 되지 않지만 로그 수집 시스템을 작동하기 위해 우리는 이미 약 8개의 코어를 사용하고 있으며 시스템에 로드율이 높은 추가 구성 요소가 있는 것으로 나타났습니다...

결론: 이 옵션은 정당화될 수 있지만 프로젝트 규모가 크고 해당 관리가 중앙 로깅 시스템에 상당한 리소스를 소비할 준비가 된 경우에만 가능합니다.

그러면 다음과 같은 자연스러운 질문이 생깁니다.

실제로 어떤 로그가 필요합니까?

접근 방식 자체를 변경해 보겠습니다. 로그는 정보를 제공하면서도 동시에 다루어서는 안 됩니다. 모든 시스템의 이벤트.

우리가 성공적인 온라인 상점을 운영하고 있다고 가정해 보겠습니다. 어떤 로그가 중요합니까? 예를 들어 지불 게이트웨이 등에서 가능한 한 많은 정보를 수집하는 것은 좋은 생각입니다. 그러나 제품 카탈로그에 있는 이미지 분할 서비스의 모든 로그가 우리에게 중요한 것은 아닙니다. 오류와 고급 모니터링만 있으면 충분합니다(예: 이 구성 요소가 생성하는 500개 오류의 비율).

그래서 우리는 다음과 같은 결론에 이르렀습니다. 중앙 집중식 로깅이 항상 정당화되는 것은 아닙니다. 클라이언트는 모든 로그를 한곳에 수집하려고 하는 경우가 많습니다. 하지만 실제로는 전체 로그에서 비즈니스에 중요한 메시지 중 조건부 5%만 필요합니다.

• 때로는 컨테이너 로그의 크기와 오류 수집기(예: Sentry)만 구성하는 것으로 충분할 때도 있습니다.
• 오류 알림과 대규모 로컬 로그 자체만으로도 사건을 조사하기에 충분한 경우가 많습니다.
• 우리는 기능 테스트와 오류 수집 시스템만을 다루는 프로젝트를 진행했습니다. 개발자는 로그가 필요하지 않았습니다. 오류 추적에서 모든 것을 보았습니다.

인생의 일러스트레이션

또 다른 이야기가 좋은 예가 될 수 있습니다. 우리는 Kubernetes가 도입되기 오래 전에 개발된 상용 솔루션을 이미 사용하고 있던 클라이언트 중 한 곳의 보안팀으로부터 요청을 받았습니다.

기업의 문제 감지 센서인 QRadar와 중앙 집중식 로그 수집 시스템의 "친구 만들기"가 필요했습니다. 이 시스템은 syslog 프로토콜을 통해 로그를 수신하고 FTP에서 검색할 수 있습니다. 그러나 Fluentd용 Remote_syslog 플러그인과 즉시 통합할 수는 없었습니다. (결과적으로는 우리는 혼자가 아니야). QRadar 설정과 관련된 문제는 고객의 보안 팀 측에서 발생한 것으로 밝혀졌습니다.

결과적으로 비즈니스에 중요한 로그의 일부가 FTP QRadar에 업로드되었고, 다른 부분은 원격 syslog를 통해 노드에서 직접 리디렉션되었습니다. 이를 위해 우리는 심지어 썼습니다 간단한 차트 - 아마도 비슷한 문제를 해결하는 데 도움이 될 것입니다... 결과 체계 덕분에 클라이언트는 자신이 선호하는 도구를 사용하여 중요한 로그를 직접 수신하고 분석했으며 로깅 시스템 비용을 절감할 수 있었습니다. 지난 달.

또 다른 예는 무엇을 하지 말아야 하는지를 잘 보여줍니다. 처리를 위한 고객 중 한 명 각 사용자로부터 오는 이벤트는 여러 줄로 만들어집니다. 구조화되지 않은 출력 로그의 정보. 짐작할 수 있듯이 이러한 로그는 읽고 저장하는 데 매우 불편했습니다.

로그 기준

이러한 예는 로그 수집 시스템을 선택하는 것 외에도 다음 사항이 필요하다는 결론으로 ​​이어집니다. 또한 로그 자체를 디자인합니다.! 여기서 요구 사항은 무엇입니까?

• 로그는 기계가 읽을 수 있는 형식(예: JSON)이어야 합니다.
• 로그는 압축되어야 하며 가능한 문제를 디버깅하기 위해 로깅 수준을 변경할 수 있는 기능을 갖추고 있어야 합니다. 동시에 프로덕션 환경에서는 다음과 같은 로깅 수준으로 시스템을 실행해야 합니다. 경고 또는 오류.
• 로그는 정규화되어야 합니다. 즉, 로그 개체에서 모든 줄은 동일한 필드 유형을 가져야 합니다.

구조화되지 않은 로그는 로그를 스토리지에 로드하는 데 문제가 발생하고 처리가 완전히 중지될 수 있습니다. 예를 들어, 다음은 fluentd 로그에서 많은 사람들이 확실히 접한 오류 400의 예입니다.

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

이 오류는 유형이 불안정한 필드를 미리 만들어진 매핑을 사용하여 인덱스로 보내고 있음을 의미합니다. 가장 간단한 예는 변수가 있는 nginx 로그의 필드입니다. $upstream_status. 숫자나 문자열을 포함할 수 있습니다. 예를 들어:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

로그에는 서버 10.100.0.10이 404 오류로 응답했으며 요청이 다른 콘텐츠 저장소로 전송되었음을 보여줍니다. 결과적으로 로그의 값은 다음과 같습니다.

"upstream_response_time": "0.001, 0.007"

이러한 상황은 너무 흔해서 별도의 조치가 필요합니다. 문서의 참조.

신뢰성은 어떻습니까?

예외 없이 모든 로그가 중요할 때가 있다. 그리고 이로 인해 위에서 제안/논의된 K8에 대한 일반적인 로그 수집 방식에는 문제가 있습니다.

예를 들어 fluentd는 수명이 짧은 컨테이너에서 로그를 수집할 수 없습니다. 우리 프로젝트 중 하나에서 데이터베이스 마이그레이션 컨테이너는 해당 주석에 따라 4초 미만 동안 유지된 후 삭제되었습니다.

"helm.sh/hook-delete-policy": hook-succeeded

이로 인해 마이그레이션 실행 로그가 스토리지에 포함되지 않았습니다. 이 경우에는 정치가 도움이 될 수 있습니다. before-hook-creation.

또 다른 예는 Docker 로그 회전입니다. 로그에 적극적으로 쓰는 애플리케이션이 있다고 가정해 보겠습니다. 정상적인 조건에서는 모든 로그를 처리할 수 있지만 위에서 설명한 잘못된 형식과 같은 문제가 발생하는 즉시 처리가 중지되고 Docker가 파일을 회전합니다. 결과적으로 비즈니스에 중요한 로그가 손실될 수 있습니다.

그 이유는 로그 스트림을 분리하는 것이 중요합니다, 가장 가치 있는 정보를 애플리케이션에 직접 전송하여 안전을 보장합니다. 또한 일부를 만드는 것은 불필요한 일이 아닙니다. 로그의 "누적기", 중요한 메시지를 저장하는 동안 잠시 동안 저장 공간을 사용할 수 없는 경우에도 살아남을 수 있습니다.

마지막으로, 우리는 그것을 잊지 말아야 합니다. 모든 하위 시스템을 적절하게 모니터링하는 것이 중요합니다.. 그렇지 않으면 fluentd가 엉뚱한 상태에 빠지기 쉽습니다. CrashLoopBackOff 아무 것도 보내지 않으며 이로 인해 중요한 정보가 손실될 수 있습니다.

조사 결과

이 기사에서는 Datadog과 같은 SaaS 솔루션을 살펴보지 않습니다. 여기에 설명된 많은 문제는 로그 수집을 전문으로 하는 상업 회사에 의해 이미 어떤 방식으로든 해결되었지만 다양한 이유로 모든 사람이 SaaS를 사용할 수 있는 것은 아닙니다. (주요한 것은 비용과 152-FZ 준수입니다).

중앙 집중식 로그 수집은 처음에는 간단한 작업처럼 보이지만 전혀 그렇지 않습니다. 다음 사항을 기억하는 것이 중요합니다.

• 중요한 구성요소만 자세히 기록하면 되며, 다른 시스템에 대해서는 모니터링 및 오류 수집을 구성할 수 있습니다.
• 불필요한 부하를 추가하지 않도록 프로덕션 로그를 최소한으로 유지해야 합니다.
• 로그는 기계가 읽을 수 있고 정규화되어야 하며 엄격한 형식을 가져야 합니다.
• 정말 중요한 로그는 기본 로그와 분리된 별도의 스트림으로 전송되어야 합니다.
• 높은 로드가 급증하는 것을 방지하고 스토리지의 로드를 보다 균일하게 만들 수 있는 로그 누산기를 고려해 볼 가치가 있습니다.

이러한 간단한 규칙을 모든 곳에 적용하면 위에 설명된 회로가 중요한 구성 요소(배터리)가 누락된 경우에도 작동할 수 있습니다. 이러한 원칙을 준수하지 않으면 작업으로 인해 귀하와 인프라가 시스템의 부하가 높은(동시에 비효율적인) 다른 구성 요소로 쉽게 이동하게 됩니다.

PS

블로그에서도 읽어보세요.

• «Loghouse 소개 - Kubernetes에서 로그 작업을 위한 오픈 소스 시스템";
• «KubeCon'19의 Kubernetes 생태계 릴리스: JFrog Container Registry, IBM의 Kui, Loki 1.0.0…";
• «모니터링 및 Kubernetes(리뷰 및 동영상 보고)".

출처 : habr.com