사용자가 문제를 신고하는 경우: 특정 온라인 기능을 사용할 때 오류가 발생하면 어떻게 빠르고 정확하게 찾을 수 있습니까? 특정 요청 인터페이스가 데이터를 느리게 반환할 때 최적화를 효과적으로 추적하는 방법은 무엇입니까?
우리 모두 알고 있듯이 요청이 오면 다음과 같은 로그가 생성될 수 있습니다.
1. AceesLog: 사용자 액세스 로그
2. 예외: 코드 예외 로그
3. SQL: sql 쿼리 로그
4. ThirdParty: third- 파티 서비스
로그 요청으로 생성된 모든 로그를 추적하는 방법은 무엇입니까?
일반적인 접근 방식은 requestId를 고유 식별자로 사용한
다음 requestId를 컨텍스트에 삽입하는 미들웨어를 작성하는 것입니다. 로깅을 수행해야 할 경우
타사 서비스 및 SQL 로그에서
인쇄할 수 있습니다., requestId를 컨텍스트에 삽입해야 합니다. requestId는 인쇄를 위해 해당 함수에 전달되기 때문에 레이어별로 전달하기가 너무 번거롭고 코드도 상대적으로 방해가 됩니다.
우리의 목표는 코드의 침입성을 줄이고, 한 번 삽입하고, 자동으로 추적하는 것입니다.
조사 후 async_hooks는 비동기 동작의 수명 주기를 추적할 수 있습니다. 각 비동기 리소스(각 요청은 비동기 리소스임)에는
asyncId(비동기 리소스의 현재 수명 주기 ID), trigerAsyncId(상위 비동기 리소스)라는
2개의 ID가 있습니다.ID).
async_hooks는 비동기 리소스를 수신하기 위해 다음과 같은 수명 주기 후크를 제공합니다.
asyncHook = async_hook.createHook({
//비동기 리소스 생성을 수신합니다. init(asyncId,type,triggerAsyncId,resource){},
// 비동기 리소스 콜백 함수가 실행되기 전 before(asyncId){},
//비동기 리소스 콜백 함수가 실행되기 시작한 후, after(asyncId){},
// 비동기 리소스의 소멸을 모니터링합니다. destroy(asyncId){}
}) 그런 다음 매핑을 수행하면 각 asyncId가 저장소에 매핑되고 해당 requestId가 저장소에 저장되면 requestId를 쉽게 얻을 수 있습니다.
cls 후크 라이브러리는 async_hooks를 기반으로 캡슐화되어 동일한 비동기 리소스에 데이터 복사본을 유지하고 이를 키-값 쌍의 형태로 저장합니다. (참고: async_hooked는 node>=8.2.1의 상위 버전에서 사용해야 합니다.) 물론 커뮤니티에는 cls-session, node-continuation-local-storage 등과 같은 다른 구현이 있습니다.
내 프로젝트에서 cls-hooked를 사용하는 예에 대해 이야기해 보겠습니다.
/session.js 명명된 저장 공간 만들기
const createNamespace = require('cls-hooked').createNamespace
const 세션 = createNamespace('requestId-store')
module.exports = 세션 /logger.js 로그 인쇄
const session = require('./session')
모듈.수출 = {
정보: (메시지) =>
{
const requestId = session.get('requestId')
console.log(`requestId:${requestId}`, 메시지)
},
오류: (메시지) =>
{
const requestId = session.get('requestId')
console.error(`requestId:${requestId}`, 메시지)
}
} /sequelize.js sql은 로거를 호출하여 로그를 인쇄합니다.
const logger = require("./logger")
새로운Sequelize(
로깅: 함수(sql, 비용 시간) {
logger.error( `sql exe : ${sql} | 비용 시간 ${costtime} ms` );
} ) /app.js requestId를 설정하고, 응답 헤더를 반환하도록 requestId를 설정하고, 액세스 로그를 인쇄합니다.
const session = require('./session')
const 로거 = require('./logger')
비동기 함수 accessHandler(ctx, next)
{
const requestId = ctx.header['x-request-id'] || uuid()
const params = ctx.request.body ? JSON.stringify(ctx.request.body) : JSON.stringify(ctx.request.query)
//requestId 설정 session.run(() => { session.set('requestId', requestId)
logger.info(`url:${ctx.request.path}; params:${params}`) next()
//반환 응답 헤더 설정 ctx.res.setHeader('X-Request-Id',requestId)
}) } 요청 경로가 /home?a=1일 때의 로그를 살펴보겠습니다.
액세스 로그:
requestId:79f422a6-6151-4bfd-93ca-3c6f892fb9ac url:/home;params:{"a":"1"}
SQL 로그:
요청 ID:79f422a6-6151-4bfd-93ca-3c6f892fb9ac SQL exe:
실행됨(기본값): SELECT `id` FROM t_user 동일한 요청에 대한 전체 링크의 로그 requestId가 동일한 것을 확인할 수 있습니다. 나중에 알람 플랫폼으로 전송된 알람이 있는 경우 requestId를 기반으로 이 요청에 의해 실행된 전체 링크를 찾을 수 있습니다.
주의 깊은 학생들은 인터페이스에서 반환된 응답 헤더에 requestId도 설정했다는 것을 알 수 있습니다. 그 목적은 요청이 느리게 응답하거나 문제가 있는 경우 브라우저에서 직접 requestId를 알 수 있고 분석할 수 있다는 것입니다.
로컬에서 스트레스 테스트를 수행했습니다.
메모리 사용량 비교는 다음과 같습니다.
async_hook을 사용하지 않는 것보다 약 10% 더 많습니다.
우리의 QPS 시스템은 100레벨 시스템이면 괜찮지만, 동시성이 높은 서비스라면 신중하게 고려해야 할 것 같습니다.
ps. 틀린 부분이 있으면 지적해주세요. 마음에 들지 않으면 댓글을 달지 마세요.