수집하고 저장할 로그를 결정했으면 이제 로그를 정리할 차례입니다. 여전히 수백 기가바이트 또는 수십 테라바이트의 로그를 수집하고 있을 가능성이 높습니다. 원래 가지고 있던 것보다 훨씬 적지만 효과적으로 사용하려면 여전히 수고해야 합니다.
이 문제를 해결하기 위해 남아 있는 로그를 주제별 파티션으로 그룹화하고 로그를 구문 분석하여 귀중한 속성을 추출하고 태그를 지정합니다. 이러한 방식으로 로그를 구성하면 다음을 수행할 수 있습니다.
- 로그 내의 모든 속성에 대한 쿼리
- 프런트엔드 로그 vs 백엔드 로그와 같은 특정 파티션을 한 번에 관리
- 쿼리 로드 시간 단축
로그를 분할하는 이유
로그를 개별 파티션으로 분리하면 성능이 향상되고 로그를 더 쉽게 관리할 수 있습니다. 예를 들어 프런트 엔드 로그에서만 찾을 수 있는 특성을 쿼리한다고 가정합니다. 5TB의 로그를 통해 쿼리하면 프런트 엔드 로그만 있는 특정 1TB 파티션을 통해 쿼리하는 것보다 훨씬 오래 걸립니다.
데이터 분할의 목표:
- 정적이거나 자주 변경되지 않는(예: 사업부, 팀, 환경, 서비스 등) 환경 또는 조직의 개념과 일치하는 데이터 파티션을 만듭니다.
- 최적의 성능을 위해 각 파티션이 일일 수집 1TB 미만으로 유지되도록 합니다.
파티션에는 두 가지 유형의 보존이 있습니다. 최대 보존을 위해 Standard [표준을] 선택하십시오. 먼 미래에 쿼리할 수 있는 귀중한 데이터에 이것을 사용하십시오. 30일 보존을 위해 Secondary [보조를] 선택하십시오. 덜 가치 있는 데이터 또는 가까운 장래에 필요할 데이터에 사용하십시오.
로그를 구문 분석하는 이유
수집 시 로그를 구문 분석하는 것은 귀하와 조직의 다른 사용자가 로그 데이터를 더 많이 사용할 수 있도록 하는 가장 좋은 방법입니다. 예를 들어 Grok 구문 분석 규칙을 사용하여 구문 분석 전 및 구문 분석 후 두 로그를 비교합니다.
사전 구문 분석:
{ "message": "32 4329 store_Portland"}구문 분석 후:
{ "transaction_total": "32", "purchase_number": "4329", "store_location": "store_Portland",}이를 통해 대시보드 및 경고에서 transaction_total 와 같이 새로 정의된 속성을 쉽게 쿼리할 수 있습니다.
로그 구성
ACME Corp에서 앞으로 몇 달 동안 약 2TB의 로그를 수집할 것임을 알고 있다고 가정해 보겠습니다. Java 앱과 인프라 에이전트에서 오는 로그에 대한 파티션을 생성하려고 합니다. 그들은 표준 보존을 사용하기로 결정하기 위해 먼 미래에 Java 로그를 쿼리해야 할 수도 있다고 생각합니다. 한편, 그들은 최근 인프라 로그만 필요하므로 이에 대해 보조 보존을 사용합니다.
이렇게 하려면:
UI로 이동
one.newrelic.com > Logs로 이동합니다.
로그 분할
- 왼쪽 탐색 메뉴의 Manage data [데이터 관리] 에서 Data partitions [데이터 파티션 을]클릭한 다음 Create partition rule [파티션 규칙 생성 을]클릭합니다.
Log_로 시작하는 영숫자 문자열로 파티션 이름을 정의합니다. 이 경우Log_java.- 선택적 설명을 추가합니다.
- 파티션에 대한 표준 네임스페이스 보존을 선택합니다.
- 규칙의 일치 기준 설정: 유효한 NRQL
WHERE절을 입력하여 이 파티션에 저장할 로그를 일치시킵니다. 이 경우logtype=java. - 만들기를 클릭하여 새 파티션을 저장합니다.
이렇게 하면 모든 Java 로그에 대해 표준 데이터 보존이 있는 데이터 파티션이 생성됩니다. 인프라 로그를 구성하려면 위와 동일한 단계를 따르되 보존을 보조로 변경하고 쿼리를 logtype=infrastructure로 변경하면 됩니다.
로그 구문 분석
이제 로그가 분할되었으므로 구문 분석할 차례입니다. 이를 구문 분석하면 더 쉽게 쿼리하고 액세스할 수 있도록 로그 내에서 관련 데이터를 가져올 수 있습니다.
로그를 구문 분석하려면:
- 로그 UI의 왼쪽 탐색 메뉴에 있는 Manage Data [데이터 관리] 에서 Parsing [구문 분석 을]클릭한 다음 Create parsing rule [구문 분석 규칙 생성 을]클릭합니다.
- 새 구문 분석 규칙의 이름을 입력합니다.
- 구문 분석할 기존 필드를 선택하거나(기본값은
message) 새 필드 이름을 입력합니다. - 구문 분석하려는 로그와 매치되는 유효한 NRQL
WHERE절을 입력합니다. - 일치하는 로그가 있는 경우 선택하거나 로그 붙여넣기 탭을 클릭하여 샘플 로그에 붙여넣습니다.
- 구문 분석 규칙을 입력하고 Output [출력] 섹션에서 결과를 확인하여 작동하는지 확인합니다. (아래 예 참조)
- 사용자 정의 구문 분석 규칙을 활성화하고 저장합니다.
다음 예는 구문 분석 규칙을 만드는 구체적인 예를 안내합니다.
로그를 구문 분석하기 위한 Grok 패턴 생성에 대한 자세한 내용은 블로그 게시물 을 참조하십시오.
무엇 향후 계획
로그의 진정한 가치를 발견하고 팀이 로그로 인해 좌절하는 시간을 절약할 수 있게 된 것을 축하합니다! 시스템이 성장하고 수집함에 따라 구문 분석 규칙과 파티션을 유지해야 합니다. New Relic에 대해 더 깊이 알아보고 싶다면 당신을 위해 할 수 있습니다. 다음 문서를 확인하십시오.
- 로그 데이터 구문 분석: Grok를 사용한 로그 구문 분석을 자세히 살펴보고 GraphQL API인 NerdGraph를 사용하여 로그 구문 분석 규칙을 생성, 쿼리 및 관리하는 방법을 알아봅니다.
- 로그 패턴: 로그 패턴은 검색 없이 로그 데이터에서 값을 발견하는 가장 빠른 방법입니다.
- 로그 난독화: 로그 난독화 규칙을 사용하면 특정 유형의 정보가 New Relic에 저장되는 것을 방지할 수 있습니다.
- 긴 로그(BLOB)에서 데이터 찾기: 광범위한 로그 데이터는 문제를 해결하는 데 도움이 될 수 있습니다. 하지만 로그의 속성에 수천 개의 문자가 포함되어 있다면 어떻게 될까요? New Relic은 이 데이터 중 얼마나 많은 데이터를 저장할 수 있습니까? 그리고 이 모든 데이터에서 유용한 정보를 어떻게 찾을 수 있습니까?