Yury Bushmelev "로그 수집 및 전달 분야의 갈퀴지도"- 보고서 사본

로그는 시스템의 중요한 부분으로 예상대로 작동하는지(또는 작동하지 않는지) 이해할 수 있습니다. 마이크로서비스 아키텍처의 조건에서 로그 작업은 스페셜 올림피아드의 별도 분야가 됩니다. 해결해야 할 많은 문제가 있습니다.

• 애플리케이션에서 로그를 작성하는 방법
• 로그를 작성할 위치;
• 저장 및 처리를 위해 로그를 전달하는 방법
• 로그를 처리하고 저장하는 방법.

현재 널리 사용되는 컨테이너화 기술의 사용은 문제 해결 옵션 분야에서 갈퀴 위에 모래를 추가합니다.

대략 이것에 대해 Yuri Bushmelev의 "로그 수집 및 전달 분야의 갈퀴지도"보고서의 사본입니다.

누가 신경 쓰나요, 고양이 밑에서 주세요.

제 이름은 유리 부시멜레프입니다. 저는 라자다에서 일합니다. 오늘은 우리가 어떻게 로그를 만들고, 어떻게 수집하고, 거기에 무엇을 쓰는지에 대해 이야기하겠습니다.

우리는 어디에서 왔습니까? 우리는 누구입니까? Lazada는 동남아시아 1개국에서 4위 온라인 소매업체입니다. 이 모든 국가는 데이터 센터에 분산되어 있습니다. 현재 총 80개의 데이터 센터가 있습니다. 이것이 중요한 이유는 무엇입니까? 일부 결정은 센터 사이에 매우 약한 연결이 있다는 사실 때문이었습니다. 마이크로서비스 아키텍처가 있습니다. 이미 20개의 마이크로서비스가 있다는 사실에 놀랐습니다. 로그로 작업을 시작했을 때 로그가 6개뿐이었고, 게다가 PHP 레거시 부분이 꽤 커서 감당하고 참아야 했습니다. 이 모든 것이 현재 시스템 전체에 대해 분당 XNUMX백만 개 이상의 메시지를 생성합니다. 더 나아가서 나는 우리가 어떻게 이것과 함께 살려고 노력하고 있으며 이것이 왜 그런지를 보여줄 것입니다.

어떻게든 이 6백만 개의 메시지와 함께 살아야 합니다. 우리는 그들과 함께 무엇을 해야 합니까? 6백만 개의 메시지 필요:

• 앱에서 보내기
• 배달을 위해 수락
• 분석 및 저장을 위해 제공합니다.
• 분석하다
• 어떻게든 저장합니다.

메시지가 XNUMX만 개였을 때, 나는 거의 같은 표정을 지었다. 적은 돈으로 시작했기 때문입니다. 응용 프로그램 로그가 거기에 기록되어 있음이 분명합니다. 예를 들어, 데이터베이스에 연결할 수 없고 데이터베이스에 연결할 수 있지만 무언가를 읽을 수 없습니다. 그러나 이 외에도 각 마이크로 서비스는 액세스 로그를 작성합니다. 마이크로 서비스에 도착하는 각 요청은 로그에 저장됩니다. 왜 이러는 거지? 개발자는 추적할 수 있기를 원합니다. 각 액세스 로그에는 traceid 필드가 포함되어 있으며, 이에 따라 특수 인터페이스가 전체 체인을 풀고 추적을 아름답게 표시합니다. 추적은 요청이 어떻게 진행되었는지 보여주며 개발자가 알 수 없는 쓰레기를 더 빨리 처리하는 데 도움이 됩니다.

그것과 함께 사는 방법? 이제 옵션 분야, 즉 이 문제가 일반적으로 어떻게 해결되는지 간략하게 설명하겠습니다. 로그 수집, 전송 및 저장 문제를 해결하는 방법.

응용 프로그램에서 작성하는 방법? 다른 방법이 있다는 것은 분명합니다. 특히 유행하는 동지들이 우리에게 말하듯이 모범 사례가 있습니다. 할아버지가 말했듯이 올드 스쿨에는 두 가지 유형이 있습니다. 다른 방법이 있습니다.

로그 수집의 경우 상황은 거의 동일합니다. 이 특정 부분을 해결하기 위한 옵션은 그리 많지 않습니다. 더 많지만 아직 많지는 않습니다.

그러나 배송 및 후속 분석을 통해 변형의 수가 폭발적으로 증가하기 시작합니다. 지금은 각 옵션에 대해 설명하지 않겠습니다. 주요 옵션은 주제에 관심이 있었던 모든 사람에게 잘 알려져 있다고 생각합니다.

Lazada에서 우리가 어떻게 했고 어떻게 시작했는지 보여드리겠습니다.

XNUMX년 전에 라자다에 와서 로그 프로젝트에 보내졌다. 그곳은 이랬습니다. 응용 프로그램의 로그는 stdout 및 stderr에 기록되었습니다. 모든 것이 세련된 방식으로 이루어졌습니다. 그러나 개발자는 그것을 표준 스트림에서 버리고 인프라 전문가가 어떻게 든 알아낼 것입니다. 인프라 전문가와 개발자 사이에는 다음과 같이 말하는 릴리스도 있습니다. 그리고 이 모든 것이 컨테이너에 있기 때문에 컨테이너 자체에 바로 포장하고 내부에 디렉토리를 매핑하고 거기에 넣었습니다. 무슨 일이 일어났는지 모두에게 꽤 명백하다고 생각합니다.

조금 더 살펴보겠습니다. 이러한 로그를 전달한 방법. 누군가가 td-agent를 골랐는데, 실제로는 유창하지만 그다지 유창하지는 않습니다. 나는 여전히 이 두 프로젝트의 관계를 이해하지 못하지만 거의 같은 것 같습니다. Ruby로 작성된 이 fluentd는 로그 파일을 읽고 일부 정규식을 사용하여 JSON으로 구문 분석했습니다. 그런 다음 그들은 Kafka로 보내졌습니다. 또한 Kafka에는 각 API에 대해 4개의 개별 주제가 있습니다. 왜 4? 라이브가 있기 때문에 스테이징이 있고 stdout 및 stderr이 있기 때문입니다. 개발자는 이를 생성하고 인프라 작업자는 Kafka에서 생성해야 합니다. 또한 Kafka는 다른 부서에서 관리했습니다. 따라서 각 API에 대해 4개의 주제를 생성하도록 티켓을 생성해야 했습니다. 모두가 그것을 잊었습니다. 일반적으로 쓰레기와 쓰레기였습니다.

다음에 무엇을 했습니까? 카프카로 보냈습니다. 또한 Kafka에서 로그의 절반이 Logstash로 날아갔습니다. 로그의 나머지 절반은 공유되었습니다. 일부는 한 Graylog로, 일부는 다른 Graylog로 날아갔습니다. 결과적으로 이 모든 것이 하나의 Elasticsearch 클러스터로 날아갔습니다. 즉,이 모든 혼란은 결국 거기에 떨어졌습니다. 당신은 그렇게 할 필요가 없습니다!

위에서 보면 이런 모습입니다. 당신은 그렇게 할 필요가 없습니다! 여기에서 문제 영역은 즉시 숫자로 표시됩니다. 실제로 더 많은 것이 있지만 6개는 정말 문제가 있는 것이므로 조치를 취해야 합니다. 나는 그들에 대해 지금 따로 말할 것입니다.

여기서 (1,2,3) 우리는 파일을 작성하므로 여기에 한 번에 세 개의 레이크가 있습니다.

첫 번째(1)는 어딘가에 작성해야 한다는 것입니다. API에 파일에 직접 쓸 수 있는 기능을 제공하는 것이 항상 바람직한 것은 아닙니다. API는 컨테이너에서 격리되는 것이 바람직하며 읽기 전용인 것이 더 좋습니다. 저는 시스템 관리자이므로 이러한 사항에 대해 약간 다른 견해를 가지고 있습니다.

두 번째 요점(2,3)은 API로 들어오는 요청이 많다는 것입니다. API는 파일에 많은 데이터를 기록합니다. 파일이 증가하고 있습니다. 회전해야 합니다. 그렇지 않으면 거기에 디스크를 저장할 수 없기 때문입니다. 쉘을 통해 디렉토리로 리디렉션되기 때문에 회전하는 것은 좋지 않습니다. 회전시킬 수 있는 방법이 없습니다. 핸들을 다시 열도록 애플리케이션에 지시할 수 없습니다. 개발자가 당신을 바보처럼 볼 것이기 때문입니다. “무슨 설명자? 우리는 일반적으로 stdout에 씁니다. 프레임워크는 copytruncate를 logrotate로 만들었습니다. logrotate는 파일의 복사본을 만들고 원본을 트렁크합니다. 따라서 이러한 복사 프로세스 사이에 일반적으로 디스크 공간이 부족합니다.

(4) 서로 다른 API에서 서로 다른 형식을 사용했습니다. 그것들은 약간 달랐지만 정규식은 다르게 작성되어야 했습니다. 모든 것이 Puppet에 의해 관리되었기 때문에 자체 바퀴벌레가 있는 많은 클래스가 있었습니다. 게다가 td-agent는 대부분의 시간 동안 메모리를 먹어치울 수 있고, 바보같이 일을 하는 척하고 아무것도 하지 않을 수 있습니다. 겉으로는 그가 아무것도하지 않는다는 것을 이해하는 것이 불가능했습니다. 기껏해야 그는 넘어지고 누군가 나중에 그를 데리러 올 것입니다. 보다 정확하게는 경고가 날아오고 누군가 가서 손으로 들어 올릴 것입니다.

(6) 그리고 가장 많은 쓰레기와 폐기물 - Elasticsearch였습니다. 구버전이었으니까. 그 당시에는 전담 마스터가 없었기 때문입니다. 필드가 겹칠 수 있는 이기종 로그가 있었습니다. 다른 애플리케이션의 다른 로그는 동일한 필드 이름으로 기록될 수 있지만 동시에 내부에 다른 데이터가 있을 수 있습니다. 즉, 하나의 로그는 레벨과 같은 필드에 정수와 함께 제공됩니다. 또 다른 로그는 레벨 필드에 문자열과 함께 제공됩니다. 정적 매핑이 없으면 이러한 놀라운 결과가 나타납니다. 인덱스 로테이션 후 문자열이 있는 메시지가 elasticsearch에 먼저 도착했다면 정상적으로 살고 있는 것입니다. 첫 번째 메시지가 Integer와 함께 도착한 경우 String과 함께 도착한 모든 후속 메시지는 단순히 버려집니다. 필드 유형이 일치하지 않기 때문입니다.

우리는 이러한 질문을 하기 시작했습니다. 우리는 유죄를 찾지 않기로 결정했습니다.

하지만 해야 할 일이 있습니다! 분명한 것은 우리가 기준을 세워야 한다는 것입니다. 우리는 이미 몇 가지 표준을 가지고 있었습니다. 일부는 나중에 가져왔습니다. 다행히 당시 모든 API에 대한 단일 로그 형식이 이미 승인되었습니다. 서비스 상호 작용 표준에 직접 기록됩니다. 따라서 로그를 받고자 하는 사람은 이 형식으로 로그를 작성해야 합니다. 누군가가 이 형식으로 로그를 작성하지 않으면 아무 것도 보장할 수 없습니다.

또한 로그를 기록하고 전달하고 수집하는 방법에 대한 단일 표준을 갖고 싶습니다. 실제로 어디에 작성하고 전달하는 방법. 이상적인 상황은 프로젝트가 동일한 라이브러리를 사용하는 경우입니다. Go용 별도의 로깅 라이브러리가 있고 PHP용 별도의 라이브러리가 있습니다. 우리가 가진 모든 사람들은 그것들을 사용해야 합니다. 지금은 우리가 80% 성공하고 있다고 말할 수 있습니다. 그러나 일부는 계속해서 선인장을 먹습니다.

그리고 (슬라이드에서) "로그 전달을 위한 SLA"가 거의 나타나기 시작했습니다. 아직은 없지만 작업 중입니다. 초당 N개 이하의 메시지를 초당 N개 이하의 장소에 그런 형식으로 작성하면 그곳으로 전달할 가능성이 높다고 infra가 말할 때 매우 편리하기 때문입니다. 그것은 많은 두통을 없애줍니다. SLA가 있다면 정말 좋습니다!

어떻게 문제를 해결하기 시작했습니까? 주요 레이크는 td-agent와 함께했습니다. 로그가 어디로 가는지 불분명했습니다. 배송되나요? 그들은 가고 있습니까? 어쨌든 그들은 어디에 있습니까? 따라서 td-agent를 첫 번째 항목으로 교체하기로 했습니다. 교체 대상에 대한 옵션은 여기에 간략하게 설명했습니다.

Fluentd. 첫째, 이전 직장에서 그를 만났고 그도 주기적으로 거기에 떨어졌습니다. 둘째, 이것은 프로필에서만 동일합니다.

filebeat. 우리에게는 어땠습니까? 그가 Go에 있고 우리는 Go에 대한 훌륭한 전문 지식을 가지고 있다는 사실. 따라서 무엇이든 우리는 그것을 우리 자신에게 추가할 수 있습니다. 그것이 우리가 그것을 받아들이지 않은 이유입니다. 자신을 위해 다시 작성하려는 유혹조차 없을 것입니다.

sysadmin을 위한 확실한 솔루션은 이 양의 모든 종류의 syslog입니다(syslog-ng/rsyslog/nxlog).

또는 자신의 것을 작성했지만 filebeat와 마찬가지로 폐기했습니다. 무언가를 쓴다면 비즈니스에 유용한 것을 쓰는 것이 좋습니다. 로그를 전달하려면 기성품을 가져가는 것이 좋습니다.

따라서 선택은 실제로 syslog-ng와 rsyslog 중에서 선택하는 것으로 귀결되었습니다. 나는 Puppet에 rsyslog에 대한 클래스가 이미 있었기 때문에 rsyslog에 기대었고 둘 사이에 분명한 차이점을 찾지 못했습니다. syslog 란 무엇입니까, syslog 란 무엇입니까? 예, 일부 문서는 더 나쁘고 일부는 더 좋습니다. 그는 이런 식으로 알고 있고 다르게 합니다.

그리고 rsyslog에 대해 조금. 일단 모듈이 많아서 좋습니다. 사람이 읽을 수 있는 RainerScript(최신 구성 언어)가 있습니다. 놀라운 보너스는 표준 도구를 사용하여 td-agent의 동작을 에뮬레이트할 수 있으며 애플리케이션에 대해 변경된 사항이 없다는 것입니다. 즉, td-agent를 rsyslog로 변경하고 아직 다른 모든 것을 건드리지 않습니다. 그리고 즉시 우리는 작동하는 배송을 받습니다. 다음으로 mmnormalize는 rsyslog의 멋진 기능입니다. 로그를 구문 분석할 수 있지만 Grok 및 regexp로는 불가능합니다. 추상 구문 트리를 만듭니다. 컴파일러가 소스 코드를 구문 분석하는 것과 거의 동일한 방식으로 로그를 구문 분석합니다. 이를 통해 매우 빠르게 작업하고 CPU를 적게 사용할 수 있으며 일반적으로 매우 멋진 것입니다. 다른 많은 보너스가 있습니다. 나는 그것들에 연연하지 않을 것이다.

rsyslog에는 훨씬 더 많은 단점이 있습니다. 그들은 보너스와 거의 같습니다. 주요 문제는 요리할 수 있어야 하고 버전을 선택해야 한다는 것입니다.

우리는 유닉스 소켓에 로그를 쓰기로 결정했습니다. 그리고 /dev/log에는 시스템 로그가 엉망이므로 이 파이프라인에는 journald가 있습니다. 이제 사용자 정의 소켓에 작성해 봅시다. 별도의 규칙 세트에 첨부하겠습니다. 아무것도 간섭하지 맙시다. 모든 것이 투명하고 이해할 수 있습니다. 그래서 우리는 실제로 했습니다. 이러한 소켓이 있는 디렉터리는 표준화되어 모든 컨테이너에 전달됩니다. 컨테이너는 필요한 소켓을 보고 열고 쓸 수 있습니다.

파일이 아닌 이유는 무엇입니까? 모두가 읽었기 때문에 Badushechka에 관한 기사, 파일을 docker로 전달하려고 시도했으며 rsyslog를 다시 시작한 후 파일 설명자가 변경되고 docker가 이 파일을 잃어버리는 것을 발견했습니다. 그는 다른 것을 열어 두지만 그들이 쓰는 동일한 소켓은 아닙니다. 우리는 이 문제를 우회하고 동시에 차단 문제를 우회하기로 결정했습니다.

Rsyslog는 슬라이드에 표시된 작업을 수행하고 로그를 릴레이 또는 Kafka로 보냅니다. Kafka는 예전 방식을 따릅니다. Rayleigh - 순수 rsyslog를 사용하여 로그를 전달하려고 했습니다. Message Queue 없이 표준 rsyslog 도구를 사용합니다. 기본적으로 작동합니다.

그러나 나중에 이 부분(Logstash/Graylog/ES)에 넣는 방법에는 미묘한 차이가 있습니다. 이 부분(rsyslog-rsyslog)은 데이터 센터 간에 사용됩니다. 다음은 압축된 tcp 링크로, 대역폭을 절약할 수 있으므로 채널이 가득 찼을 때 다른 데이터 센터에서 일부 로그를 수신할 가능성이 높아집니다. 모든 것이 나쁜 인도네시아가 있기 때문입니다. 그것은 끊임없는 문제가 있는 곳입니다.

애플리케이션에서 기록된 로그가 그 끝에 도달할 확률이 얼마나 되는지, 실제로 모니터링하는 방법에 대해 생각했습니다. 우리는 메트릭스를 시작하기로 결정했습니다. Rsyslog에는 일종의 카운터가 있는 자체 통계 수집 모듈이 있습니다. 예를 들어 대기열의 크기 또는 그러한 작업에 대해 얼마나 많은 메시지가 들어왔는지를 보여줄 수 있습니다. 당신은 이미 그들로부터 무언가를 얻을 수 있습니다. 또한 구성할 수 있는 사용자 지정 카운터가 있으며 예를 들어 일부 API가 기록한 메시지 수를 표시합니다. 다음으로 rsyslog_exporter를 Python으로 작성하고 Prometheus에 모두 전송하여 플롯했습니다. 우리는 Graylog 지표를 정말로 원했지만 지금까지는 설정할 시간이 없었습니다.

문제가 무엇입니까? Live API가 초당 50개의 메시지를 작성한다는 사실을 (갑자기!) 알게 되면서 문제가 발생했습니다. 스테이징이 없는 Live API만 있습니다. 그리고 Graylog는 초당 12개의 메시지만 표시합니다. 그리고 합리적인 질문이 생겼습니다. 나머지는 어디에 있습니까? Graylog는 단순히 대처할 수 없다는 결론을 내 렸습니다. 실제로 Elasticsearch를 사용한 Graylog는 이 흐름을 마스터하지 못했습니다.

다음으로, 그 과정에서 우리가 만든 다른 발견들입니다.

소켓에 대한 쓰기가 차단됩니다. 어떻게이 일이 일어 났어요? 배달을 위해 rsyslog를 사용했을 때 어느 시점에서 데이터 센터 간의 채널이 끊어졌습니다. 배달은 한 곳에서, 배달은 다른 곳에서 일어났습니다. 이 모든 것은 rsyslog 소켓에 기록하는 API가 있는 시스템으로 귀결됩니다. 대기열이 있었습니다. 그런 다음 기본적으로 128 패킷인 유닉스 소켓에 쓰기 위한 대기열이 가득 찼습니다. 그리고 애플리케이션 블록의 다음 write(). Go 애플리케이션에서 사용하는 라이브러리를 살펴보면 소켓에 대한 쓰기가 비차단 모드에서 발생한다고 기록되어 있습니다. 우리는 막힌 것이 없다고 확신했습니다. 우리가 읽었기 때문에 Badushechka에 관한 기사누가 그것에 대해 썼습니다. 그러나 순간이 있습니다. 또한 이 호출 주위에 무한 루프가 있었는데, 메시지를 소켓에 푸시하려는 지속적인 시도가 있었습니다. 우리는 그를 눈치채지 못했습니다. 라이브러리를 다시 작성해야 했습니다. 그 이후로 여러 번 변경되었지만 이제 모든 하위 시스템에서 잠금을 제거했습니다. 따라서 rsyslog를 중지하면 아무것도 떨어지지 않습니다.

이 갈퀴를 밟지 않는 데 도움이되는 대기열의 크기를 모니터링해야합니다. 첫째, 언제 메시지가 손실되기 시작하는지 모니터링할 수 있습니다. 둘째, 기본적으로 배송에 문제가 있는지 모니터링할 수 있습니다.

그리고 또 다른 불쾌한 순간은 마이크로 서비스 아키텍처에서 10배 증폭이 매우 쉽다는 것입니다. 들어오는 요청이 그렇게 많지는 않지만 이러한 메시지가 계속 실행되는 그래프와 액세스 로그 때문에 실제로 로그의 부하가 약 XNUMX배 증가합니다. 안타깝게도 정확한 수치를 계산할 시간이 없었지만 마이크로서비스가 바로 그 것입니다. 이것을 명심해야 합니다. 현재 로그 수집 하위 시스템이 Lazada에서 가장 많이 로드되는 것으로 나타났습니다.

Elasticsearch 문제를 해결하는 방법은 무엇입니까? 로그를 한 곳에서 신속하게 가져와야 하는 경우 모든 시스템에서 실행되고 수집되지 않도록 파일 스토리지를 사용하십시오. 이것은 작동이 보장됩니다. 모든 서버에서 수행됩니다. 거기에 디스크를 붙이고 syslog를 넣으면 됩니다. 그 후에는 모든 로그를 한 곳에 보관할 수 있습니다. 그런 다음 elasticsearch, graylog 또는 다른 항목을 천천히 구성할 수 있습니다. 그러나 이미 모든 로그가 있을 것이며 디스크 어레이가 충분하다면 로그를 저장할 수도 있습니다.

내 보고서 당시 계획은 다음과 같이 보이기 시작했습니다. 파일 쓰기를 거의 중단했습니다. 이제 우리는 나머지를 끌 것입니다. API를 실행하는 로컬 시스템에서는 파일 쓰기를 중지합니다. 첫째, 매우 잘 작동하는 파일 저장소가 있습니다. 둘째, 이러한 머신은 지속적으로 공간이 부족하므로 지속적으로 모니터링해야 합니다.

Logstash와 Graylog가 있는 이 부분은 정말 치솟습니다. 따라서 제거해야합니다. 하나를 선택해야 합니다.

우리는 Logstash와 Kibana를 중단하기로 결정했습니다. 보안 부서가 있기 때문입니다. 연결은 무엇입니까? X-Pack이 없는 Kibana와 Shield가 없는 Kibana는 로그에 대한 액세스 권한을 구분할 수 없습니다. 따라서 그들은 Graylog를 사용했습니다. 모든 것이 있습니다. 마음에 들지 않지만 작동합니다. 우리는 새 하드웨어를 구입하고 거기에 새 Graylog를 설치했으며 엄격한 형식의 모든 로그를 별도의 Graylog로 옮겼습니다. 같은 분야의 다른 유형의 문제를 조직적으로 해결했습니다.

새로운 Graylog에 정확히 무엇이 포함되어 있습니까? 우리는 도커에 모든 것을 썼습니다. 우리는 여러 대의 서버를 가져와 7개의 Kafka 인스턴스, 2.3개의 Graylog 서버 버전 5을 출시했습니다(Elasticsearch 버전 100를 원했기 때문). 이 모든 것은 HDD의 습격에서 제기되었습니다. 초당 최대 140개 메시지의 인덱싱 속도를 확인했습니다. 우리는 주당 XNUMX테라바이트의 데이터라는 수치를 보았습니다.

그리고 다시 갈퀴! 6건의 판매가 예정되어 있습니다. 우리는 XNUMX만 게시물을 넘어 이동했습니다. 우리 Graylog는 씹을 시간이 없습니다. 어떻게든 다시 살아남아야 합니다.

이것이 우리가 살아남은 방법입니다. 서버와 SSD를 몇 개 더 추가했습니다. 현재 우리는 이렇게 살고 있습니다. 이제 우리는 이미 초당 160k 메시지를 씹고 있습니다. 아직 한계에 도달하지 않았기 때문에 현실적으로 얼마나 벗어날 수 있을지 불분명합니다.

이것이 미래에 대한 우리의 계획입니다. 이 중에서 실제로 가장 중요한 것은 아마도 고가용성일 것입니다. 아직 가지고 있지 않습니다. 여러 대의 자동차가 같은 방식으로 설정되어 있지만 지금까지 모든 것은 한 대의 자동차를 통해 진행됩니다. 그들 사이에 장애 조치를 설정하는 데 시간이 필요합니다.

Graylog에서 메트릭을 수집합니다.

대역폭과 다른 모든 것을 죽이지 않는 하나의 미친 API를 갖도록 속도 제한을 만드십시오.

마지막으로 개발자와 일종의 SLA에 서명하여 그만큼 서비스를 제공할 수 있습니다. 더 쓰시면 죄송합니다.

그리고 문서를 작성합니다.

간단히 말해서 우리가 경험한 모든 것의 결과입니다. 첫째, 표준. 둘째, syslog는 케이크입니다. 셋째, rsyslog는 슬라이드에 쓰여진 대로 정확하게 작동합니다. 그리고 질문을 합시다.

질문.

문제: 그들은 왜 안 찍기로 결정했을까... (파일비트?)

답변: 파일에 써야 합니다. 나는 정말로 원하지 않았다. API가 초당 수천 개의 메시지를 작성하는 경우 한 시간에 한 번 회전하더라도 여전히 옵션이 아닙니다. 파이프에 쓸 수 있습니다. 개발자가 저에게 "우리가 작성하는 프로세스가 중단되면 어떻게 될까요? "라고 물었습니다. 나는 그들에게 무엇을 대답해야할지 찾지 못하고 "글쎄, 그러지 말자"라고 말했습니다.

문제: 그냥 HDFS에 로그를 쓰지 않는 이유는 무엇입니까?

답변A: 다음 단계입니다. 우리는 처음에 그것에 대해 생각했지만 현재 처리할 리소스가 없기 때문에 장기적인 솔루션에 달려 있습니다.

문제: 열 형식이 더 적합합니다.

답변: 이해합니다. 우리는 양손으로 "용"입니다.

문제: rsyslog에 씁니다. TCP와 UDP 모두 사용할 수 있습니다. 그러나 UDP의 경우 배달을 어떻게 보장합니까?

답변A. 두 가지 포인트가 있습니다. 먼저 로그 전달을 보장하지 않는다는 점을 모든 사람에게 즉시 알립니다. 개발자가 와서 "재무 데이터 작성을 시작하겠습니다. 어떤 일이 발생할 경우를 대비하여 어딘가에 두겠습니다. "라고 말하면 "좋습니다! 소켓에 쓰기를 차단하고 트랜잭션에서 수행하여 우리를 위해 소켓에 넣고 다른 쪽에서 받았는지 확인하십시오. 그리고 현재 모든 사람은 즉시 불필요해집니다. 그렇지 않다면 어떤 질문이 있습니까? 소켓에 대한 쓰기를 보장하지 않으려면 배달을 보장하는 이유는 무엇입니까? 최선의 노력을 다하고 있습니다. 우리는 가능한 한 많이, 최선을 다해 전달하려고 노력하지만 100% 보장하지는 않습니다. 따라서 거기에 재무 데이터를 작성할 필요가 없습니다. 이를 위한 트랜잭션 데이터베이스가 있습니다.

문제: API가 로그에 일부 메시지를 생성하고 제어를 마이크로서비스로 넘길 때 다른 마이크로서비스의 메시지가 잘못된 순서로 도착하는 문제에 직면한 적이 있습니까? 이로 인해 혼란이 발생합니다.

답변A: 다른 순서로 오는 것이 정상입니다. 이에 대한 준비가 되어 있어야 합니다. 모든 네트워크 배송은 귀하에게 주문을 보장하지 않거나 이에 대한 특별한 자원을 소비해야 하기 때문입니다. 파일 저장소를 사용하면 각 API는 자체 파일에 로그를 저장합니다. 오히려 rsyslog는 그것들을 디렉토리로 분해합니다. 각 API에는 고유한 로그가 있으며 여기에서 찾아보고 이 로그의 타임스탬프를 사용하여 비교할 수 있습니다. Graylog를 찾으러 가면 타임스탬프별로 정렬됩니다. 모든 것이 잘 될 것입니다.

문제: 타임스탬프는 밀리초 단위로 다를 수 있습니다.

답변: 타임스탬프는 API 자체에서 생성됩니다. 사실 이것이 요점입니다. NTP가 있습니다. API는 메시지 자체에 이미 타임스탬프를 생성합니다. rsyslog에 의해 추가되지 않습니다.

문제: 데이터 센터 간의 상호 작용이 명확하지 않습니다. 데이터 센터의 프레임워크 내에서 로그가 수집되고 처리된 방식이 명확합니다. 데이터 센터 간의 상호 작용은 어떻습니까? 아니면 각 데이터 센터가 자체 수명을 가집니까?

답변: 거의. 각 국가는 하나의 데이터 센터에 있습니다. 현재 확산이 없으므로 한 국가가 다른 데이터 센터에 배치됩니다. 따라서 이들을 결합할 필요가 없습니다. 각 센터 내부에는 로그 릴레이가 있습니다. 이것은 Rsyslog 서버입니다. 실제로 두 개의 관리 시스템입니다. 그들은 같은 방식으로 설정됩니다. 그러나 지금은 트래픽이 그 중 하나를 통과합니다. 그녀는 모든 집계를 기록합니다. 만일을 대비하여 디스크 대기열이 있습니다. 그녀는 로그를 눌러 중앙 데이터 센터(싱가포르)로 보내며, 이미 Graylog에 중독되어 있습니다. 그리고 각 데이터 센터에는 자체 파일 저장소가 있습니다. 연결이 끊어진 경우 모든 로그가 있습니다. 그들은 거기에 머물 것입니다. 그들은 거기에 저장됩니다.

문제: 비정상적인 상황에서 로그를 받나요?

답변: (파일 저장소로) 가셔서 보시면 됩니다.

문제: 로그가 손실되지 않는지 어떻게 모니터링합니까?

답변: 우리는 실제로 그것들을 잃어버리고 있고, 우리는 그것을 감시하고 있습니다. 모니터링은 한 달 전에 시작되었습니다. Go API가 사용하는 라이브러리에는 메트릭이 있습니다. 그녀는 소켓에 쓰기에 실패한 횟수를 셀 수 있습니다. 현재 까다로운 휴리스틱이 있습니다. 거기에 버퍼가 있습니다. 메시지를 소켓에 쓰려고 시도합니다. 버퍼가 오버플로되면 드롭하기 시작합니다. 그리고 그는 얼마나 많은 것을 떨어뜨렸는지 세었습니다. 카운터가 거기에서 넘치기 시작하면 우리는 그것에 대해 알게 될 것입니다. 그들은 이제 프로메테우스에도 오고 있으며 Grafana에서 그래프를 볼 수 있습니다. 알림을 설정할 수 있습니다. 그러나 누구에게 보낼지는 아직 명확하지 않습니다.

문제: Elasticsearch에서는 로그를 중복으로 저장합니다. 복제본이 몇 개 있습니까?

답변: 하나의 복제본.

문제: 한 줄인가요?

답변: 마스터와 레플리카입니다. 데이터는 중복으로 저장됩니다.

문제: rsyslog 버퍼의 크기를 조정했습니까?

답변: 맞춤형 유닉스 소켓에 데이터그램을 작성합니다. 이것은 즉시 우리에게 128 킬로바이트의 제한을 부과합니다. 더 이상 쓸 수 없습니다. 우리는 이것을 표준으로 작성했습니다. 스토리지에 들어가고 싶은 사람은 128KB를 씁니다. 또한 라이브러리는 메시지를 차단하고 메시지가 차단되었음을 표시합니다. 녹음 중에 잘렸는지 여부를 보여주는 메시지 자체의 표준에 특별한 필드가 있습니다. 그래서 우리는 이 순간을 추적할 기회가 있습니다.

질문: 깨진 JSON을 작성합니까?

답변: 깨진 JSON은 패킷이 너무 커서 릴레이 중에 폐기됩니다. 또는 JSON을 구문 분석할 수 없기 때문에 Graylog가 삭제됩니다. 그러나 여기에는 수정해야 하는 뉘앙스가 있으며 대부분 rsyslog에 연결되어 있습니다. 아직 작업해야 할 몇 가지 문제를 이미 작성했습니다.

질문: 왜 카프카인가? RabbitMQ를 사용해 보셨습니까? Graylog는 이러한 부하에 합산되지 않습니까?

답변: Graylog와 연동되지 않습니다. 그리고 Graylog가 구체화되고 있습니다. 그에게는 정말 문제가 됩니다. 그는 일종의 것입니다. 사실 필요하지 않습니다. 차라리 rsyslog에서 elasticsearch로 직접 작성한 다음 Kibana를 시청하겠습니다. 하지만 경비원과 문제를 해결해야 합니다. 이것은 Graylog를 버리고 Kibana를 사용할 때 가능한 개발 변형입니다. Logstash는 의미가 없습니다. rsyslog로 동일한 작업을 수행할 수 있기 때문입니다. 그리고 elasticsearch에 쓰는 모듈이 있습니다. Graylog와 함께 우리는 어떻게든 살려고 노력하고 있습니다. 우리는 그것을 약간 조정했습니다. 그러나 여전히 개선의 여지가 있습니다.

카프카에 대해. 그것이 역사적으로 일어난 방식입니다. 내가 도착했을 때 그것은 이미 거기에 있었고 이미 로그가 기록되고 있었습니다. 방금 클러스터를 올리고 로그를 이동했습니다. 우리는 그를 관리하고 그가 어떻게 느끼는지 압니다. RabbitMQ의 경우... RabbitMQ에 문제가 있습니다. 그리고 RabbitMQ는 우리를 위해 개발하고 있습니다. 우리는 그것을 생산에 가지고 있고 그것에 문제가 있었습니다. 이제 판매되기 전에 그는 무당이 될 것이고 정상적으로 일하기 시작할 것입니다. 하지만 그 전에는 프로덕션에 출시할 준비가 되어 있지 않았습니다. 한 가지 더 있습니다. Graylog는 AMQP 0.9 버전을 읽을 수 있고 rsyslog는 AMQP 1.0 버전을 쓸 수 있습니다. 그리고 중간에 둘 다 할 수 있는 단일 솔루션은 없습니다. 둘 중 하나가 있습니다. 그래서 지금은 Kafka만 있습니다. 그러나 뉘앙스도 있습니다. 우리가 사용하는 rsyslog 버전의 omkafka는 rsyslog에서 가져온 전체 메시지 버퍼를 잃을 수 있기 때문입니다. 우리가 참는 한.

질문: 카프카가 있어서 사용하는 건가요? 다른 용도로 사용되지 않습니까?

답변: Data Science 팀에서 사용했던 Kafka. 이것은 불행히도 아무 말도 할 수없는 완전히 별개의 프로젝트입니다. 모르겠어요. 그녀는 데이터 과학 팀에서 운영했습니다. 로그가 시작되었을 때 그들은 자신의 로그를 넣지 않기 위해 로그를 사용하기로 결정했습니다. 이제 Graylog를 업데이트했으며 이전 버전의 Kafka가 있기 때문에 호환성이 손실되었습니다. 우리는 우리 자신을 만들어야 했습니다. 동시에 각 API에 대해 이 네 가지 주제를 없앴습니다. 우리는 모든 라이브를 위해 하나의 와이드 탑을 만들고 모든 무대를 위해 하나의 와이드 와이드 탑을 만들고 거기에서 모든 것을 촬영합니다. Graylog는 이 모든 것을 병렬로 처리합니다.

질문: 소켓이 있는 샤머니즘이 필요한 이유는 무엇입니까? 컨테이너용 syslog 로그 드라이버를 사용해 보셨습니까?

답변: 이 질문을 던질 당시 우리는 도커와 긴장 관계에 있었습니다. 도커 1.0 또는 0.9였습니다. Docker 자체가 이상했습니다. 둘째, 로그를 밀어 넣으면 ... 도커 데몬을 통해 자체적으로 모든 로그를 전달한다는 확인되지 않은 의심이 있습니다. 하나의 API가 이상해지면 나머지 API는 stdout 및 stderr을 보낼 수 없다는 사실에 직면하게 됩니다. 이것이 어디로 이어질지 모르겠습니다. 굳이 이런 곳에서 docker syslog 드라이버를 쓸 필요가 없다는 느낌이 드는 수준에서 의심이 듭니다. 기능 테스트 부서에는 로그가 포함된 자체 Graylog 클러스터가 있습니다. 그들은 도커 로그 드라이버를 사용하며 모든 것이 괜찮은 것 같습니다. 그러나 그들은 즉시 GELF를 Graylog에 씁니다. 우리가 이 모든 것을 시작한 순간, 우리는 그것이 제대로 작동하기를 원했습니다. 아마도 나중에 누군가 와서 백년 동안 정상적으로 작동했다고 말하면 시도하겠습니다.

질문: rsyslog를 사용하여 데이터 센터 간에 전달합니다. Kafka에서는 왜 안되나요?

답변: 우리는 이렇게 하고, 실제로는 이렇습니다. 두 가지 이유가 있습니다. 채널이 완전히 작동하지 않으면 압축된 형식이더라도 모든 로그가 채널을 통과하지 않습니다. 그리고 kafka는 그들이 그 과정에서 단순히 패배하도록 허용합니다. 이런 식으로 이러한 로그의 고착을 제거합니다. 이 경우 Kafka를 직접 사용하고 있습니다. 좋은 채널이 있고 해제하려는 경우 rsyslog를 사용합니다. 그러나 실제로 통과하지 못한 것을 삭제하도록 설정할 수 있습니다. 현재 우리는 Kafka 어딘가에 직접 rsyslog 전달을 사용하고 있습니다.

출처 : habr.com