직장에서 모든 사람이 가장 두려워하는 것 중 하나는 작업 그룹의 누군가가 당신의 말을 듣는 것입니다. XX 기능이 오류를보고합니다. . .
그런 다음 로그를보기 위해 서버로 이동해야합니다. 로그가 적을수록 좋습니다. 로그가 많으면 찾기가 너무 번거로울 것입니다. 주요 장소를 직접 찾는 것은 쉽지 않습니다.
동쪽과 서쪽을 보면 마침내 오류 메시지를 찾았지만 그 당시 매개 변수 정보가 무엇이 었는지 모르겠고 재현하기가 쉽지 않고 너무 어렵습니다. .
수정 후 오류 보고서를 작성해야하며 좋은 날이 지났습니다.
이러한 종류의 문제점을 해결하려면 다음 작업을 수행해야합니다.
- 로그 수집
- 비정상적인 경고
- 로그 증가 링크
- API 응답 증가 traceId
- 비정상적인 경우 현재 오류 방법의 매개 변수 인쇄
- 디버깅 모드 지원
로그 수집
해결해야 할 첫 번째 문제는 로그의 중앙 집중식 관리입니다. 그렇지 않으면 오류를보고하면 여러 서비스에서 오류 정보를 찾아야하므로 비효율적입니다. 물론 ansible과 같은 도구를 사용하여 수행 할 수도 있으며, 가장 좋은 방법은 로그 통계를 수집하고 웹 페이지를 통해 검색하고 보는 것입니다.
로그 수집의 벤치 마크는 ELK이므로 너무 많이 설명하지 않겠습니다. 우리가 사용하는 클라우드 서비스와 마찬가지로 수집하는 것이 더 편리합니다. 페이지를 클릭하면 얻을 수 있습니다.
로그 증가 링크
로그에 링크 추적 기능을 추가하는 과정은 두 단계로 나뉘는데, 먼저 시스템에 링크 추적이 있어야하며 링크 정보가 로그에 통합됩니다.
나는 주로 Sleuth가 많은 오픈 소스 프레임 워크를 지원하고 사용하기 매우 편리한 logback과 같은 로깅 프레임 워크를 통합하기 때문에 Spring Cloud Sleuth를 사용합니다.
Sleuth의 기본 확장 로그 형식은 다음과 같습니다.
[${spring.zipkin.service.name:${spring.application.name:-}},%X{X-B3-TraceId:-},%X{X-B3-SpanId:-},%X{X-Span-Export:-}]
서비스 이름, 링크 ID, 작업 단위 ID, zipkin으로 가져올 지 여부입니다. 로그에서 가장 중요한 것은 traceId이며 traceId를 사용하면 모든 시스템 로그를 직렬로 연결할 수 있습니다.
우리는 스스로 확장하고 다른 정보를 로그에 추가 할 수도 있습니다. 예 :
%X{X-REST-API:-},%X{X-RPC-SERVICE:-},%X{X-ORIGIN-INFO:-},%X{X-USER-ID:-},%X{X-BIZ-NAME:-},%X{X-BIZ-ID:-}
- X-REST-API : 엔트리 API, 글로벌 투명 전송
- X-RPC-SERVICE : 각 서비스 항목에 추가 된 항목 RPC
- X-ORIGIN-INFO : 소스 정보 (발신자 애플리케이션 이름 : IP : 서비스 이름)
- X-USER-ID : 사용자 ID, 전역 투명 전송
- X-BIZ-NAME : 상호, 글로벌 투명 전송, 응용 프로그램에서 대체 가능
- X-BIZ-ID : 비즈니스 ID, 글로벌 투명 전송, 애플리케이션에서 대체 가능
이러한 확장 정보를 사용하면 현재 요청이 어떤 항목 API이고 전체 요청이 어떤 서비스를 통과했는지 로그에서 직접 알 수 있습니다.
내가 주문 서비스를 담당하는 사람이라면 문제를 해결하러 갔을 때 현재 오류가 어떤 업스트림 시스템과 어떤 인터페이스 호출로 인해 발생했는지 로그를 통해 알 수 있습니다.
또한 로그에는 요청한 사용자를 알 수있는 사용자 정보가 포함됩니다.
BIZ-ID 및 BIZ-NAME을 사용하여 비즈니스 시나리오 문제를 해결할 수 있습니다. 예를 들어, 주문을 한 후 주문 ID를 알고 나면 주문 ID를 로그에 추가 할 수 있습니다. BIZ-NAME = order, BIZ- ID = 20102121212121.
결제, 배송, 환불 등과 같은 주문 관련 작업이 있습니다. 주문 ID는 로그에 있습니다. 문제 해결이 필요한 경우 주문 ID를 기반으로 직접 전체 주문과 관련된 로그 정보를 볼 수 있습니다. 정보가 입력됩니다.
비정상적인 경고
사용자 피드백 외에도 개발팀은 처음에 문제가 있음을 알아야합니다. 따라서 비정상적인 경보가 수행되어야합니다.
일반적으로 우리의 응용 프로그램은 서비스 응용 프로그램, 작업 응용 프로그램, 비동기 소비자 응용 프로그램으로 나뉩니다.
서비스 응용 프로그램의 경우 통합 된 예외 처리에서 경고 할 수 있습니다. 작업 응용 프로그램은 통합 된 스케줄링 시작시 경고 할 수도 있습니다. 비동기 소비도 마찬가지입니다.
메시지 대기열을 사용하여 경고하거나 로그 형식을 공식화하고 로그를 기록하여 로그 플랫폼에서 로그를 수집 한 다음 경고 할 다양한 규칙을 구성 할 수 있습니다.
이상이보고되면 traceId를 가져와 이상이 발견되면 traceId를 통해 로그 플랫폼을 직접 검색 할 수 있으며, 문제 해결에 매우 도움이되는 traceId와 관련된 모든 로그를 볼 수 있습니다. 주요 로그 정보를 인쇄합니다.
API 응답 증가 traceId
ResponseBodyAdvice를 통해 응답 결과를 균일하게 사용자 정의 할 수 있으며 traceId 응답을 추가 할 수 있습니다. 이런 식으로 문제가 발생하면 로그 플랫폼으로 직접 이동하여 응답의 traceId를 통해 로그를 검색 할 수 있습니다.
비정상적인 문제를 신속하게 해결하는 것 외에도 성능을 최적화 할 때 traceId가 APM 시스템과 일치하는 경우 traceId에 따라이 API의 시간 소모적 인 상황을 직접 볼 수도 있습니다.
비정상적인 경우 현재 오류 방법의 매개 변수 인쇄
이전 작업을 통해 이미 traceId를 획득하여 비정상시 관련 오류 정보를 확인할 수 있으며, 여러 머신으로 이동하여 로그를 무작위로 찾을 필요가 없어 문제 해결 속도가 크게 향상되었습니다.
이러한 작업이 문제 해결의 절반에 도움이되었다고 할 수 있습니다. 예를 들어 이제 경고를받은 다음 로그 플랫폼으로 이동하여 관련 로그를 확인한 후 행이 잘못보고되었음을 발견했습니다.
현재로서는 어떤 매개 변수로 인해이 라인이 오류를보고하게되었는지 모르기 때문에이 장소가 문제가된다고 추측 할 수 있습니다. 따라서 현재 오류보고 방법의 매개 변수를 오류보고시 로그에 인쇄 할 수 있다면 문제가 발생했을 때 장면을 유지하는 것과 같으며 문제를 해결하는 데 몇 분이면 충분합니다.
특정 구현 계획은 고정되어 있지 않습니다. 가장 쉬운 방법은 모든 비즈니스 메소드에 적용되는 Aspect를 작성하는 것입니다. 메소드에서 예외가 발생하면 매개 변수 정보를 기록하십시오.이 기록 작업은 예외가 발생할 때만 수행해야합니다. 그렇지 않으면 성능에 큰 영향을 미칩니다.
효과:
com.xxx.biz.service.impl.GoodsSkuServiceImpl.createSku异常, 参数信息：{"cspuId":1, stock:10, price:100}
Caused by: java.util.NoSuchElementException: No value present
at java.util.Optional.get(Optional.java:135)
at com.xxx.biz.service.impl.GoodsSkuServiceImpl.createSku(GoodsSkuServiceImpl.java:682)
디버깅 모드 지원
디버깅 모드를 지원한다는 것은 일부 시나리오에서 오류를 재현 할 수 있음을 의미하지만 예외 시점에 기록 된 매개 변수 정보 외에도 전체 요청 링크의 매개 변수와 응답을 알고 싶습니다. 즉, 입구를 통과하는 모든 메소드는 요청 및 응답 데이터를 출력 할 수 있습니다.
특정 요청 헤더를 정의하고 문제를 재현 할 때이 요청 헤더를 가져 오면 통합 프레임 워크가 요청 헤더를 수신 한 다음 전체 링크에 투명하게 전송할 수 있습니다. 그런 다음 비정상적인 측면을 결합하여 매개 변수와 결과를 기록합니다.
효과:
xxx.xxxController.makeOrder 参数：xxx
xxx.xxxRpcService.makeOrder 参数：xxx
xxx.xxxStockRpcService.lockStock 参数：xxx
xxx.xxxStockRpcService.lockStock 响应：xxx
xxx.xxxRpcService.makeOrder 响应：xxx
xxx.xxxController.makeOrder 响应：xxx