데이터 수집 거버넌스는 조직에서 수집한 원격 측정 데이터에 대해 최적의 가치를 얻는 방법입니다. 이것은 수많은 비즈니스 단위와 작업 그룹이 있는 복잡한 조직에 특히 중요합니다. 이것은 New Relic 데이터 수집을 최적화하기 위한 4부작 가이드의 두 번째 부분이며 관찰 가능성 성숙도에 대한 시리즈의 일부입니다.
시작하기 전에
이 가이드에는 데이터 수집을 최적화하기 위한 자세한 권장 사항이 포함되어 있습니다. 이 가이드를 사용하기 전에 일반 데이터 관리 문서를검토하는 것이 좋습니다.
이 단계에 대해
데이터 수집 거버넌스 사례의 이 단계에서는 조직에서 현재 생성 중인 모든 원격 분석에 대한 높은 수준의 보기를 얻는 것이 필요합니다. 이 단위는 수집 통계를 계정, 원격 분석 유형 및 애플리케이션과 같은 다양한 그룹으로 분류하는 데 중점을 둡니다. 이 수치는 수집 데이터 최적화 및 수집 데이터예측 단계에 정보를 제공하는 데 사용됩니다.
다음 측정기준에 대한 구조화된 분석 보고서를 생성하는 방법을 배웁니다.
조직
조직의 특정 계정
청구 가능한 원격 분석 유형
또한 다음을 포함하여 매우 세분화된 분석을 생성하는 방법을 배우게 됩니다.
애플리케이션(APM | 브라우저 | 모바일)
쿠버네티스 클러스터
인프라 통합
요망되는 결과
조직 내에서 어떤 그룹이 어떤 유형의 데이터와 얼마나 기여하고 있는지 정확히 이해합니다.
전제 조건
청구 가능한 모든 원격 분석은 NrConsumption 및 NrMTDConsumption 이벤트로 추적됩니다. 이 가이드는 NrMTDConsumption 보다 더 세분화된 실시간 데이터를 제공하는 NrConsumption 쿼리 방법에 중점을 둡니다. NrConsumption 속성 usageMetric 은 원격 분석 유형을 나타냅니다.
NrConsumption 을 사용하여 "지난 30일 동안 각 계정에서 수집한 브라우저 모니터링 데이터의 양은 얼마입니까?"와 같은 질문을 할 수 있습니다. 및 "지난 30일 이후 수집이 어떻게 변경되었습니까?" 다음은 해당 데이터를 반환하는 쿼리입니다.
FROM NrConsumption SELECTsum(GigabytesIngested)WHERE usageMetric ='BrowserEventsBytes' SINCE 30 days AGO COMPARE WITH30 days AGO FACET consumingAccountName
응답은 계정별로 수집한 브라우저 모니터링 데이터의 GB 수를 보여줍니다.
bash
$
Banking platform, 75 GB, +2.9%
$
Marketing platform, 40 GB, -1.3%
다음은 다양한 usageMetric 유형, 구성 이벤트(데이터가 저장되는 이벤트 유형), 데이터 수집 생성을 담당하는 에이전트 또는 메커니즘의 유형에 대한 분석입니다.
사용량 기반 가격 책정 모델 의 경우 원격 측정 데이터와 사용자 모두 사용량과 비용에 기여합니다. 이 가이드는 원격 분석 데이터의 가치를 극대화하는 데 중점을 둡니다. 이 섹션에서 사용자에 대한 언급은 사용자와 데이터의 균형을 맞추기 위한 다양한 옵션을 이해하는 데 도움이 됩니다.
사용 계획에는 세 가지 일반적인 유형이 있습니다. 사용 계획은 조직의 수집 대상을 설정하는 방법에 영향을 미칠 수 있습니다.
약정 계약
약정 계약 이 있는 경우 데이터 수집을 위한 월별 목표 예산이 있을 수 있습니다. 예를 들어, 하루에 5TB 및 100명의 전체 플랫폼 사용자를 목표로 설정했을 수 있습니다. 이러한 유형의 계약에서 사용자는 "교환"될 수 있지만 관찰 가능성 목표에 적합한 조합을 얻을 수 있도록 조직의 다른 이해 관계자와 이에 대해 논의하는 것이 가장 좋습니다. 일부 고객은 1년 동안 소비 변동성을 계획할 것이지만 지금은 월별 소비 예산이 연간 총 약정 요금을 12로 나눈 값이라고 가정해 보겠습니다.
필요한 전체 플랫폼 사용자 및 핵심 사용자의 수를 알고 있는 경우 다음 공식을 사용할 수 있습니다.
모든 버전 에서는 매월 100GB의 데이터 수집이 무료로 제공됩니다. 무료 금액 이상의 데이터 수집 가격에 대한 자세한 내용은 정가표를 참조하세요.
사용 시기
특정 기간에서 가져온 데이터 샘플을 가져와서 지정된 비율을 생성해야 하는 경우 rate 연산자를 사용합니다. 예를 들어, 데이터의 일일 샘플을 가져와 이를 기반으로 30일 요금을 계산합니다.
주어진 데이터 샘플을 기반으로 속도 계산
지난 달에 대한 일일 평균 섭취량을 확인하십시오.
SELECT rate(sum(GigabytesIngested),1day)AS'Daily Ingest Rate (GB)'FROM NrConsumption WHERE productLine ='DataPlatform'LIMIT MAX SINCE 30 days AGO
전체 조직에 대한 우리의 간단한 응답은
bash
$
Daily ingest rate: 30.4 k
이 쿼리는 지난 달의 일일 수집 비율이 하루에 약 30TB임을 보여줍니다.
사용 시기
수집 계산을 특정 달력 월로 제한하는 것이 중요한 경우 이 옵션을 사용합니다. 예를 들어 통합을 위한 수집이 1월 말에 증가하여 2월 중순까지 계속되었을 수 있습니다. 이 연산자는 청구에 사용되는 특정 달력 월에 대한 수집을 패싯 처리하는 데 도움이 됩니다.
달력 월별 패싯
SELECTsum(GigabytesIngested)AS'Daily Ingest Rate (GB)'FROM NrConsumption WHERE productLine ='DataPlatform' FACET monthOf(timestamp)LIMIT MAX SINCE 56 weeks AGO
결과 테이블은 상당히 높은 변동성을 보여줍니다. 8월과 9월의 상황은 상당히 hot 였습니다. 그 중 일부는 우리 조직의 계절성이지만 일부는 원격 측정 범위의 확장과 관련이 있습니다.
bash
$
|MONTH OF TIMESTAMP|GB INGESTED|
$
|---|---|
$
|December 2021*|636 k|
$
|November 2021|901 k|
$
|October 2021|873 k|
$
|September 2021|1.05 M|
$
|August 2021|1.08 M|
$
|July 2021|1.05 M|
$
|June 2021|887 k|
$
|May 2021|881 k|
$
|||
사용 시기
한 기간 동안 다른 기간 사이에 수집 볼륨 또는 비율의 변화량을 평가하려는 경우 이 옵션을 사용합니다. 수집이 예기치 않게 증가하는지 아는 것이 중요합니다.
단순 변경 분석
SELECTsum(GigabytesIngested)FROM NrConsumption WHERE productLine ='DataPlatform'AND usageMetric ='BrowserEventsBytes' SINCE 6 months AGO UNTIL 1 week AGO TIMESERIES 7 weeks COMPARE WITH2 months ago
COMPARE WITH 를 사용하여 성장 패턴을 이해하는 것을 보여주는 예시 차트.
사용 시기
더 넓은 패턴을 보기 위해 수집의 규칙적인 가변성의 효과를 제거해야 할 때 이것을 사용하십시오.
원격 측정은 본질적으로 잡음이 있습니다. 실제 현상은 신호에 많은 임의의 피크와 골을 남기는 스퍼트에서 발생합니다. 이것은 현상의 전체 복잡성을 볼 수 있게 해주기 때문에 어떤 면에서는 좋습니다. 그러나 추세를 보려고 할 때 세부 사항에 주의가 산만해질 수 있습니다. NRQL은 각 데이터 포인트를 약간 오래된 포인트와 결합하여 모든 시계열을 매끄럽게 만드는 강력한 방법을 제공합니다. 이것은 우리가 극단적인 increase 또는 decrease 보다는 전체적인 시간적 경향에 초점을 맞추도록 합시다.
1일 수집 비율에 대한 원시 시계열의 들쭉날쭉함을 확인하세요.
FROM NrConsumption SELECT rate(sum(GigabytesIngested),1day)WHERE productLine ='DataPlatform' SINCE 26 weeks AGO TIMESERIES 1DAY
평활화 없는 일일 비율 시계열
이제 4일의 슬라이딩 윈도우 를 사용하여 하루 이벤트의 영향을 줄이면 더 명확한 그림을 볼 수 있습니다. 4일은 weekends 의 영향을 흐리게 하므로 일요일에 대한 데이터가 금요일에 대한 데이터와 어느 정도 결합됩니다.
FROM NrConsumption SELECT rate(sum(GigabytesIngested),1day)WHERE productLine ='DataPlatform' since 24 weeks ago TIMESERIES 1DAY SLIDE BY4 days
스무딩이 있는 일일 비율 시계열
사용 시기
이를 사용하여 주어진 기간 동안의 통계적 변화율을 추정합니다. 변화율은 도함수를 근사화하기 위해 선형 최소제곱 회귀를 사용하여 계산됩니다.
NRQL은 변화율을 평가하기 위한 몇 가지 도구를 제공합니다. 이전 예에서 볼 수 있듯이 지난 몇 개월 동안 브라우저 메트릭이 매우 크게 증가했기 때문에 이것은 유용합니다. 이 변화율 분석은 derivative 연산자를 사용하며 주요 성장이 9월 초에 일어났다는 확신을 줍니다. 7일 파생 상품을 기반으로 하는 성장률이 다소 마이너스인 것 같으므로 BrowserEventsBytes 수집에서 현재 새로운 고원에 도달했을 수 있습니다.
SELECT derivative(sum(GigabytesIngested),7day)FROM NrConsumption WHERE productLine ='DataPlatform'and usageMetric ='BrowserEventsBytes'LIMIT MAX SINCE 3 MONTHS AGO UNTIL THIS MONTH TIMESERIES 1MONTH slide by3 days COMPARE WITH1 WEEK AGO
각 하위 계정 또는 계정별 차트가 있는 대시보드에서 이러한 쿼리를 실행합니다. 쿼리는 수집 1주일을 기준으로 30일 요금을 추정합니다.
30일 요금 추정
APM:
FROMTransaction, TransactionError, TransactionTrace, SqlTrace, ErrorTrace, Span SELECT rate(bytecountestimate()/10e8,30day)AS'GB Ingest' FACET appName SINCE 1 WEEK AGO
브라우저:
FROM PageAction, PageView, PageViewTiming, AjaxRequest, JavaScriptError SELECT rate(bytecountestimate()/10e8,30day)AS'GB Ingest' FACET appName SINCE 1 WEEK AGO
이동하는:
FROM Mobile, MobileRequestError, MobileSession SELECT rate(bytecountestimate()/10e8,30day)AS'GB Ingest' FACET appName SINCE 1 WEEK AGO
이 패싯과 함께 표시될 usage.Integration 값의 몇 가지 예는 다음과 같습니다.
FROM Metric SELECT rate(bytecountestimate()/10e8, 30 day) FACET usage.integrationName SINCE 1 WEEK AGO
7일 합계:
FROM Metric SELECT bytecountestimate()/10e8 FACET usage.integrationName SINCE 1 WEEK AGO
모든 New Relic 원격 측정 유형 중에서 로그 데이터가 가장 변동이 심한 유형입니다.Log 레코드에는 거의 모든 필드가 포함될 수 있으며 지정된 로그 레코드에 무엇을 포함할지 알 수 없는 경우가 많습니다.공통 스키마가 없기 때문에 로그 수집 기준선은 다른 데이터 유형 기준선보다 약간 더 많은 분석이 필요할 수 있습니다.
보다 유용한 기본 로그 수집 기술 중 하나는 호스트, 컨테이너 또는 Kubernetes 클러스터별로 수집을 추정하는 것입니다.여기 몇 가지 예가 있어요.
지난 3시간 동안 호스트별 로그 수집(총):
FROM Log SELECT bytecountestimate()/10e8
WHERE host isnotNULL SINCE 3 hours ago FACET host
호스트별 로그 수집(30일 비율):
FROM Log SELECT rate(bytecountestimate()/10e8,30day)
WHERE host isnotNULL SINCE 3 hours ago FACET host
cluster_name별 로그 수집(30일 비율):
FROM Log SELECT rate(bytecountestimate()/10e8,30day)
WHERE host isnotNULL SINCE 3 hours ago FACET cluster_name
cluster_name 및 container_name별 로그 수집(30일 요금):
FROM Log SELECT rate(bytecountestimate()/10e8,30day)
WHERE host isnotNULL SINCE 3 hours ago FACET cluster_name, container_name
30일 요금 추정
FROM K8sClusterSample, K8sContainerSample,K8sDaemonsetSample, K8sDeploymentSample, K8sEndpointSample, K8sHpaSample, K8sNamespaceSample, K8sNodeSample, K8sPodSample, K8sReplicasetSample, K8sServiceSample, K8sVolumeSample SELECT rate(bytecountestimate()/10e8,30day)AS'GB Ingest' FACET clusterName SINCE 1 WEEK AGO
ProcessSample 상당히 많은 양의 이벤트가 될 수 있습니다. 이 예에서는 명령줄당 30일 수집을 계산합니다.
명령 이름으로 30일 요금 추정
FROM ProcessSample SELECT rate(bytecountestimate()/10e8,30day)AS'GB Ingested' FACET commandName SINCE 1DAY AGO
사용 시기
쿼리에 이벤트 수준 단위가 필요하고 계정에 어떤 맞춤 이벤트가 있는지 잘 모르는 경우 eventType() 연산자를 사용합니다.
종종 여러 이벤트를 선택하는 쿼리를 사용합니다. 이것은 주요 수단 중 하나입니다. 주어진 에이전트 또는 통합이 우리에게 보내는 데이터의 양을 결정해야 합니다.
다음 쿼리는 Kubernetes 통합이 우리에게 보내는 데이터의 양을 알려줍니다.
FROM
K8sApiServerSample,
K8sClusterSample,
K8sContainerSample,
K8sControllerManagerSample,
K8sDaemonsetSample,
K8sDeploymentSample,
K8sEndpointSample,
K8sNamespaceSample,
K8sNodeSample,
K8sPodSample,
K8sReplicasetSample,
K8sSchedulerSample,
K8sServiceSample,
K8sStatefulsetSample,
K8sVolumeSample
SELECT bytecountestimate()/10e8 AS'Gigabytes'
SINCE 1 DAYS AGO
LIMIT MAX
자체적으로 강력하지만 단일 집계 값만 반환합니다.
bash
$
42.341 Gigabytes
특정 이벤트가 소비하는 데이터의 양을 알기 위해 더 깊이 드릴해야 하는 경우 패싯 절에서 eventType() 을 사용하여 해당 결과를 얻을 수 있습니다.
이전 쿼리에 FACET eventType() 절을 추가하면 다음이 제공됩니다.
K8s 이벤트 유형별 수집 목록
사용 시기
계정에 존재하는 이벤트가 확실하지 않은 경우 SHOW EVENT TYPES 을 사용합니다.
SHOW EVENT TYPES 주어진 기간 동안 계정의 모든 이벤트 유형을 나열합니다. 자세한 내용은 이벤트 유형 표시 를 참조하십시오. 특정 시간 창을 사용하면 주어진 이벤트가 시스템에 들어오기 시작한 시점을 더 잘 이해하는 데 유용할 수 있습니다.
사용 시기
쿼리에 측정항목 이름 수준의 세분화가 필요한 경우 FACET metricName 을 사용합니다.
측정항목을 실제로 탐색하고 각각에서 오는 데이터의 상대적인 양을 파악하는 가장 좋은 방법은 SELECT FROM Metric 쿼리에 FACET metricName 를 사용하는 것입니다. WHERE 절을 통합하여 목록의 범위를 좁힐 수 있습니다. 예를 들어, metricName 에서 텍스트가 kube_pod 인 측정항목의 상대적 수집 볼륨을 보려면 다음과 같은 쿼리를 실행합니다.
SELECT bytecountestimate()/10e8 as'Gigabytes'from Metric facet metricName where metricName like'%kube_pod%' since 1day ago limit max
브라우저 창의 오른쪽 상단에 있는 Install this quickstart 을 클릭합니다.
해당하는 경우: 계정 전환기에서 기본 또는 최상위 계정을 선택합니다.
Done 을(를) 클릭합니다.
빠른 시작 설치가 완료되면 Data ingest governance baseline 대시보드를 엽니다.
새로 설치된 대시보드로 이동합니다.
대시보드 개요
기본 개요 탭에는 강력한 시계열 보기를 포함한 다양한 차트가 표시됩니다.
조직 전체 기준 수집 시계열
두 번째 탭은 하위 계정 및 사용 메트릭별 기준 보고서를 제공합니다.
조직 전체 기준 보고서 보기
나머지 탭은 브라우저 데이터, APM 데이터, 로그 및 추적과 같은 특정 원격 분석 유형에 대한 자세한 보기를 제공합니다. 예를 들어 이 스크린샷은 브라우저 세부 정보 페이지를 보여줍니다.
단일 원격 분석 유형(이 경우 브라우저 데이터)에 초점을 맞춘 수집 세부 정보의 예.
세부 정보 탭에는 다음이 포함됩니다.
APM: ApmEventsBytes
트레이싱: TracingBytes
브라우저: BrowserEventsBytes
이동하는: MobileEventsBytes
인프라(호스트): InfraHostBytes
인프라(프로세스):InfraProcessBytes
인프라(통합): InfraIntegrationBytes
맞춤 이벤트: CustomEventsBytes
서버리스: ServerlessBytes
픽시: PixieBytes
대시보드에 수집 대상 지표 추가
전제 조건 섹션에서 우리는 월별 사용량 목표의 개념에 대해 논의했습니다. 실제로 추적을 유지하는 데 도움이 되는 몇 가지 목표가 있을 수 있습니다.
일일 요금 또는 월별 수집에 대한 전체 조직 목표입니다.
최적의 분석을 위해 데이터 유형별로 대상을 지정합니다(예: 로그의 경우 하루 1TB, 지표의 경우 하루 2TB).
특정 하위 계정 또는 사업부에 대한 대상입니다.
이 예에는 조직의 총 수집을 월 < 360TB로 목표로 하는 조직이 있습니다. 이는 하루 20TB(월 600TB) 이상에서 수집을 줄인 후 새로운 목표였습니다.
대상을 더 쉽게 측정할 수 있도록 SELECT 문에 정적 숫자 360000 를 추가하여 임계값 선 차트를 추가했습니다.
SELECT360000, rate(sum(GigabytesIngested),30day)AS'30 Day Rate'FROM NrConsumption WHERE productLine='DataPlatform' since 30 days ago limit max compare with1month ago TIMESERIES 7 days
NRQL을 사용하여 대상 30일 수집 대상 을 나타내는 라인을 렌더링할 수 있습니다.
일일 환율 목표 라인을 적용할 수도 있습니다. 360000을 30으로 나누고 12000을 일일 요금 목표로 사용하겠습니다. Daily ingest rate (compare with 3 months prior) 차트 업데이트:
SELECT12000, rate(sum(GigabytesIngested),1day)AS avgGbIngestTimeseries FROM NrConsumption WHERE productLine='DataPlatform' TIMESERIES AUTO since 9 months ago limit max COMPARE WITH3 months ago
NRQL을 사용하여 일일 수집 대상 을 나타내는 라인을 렌더링할 수 있습니다.
표 형식의 30일 수집 보고서 생성
30일 수집 보고서를 생성하려면:
이전에 설치된 데이터 수집 거버넌스 기준 대시보드를 엽니다.
기준 보고서 탭을 클릭합니다.
"지난 30일" 표의 오른쪽 상단에 있는 ... 을 클릭하고 Export as CSV
CSV를 Google 스프레드시트 또는 원하는 스프레드시트로 가져옵니다.
또는 대시보드를 설치하지 않은 경우 이 쿼리를 사용하여 쿼리 빌더 에서 사용자 지정 차트를 생성할 수 있습니다.
SELECTsum(GigabytesIngested)AS'gb_ingest_30_day_sum', rate(sum(GigabytesIngested),1day)AS'gb_ingest_daily_rate', derivative(GigabytesIngested,90day)as'gb_ingest_90_day_derivative'FROM NrConsumption WHERE productLine='DataPlatform' since 30 days ago facet consumingAccountName, usageMetric limit max
다음은 Google 스프레드시트로 가져온 시트의 예입니다.
기준 대시보드 테이블 형식 페이지에서 내보낸 스프레드시트
스크린샷은 30일 수집 총계로 정렬된 테이블을 보여줍니다.
필요에 따라 타임라인과 일부 세부정보를 자유롭게 조정하세요. 예를 들어, 우리는 지난 몇 달 동안의 변화를 느끼기 위해 90일 파생상품을 추출하기로 결정했습니다. 목표에 맞게 파생 상품의 기간을 쉽게 변경할 수 있습니다.
보고서 사용자 정의
Optimize 및 Forecast 와 같은 데이터 수집 거버넌스의 다른 단계를 용이하게 하기 위해 보고서에 유용한 열을 추가합니다. 다음 필드는 최적화 및 계획 결정을 안내하는 데 도움이 됩니다.
참고: 성장 이상 현상 및 이에 대한 관련 설명을 기록합니다. 예상되는 주요 예상 성장을 표시하십시오.
기술 담당자: 특정 계정의 관리자 또는 특정 원격 측정 유형과 관련된 사람의 이름입니다.
수집 이상 감지
수집 이상을 감지하는 몇 가지 단계는 다음과 같습니다.
수집 이상에 대한 경고
이 수집 경고 가이드 를 사용하여 데이터 소비 증가로 인해 놀라지 않도록 하십시오. 최소한 다음을 작성하십시오.
계절적 증가를 넘어 데이터 수집에 대한 월별 목표를 초과하는 경우 알리는 임계값 경고
수집 데이터의 급격한 증가를 알리는 이상 경고
경고를 사용하여 소비 이상을 식별하는 것 외에도 New Relic Lookout을 사용하여 잠재적인 수집 이상을 탐색할 수 있습니다.
전망대
Lookout을 사용하면 거의 모든 NRQL 쿼리를 제공할 수 있으며 주어진 기간 동안 이상 징후를 검색합니다. 아래 보기는 이 쿼리를 기반으로 합니다.
SELECT rate(sum(GigabytesIngested),1day)AS avgGbIngest FROM NrConsumption WHERE productLine='DataPlatform' FACET usageMetric
Lookout을 사용하여 사용 메트릭 으로 수집에서 이상을 찾을 수 있습니다.
이 보기를 얻으려면 패싯 필드를 consumingAccountName 으로 변경합니다.
Lookout을 사용하여 sumptionAccountName 을 통해 수집에서 이상을 찾을 수 있습니다.
엔터티 분석 대시보드 설치(선택 사항)
이전 섹션에서는 NrConsumption 을 기본 소스로 사용하는 수집 baseline 대시보드를 설치했습니다. 이러한 상위 수준 보기 외에도 bytescountestimate() 를 사용하여 거의 모든 이벤트 또는 측정항목에 대한 수집을 추정하는 다른 시각화를 만들 수 있습니다. bytescountestimate() 에 대한 자세한 개요 는 전제 조건 섹션에서 논의되었습니다 .
브라우저 창의 오른쪽 상단 섹션에서 Install this quickstart 을 클릭합니다.
대시보드 가져오기 기능 을 사용하여 APM, 브라우저 모니터링, 모바일 모니터링 또는 Kubernetes 클러스터가 포함된 모든 계정에 설치해야 합니다. (파트너십이 있는 경우: 이 대시보드를 파트너십 소유자 계정 또는 POA에 설치하지 마십시오.) 이 대시보드를 여러 계정에 설치할 수 있습니다. 상위/하위 계정 구조가 있는 경우: 대시보드를 상위 계정에 설치하고 대시보드를 수정하여 하나의 대시보드에서 계정별 차트를 모두 가질 수 있습니다.
Done 을(를) 클릭합니다.
빠른 시작 설치가 완료되면 Data governance entity breakdowns 대시보드를 엽니다.
엔티티 분석 대시보드는 bytecountestimate() 를 사용하여 애플리케이션 또는 클러스터 이름과 같은 유용한 속성으로 수집을 패싯 처리합니다.
이 섹션 을 다시 참조하여 이러한 분류에 사용된 이벤트 유형을 정확히 확인할 수 있습니다.
팁
이러한 쿼리는 NrConsumption 과 같은 사전 집계 데이터 소스에서 작동하지 않기 때문에 더 많은 리소스를 소비합니다. 일부 환경에서 더 잘 작동하도록 추가 WHERE 및 LIMIT 절을 사용하여 시간 프레임을 조정해야 할 수도 있습니다.
클라우드 통합 대시보드 설치(선택 사항)
New Relic의 클라우드 통합은 종종 데이터 수집 증가의 중요한 소스가 될 수 있습니다. 좋은 시각화가 없으면 성장이 어디에서 오는지 정확히 파악하기가 매우 어려울 수 있습니다. 이는 부분적으로 이러한 통합이 구성하기 쉽고 조직의 일반 CI/CD 파이프라인의 일부가 아니기 때문입니다. 또한 공식적인 구성 관리 시스템의 일부가 아닐 수도 있습니다.
이 빠른 시작 에는 거의 모든 클라우드 통합, 호스트 내 통합 및 Kubernetes 통합으로 데이터를 분류하는 매우 세분화된 대시보드 세트가 포함되어 있습니다.
운동
다음 질문에 답하면 기준 데이터를 해석하고 올바른 추론을 수행하는 능력에 대한 자신감을 키우는 데 도움이 됩니다. 이러한 질문은 데이터 수집 기준선 및 데이터 수집 엔터티 분석 대시보드를 사용하여 답변할 수 있습니다. 설명된 대로 해당 대시보드를 설치하고 이러한 질문 중 얼마나 많은 답변을 할 수 있는지 확인하십시오.
질문
지난 주 전체 조직(모든 계정)의 일반적인 일일 수집 비율은 얼마입니까? 3개월 전에는 뭐였지?
수집 기준 상위 세 가지 원격 분석 유형(전체 조직의 경우)은 무엇입니까? 각 원격 분석 유형과 가장 최근의 30일 수집 속도를 나열합니다.
이 조직의 수집에 기여하는 계정은 몇 개입니까?
현재 월 50TB 이상을 제공하는 계정(있는 경우)은 몇 개입니까?
지난 30일 동안 수집 측면에서 상위 3개 계정은 무엇입니까?
가장 많이 소비하는 계정에 대한 지난 1월의 GB 수집은 무엇입니까?
지난 30일 동안 ApmEventsBytes 수집 측면에서 상위 3개 계정은 무엇입니까?
지난 9개월 동안 특정 계정에 대한 원격 분석 유형 수집 측면에서 가장 큰 단일 증가는 무엇입니까? 감소는 어떻습니까?
가장 많이 기여한 계정으로 이동하여 ApmEventsBytesdata governance entity breakdown dashboard 을(를) 설치/엽니다. 지난 24시간 동안 수집한 상위 3개 APM 애플리케이션과 해당 24시간 수집 속도를 나열합니다.
결론
프로세스 섹션에서는 데이터 수집 시각화 및 보고서 생성을 안내했습니다. 이제 귀하와 동료가 협업하는 데 사용할 수 있는 데이터 기반 시각적 접근 방식으로 데이터 수집을 검토할 수 있습니다.