로그 관리 모범 사례

로깅(logging)은 진화하고 있습니다. 문제가 발생할 때마다 애플리케이션과 인프라의 로그들을 일일이 찾아보는 것은 과거의 일이 되었습니다. 이제 로깅은 조직의 운영, 비즈니스 인텔리전스 및 마케팅에서 중요한 역할을 합니다. 로그는 옵저버빌리티(observability)를 지원합니다. 체계적인 로그는 옵저버빌리티를 위한 기반으로서, 전체 시스템이 어떻게 실행되는지 빠르고 쉽게 이해하며 문제를 선제적으로 해결할 수 있도록 해줍니다. 세부적인 로그는 물론 모든 텔레메트리 데이터를 위해 단일 통합 플랫폼을 제공하는 New Relic One이 필요한 이유입니다.

로그가 풀 스택 옵저버빌리티를 향상시킬 수 있도록, 로깅 관행을 쉽게 전환할 수 있습니다. 이 글에서는 현대 조직을 위한 로깅의 모범 사례 몇 가지를 살펴보도록 하겠습니다.

풀 스택 옵저버빌리티(full-stack observability)란?

풀 스택 옵저버빌리티에 대해 먼저 알아보겠습니다. 풀 스택 옵저버빌리티는 인시던트 진단, 평균 해결 시간 단축, 고객 경험에 대한 이해를 제공하는 단일 통합 솔루션을 통해, 복잡한 애플리케이션과 시스템의 성능에 대한 완전한 가시성을 제공합니다.

모든 정보를 한곳에서 검색하고 진단할 수 있기 때문에, 문제를 해결하는 데 소요되는 시간을 줄일 수 있습니다. 또한 여러 소프트웨어를 확인하기 위해 툴(tool) 간에 전환을 하거나, 무슨 일이 일어나고 있는지 볼 수 없는 사각 지대가 생길 것을 우려할 필요가 없습니다.

기존 로깅

이는 각 시스템마다 데이터를 격리해 저장하는 기존 로깅과는 대조됩니다. 기존에는 가시성을 확보하기 위해 애플리케이션 성능 모니터링(APM)과 인프라 모니터링을 사용했습니다. 이러한 방식은 모니터링을 하는 데는 효과적이었지만, 애플리케이션과 인프라 디바이스의 로그 안에 포함된 전체 내용을 파악하기는 어려웠습니다. 또한, 서로 분리되고 격리된 여러 개의 모니터링 및 로깅 툴들은 애플리케이션에 중점을 두고 스택의 한 부분에만 초점을 맞추기 때문에, 무슨 일이, 왜 일어났는지 완전한 정보를 제공할 수 없습니다. 출시 시간을 단축하고, 고객 행동에 대한 인사이트를 향상시키면서 인시던트 대응시간을 줄이는 데 필요한 정보를 확보하는 것이 중요합니다.

풀 스택 옵저버빌리티를 원하는 조직은 로그에서 세부적인 정보를 얻을 수가 없거나, 문제의 근본적인 원인을 파악하는데 어려움을 겪었습니다. 또는 별도의 툴을 사용해 로그의 세부 정보를 오류와 트레이스에 연결해야 했습니다. 세부 로그를 격리시켜 따로 유지하면, 전체 그림을 볼 수 없고, 제품의 비용과 출시 시간이 늘어나며, 고객 경험에 대한 가시성은 줄어들고, 문제 해결에 걸리는 평균 시간은 늘어납니다.

New Relic One 풀 스택 옵저버빌리티

New Relic One 풀 스택 옵저버빌리티는 로그 관리, APM, 인프라 모니터링, 서버리스 모니터링, 모바일 모니터링, 브라우저 신세틱 모니터링, 분산 추적 및 쿠버네티스 모니터링을 통합합니다. 이 기능을 사용하면, 전체 소프트웨어 스택을 효과적으로 시각화 및 분석하고 문제를 해결할 수 있습니다. 이 기능의 일부로 제공되는 New Relic 로그 관리는 로깅 데이터를 애플리케이션 및 인프라 모니터링 데이터와 결합하여, 강력한 올인원 옵저버빌리티 플랫폼을 만들 수 있도록 해줍니다.

풀 스택 옵저버빌리티는 IT 운영을 위한 인공 지능(AIOps)과 전체 소프트웨어 스택의 메트릭, 이벤트, 로그 및 트레이스를 한데 모아줍니다. 덕분에, 다른 레거시 솔루션보다 낮은 비용으로 더 빠르게 로그를 검색할 수 있습니다. 개발자는 스택의 각 부분마다 다른 툴을 사용하는 것이 아니라, 특정 오류와 관련된 모든 세부 로그를 한 곳에서 쉽게 확인할 수 있습니다. 기존 로깅 솔루션은 속도와 확장성 문제로 인해, 지연된 데이터로 실행하는 데 몇 분에서 몇 시간까지 걸릴 수 있기 때문에 세부적인 로그를 쿼리하기가 쉽지 않았습니다. 뉴렐릭의 로그 관리 검색은 몇 초 밖에 걸리지 않으므로, 전체 소프트웨어 스택에서 인시던트를 신속하게 조사하고 대응할 수 있습니다.

로그를 효과적으로 관찰하려면, 형식이 갖춰지지 않은 대량의 로그를 데이터베이스나 파일에 그냥 던져놓는 것 보다는 좀 더 많은 생각과 주의가 필요합니다. 여러 다른 애플리케이션 간에 전환을 하지 않아도, 세부 로그가 실시간으로 애플리케이션과 인프라 전반에서 인시던트를 상호 연관시킬 수 있도록 로깅 관행을 지능적으로 바꾸려면 어떻게 해야 할까요? 포괄적인 옵저버빌리티는 어떻게 해야 더 잘 확보할 수 있을까요? 어떻게 효과적으로 풀 스택 옵저버빌리티를 확보해서 비즈니스를 잘 지원할 수 있을까요?

전체 스택에 대한 로그를 생성한다는 것이 어렵고 막막하게 느껴질 수 있습니다. 어떤 항목을 로깅해야 할지, 얼마나 많은 양의 세부 정보를 포함시켜야 할지, 많은 양의 데이터로 인해 높은 비용이 발생하지는 않을지 등, 여러 가지 질문이 있을 수 있습니다. 수많은 기업들이 플랫폼에서 로그 관리를 중앙화하는 데 많은 비용을 지불하고 있으며, 성능과 비용 문제로 인해 전송되는 로그 데이터를 제한해야 해서 궁극적으로 비즈니스에 대한 가시성과 가치도 제한이 됩니다.

뉴렐릭은 텔레메트리 데이터 플랫폼(Telemetry Data Platform)의 일부로 로그 관리를 제공합니다. 그리고 로그 관리에는 볼륨이 많지 않은 고객을 위한 무료 티어가 포함되어 있으며, 조직이 필요한 모든 세부 로그를 수집할 수 있도록 GB 당 가격도 낮습니다.

이를 염두에 두고, 옵저버빌리티을 위한 로그 관리에 적용할 수 있는 몇 가지 모범 사례를 살펴보겠습니다.

올바른 항목 로깅

로그 생성에서 필요한 것은 표준 출력(stdout)이나 파일에 텍스트를 쓰는 것뿐입니다. 가장 중요한 것은 로그에 들어갈 내용을 선택하는 것입니다. 로그에는 조사할 때 이벤트와 정확한 근본 원인을 파악하는 데 도움이 되는 메타데이터가 충분히 포함되어야 합니다. 메타데이터는 오류 메시지, 스택 트레이스와 관련 값, 메트릭, 이벤트 같은 요소가 될 수 있습니다. 로깅되는 모든 항목은 목적이 있어야 합니다. 사용량 데이터, 사용자 이벤트, 애플리케이션 오류, 예외 등 모든 것은 팀에 가치가 있어야 합니다. 어떤 것을 로깅할지 결정을 내릴 때는 기본적으로 "이 정보가 어떤 식으로든 즉시 유용하며, 근본적인 원인을 이해하고 결정을 내리는 데 필요한 세부 정보를 제공하는가?"라고 자문해볼 필요가 있습니다.

일반적인 시나리오 예상

로그는 인시던트 대응만을 위한 것이 아닙니다. 로그는 성능 프로파일링, 통계 수집 같은 비즈니스의 다른 부분에도 도움을 줄 수 있습니다. 몇 가지 일반적인 시나리오를 염두에 두고 로깅을 하면, 로그로부터 직접적인 가치를 얻을 수 있습니다. 예를 들어, 사용자 상호작용 로그는 고객 경험에 대한 중요한 인사이트를 제공하고, 시스템 로그는 이슈 또는 하드웨어 오류를 모니터링할 수 있습니다. 자세한 애플리케이션 로그는 성능 및 메모리 누수같은 잠재적인 문제에 대한 인사이트를 제공하며, 이 모든 것은 비즈니스 결정을 내리는 데 중요할 수 있습니다.

의미 있는 메시지 로깅

로그 메시지는 제공하는 정보와 문맥 만큼만 가치가 있습니다. 충분한 세부 정보를 추가하고 사용자가 읽고 이해할 수 있도록 만들면, 팀이 로그를 효과적으로 사용할 수 있습니다. 서드파티 인프라는 보통 필요한 세부 정보를 수집합니다. 하지만 내부적으로 구축된 애플리케이션의 경우, 항상 “로그가 이유를 진단하고 파악할 수 있도록 해주는 세부 정보를 수집하여, 사용자가 비즈니스에 영향을 미치는 필요한 조치를 취할 수 있도록 해주는가?"라는 질문을 해봐야 합니다.

애플리케이션 오류의 경우, 코드 줄로 어떤 일이 일어나고 있는지를 제대로 전달할 수 있어야 합니다. 예를 들어, '트랜잭션 실패'라는 오류 메시지는 '트랜잭션 실패: ${path/to/file:line-number} 사용자를 생성할 수 없음' 처럼 설명이 포함된 오류 메시지만큼 유용하지 않습니다. 로그에 트랜잭션에 대한 데이터가 포함되어 있어야, 개발자가 트랜잭션이 실패한 이유를 알 수 있습니다.

일반적으로, 프로그램의 오류 코드나 상태 코드는 애플리케이션의 문제 유형을 나타낼 수도 있습니다. 오류 코드의 텍스트나 번호를 출력하는 대신, 코드에 간단한 설명을 첨부하여 다른 개발자가 문제 해결을 위해 검색하는 데 드는 시간과 노력을 절약할 수 있도록 해주어야 합니다. 로그는 조직에 중요한 정보를 제공해야 합니다. 제한된 팀원들만 이해할 수 있는 암호 메시지나 설명이 포함되지 않은 메시지는 로깅하면 안됩니다.

로그를 간단하고 간결하게 유지

로그 메시지 내에 충분한 정보가 있는 것도 중요하지만 그 반대도 중요합니다. 메시지에 필요하지 않은 데이터가 너무 많으면 로그 스토리지의 크기와 비용이 늘어나고 검색 로그 속도가 느려지며 핵심 문제에 집중할 수 없게 되어 디버깅이 어려워질수 있습니다. 가장 중요한 정보만 캡처할 수 있도록 로그를 간결하게 유지해야 합니다. 로그에는 ‘이유’가 포함되어야 하고 불필요한 정보는 피해야 합니다. 오류가 발생하면, 환경에 대한 모든 세부 정보를 포함시키지 않고도, 오류의 근본 원인에 대한 정보를 제공할 수 있습니다.

예를 들어, 애플리케이션이 내부 API에서 데이터를 연결하고 검색하는 데 실패했다고 가정해보겠습니다. 이 경우, API의 오류 메시지나 환경의 네트워크 상태 정보를 기록하는 것이 좋습니다. 애플리케이션이 사용하는 메모리 양이나 실행 중인 애플리케이션 수를 포함시킬 필요는 없습니다.

시간 포함

타임스탬프를 포함시켜야 합니다. 어쩌면 당연하게 들릴 수도 있지만, 날짜와 시간이 자동으로 포함되는 데이터베이스에 로그를 지속적으로 작성하다 보면, 로그 메시지에 타임스탬프를 추가해야 한다는 사실을 잊을 수 있습니다. 의미가 있는 세분화된 수준을 선택하고 로그에 출력합니다. 빈도가 높은 작업은 시간을 밀리 초까지 추적하는 것이 필요할 수 있지만, 빈도가 낮은 작업은 분 또는 하루 단위로만 추적하면 됩니다. 중요한 것은 세분화 수준이 아니라, 조직 전체에 일관된 표준을 적용하는 것입니다.

당연하지만 중요한 또 다른 사항은 모든 시스템을 동시에 동기화해야 한다는 것입니다. 그래야 옵저버빌리티 플랫폼이 타임스탬프를 사용해, 로그 이벤트를 다른 텔레메트리 데이터와 연관시킬 수 있습니다.

파싱(구문 분석)이 가능한 로그 형식 사용

옵저버빌리티 플랫폼이 로그 데이터에서 데이터를 추출할 수 없다면, 별로 도움이 되지 않습니다. 쉽게 수집하고 집계할 수 있도록, 파싱을 하고 일관된 로그 구조를 유지할 수 있는 로그 형식을 사용해야 합니다. 뉴렐릭은 커스텀 로그 파싱 규칙을 쉽게 정의합니다. 그러나 로그 데이터를 이해할 수 없다면, 파싱 규칙은 효과가 없습니다.

MELT(메트릭, 이벤트, 로그 및 트레이스) 형식은 구문 분석이 가능한 로그 형식의 일례입니다. 사용자 정의 형식을 사용하는 경우, 로그 유형을 설정하면 사용자가 정의한 파싱 규칙이 트리거됩니다.

여러 애플리케이션들이 공통 목적을 지원하면, 모든 앱의 로그 형식을 표준화하는 데 중점을 두어야 합니다. 그래야, 각 앱과 관련된 팀이 다른 속성에 대한 가시성을 원하는 경우, 데이터를 옵저버빌리티 플랫폼에 더 쉽게 통합할 수 있습니다.

로그 형식에 대해 좀 더 자세히 살펴보겠습니다. 로그 집계 툴로 데이터가 수집되면, 세 가지 텍스트 구조가 유용성에 영향을 미칩니다.

그 세 가지 형식 범주는 다음과 같습니다.

• 구조화(Structured) — 구조화된 로그 형식 중 가장 일반적인 것은 JSON입니다. 많은 툴들이 이 로그 형식을 빠르게 파싱할 수 있습니다. 이 형식은 매우 유연하고 부피가 크지 않습니다. 이상적으로, 생성되는 모든 로그는 구조화된 형식입니다. JSON은 계층적 데이터를 구성하는 데 도움이 됩니다. 쉼표로 구분된 값(CSV)과 탭으로 구분된 값(TSV) 같은 다른 일반적인 형식도 구조화된 로그 데이터의 예입니다.

• 커먼(Common) — 커먼 형식은 구조화되지는 않았지만 잘 알려져 있고 정의되며 일관성이 있습니다. 액세스 로그를 위한 Apache 일반 로그 형식이 그 예입니다. 커먼 형식의 장점은 많은 툴로 즉시 데이터를 파싱할 수 있다는 것입니다.

• 커스텀(Custom) — 애플리케이션이 구조화된 형식이나 커먼 형식으로 로깅하지 않는 경우, 커스텀(사용자 지정) 형식으로 로그를 작성합니다. 로그 전달 중에, 각 로그 행의 시작과 끝을 인식하기 위해 일부 파싱이 필요할 수 있습니다. 커스텀 파싱 규칙을 만들면 데이터의 가치를 높일 수 있습니다.

로그 분류 및 그룹화

로그에 데이터 모델을 지정하면 보다 효과적으로 검색을 할 수 있습니다. 가능한 경우 로그를 분류하고 그룹화할 수 있도록 속성을 정의하고 포함시켜야 합니다. 뉴렐릭 등 업계 리더들이 구축한 로그에 대한 오픈 텔레메트리 표준을 살펴보는 것이 도움이 될 것입니다. 모든 프레임워크가 기본적으로 이 표준에 맞는 형식의 로그를 지원하는 것은 아니지만, 명명 규칙, 필드 값 정의 같은 많은 요소를 다루기 때문에 지침으로서 유용할 것입니다.

다음은 로그 데이터 모델에 유용한 몇 가지 공통 속성입니다.

리소스

리소스는 다음과 같이 로그의 소스와 위치를 정의합니다.

• 날짜 및 시간

• 컴퓨터나 호스트의 이름 또는 식별자

호스트 이름은 이름이 지정된 환경이 있는 호스트 기반 애플리케이션의 로그에서 의미가 있을 수 있습니다. 포드 또는 컨테이너 ID는 컨테이너화 또는 오케스트레이션된 환경에서 로그를 정리하는 데 도움이 됩니다. 오케스트레이션된 환경이나 PaaS 환경은 종종 많은 양의 메타데이터로 로그를 자동으로 채웁니다. 이는 조직에 도움이 되는 일이지만, 시스템은 알 수 없는 한정자를 사용해 로그에 주석을 다는 것도 중요합니다. 

예를 들어, 제품 버전 번호, 스테이징 환경과 실제 운영 환경의 비교, 테스트 분기 또는 A/B 테스트 버전이 유용합니다. 로그 집계는 여러 소스의 로그들이 모두 동일한 시스템에서 수집된다는 것을 의미합니다. 올바른 메타데이터가 없으면, 테스트에서 실패한 트랜잭션과 운영 환경의 실제 오류 로그를 구분할 수 없습니다.

로그 소스를 식별하는 데 도움이 되는 또 다른 리소스는 로그 전달(forwarding)입니다. 뉴렐릭이 제공하는 대부분의 로그 전달 솔루션은 데이터를 전달하는 데 사용되는 툴의 유형 및 버전을 통해 데이터에 자동으로 주석을 추가합니다.

문맥적 로그

문맥적 로그(logs in context)는 애플리케이션 정보를 로그에 자동으로 추가하는 뉴렐릭의 기능입니다. New Relic APM 에이전트가 로깅 프레임워크로 제공하는 애플리케이션 성능 관리 데이터가 애플리케이션 로그에 포함됩니다. 그리고 문맥적 로그가 로그 데이터를 관련된 애플리케이션 이벤트 및 트레이스와 자동으로 연관시킵니다. APM 오류와 분산된 트레이스는 오류 또는 트레이스와 동일한 트랜잭션 중에 생성된 로그에 직접 연결됩니다. 문맥적 로그는 스팬 ID, 트레이스 ID 및 애플리케이션 이름을 로그 메시지에 삽입함으로써 이러한 상관 관계를 생성합니다. 이는 애플리케이션과 로그 데이터를 함께 가져다, 훨씬 더 빠르게 문제를 해결할 수 있다는 의미입니다.

이러한 기능은 어떻게 구현하며 어떤 도움을 주는지 보다 자세한 정보는 문맥적 로그 설정에 대한 문서를 확인하시기 바랍니다.

로그 수준

개발자, 데브옵스 실무자 및 관리자는 종종 로그 수준을 심각도 수준이라고 부릅니다. 로그 수준은 이벤트의 상대적 중요도(디버그, 정보, 경고, 오류 및 치명적과 관련된 용어 포함)와 로깅 프레임워크 정보의 밀도 수준을 나타냅니다. 심각도 속성이 있으면, 덜 중요한 정보를 필터링하거나 삭제해 중요한 오류만 골라낼 수 있습니다.

로그 수준을 효과적으로 사용하면 데이터 양을 제한하고, 중앙화된 로그 관리 툴을 사용하는 데 드는 비용을 절감하며, 신속하게 검색 결과를 얻을 수 있습니다. 애플리케이션이 로그 생성 방법을 제어할 수 없는 경우도 있긴 하지만, 로그 관리 시스템이 원하지 않는 데이터를 삭제할 수도 있습니다. New Relic One을 사용하면, 로그 수준을 기반으로 머신 러닝 기반 패턴을 사용해 이상 값을 가시화할 수 있습니다. 또한 시각적으로 구분할 수 있도록 로그 수준에 색상이 지정되어 있기 때문에, 가장 중요한 영역에 주의를 집중할 수 있습니다.

디버그 로그 수준을 사용할 때는 특히 주의해야 합니다. 디버그는 특정 행동과 관련된 장황한 메시지를 캡처해야 할 때 유용하지만, 불필요하게 사용하면 추가적인 가치는 없이 지나치게 많은 양의 로그가 생성되어 수집 및 검색 기능이 느려질 수 있기 때문입니다. 그룹화, 분류 및 로깅 방법이 일관되도록, 대규모 팀과 프로젝트가 로그 수준에 대한 표준을 구축하는 것이 도움이 됩니다.

로깅 툴 및 프레임워크 사용

많은 테스트를 거친 기존 로깅 툴과 프레임워크를 사용해야 합니다. 로깅 솔루션을 처음부터 구현하는 데 시간과 리소스를 소비하는 대신, 기존 프레임워크를 사용하면 시간과 번거로움을 줄일 수 있습니다. 일관된 하나의 로깅 프레임워크를 사용하면, 엔지니어링 팀이 쉽게 도입할 수 있고, 로그 출력이 정규화되며, 문맥적 로그를 일관되게 만들 수 있습니다. 로깅 프레임워크를 도입할 때는 세심하게 검토를 하고, 새 코드를 사용할 때와 마찬가지로 성능에 미치는 영향을 테스트해봐야 합니다.

큰 값은 참조에만 사용

경우에 따라, 메모리 덤프나 파일 또는 이미지 세트 같은 보다 심도 있는 문맥을 제공하기 위해 로그에 대용량 데이터가 필요할 수 있습니다. 일반적으로 이러한 데이터는 별도로 저장하거나 지정된 서버에 업로드하고, 로그 내에 blob으로 저장하는 것이 아니라 로그에 그 위치를 참조하는 것이 좋습니다. 로그를 최대한 경량으로 유지하고 데이터에는 별도로 액세스해야 합니다.

유용한 뷰, 쿼리 및 알람 공유

마지막으로, 로그에 대한 표준화된 시각화, 쿼리 및 알람을 생성하고 공유해야 합니다. 이를 통해, 조직의 현재 상태에 대한 광범위한 인사이트를 확보하고 팀들 간에 가시성과 커뮤니케이션을 향상할 수 있습니다. 이것이 바로 풀 스택 옵저버빌리티의 힘입니다. 무슨 일이 일어나고 있는지 완전한 가시성이 있어야 하지 않을까요?

유용할지 모르는 모든 것을 로그에 포함시키고 싶겠지만, 몇 가지 예외와 피해야 할 사항들이 있습니다.

민감한 정보

민감한 정보는 주의해서 다루어야 합니다. 개인 식별 정보(PII), 신용카드 번호 등 규제되는 데이터는 반드시 보호해야 합니다. 유럽 연합의 일반 데이터 보호 규정(GDPR), 미국의 건강 보험 이동성 및 책임법(HIPAA) 같은 법률을 고려할 필요가 있습니다. 

오픈 웹 애플리케이션 보안 프로젝트(OWASP)의 로깅 지침 은 액세스 토큰, 비밀번호, 민감 정보, 개인이 비공개로 유지하길 원하는 정보 등 로그에 포함되면 안되는 항목을 지정하고 있습니다. 

프라이빗 서버나 데이터베이스에 로그를 보관하면, 이름과 이메일 주소 같은 PII를 실수로 로깅하기 쉽습니다. 일반적으로, 옵저버빌리티를 향상시키지는 않지만 특정 사용자의 행동이나 이벤트를 추적해야 하는 경우, 익명화된 식별자를 사용하는 것이 좋습니다. 옵저버빌리티 플랫폼에서 로그 데이터는 안전하게 보호되지만, 조직 외부로 PII를 전송할 때는 각별히 주의해야 합니다.

소스 코드 및 독점 데이터

규정이나 규제 준수와 관련된 정보 외에도,애플리케이션의 소스 코드, 조직 내에서 보호되는 데이터 등 로그에 저장을 원치 않는 다른 정보가 있을 수 있습니다. 로그를 안전하게 저장할 수는 있지만 안전하게 액세스하는 것이 불가능한 경우가 있을 수 있습니다. 영업 비밀이나 미공개 또는, 미발표된 프로젝트와 기능이 공개될 수 있는 정보는 로그에 포함시키면 안됩니다. 특히 서드파티 서비스의 외부에 로그를 저장하는 경우, 이러한 정보를 로그에서 제외시켜야 합니다.

중복 정보

마지막으로, 중복 정보입니다. 로그에 중복된 정보가 추가되어도 크게 문제가 될 것은 없고, 일반적으로 정보가 너무 많은 것이 부족한 것보다는 낫습니다. 그러나 같은 정보를 많이 포함시키면, 불필요한 로그가 생성되어 목적은 달성하지 못하고 비용만 증가할 수 있습니다.

풀 스택 옵저버빌리티를 향상시키기 위해 로그를 사용하면, 비즈니스에 영향을 미치는 결정을 실시간으로 내리는 데 도움이 되고, 엔지니어의 디버깅 및 인시던트 대응 시간을 줄일 수 있으며, 구축에 더 많은 시간을 할애할 수 있습니다.

이러한 모범 사례에 부합하는 로그는 고객들을 위해 모든 것을 원활하게 실행하고 유지하는 데 필요한 세부 정보와 전체 스택에 대한 심층적인 가시성을 제공해, 문제를 더 빨리 해결하고 개발 속도를 높일 수 있도록 해줍니다.

로그를 사용해 옵저버빌리티를 확보하고 로그 관리로부터 최대한의 가치를 얻으려면, 지금 무료 계정을 신청하여 New Relic 로그 관리를 사용해보시기 바랍니다.