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