방대한 마이크로 서비스 로그를 처리하는 방법,이 도구는 사용하기 매우 쉽습니다!

이 기사에서는 주로 ELK Stack을 사용하여 Nissan의 TB 수준을 지원하는 로그 모니터링 시스템을 구축하는 방법을 소개합니다. 자세한 지식이 많지만 기사 하나만으로는 충분하지 않습니다.이 기사에서는 주로 핵심 지식 포인트를 소개합니다.

엔터프라이즈 수준의 마이크로 서비스 환경에서 수백 개의 서비스를 실행하는 것은 상대적으로 작은 규모로 간주됩니다. 프로덕션 환경에서 로그는 매우 중요한 역할을하며 예외 문제를 해결하려면 로그가 필요하고 성능 최적화를 위해서는 로그가 필요하며 비즈니스 문제 해결을 위해서는 서비스가 필요합니다. 그러나 프로덕션 환경에는 수백 개의 서비스가 실행되고 있으며 각 서비스는 단순히 현지화되어 저장되며 문제 해결을 위해 로그가 필요한 경우 로그가있는 노드를 찾기가 어렵습니다. 비즈니스 로그의 데이터 가치를 파악하는 것도 어렵습니다. 그런 다음 중앙 집중식 관리를 위해 로그를 한곳에 통합 출력 한 다음 로그를 처리하고 그 결과를 운영 및 유지 관리, 연구 개발에 사용할 수있는 데이터로 출력하는 것은 로그 관리 및 운영 및 유지 관리 지원을위한 실행 가능한 솔루션이며 기업이 로그를 해결하는 것도 시급합니다.

우리의 솔루션

ELK를 사용하여 TB 수준의 마이크로 서비스 대량 로그 모니터링 시스템을 구축하는 방법은 무엇입니까?

위의 요구 사항을 기반으로 위 그림과 같이 로그 모니터링 시스템을 시작했습니다.

통나무는 수집, 여과 및 균일하게 청소됩니다.
시각적 인터페이스, 모니터링, 알람, 로그 검색을 생성합니다.

ELK를 사용하여 TB 수준의 마이크로 서비스 대량 로그 모니터링 시스템을 구축하는 방법은 무엇입니까?

기능 프로세스의 개요는 위에 표시된대로입니다.

각 서비스 노드에 포인트를 매립하고 관련 로그를 실시간으로 수집합니다.
통합 로그 수집 서비스, 필터링, 로그 정리 후 비주얼 인터페이스와 알람 기능이 생성됩니다.

우리의 건축

ELK를 사용하여 TB 수준의 마이크로 서비스 대량 로그 모니터링 시스템을 구축하는 방법은 무엇입니까?

① 로그 파일 수집 터미널로 FileBeat를 사용합니다. 운영 및 유지 관리는 백엔드 관리 인터페이스를 통해 구성됩니다. 각 머신은 FileBeat에 해당합니다. 각 FileBeat 로그에 해당하는 Topic은 일일 로그 볼륨 구성에 따라 일대일 또는 다 대일이 될 수 있습니다. 다른 전략.

비즈니스 서비스 로그 수집 외에도 MySQL 느린 쿼리 로그 및 오류 로그는 물론 Nginx와 같은 기타 타사 서비스 로그도 수집했습니다.

마지막으로 자동화 된 게시 플랫폼과 결합되어 각 FileBeat 프로세스를 자동으로 게시하고 시작합니다.

② 우리가 호출 스택, 링크 및 프로세스 모니터링 지표에 사용하는 프록시 방법 : Elastic APM이므로 비즈니스 측에서 프로그램을 변경할 필요가 없습니다.

이미 운영중인 비즈니스 시스템의 경우 모니터링에 참여하기 위해 코드를 변경하는 것은 바람직하지 않으며 용납 할 수 없습니다.

Elastic APM은 HTTP 인터페이스 호출 링크, 내부 메서드 호출 스택, 사용 된 SQL, 프로세스 CPU, 메모리 사용량 표시기 등을 수집하는 데 도움이 될 수 있습니다.

질문이있는 사람도 있고 Elastic APM을 사용하면 기본적으로 다른 로그를 수집 할 수 있습니다. FileBeat를 사용하는 이유는 무엇입니까?

예, Elastic APM에서 수집 한 정보는 실제로 문제의 80 % 이상을 찾는 데 도움이 될 수 있지만 C와 같은 모든 언어에서 지원되지는 않습니다.

둘째, 인터페이스 호출시 오류 발생, 오류 발생 전후 로그 확인, 분석 용이성을위한 인쇄 업무 등 원하는 비 오류 로그 및 소위 중요 로그 수집에 도움이되지 않습니다. 로그.

셋째, 비 시스템 예외이며 업무 범주에 속하는 사용자 지정 업무 예외입니다. APM은 이러한 예외를 시스템 예외로보고합니다.

나중에 시스템 이상에 대해 경고하는 경우 이러한 이상은 경보의 정확성을 방해하고 사용자 지정 비즈니스 예외 유형이 많기 때문에 비즈니스 예외를 필터링 할 수 없습니다.

③ 동시에 에이전트를 두 번 열었습니다. 더 자세한 GC, 스택, 메모리 및 스레드 정보를 수집합니다.

④ 우리 는 서버 수집을 위해 Prometheus를 사용합니다.

⑤ 우리는 Saas 서비스 지향적이기 때문에 많은 서비스가 있고 많은 서비스 로그가 통합 및 표준화 될 수 없으며 이는 역사적 문제와도 관련이 있습니다. 비즈니스 시스템과 간접적으로 관련이 없거나 기존의 비즈니스 시스템과 직접 연결되는 시스템입니다. 자신에게 적응하기 위해 코드를 변경하도록 놔두면 푸시 할 수 없습니다.

멋진 디자인은 자신이 다른 사람과 호환되고 상대방을 공격 대상으로 취급하는 것입니다. 많은 로그는 의미가 없습니다. 예를 들어, 개발 프로세스에서 문제 해결 및 추적을 용이하게하기 위해 if else에 인쇄하는 것은 if 코드 블록 또는 else 코드 블록이 사라 졌는지 여부를 나타내는 서명 로그입니다.

일부 서비스는 디버그 수준 로그도 인쇄합니다. 제한된 비용과 자원 조건에서 모든 로그는 비현실적이며 자원이 허용하더라도 1 년 안에 큰 비용이 될 것입니다.

따라서 필터링, 정리 및 로그 우선 순위 수집을 동적으로 조정하는 솔루션을 채택했습니다. 먼저 모든 로그를 Kafka 클러스터에 수집하고 짧은 유효 기간을 설정합니다.

현재 데이터 볼륨을 1 시간, 1 시간으로 설정하고 있으며 당분간 리소스를 사용할 수 있습니다.

⑥ Log Streams는 로그 필터링 및 정리를위한 스트림 처리 서비스입니다. ETL 필터가 필요한 이유는 무엇입니까?

우리의 로그 서비스는 제한된 리소스를 가지고 있기 때문에 옳지 않습니다. 원래 로그는 각 서비스의 로컬 스토리지 미디어에 흩어져 리소스가 필요합니다.

이제 우리는 그것을 수집하고 있으며 수집 후 각 서비스의 원래 리소스는 로그가 차지하는 리소스의 일부를 해제 할 수 있습니다.

맞습니다.이 계산은 원래 서비스의 자원화를 로그 서비스 자원으로 실제로 나누고 자원을 증가시키지 않습니다.

그러나 이것은 이론적 일 뿐이며 온라인 서비스에서는 리소스 확장이 쉽지만 축소는 쉽지 않으며 구현하기가 매우 어렵습니다.

따라서 각 서비스에서 사용하는 로그 자원을 단시간에 로그 서비스에 할당하는 것은 불가능합니다. 이 경우 로그 서비스의 리소스는 현재 모든 서비스 로그에서 사용하는 리소스의 양입니다.

저장 시간이 길수록 리소스 소비량이 많아집니다. 비업무 적이거나 필수 불가결 한 문제를 해결하는 데 드는 비용이 현재 문제를 단시간에 해결하는 편익보다 크다면, 제한된 자금으로 어떤 리더 나 회사도 해결책을 채택하지 않을 것이라고 생각합니다.

따라서 비용 측면에서 로그 스트림 서비스에 필터를 도입하여 가치가없는 로그 데이터를 필터링하여 로그 서비스에서 사용하는 리소스 비용을 줄였습니다.

기술 우리는 Kafka Streams를 ETL 스트림 처리로 사용합니다. 인터페이스 구성을 통해 동적 필터링 및 정리 규칙을 실현합니다.

일반적인 규칙은 다음과 같습니다.

인터페이스 기반 구성 로그 수집. 기본 오류 수준의 모든 로그가 수집됩니다.
오류 시간을 중심으로 스트림 처리 창을 열고 위아래로 구성 할 수있는 N 개 시점에서 오류 수준이 아닌 로그를 수집합니다. 기본적으로 정보 수준 만 사용됩니다.
각 서비스에는 100 개의 키 로그가 장착 될 수 있으며 기본적으로 모든 키 로그가 수집됩니다.
느린 SQL을 기반으로 비즈니스 분류에 따라 시간이 많이 걸리는 다양한 필터를 구성합니다.
다음과 같은 비즈니스 요구에 따라 비즈니스 SQL의 실시간 통계 : 피크 기간 동안, 1 시간 이내에 유사한 비즈니스 SQL의 쿼리 빈도 통계. 쿼리 SQL을 기반으로 인덱스를 생성하는 등 DBA에 데이터베이스 최적화를위한 기반을 제공 할 수 있습니다.
피크 시간 동안 로그는 비즈니스 유형의 가중치 지수, 로그 수준 지수, 기간 내 각 서비스의 최대 로그 제한 지수 및 기간 지수에 따라 동적으로 정리되고 필터링됩니다.
다른 기간에 따라 기간을 동적으로 축소합니다.
로그 인덱스 생성 규칙 : 서비스에서 생성 된 로그 파일 규칙에 따라 해당 인덱스를 생성합니다. 예 : 서비스 로그는 debug, info, error, xx_keyword로 구분되며 생성 된 인덱스도 debug, info, error, xx_keyword와 접미사로 날짜입니다. . 그 목적은 연구 개발을 위해 로그를 습관적으로 사용하는 것입니다.

⑦ 시각화 인터페이스 주로 Grafana를 사용하고 있으며 지원하는 많은 데이터 소스 중 Prometheus와 Elasticsearch가 있는데, 이는 Prometheus와의 완벽한 도킹이라고 할 수 있습니다. 우리는 주로 APM의 시각적 분석을 위해 Kibana를 사용합니다.

로그 시각화

로그 시각화는 다음과 같습니다.

ELK를 사용하여 TB 수준의 마이크로 서비스 대량 로그 모니터링 시스템을 구축하는 방법은 무엇입니까?