센트리
센트리는 에러 모니터링/리포팅 툴입니다.
커스텀 웹 훅, AWS SQS, 슬랙, 지라등 다양한 운영 도구들과 함께 연계할 수 있습니다.
운영 툴
개발자들은 오래 전 부터 프로덕션에서 발생하는 에러를 관리하고 방지하기 위해 많은 노력을 기울였습니다.
요구사항과 코드의 잦은 변경으로 양산되는 예상치 못한 버그들을 막기 위해 테스트코드 작성과 QA의 자동화등을 개발자의 테스크로 할당하여 이를 위한 추가 리소스를 배정했습니다.
하지만 개발 과정에 참여하는 사람보다 실 사용자의 수가 훨씬 많기 때문에, 개발자가 모든 에러 상황을 예견하고 방지하는 것은 현실적으로 불가능합니다.
사람이 지진을 정확하게 예측할 수는 없어도 어느 지역에서 지진이 발생활 확률이 높은지에 대한 데이터를 쌓는 것과 같이, 에러 모니터링 툴을 이용해 제품의 어떤 영역에서 큰 에러 발생의 징후가 나타나는지 확인할 수 있습니다.
도입 난이도
Sentry는 도입을 위해 특정한 언어나 매커니즘을 따로 시간을 내서 공부하지 않아도 됩니다. document가 굉장히 잘 되어있으며, 기존에 사용하던 웬만한 기업용 툴들과도 통합할 수 있는 기능을 자체적으로 제공하기 때문에 따로 코드를 작성해야 한다거나 하는 부분이 매우 적습니다.
기업 전용 솔루션이 아니기 때문에, 사이드 프로젝트에서도 적용할 수 있으며 서비스의 사이즈가 점진적으로 커짐에 따라 플랜을 유동적으로 선택할 수 있습니다.
설정
계정과 프로젝트를 생성하면 각 언어/프레임워크별로 어떻게 설치해야 하는지 친절하게 알려줍니다.
리엑트를 기준으로 설치 코드를 보면
다음과 같이 센트리에서 제공하는 SDK코드만 적절한 위치에 적용해주면 어플리케이션에 센트리 설치가 완료됩니다.
# Using yarn
yarn add @sentry/react @sentry/tracing
# Using npm
npm install --save @sentry/react @sentry/tracingimport React from "react";
import ReactDOM from "react-dom";
import * as Sentry from "@sentry/react";
import { Integrations } from "@sentry/tracing";
import App from "./App";
Sentry.init({
dsn: "https://zc380fd12345a417@o1123325.iest.sentry.io/6090",
integrations: [new Integrations.BrowserTracing()],
// Set tracesSampleRate to 1.0 to capture 100%
// of transactions for performance monitoring.
// We recommend adjusting this value in production
tracesSampleRate: 1.0,
});
ReactDOM.render(<App />, document.getElementById("root"));
// Can also use with React Concurrent Mode
// ReactDOM.createRoot(document.getElementById('root')).render(<App />);리엑트의 경우 에러 처리를 보통 ErrorBoundary 컴포넌트를 만들어 처리해주는데요,
센트리 문서에서 ErrorBoundary 컴포넌트를 어떻게 구성해야 하는지 예제 코드와 방법을 알려주기도 하며, 기존에 자체적으로 ErrorBoundary 컴포넌트가 존재했다면 생명주기 함수 내부에서 sentry가 제공하는 함수를 통해 명시적으로 센트리에 에러를 기록할 수 있습니다.
componentDidCatch(error, errorInfo) {
this.setState({ error });
Sentry.withScope(scope => {
Object.keys(errorInfo).forEach(key => {
scope.setExtra(key, errorInfo[key]);
});
Sentry.captureException(error);
});
}센트리 사이트로 넘어오면, 아직 실제로 에러가 발생하지 않았기 때문에 아무런 기록이 남아있지 않을 것인데요,
사진에 있는 Create a sample event 를 눌러서 에러가 어떻게 기록되는지 한번 살펴보면 TypeError가 샘플 에러로 기록된 것을 확인해볼 수 있습니다.
다음과 같이 내가 작성한 코드에서 어떤 부분이 에러 발생을 야기했는지 알 수 있다는 점이 되게 큰 장점입니다. 번들러를 사용했을 경우 소스맵을 따로 제공해야 아래처럼 표기됩니다.
에러 알림
에러 발생은 기본적으로 이메일을 통해 알림이 갑니다.
하지만 기존에 사용하던 협업용 툴이 있고 센트리에서 해당 툴에 대한 통합을 지원한다면, 알림 확인에 대한 콘텍스트 스위칭을 피하기 위해 통합을 하는게 개인적으로 더 낫다고 생각합니다.
나와 팀은 같으나 다른 프로젝트를 맡고 있는 동료가 이 에러를 먼저 발견한다면 나에게 알려주거나 담당자 부재시에도 해당 이슈에 대해 모든 팀원이 인지할 수 있습니다.
위의 사진처럼 센트리에서 에러 발생 내용을 카드로 만들어 슬랙에 보내주는데요, 이 카드안에 어떤 내용이 담겨야 할지도 커스터마이징 할 수 있습니다. 유저 IP, 릴리즈 버전, OS등의 정보가 들어갑니다. 자세한것은 Sentry tags 문서를 참조하세요.
소스맵 적용
SPA는 번들러로 빌드를 하기 때문에 소스맵을 센트리에 올려줘야 정확히 어느 부분에서 에러가 발생했는지를 센트리에서 표기해줄 수 있습니다.
센트리에 소스맵에 업로드하는 방법은 여러가지가 있습니다.
저는 최신 코드 내용이 반영된 소스맵을 반영하기 위해 빌드 시 커밋 해쉬를 이용해 센트리에 올려주는 방식을 사용합니다.
소스맵을 적용하기 위해서는 본인 계정으로 만든 api key가 필요하며, 이 key는 외부에 노출되지 않게 유의해야 합니다.
함께보면 좋은 글
