다음을 통해 공유

데이터베이스 Watcher 만들기 및 구성(프리뷰)

  • 아티클

적용 대상: Azure SQL 데이터베이스 Azure SQL Managed Instance

이 문서에는 Azure SQL 데이터베이스 및 Azure SQL Managed Instance용 Azure Portal에서 데이터베이스 감시자를 만들고 구성하고 시작하는 자세한 단계가 포함되어 있습니다.

데이터베이스 Watcher는 모니터링 에이전트 또는 기타 모니터링 인프라를 배포하고 유지할 필요가 없습니다. 몇 분 안에 Azure SQL 리소스에 대한 심층 데이터베이스 모니터링을 활성화할 수 있습니다.

데이터베이스 감시자를 만들고 구성하는 기본 단계별 예는 빠른 시작: Azure SQL을 모니터링하는 데이터베이스 Watcher 만들기를 참조하세요.

Bicep 또는 ARM 템플릿을 사용하여 데이터베이스 감시자를 만들고 구성하는 방법을 보려면 데이터베이스 감시자 만들기 코드 샘플을 참조하세요.

데이터베이스 감시자를 프로그래밍 방식으로 관리하려면 데이터베이스 감시자 REST API 설명서를 참조하세요.

참고 항목

데이터베이스 Watcher 현재 미리 보기로 제공됩니다.

필수 조건

데이터베이스 감시자를 사용하려면 다음 필수 조건이 요구됩니다.

  • 활성 상태인 Azure 구독이 필요합니다. 아직 없는 경우 무료 계정을 만들 수 있습니다. 리소스를 만들려면 구독 또는 리소스 그룹의 기여자 역할 또는 소유자 역할의 구성원이어야 합니다.

  • 데이터베이스 감시자를 구성하고 시작하려면 기존 SQL 대상(Azure SQL 데이터베이스, Elastic Pool 또는 SQL Managed Instance)이 필요합니다.

  • Microsoft.DatabaseWatcher, Microsoft.Kusto, Microsoft.Network 리소스 공급자를 Azure 구독에 등록해야 합니다.

    리소스 공급자 등록은 구독 수준에서 소유자 또는 기여자 RBAC 역할 멤버십이 있는 경우 자동으로 이루어집니다. 그렇지 않으면 이러한 역할 중 하나의 사용자가 리소스 공급자를 등록해야 감시자를 만들고 구성할 수 있습니다. 자세한 정보는 리소스 공급자 등록을 참조하세요.

  • 감시자 및 Azure Data Explorer 클러스터 리소스를 만들고 구성하는 사용자는 이러한 리소스가 만들어지는 리소스 그룹 또는 구독의 소유자 또는 기여자 RBAC 역할의 구성원이어야 합니다.

    또한 SQL 인증을 사용하는 경우 사용자는 리소스 그룹의 소유자 역할의 구성원이거나 SQL 인증 자격 증명을 저장하는 키 자격 증명 모음의 소유자 또는 사용자 액세스 관리자 역할의 구성원이어야 합니다.

  • 감시자를 구성하는 사용자는 Azure SQL 대상에 대한 관리자 액세스 권한이 있어야 합니다. 관리자가 감시자에게 SQL Monitoring 대상에 대한 제한된 특정 액세스 권한을 부여합니다. 자세한 내용은 대상에 대한 액세스 권한 부여를 참조하세요.

  • 감시자에게 SQL 대상에 대한 액세스 권한을 부여하려면 관리자는 SQL Server mssql 확장과 함께 SSMS(SQL Server Management Studio), Azure Data Studio 또는 Visual Studio Code를 사용하여 T-SQL 스크립트를 실행해야 합니다.

  • Azure 리소스에 대한 프라이빗 연결에 Azure Private Link를 사용하려면 프라이빗 엔드포인트를 승인하는 사용자가 소유자 RBAC 역할의 구성원이거나 필요한 RBAC 권한이 있어야 합니다. 자세한 내용은 프라이빗 엔드포인트에 대한 승인 RBAC를 참조하세요.

Watcher 만들기

  1. Azure Portal의 탐색 메뉴에서 모든 서비스를 선택합니다. 범주로 모니터를 선택하고 모니터링 도구에서데이터베이스 감시자를 선택합니다. 또는 포털 페이지의 맨 위에 있는 검색창에 데이터베이스 감시자를 입력하고 데이터베이스 감시자를 선택할 수 있습니다.

    데이터베이스 감시자 보기가 열리면 만들기를 선택합니다.

  2. 기본 탭에서 감시자의 구독 및 리소스 그룹을 선택하고 감시자의 이름을 입력한 다음 Azure 지역을 선택합니다.

    팁

    미리 보기 중에 해당 지역에서 데이터베이스 감시자를 아직 사용할 수 없는 경우 다른 지역에서 만들 수 있습니다. 자세한 내용은 지역별 가용성을 참조하세요.

  3. ID 탭에서 감시자의 시스템 할당 관리 ID는 기본적으로 사용하도록 설정됩니다. 감시자가 사용자 할당 관리 ID를 대신 사용하도록 하려면 추가 단추를 선택하고 사용할 ID를 찾은 다음 추가 단추를 선택합니다. 사용자가 할당한 ID를 감시자에게 효과적으로 적용하려면 시스템 할당 관리 ID를 사용하지 않도록 설정합니다.

    데이터베이스 감시자의 관리 ID에 대한 자세한 내용은 감시자 ID 수정을 참조 하세요.

  4. 감시자의 데이터 저장소를 선택합니다.

    기본적으로 감시자를 만들면 Azure Data Explorer 클러스터도 만들어지고 해당 클러스터에 데이터베이스를 수집된 모니터링 데이터의 데이터 저장소로 추가합니다.

    • 기본적으로 새 Azure Data Explorer 클러스터는 매우 작은 컴퓨팅 최적화 SKU를 사용합니다. 이는 여전히 SLA(서비스 수준 약정)를 제공하는 가장 경제적인 SKU입니다. 필요에 따라 나중에 이 클러스터의 크기를 조정할 수 있습니다.

    • 또는 기존 Azure Data Explorer 클러스터, 무료 Azure Data Explorer 클러스터 또는 실시간 분석에서 데이터베이스를 사용할 수 있습니다.

      1. 데이터 저장소 탭에서 데이터 저장소 선택 옵션을 선택하고 추가를 선택합니다.
      2. 실시간 분석 데이터베이스 또는 Azure Data Explorer 클러스터를 선택합니다.
      3. 기존Azure Data Explorer 클러스터를 사용하는 경우 스트리밍 수집을 사용하도록 설정해야 합니다.
      4. 새 데이터베이스를 만들거나 기존 데이터베이스를 사용합니다.

      참고 항목

      선택한 기존 데이터베이스는 비어 있거나 이전에 데이터베이스 감시자 데이터 저장소로 사용한 데이터베이스여야 합니다. 데이터베이스 감시자가 만들지 않은 개체를 포함하는 데이터베이스를 선택하는 것은 지원되지 않습니다.

    • 또는 현재 데이터 저장소 추가를 건너뛰고 나중에 추가할 수 있습니다. 감시자를 시작하려면 데이터 저장소가 필요합니다.

  5. SQL 대상 탭에서 모니터링할 하나 이상의 Azure SQL 리소스를 추가합니다. 감시자를 만들 때 SQL 대상 추가를 건너뛰고 나중에 추가할 수 있습니다. 감시자를 시작하기 전에 대상을 하나 이상 추가해야 합니다.

  6. 검토 + 만들기 탭에서 감시자 구성을 검토하고 만들기를 선택합니다. 새 Azure Data Explorer 클러스터를 만드는 기본 옵션을 선택하는 경우 배포에는 일반적으로 15~20분이 걸립니다. 기존 Azure Data Explorer 클러스터, 무료 Azure Data Explorer 클러스터 또는 실시간 분석에서 데이터베이스를 선택하는 경우 배포에는 일반적으로 최대 5분이 걸립니다.

  7. 배포가 완료되면 감시자에게 SQL 대상에 대한 액세스 권한을 부여합니다.

  8. 감시자에게 데이터 저장소에 대한 액세스 권한을 부여해야 할 수도 있습니다.

    • 감시자를 만드는 사용자가 클러스터에 대한 소유자 RBAC 역할의 구성원이면 감시자를 만드는 동안 신규 또는 기존 Azure Data Explorer 클러스터 데이터 베이스의 액세스 권한이 자동으로 부여됩니다.
    • 그러나 다음에서 데이터베이스를 선택하는 경우 KQL 명령을 사용하여 데이터 저장소에 대한 액세스 권한을 부여해야 합니다.
      • Microsoft Fabric의 실시간 분석.
      • 무료 Azure Data Explorer 클러스터.

  9. 프라이빗 연결을 사용하려는 경우 관리되는 프라이빗 엔드포인트를 만들고 승인합니다.

    • SQL 대상, 데이터 저장소 및 키 자격 증명 모음에 대한 공용 액세스를 사용하도록 설정하고 공용 연결을 사용하려는 경우 모든 공용 연결 필수 구성 요소가 충족되는지 확인합니다.

감시자 시작 및 중지

감시자가 만들어지면 추가 구성이 필요할 수 있으므로 자동으로 시작되지 않습니다.

감시자를 시작하려면 다음이 있어야 합니다.

감시자가 완전히 구성되면 개요 페이지에서 시작 버튼을 사용하여 데이터 컬렉션을 시작합니다. 몇 분 후에 새 모니터링 데이터가 데이터 저장소 및 대시보드에 표시됩니다. 5분 이내에 새 데이터가 표시되지 않으면 문제 해결을 참조하세요.

한동안 Azure SQL 리소스를 모니터링할 필요가 없는 경우 중지 버튼을 사용하여 감시자를 중지할 수 있습니다.

감시자를 다시 시작하려면 감시자를 중지한 다음 다시 시작하세요.

감시자 수정

Azure Portal에서 대상을 추가 또는 제거하거나, 프라이빗 엔드포인트를 만들거나 삭제하거나, 기존 감시자에 대해 다른 데이터 저장소를 사용하거나, 감시자의 관리 ID를 수정할 수 있습니다.

참고 항목

특별히 언급하지 않는 한 감시자 구성에 대한 변경 내용은 감시자를 중지했다가 다시 시작한 후에 적용됩니다.

감시자에 SQL 대상 추가

Azure SQL 데이터베이스, Elastic Pool 또는 SQL Managed Instance에 대해 데이터베이스 감시자 모니터링을 사용하도록 설정하려면 이 리소스를 SQL 대상으로 추가해야 합니다.

  1. 대상을 추가하려면 SQL 대상 페이지에서 추가를 선택합니다.
  2. 모니터링하려는 Azure SQL 리소스를 찾습니다. 리소스 종류 및 구독을 선택한 다음 리소스 목록에서 SQL 대상을 선택합니다. SQL 대상은 Watcher와 동일한 Microsoft Entra ID 테넌트 내의 모든 구독에 있을 수 있습니다.
  3. 데이터베이스, 탄력적 풀 또는 SQL 관리형 인스턴스의 주 복제본 및 고가용성 보조 복제본을 모니터링하려면 동일한 리소스에 대해 별도의 두 개의 SQL 대상을 추가하고 그 중 하나에 대한 읽기 의도 상자를 선택합니다. 마찬가지로 지역 복제본과 고가용성 보조 복제본(있는 경우)에 대한 두 개의 별도 SQL 대상을 만듭니다.
    • 읽기 의도 상자를 선택하면 고가용성 보조 복제본에 대한 SQL 대상만 구성됩니다.
    • 주 복제본 또는 지역 복제본만 모니터링하거나 이 리소스에 대한 고가용성 보조 복제본이 없거나 읽기 확장 기능을 사용하지 않도록 설정한 경우 읽기 의도 상자를 선택하지 마세요.

기본적으로 데이터베이스 감시자는 SQL 대상에 연결할 때 Microsoft Entra 인증을 사용합니다. 감시자가 SQL 인증을 사용하도록 하려면 SQL 인증 사용 상자를 선택하고 필요한 세부 정보를 입력합니다. 자세한 내용은 SQL 인증을 사용하기 위한 추가 구성을 참조하세요.

감시자에서 SQL 대상 제거

하나 이상의 대상을 제거하려면 SQL 대상 페이지를 열고 목록에서 제거하려는 대상을 선택한 다음 삭제를 선택합니다.

대상 제거는 감시자가 다시 시작되면 Azure SQL 리소스에 대한 모니터링을 중지하지만 실제 리소스는 삭제하지 않습니다.

데이터베이스 감시자가 모니터링하는 Azure SQL 리소스를 삭제하는 경우 해당 대상도 제거해야 합니다. 감시자가 가질 수 있는 SQL 대상 수에는 제한이 있으므로 사용되지 않는 대상을 유지하면 새 대상을 추가하지 못할 수 있습니다.

관리형 프라이빗 엔드포인트 만들기

SQL 대상에서 데이터 컬렉션, 데이터 저장소로 수집, 키 자격 증명 모음에 연결하기 위해 프라이빗 연결을 사용하려면 관리형 프라이빗 엔드포인트를 만들어야 합니다. 프라이빗 엔드포인트를 만들지 않으면 데이터베이스 감시자는 기본적으로 공용 연결을 사용합니다.

참고 항목

데이터베이스 감시자는 Azure 리소스에 연결하기 위해 자체 관리형 프라이빗 엔드포인트가 필요합니다. Azure SQL 논리 서버, SQL Managed Instance, Azure Data Explorer 클러스터 또는 키 자격 증명 모음에 대해 이미 존재할 수 있는 프라이빗 엔드포인트는 감시자가 사용할 수 없습니다.

감시자용 관리형 프라이빗 엔드포인트를 만들려면:

  1. 관리형 프라이빗 엔드포인트를 만드는 리소스, 리소스 그룹 또는 리소스의 구독에 대한 읽기 전용 잠금 이 있는 경우 잠금을 제거합니다. 프라이빗 엔드포인트를 성공적으로 만든 후에 잠금을 다시 추가할 수 있습니다.

  2. Azure Portal에서 데이터베이스 감시자로 이동하여 관리형 프라이빗 엔드포인트 페이지를 열고 추가를 선택합니다.

  3. 프라이빗 엔드포인트의 이름을 입력합니다.

  4. 프라이빗 엔드포인트를 만들려는 Azure 리소스의 구독을 선택합니다.

  5. 프라이빗 엔드포인트를 만들려는 리소스 유형에 따라 다음과 같이 리소스 종류 및 대상 하위 리소스를 선택합니다.

    리소스 리소스 종류 대상 하위 리소스
    논리 서버 Microsoft.Sql/servers sqlServer
    SQL Managed Instance Microsoft.Sql/managedInstances managedInstance
    Azure Data Explorer 클러스터 Microsoft.Kusto/clusters cluster
    키 자격 증명 모음 Microsoft.KeyVault/vaults vault

  6. 프라이빗 엔드포인트를 만들려는 리소스를 선택합니다. Azure SQL 논리 서버, SQL 관리형 인스턴스, Azure Data Explorer 클러스터 또는 키 자격 증명 모음일 수 있습니다.

    • Azure SQL 데이터베이스 논리 서버에 대한 프라이빗 엔드포인트를 만들면 해당 서버의 모든 데이터베이스 및 Elastic Pool 대상에 대해 데이터베이스 감시자 프라이빗 연결을 사용할 수 있습니다.

  7. 필요에 따라 프라이빗 엔드포인트에 대한 설명을 입력합니다. 리소스 소유자가 요청을 승인하는 데 도움이 될 수 있습니다.

  8. 만들기를 실행합니다. 프라이빗 엔드포인트를 만드는 데 몇 분 정도 걸릴 수 있습니다. 프로비전 상태가 수락됨 또는 실행 중에서 성공으로 변경되면 프라이빗 엔드포인트가 만들어집니다. 보기를 새로 고쳐 현재 프로비전 상태를 확인합니다.

    중요

    프라이빗 엔드포인트는 보류 중 상태로 만들어집니다. 데이터베이스 감시자가 이를 사용하여 리소스에 연결하려면 먼저 리소스 소유자의 승인을 받아야 합니다.

    리소스 소유자가 네트워크 연결을 제어할 수 있도록 하기 위해 데이터베이스 감시자 프라이빗 엔드포인트는 자동으로 승인되지 않습니다.

  9. 리소스 소유자가 프라이빗 엔드포인트 요청을 승인해야 합니다.

    • Azure Portal에서 리소스의 소유자가 Private Link를 검색하여 Private Link 센터를 열 수 있습니다. 보류 중인 연결에서 만든 프라이빗 엔드포인트를 찾아 해당 설명 및 세부 정보를 확인하고 승인을 선택합니다.
    • Azure CLI를 사용하여 프라이빗 엔드포인트 요청을 승인할 수도 있습니다.

프라이빗 엔드포인트가 승인될 때 감시자가 이미 실행 중인 경우 프라이빗 연결 사용을 시작하려면 감시자를 다시 시작해야 합니다.

팁

클러스터 공용 연결을 사용하지 않도록 설정한 경우 Azure Data Explorer 클러스터에 대한 추가 프라이빗 엔드포인트를 만들어야 합니다. 자세한 내용은 데이터 저장소에 대한 프라이빗 연결을 참조하세요.

관리형 프라이빗 엔드포인트 삭제

  1. 관리형 프라이빗 엔드포인트를 삭제하려는 리소스, 리소스 그룹 또는 리소스의 구독에 삭제 또는 읽기 전용 잠금이 있는 경우 잠금을 제거합니다. 프라이빗 엔드포인트를 성공적으로 삭제한 후에 잠금을 다시 추가할 수 있습니다.
  2. 데이터베이스 감시자의 Azure Portal 페이지에서 관리형 프라이빗 엔드포인트 페이지를 엽니다.
  3. 삭제하려는 프라이빗 엔드포인트를 선택합니다.
  4. 삭제를 선택합니다.

관리형 프라이빗 엔드포인트를 삭제하면 이 프라이빗 엔드포인트를 사용하는 SQL 대상에서 데이터 수집이 중지됩니다. Azure Data Explorer 클러스터에 대한 관리형 프라이빗 엔드포인트를 삭제하면 모든 대상에 대한 데이터 수집이 중지됩니다. 데이터 수집을 다시 시작하려면 프라이빗 엔드포인트를 다시 만들거나 공용 연결을 사용하도록 설정하고 감시자를 다시 시작하세요.

감시자의 데이터 저장소 변경

감시자는 하나의 데이터 저장소만 가질 수 있습니다.

현재 데이터 저장소를 변경하려면 기존 데이터 저장소를 제거한 다음 새 데이터 저장소를 추가하세요.

  • 현재 데이터 저장소를 제거하려면 데이터 저장소 페이지를 열고 약식 표에서 데이터 저장소를 선택한 다음 삭제를 선택합니다.

    • 데이터 저장소를 제거해도 Azure Data Explorer 클러스터 또는 Microsoft Fabric의 실시간 분석에서 실제 데이터 저장소 데이터베이스가 삭제되지는 않습니다.
    • 제거된 데이터 저장소로의 데이터 수집을 중지하려면 감시자를 중지하세요.
    • 데이터 저장소를 제거하는 경우 새 데이터 저장소를 추가해야 감시자를 다시 시작할 수 있습니다.

  • 데이터 저장소를 추가하려면 데이터 저장소 페이지에서 추가를 선택한 다음 Azure Data Explorer 클러스터 또는 실시간 분석에서 데이터베이스를 선택하거나 만듭니다.

    • 선택한 데이터베이스는 비어 있거나 이전에 데이터베이스 감시자 데이터 저장소로 사용한 데이터베이스여야 합니다. 데이터베이스 감시자가 만들지 않은 개체를 포함하는 데이터베이스를 선택하는 것은 지원되지 않습니다.
    • 데이터 저장소를 추가한 후에는 감시자에게 데이터 저장소를 사용할 수 있는 액세스 권한을 부여해야 합니다. 자세한 내용은 데이터 저장소에 대한 액세스 권한 부여를 참조하세요.
    • 감시자가 다시 시작되면 새 데이터 저장소가 사용됩니다.

감시자 ID 수정

감시자는 SQL 대상, 키 자격 증명 모음 및 데이터 저장소에 인증할 관리 ID가 있어야 합니다. 시스템 할당 또는 사용자 할당 관리 ID를 사용할 수 있습니다. Azure의 관리 ID에 대한 자세한 내용은 Azure 리소스에 대한 관리 ID란?

다음 고려 사항은 감시자에 대한 관리 ID 유형을 선택하는 데 도움이 됩니다.

  • 시스템 할당

    • 감시자를 만들 때 기본적으로 사용하도록 설정됩니다.
    • 항상 단일 감시자와 연결됩니다.
    • 감시자를 사용하여 만들어지고 삭제되었습니다.
    • 감시자에 대해 시스템 할당 ID를 사용하지 않도록 설정하면 해당 ID에 부여된 모든 액세스 권한이 손실됩니다. 동일한 감시자에 대해 시스템 할당 ID를 다시 사용하도록 설정하면 다른 개체(보안 주체) ID를 사용하여 새로운 다른 ID가 만들어집니다. SQL 대상, 키 자격 증명 모음 및 데이터 저장소에 대한 액세스 권한을 이 새 ID에 부여해야 합니다.

  • 사용자 할당

    • 감시자에 대해 시스템 할당 ID를 사용하지 않도록 설정한 경우에만 적용됩니다.
    • 동일한 사용자 할당 ID를 여러 감시자에게 할당하여 액세스 관리를 간소화할 수 있습니다(예: 대규모 Azure SQL 자산을 모니터링하는 경우). 여러 감시자의 시스템 할당 ID에 대한 액세스 권한을 부여하는 대신 단일 사용자 할당 ID에 대한 액세스 권한을 부여할 수 있습니다.
    • 업무 분리를 지원하기 위해 ID 관리를 감시자 관리와 분리할 수 있습니다. 감시자가 생성되기 전이나 후에 다른 사용자가 사용자 할당 ID를 만들고 액세스 권한을 부여할 수 있습니다.
    • 반대로 감시자가 삭제되면 사용자 할당 ID와 해당 액세스 권한은 변경되지 않은 상태로 유지됩니다. 그런 다음 새 감시자에 동일한 ID를 사용할 수 있습니다.
    • 감시자에 대해 둘 이상의 사용자 할당 ID를 지정하는 것은 지원되지 않습니다.

감시자의 관리 ID를 수정하려면 감시자의 ID 페이지를 엽니다.

  • 시스템 할당 ID를 사용하려면 시스템 할당 ID 토글을 사용하도록 설정합니다.

  • 사용자 할당 ID를 사용하려면 시스템 할당 ID 토글을 사용하지 않도록 설정합니다. 추가 단추를 선택하여 기존 사용자 할당 ID를 찾아 추가합니다.

    새 사용자 할당 ID를 만들려면 사용자 할당 관리 ID 만들기를 참조 하세요.

  • 감시자에서 사용자 할당 ID를 제거하려면 목록에서 해당 ID를 선택하고 제거를 선택합니다. 사용자 할당 ID가 제거되면 다른 사용자 할당 ID를 추가하거나 시스템 할당 ID를 사용하도록 설정해야 합니다.

    제거된 사용자 할당 ID는 Microsoft Entra ID 테넌트에서 삭제되지 않습니다.

저장 단추를 선택하여 ID 변경 내용을 저장합니다. 감시자에게 ID가 없는 경우 ID 변경 내용을 저장할 수 없습니다. 유효한 관리 ID가 없는 감시자는 지원되지 않습니다.

팁

감시자 관리 ID의 표시 이름은 Microsoft Entra ID 테넌트 내에서 고유한 것이 좋습니다. 감시자에 대한 사용자 할당 ID를 만들 때 고유한 이름을 선택할 수 있습니다.

시스템 할당 ID의 표시 이름은 감시자 이름과 동일합니다. 시스템 할당 ID를 사용하는 경우 감시자 이름이 Microsoft Entra ID 테넌트 내에서 고유해야 합니다.

관리 ID 표시 이름이 고유 하지 않으면 감시자에게 SQL 대상에 대한 액세스 권한을 부여하는 T-SQL 스크립트 가 중복된 표시 이름 오류와 함께 실패합니다. 자세한 내용 및 해결 방법은 Microsoft Entra 로그인 및 특수하지 않은 표시 이름을 가진 사용자를 참조하세요.

ID 변경 내용을 저장한 직후 감시자는 현재 관리 ID를 사용하여 SQL 대상, 키 자격 증명 모음(사용되는 경우) 및 데이터 저장소에 다시 연결합니다.

감시자 삭제

감시자, 해당 리소스 그룹 또는 구독에 삭제 또는 읽기 전용 잠금이 있는 경우 잠금을 제거합니다. 감시자를 성공적으로 삭제한 후에 잠금을 다시 추가할 수 있습니다.

시스템 할당 관리 ID를 사용하도록 설정된 감시자를 삭제하면 ID도 삭제됩니다. 이렇게 하면 이 ID에 부여한 모든 액세스 권한이 제거됩니다. 나중에 감시자를 다시 만드는 경우 각 리소스에 인증하려면 새 감시자의 시스템 할당 관리 ID에 대한 액세스 권한을 부여해야 합니다. 다음 내용이 포함됩니다:

동일한 감시자 이름을 사용하더라도 다시 생성된 감시자에 대한 액세스 권한을 부여해야 합니다.

감시자를 삭제하면 SQL 대상으로 참조된 Azure 리소스와 데이터 저장소가 삭제되지 않습니다. 수집된 SQL Monitoring 데이터는 데이터 저장소에 유지되며 나중에 새 감시자를 만드는 경우 데이터 저장소와 동일한 Azure Data Explorer 또는 Real-Time Analytics 데이터베이스를 사용할 수 있습니다.

SQL 대상에 대한 액세스 권한 부여

감시자가 SQL Monitoring 데이터를 수집할 수 있도록 하려면 감시자에게 제한된 특정 SQL 권한을 부여하는 T-SQL 스크립트를 실행해야 합니다.

  • Azure SQL 데이터베이스에서 스크립트를 실행하려면 모니터링하려는 데이터베이스 및 Elastic Pool을 포함하는 논리 서버에 대한 서버 관리자 액세스 권한이 필요합니다.

    • Azure SQL 데이터베이스에서는 만드는 모든 감시자에 대해 논리 서버당 한 번만 스크립트를 실행하면 됩니다. 이렇게 하면 감시자에게 해당 서버의 모든 기존 및 새 데이터베이스 및 Elastic Pool에 대한 액세스 권한을 부여합니다.

  • Azure SQL Managed Instance에서 스크립트를 실행하려면 sysadmin 또는 securityadmin 서버 역할의 구성원이거나 SQL Managed Instance에 대한 CONTROL 서버 권한이 있어야 합니다.

    • Azure SQL Managed Instance에서는 모니터링하려는 각 인스턴스에서 스크립트를 실행해야 합니다.

  1. Azure Portal에서 감시자로 이동하여 SQL 대상을 선택하고, 액세스 권한 부여 링크 중 하나를 선택하여 T-SQL 스크립트를 연 다음 스크립트를 복사합니다. 대상 유형 및 사용하려는 인증 유형에 맞는 올바른 링크를 선택해야 합니다.

    Important

    Azure Portal의 Microsoft Entra 인증 스크립트는 감시자의 관리 ID 이름을 포함하기 때문에 감시자와 관련이 있습니다. 각 감시자에 대해 사용자 지정할 수 있는 이 스크립트의 일반 버전은 T-SQL 스크립트를 사용하여 SQL 대상에 대한 액세스 권한 부여를 참조하세요.

  2. SQL Server Management Studio, Azure Data Studio 또는 기타 SQL 클라이언트 도구에서 새 쿼리 창을 열고 대상을 포함하는 Azure SQL 논리 서버의 master 데이터베이스 또는 SQL Managed Instance 대상의 master 데이터베이스에 연결합니다.

  3. T-SQL 스크립트를 붙여넣고 실행하여 감시자에게 액세스 권한을 부여합니다. 이 스크립트는 감시자가 연결하는 데 사용할 로그인을 만들고 모니터링 데이터를 수집하기 위한 제한된 특정 권한을 부여합니다.

    1. Microsoft Entra 인증 스크립트를 사용하고 감시자가 시스템 할당 관리 ID를 사용하는 경우 스크립트를 실행할 때 감시자를 이미 만들어야 합니다. 감시자가 사용자 할당 관리 ID를 사용하는 경우 감시자가 생성되기 전이나 후에 스크립트를 실행할 수 있습니다.

    관리 ID에 대한 액세스 권한을 부여하는 T-SQL 액세스 스크립트를 실행할 때 Microsoft Entra 인증에 연결해야 합니다.

나중에 감시자에 새 대상을 추가하는 경우 해당 대상이 이미 액세스 권한이 부여된 논리 서버에 있지 않는 한 유사한 방식으로 해당 대상에 대한 액세스 권한을 부여해야 합니다.

T-SQL 스크립트를 사용하여 SQL 대상에 대한 액세스 권한 부여

Microsoft Entra 인증 및 SQL 인증, Azure SQL 데이터베이스 및 Azure SQL Managed Instance 대상에 대한 스크립트는 서로 다릅니다.

중요

항상 제공된 스크립트를 사용하여 데이터베이스 감시자에 대한 액세스 권한을 부여하세요. 다른 방식으로 액세스 권한을 부여하면 데이터 수집을 차단할 수 있습니다. 자세한 내용은 감시자 권한 부여를 참조하세요.

스크립트를 실행하기 전에 스크립트에 있을 수 있는 자리 표시자의 모든 인스턴스(예: login-name-placeholder, password-placeholder)를 실제 값으로 바꾸세요.

Microsoft Entra 인증된 감시자에 대한 액세스 권한 부여

이 스크립트는 Azure SQL 데이터베이스의 논리 서버에 Microsoft Entra(이전의 Azure Active Directory) 인증 로그인을 만듭니다. 로그인은 감시자의 관리 ID에 대해 만들어집니다. 이 스크립트는 감시자에게 논리 서버의 모든 데이터베이스 및 Elastic Pool에서 모니터링 데이터를 수집하는 데 필요한 충분한 권한을 부여합니다.

감시자가 시스템 할당 관리 ID를 사용하는 경우 감시자 이름을 로그인 이름으로 사용해야 합니다. 감시자가 사용자 할당 관리 ID를 사용하는 경우 ID의 표시 이름을 로그인 이름으로 사용해야 합니다.

스크립트는 논리 서버의 master 데이터베이스에서 실행되어야 합니다. 서버 관리자인 Microsoft Entra 인증 로그인을 사용하여 로그인해야 합니다.

CREATE LOGIN [identity-name-placeholder] FROM EXTERNAL PROVIDER;

ALTER SERVER ROLE ##MS_ServerPerformanceStateReader## ADD MEMBER [identity-name-placeholder];
ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER [identity-name-placeholder];
ALTER SERVER ROLE ##MS_DatabaseConnector## ADD MEMBER [identity-name-placeholder];

SQL 인증된 감시자에 대한 액세스 권한 부여

SQL 인증을 사용하는 경우 추가 단계가 필요합니다. SQL 인증을 사용하기 위한 추가 구성을 참조하세요.

이 스크립트는 Azure SQL 데이터베이스의 논리 서버에 SQL 인증 로그인을 만듭니다. 해당 논리 서버의 모든 데이터베이스 및 Elastic Pool에서 모니터링 데이터를 수집하는 데 필요한 충분한 권한을 로그인에 부여합니다.

스크립트는 논리 서버 관리자인 로그인을 사용하여 논리 서버의 master 데이터베이스에서 실행되어야 합니다.

CREATE LOGIN [login-name-placeholder] WITH PASSWORD = 'password-placeholder';

ALTER SERVER ROLE ##MS_ServerPerformanceStateReader## ADD MEMBER [login-name-placeholder];
ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER [login-name-placeholder];
ALTER SERVER ROLE ##MS_DatabaseConnector## ADD MEMBER [login-name-placeholder];

SQL 인증을 사용하기 위한 추가 구성

인증 자격 증명을 안전하게 저장하기 위해 데이터베이스 감시자에서 SQL 인증을 사용하려면 추가 구성이 필요합니다.

팁

보다 안전하고 간단하며 오류가 덜 발생하는 구성을 위해 Azure SQL 리소스에 대해 Microsoft Entra 인증을 사용하도록 설정하고 SQL 인증 대신 사용하는 것이 좋습니다.

SQL 인증을 사용하여 대상에 연결하도록 데이터베이스 감시자를 구성하려면 다음 단계를 따릅니다.

  1. Azure Key Vault에서 자격 증명 모음을 만들거나 사용할 수 있는 기존 자격 증명 모음을 식별합니다. 자격 증명 모음은 RBAC 권한 모델을 사용해야 합니다. RBAC 권한 모델은 새 자격 증명 모음의 기본값입니다. 기존 자격 증명 모음을 사용하려면 이전 액세스 정책 모델을 사용하도록 구성되어 있지 않은지 확인합니다.

    자격 증명 모음에 대한 프라이빗 연결을 사용하려면 관리형 프라이빗 엔드포인트 페이지에서 프라이빗 엔드포인트를 만듭니다. Microsoft.KeyVault/vaults를 리소스 유형으로 선택하고 vault를 대상 하위 리소스로 선택합니다. 감시자를 시작하기 전에 프라이빗 엔드포인트가 승인되었는지 확인합니다.

    공용 연결을 사용하려면 자격 증명 모음에 모든 네트워크에서 공용 액세스가 사용하도록 설정되어 있어야 합니다. 특정 네트워크로 공용 자격 증명 모음 연결을 제한하는 것은 데이터베이스 감시자에서 지원되지 않습니다.

  2. 모니터링하려는 각 Azure SQL 논리 서버 또는 Managed Instance에 SQL 인증 로그인을 만들고 제공된 액세스 스크립트를 사용하는 제한된 특정 권한을 부여합니다. 스크립트에서 로그인 이름 및 암호 자리 표시자를 실제 값으로 바꿉니다. 강력한 비밀번호를 사용하세요.

  3. 자격 증명 모음에서 두 가지 비밀, 즉 로그인 이름에 대한 비밀과 비밀번호에 대한 별도의 비밀을 만듭니다. 유효한 이름을 비밀 이름으로 사용하고 T-SQL 스크립트에서 사용한 로그인 이름 및 비밀번호를 각 비밀의 비밀 값으로 입력합니다.

    예를 들어 두 비밀의 이름은 database-watcher-login-name과 database-watcher-password일 수 있습니다. 비밀 값은 로그인 이름과 강력한 암호입니다.

    비밀을 만들려면 키 자격 증명 모음 비밀 책임자 RBAC 역할의 구성원이어야 합니다.

  4. 감시자에 SQL 대상을 추가합니다. 대상을 추가할 때 SQL 인증 사용 상자를 선택하고 로그인 이름과 비밀번호 비밀이 저장되는 자격 증명 모음을 선택합니다. 해당 필드에 로그인 이름과 비밀번호의 비밀 이름을 입력합니다.

    SQL 대상을 추가할 때 실제 로그인 이름과 비밀번호를 입력하지 마세요. 이전 예를 사용하면 database-watcher-login-name과 database-watcher-password 비밀 이름을 입력합니다.

  5. Azure Portal에서 SQL 대상을 추가하면 현재 사용자가 소유자 역할의 멤버이거나 키 자격 증명 모음에 대한 사용자 액세스 관리자 역할인 경우 감시자의 관리 ID에 키 자격 증명 모음 비밀에 대한 필수 액세스 권한이 자동으로 부여됩니다. 그렇지 않으면 다음 단계에 따라 필요한 액세스 권한을 수동으로 부여합니다.

  6. 각 비밀의 액세스 제어(IAM) 페이지에서 키 자격 모음 비밀 사용자 RBAC 역할에서 감시자의 관리 ID에 대한 역할 할당을 추가합니다. 최소 권한 원칙을 따르려면 전체 자격 증명 모음이 아닌 각 비밀에 대해 이 역할 할당을 추가합니다. 액세스 제어(IAM) 페이지는 자격 증명 모음이 RBAC 권한 모델을 사용하도록 구성된 경우에만 표시됩니다.

서로 다른 SQL 대상에서 서로 다른 SQL 인증 자격 증명을 사용하려는 경우 비밀을 여러 쌍 만들어야 합니다. 동일한 자격 증명 모음 또는 다른 자격 증명 모음을 사용하여 각 SQL 대상에 대한 비밀을 저장할 수 있습니다.

참고 항목

감시자가 실행되는 동안 키 자격 증명 모음의 로그인 이름 또는 비밀번호에 대한 비밀 값을 업데이트하면 감시자는 15분 이내에 새 SQL 인증 자격 증명을 사용하여 대상에 다시 연결합니다. 새 자격 증명을 즉시 사용하려면 감시자를 중지했다가 다시 시작하세요.

데이터 저장소에 대한 액세스 권한 부여

데이터 저장소에 데이터베이스 스키마를 만들고 관리하며 모니터링 데이터를 수집하려면 데이터베이스 감시자는 Azure Data Explorer 클러스터 또는 실시간 분석 데이터 저장소 데이터베이스에서 관리자 RBAC 역할의 구성원 자격이 필요합니다. 데이터베이스 Watcher는 Azure Data Explorer 클러스터에 대한 클러스터 수준 액세스 권한 또는 동일한 클러스터에 있을 수 있는 다른 데이터베이스에 대한 액세스 권한이 필요하지 않습니다.

Azure Data Explorer 클러스터의 데이터베이스를 데이터 저장소로 사용하는 경우 클러스터에 대한 소유자 RBAC 역할의 멤버인 경우 이 액세스 권한이 자동으로 부여됩니다. 그렇지 않으면 이 섹션에 설명된 대로 액세스 권한을 부여해야 합니다.

실시간 분석 또는 무료 Azure Data Explorer 클러스터에서 데이터베이스를 사용하는 경우 KQL을 사용하여 액세스 권한을 부여해야 합니다.

Azure Portal을 사용하여 Azure Data Explorer 데이터베이스에 대한 액세스 권한 부여

Azure Portal을 사용하여 Azure Data Explorer 클러스터의 데이터베이스에 대한 액세스 권한을 부여할 수 있습니다.

  1. Azure Data Explorer 클러스터의 데이터베이스에 대해 보안 + 네트워킹 아래의 리소스 메뉴에서 권한을 선택합니다. 클러스터의 권한 페이지를 사용하지 마세요.
  2. 추가를 선택하고 관리자를 선택합니다.
  3. 새 보안 주체 페이지에서 엔터프라이즈 애플리케이션을 선택합니다. 감시자가 시스템 할당 관리 ID를 사용하는 경우 검색 상자에 감시자의 이름을 입력합니다. 감시자가 사용자 할당 관리 ID를 사용하는 경우 검색 상자에 해당 ID의 표시 이름을 입력합니다.
  4. 감시자의 관리 ID에 대한 엔터프라이즈 애플리케이션을 선택합니다.

KQL을 사용하여 Azure Data Explorer 데이터베이스에 대한 액세스 권한 부여

Azure Portal을 사용하는 대신 KQL 명령을 사용하여 데이터베이스에 대한 액세스 권한을 부여할 수도 있습니다. 이 방법을 사용하여 실시간 분석 또는 무료 Azure Data Explorer 클러스터의 데이터베이스에 대한 액세스 권한을 부여합니다.

  1. Kusto Explorer 또는 Azure Data Explorer 웹 UI를 사용하여 Azure Data Explorer 클러스터의 데이터베이스에 연결합니다.

  2. 표에 설명된 대로 다음 샘플 KQL 명령에서 세 개의 자리 표시자를 바꿉니다.

    .add database [adx-database-name-placeholder] admins ('aadapp=identity-principal-id-placeholder;tenant-primary-domain-placeholder');
    자리 표시자 치환
    adx-database-name-placeholder Azure Data Explorer 클러스터 또는 실시간 분석의 데이터베이스 이름입니다.
    identity-principal-id-placeholder 감시자의 ID 페이지에 있는 관리 ID(GUID)의 보안 주체 ID 값입니다. 시스템 할당 ID를 사용하는 경우 해당 보안 주체 ID 값을 사용합니다. 그렇지 않으면 사용자 할당 ID의 보안 주체 ID 값을 사용합니다.
    tenant-primary-domain-placeholder 감시자 관리 ID의 Microsoft Entra ID 테넌트 도메인 이름입니다. Azure Portal의 Microsoft Entra ID 개요 페이지에서 찾을 수 있습니다. 테넌트 주 도메인 대신 테넌트 ID GUID 값도 사용할 수 있습니다.

    실시간 분석 또는 무료 Azure Data Explorer 클러스터에서 데이터베이스를 사용하는 경우 명령의 이 부분이 필요합니다.

    클러스터는 항상 감시자 관리 ID와 동일한 Microsoft Entra ID 테넌트에 있으므로 Azure Data Explorer 클러스터의 데이터베이스에 대해 도메인 이름 또는 테넌트 ID 값(및 이전 세미콜론)을 생략할 수 있습니다.

    예시:

    .add database [watcher_data_store] admins ('aadapp=9da7bf9d-3098-46b4-bd9d-3b772c274931;contoso.com');

자세한 내용은 Kusto 역할 기반 액세스 제어를 참조하세요.

사용자 및 그룹에 데이터 저장소에 대한 액세스 권한 부여

Azure 포털 또는 KQL 명령을 사용하여 사용자 및 그룹에 Azure Data Explorer 클러스터 또는 실시간 분석의 데이터베이스에 대한 액세스 권한을 부여할 수 있습니다. 액세스 권한을 부여하려면 데이터베이스에서 관리자 RBAC 역할의 구성원이어야 합니다.

KQL 명령을 사용하여 무료 Azure Data Explorer 클러스터 또는 실시간 분석에서 데이터베이스에 대한 액세스 권한을 부여합니다. 최소 권한 원칙을 따르기 위해 기본 뷰어 이외의 RBAC 역할에 사용자 및 그룹을 추가하지 않는 것이 좋습니다.

Important

데이터베이스 감시자가 수집한 SQL Monitoring 데이터를 볼 수 있는 액세스 권한을 부여할 때는 데이터 개인 정보 보호 및 보안 요구 사항을 신중하게 고려하세요.

데이터베이스 감시자는 SQL 데이터베이스의 사용자 테이블에 저장된 데이터를 수집할 수 없지만 활성 세션, 인덱스 메타데이터, 누락된 인덱스, 쿼리 런타임 통계, 쿼리 대기 통계, 세션 통계, 테이블 메타데이터와 같은 특정 데이터 세트에는 테이블 및 인덱스 이름, 쿼리 텍스트, 쿼리 매개 변수 값, 로그인 이름 등 잠재적으로 중요한 데이터가 포함될 수 있습니다.

SQL 데이터베이스에서 이 데이터를 볼 수 있는 액세스 권한이 없는 사용자에게 데이터 저장소에 대한 보기 액세스 권한을 부여하면 다른 방법으로는 볼 수 없는 중요한 데이터를 볼 수 있게 할 수 있습니다.

Azure Portal을 사용하여 데이터 저장소에 대한 액세스 권한 부여

Azure Portal을 사용하여 사용자 및 그룹에 Azure Data Explorer 클러스터의 데이터베이스에 대한 액세스 권한을 부여할 수 있습니다.

  1. Azure Data Explorer 클러스터의 데이터베이스에 대해 보안 + 네트워킹 아래의 리소스 메뉴에서 권한을 선택합니다. 클러스터의 권한 페이지를 사용하지 마세요.
  2. 추가를 선택하고 시청자를 선택합니다.
  3. 새 보안 주체 페이지의 검색창에 사용자 또는 그룹의 이름을 입력합니다.
  4. 사용자 또는 그룹을 선택합니다.

KQL을 사용하여 데이터 저장소에 대한 액세스 권한 부여

Azure Portal을 사용하는 대신 KQL 명령을 사용하여 사용자 및 그룹에 데이터베이스에 대한 액세스 권한을 부여할 수도 있습니다. 다음 KQL 명령 예는 mary@contoso.com 사용자 및 특정 테넌트 ID 값을 가진 Microsoft Entra ID 테넌트의 SQLMonitoringUsers@contoso.com 그룹에 데이터 읽기 권한을 부여합니다.

.add database [watcher_data_store] viewers ('aaduser=mary@contoso.com');

.add database [watcher_data_store] viewers ('aadgroup=SQLMonitoringUsers@contoso.com;8537e70e-7fb8-43d3-aac5-8b30fb3dcc4c');

자세한 내용은 Kusto 역할 기반 액세스 제어를 참조하세요.

다른 테넌트에서 사용자 및 그룹에 데이터 저장소에 대한 액세스 권한을 부여하려면 Azure Data Explorer 클러스터에서 테넌트 간 인증을 사용하도록 설정해야 합니다. 자세한 내용은 테넌트 간 쿼리 및 명령 허용을 참조하세요.

팁

Microsoft Entra ID 테넌트에서 사용자 및 그룹에 대한 액세스 권한을 부여하기 위해 실시간 분석 및 무료 Azure Data Explorer 클러스터에서 테넌트 간 인증을 사용하도록 설정합니다.

데이터 저장소 관리

이 섹션에서는 크기 조정, 데이터 보존 및 기타 구성을 포함하여 모니터링 데이터 저장소를 관리하는 방법을 설명합니다. 이 섹션의 클러스터 크기 조정 고려 사항은 Azure Data Explorer 클러스터에서 데이터베이스를 사용하는 경우 적용됩니다. 데이터베이스를 Fabric의 실시간 분석에서 사용하는 경우 크기 조정은 자동으로 관리됩니다.

Azure Data Explorer 클러스터 크기 조정

필요에 따라 Azure Data Explorer 클러스터의 크기를 조정할 수 있습니다. 예를 들어 SLA(서비스 수준 약정)가 필요하지 않고 쿼리 및 데이터 수집 성능이 허용 가능한 수준인 경우 클러스터를 매우 작은 개발/테스트 SKU로 스케일 다운할 수 있습니다.

많은 데이터베이스 감시자 배포의 경우 기본 매우 작은 컴퓨팅 최적화 2개 인스턴스 클러스터 SKU면 무한정 충분합니다. 경우에 따라 시간이 지남에 따른 구성 및 워크로드 변경에 따라 적절한 쿼리 성능을 보장하고 낮은 데이터 수집 대기 시간을 유지하기 위해 클러스터 크기를 조정해야 할 수도 있습니다.

Azure Data Explorer는 수직 및 수평 클러스터 크기 조정을 지원합니다. 수직 크기 조정을 사용하면 클러스터 SKU를 변경하여 인스턴스(노드)당 vCPU, 메모리 및 캐시 수를 변경합니다. 수평 크기 조정을 사용하면 SKU는 동일하게 유지되지만 클러스터의 인스턴스 수가 늘어나거나 줄어듭니다.

다음 증상 중 하나 이상이 나타나면 클러스터를 수평으로 확장하거나 수직으로 확장해야 합니다.

  • 대시보드 또는 임시 쿼리 성능이 너무 느려집니다.
  • 클러스터에서 여러 동시 쿼리를 실행하고 제한 오류가 관찰됩니다.
  • 데이터 수집 대기 시간이 허용 가능한 수준보다 지속적으로 높아집니다.

일반적으로 시간이 지남에 따라 데이터 저장소의 데이터 양이 증가하더라도 클러스터 크기를 조정할 필요는 없습니다. 대시보드 쿼리와 가장 일반적인 분석 쿼리는 클러스터 노드의 로컬 SSD 저장소에 캐시된 최신 데이터만 사용하기 때문입니다.

그러나 더 긴 시간 범위에 걸쳐 분석 쿼리를 실행하는 경우 수집된 데이터의 총량이 증가하여 더 이상 로컬 SSD 스토리지에 맞지 않아 시간이 지남에 따라 느려질 수 있습니다. 이 경우 적절한 쿼리 성능을 유지하기 위해 클러스터 크기를 조정해야 할 수 있습니다.

  • 클러스터의 크기를 조정해야 하는 경우 먼저 수평으로 크기를 조정하여 인스턴스 수를 늘리는 것이 좋습니다. 이렇게 하면 크기 조정 프로세스 중에 클러스터를 쿼리 및 수집에 계속 사용할 수 있습니다.

    • 최적화된 자동 크기 조정을 사용하도록 설정하여 워크로드 변경 또는 계절 추세에 따라 인스턴스 수를 자동으로 줄이거나 늘릴 수 있습니다.

  • 클러스터를 수평으로 확장한 후에도 일부 쿼리가 여전히 예상대로 수행되지 않을 수 있습니다. 이는 쿼리 성능이 클러스터의 인스턴스(노드)에서 사용 가능한 리소스에 의해 제한되는 경우 발생할 수 있습니다. 이 경우 클러스터를 수직으로 스케일 업합니다.

    • 수직 클러스터 크기 조정에는 몇 분 정도 걸립니다. 이 프로세스 중에는 감시자의 데이터 컬렉션을 중단할 수 있는 가동 중지 시간이 있습니다. 이 경우 크기 조정 작업이 완료된 후 감시자를 중지했다가 다시 시작하세요.

무료 Azure Data Explorer 클러스터

무료 Azure Data Explorer 클러스터에는 원래 압축되지 않은 데이터에 대한 스토리지 용량 제한을 포함하여 특정 용량 제한이 있습니다. 무료 Azure Data Explorer 클러스터의 크기를 조정하여 컴퓨팅 또는 스토리지 용량을 늘릴 수 없습니다. 클러스터가 스토리지 용량에 근접하거나 용량에 도달하면 무료 클러스터 페이지에 경고 메시지가 표시됩니다.

스토리지 용량에 도달하면 새 모니터링 데이터가 수집되지 않지만 기존 데이터는 데이터베이스 감시자 대시보드에서 계속 액세스할 수 있으며 KQL 또는 SQL 쿼리를 사용하여 분석할 수 있습니다.

무료 클러스터의 사양이 요구 사항에 충분하지 않은 경우 전체 Azure Data Explorer 클러스터로 업그레이드하고 수집된 모든 데이터를 유지할 수 있습니다. 업그레이드하는 동안 가동 중지 시간이 있을 수 있으므로 업그레이드가 완료되면 데이터 수집을 다시 시작하기 위해 감시자를 중지했다가 다시 시작해야 할 수 있습니다.

무료 Azure Data Explorer 클러스터 를 계속 사용하려면 데이터 보존 을 관리하여 이전 데이터를 자동으로 삭제하고 새 데이터를 위한 공간을 확보합니다. 스토리지 공간을 사용할 수 있게 되면 감시자를 중지하고 다시 시작하여 데이터 수집을 다시 시작해야 할 수 있습니다.

데이터 보존 관리

이전 데이터가 필요하지 않은 경우 데이터 보존 정책을 구성하여 자동으로 제거할 수 있습니다. 기본적으로 데이터 보존 은 Azure Data Explorer 클러스터 또는 실시간 분석의 새 데이터베이스에서 365일로 설정됩니다.

  • 데이터베이스 수준에서 또는 데이터베이스의 개별 테이블에 대해 데이터 보존 기간을 줄일 수 있습니다.
  • 모니터링 데이터를 1년 이상 저장해야 하는 경우 보존 기간을 늘릴 수도 있습니다. 데이터 보존 기간에는 상한이 없습니다.
  • 서로 다른 테이블에 대해 서로 다른 데이터 보존 기간을 구성하는 경우 대시보드가 이전 시간 범위에 대해 예상대로 작동하지 않을 수 있습니다. 이 문제는 데이터가 일부 테이블에는 여전히 존재하지만 동일한 시간 간격 동안 다른 테이블에서 이미 제거된 경우 발생할 수 있습니다.

데이터 저장소에서 수집되는 SQL 모니터링 데이터의 양은 SQL 워크로드 및 Azure SQL 자산의 크기에 따라 달라집니다. 다음 KQL 쿼리를 사용하여 하루에 수집된 평균 데이터 양을 보고, 시간에 따른 스토리지 사용량을 예측하고, 데이터 보존 정책을 관리할 수 있습니다.

.show database extents
| summarize OriginalSize = sum(OriginalSize),
            CompressedSize = sum(CompressedSize)
            by bin(MinCreatedOn, 1d)
| summarize DailyAverageOriginal = format_bytes(avg(OriginalSize)),
            DailyAverageCompressed = format_bytes(avg(CompressedSize));

데이터베이스 감시자 데이터 저장소의 스키마 및 액세스 변경 내용

시간이 지남에 따라 Microsoft는 새 데이터베이스 감시자 데이터 세트를 도입하거나 기존 데이터 세트를 확장할 수 있습니다. 즉, 데이터 저장소의 새 테이블 또는 기존 테이블의 새 열이 자동으로 추가될 수 있습니다.

이렇게 하려면 데이터베이스 감시자의 현재 관리 ID가 데이터 저장소에서 관리자 RBAC 역할의 구성원이어야 합니다. 이 역할 구성원 자격을 해지하거나 다른 RBAC 역할의 구성원 자격으로 바꾸면 데이터베이스 감시자 데이터 수집 및 스키마 관리에 영향을 미칠 수 있으며 지원되지 않습니다.

마찬가지로 데이터베이스 감시자 데이터 저장소에서 테이블, 외부 테이블, 구체화된 뷰, 함수 등의 새 개체를 만드는 것은 지원되지 않습니다. 클러스터 간 및 데이터베이스 간 쿼리를 사용하여 다른 Azure Data Explorer 클러스터 또는 동일한 클러스터의 다른 데이터베이스에서 데이터 저장소의 데이터를 쿼리할 수 있습니다.

중요

데이터 저장소에 대한 데이터베이스 감시자 액세스 권한을 변경하거나 데이터 수집에 영향을 주는 데이터베이스 스키마 또는 구성을 변경하는 경우 새로운 빈 데이터베이스로 해당 감시자의 데이터 저장소를 변경하고 감시자에게 이 새 데이터베이스에 대한 액세스 권한을 부여하여 데이터 수집을 다시 시작하고 지원되는 구성으로 되돌려야 할 수 있습니다.

중지된 Azure Data Explorer 클러스터

예를 들면 비용 절감을 위해 Azure Data Explorer 클러스터를 중지할 수 있습니다. 기본적으로 Azure Portal에서 만든 Azure Data Explorer 클러스터는 며칠 동안 활동이 없으면 자동으로 중지됩니다. 예를 들어 클러스터의 유일한 데이터베이스에 데이터를 수집하는 감시자를 중지하고 해당 데이터베이스에서 쿼리를 실행하지 않는 경우 이런 일이 발생할 수 있습니다.

새 감시자를 만들 때 기본 옵션을 사용하여 새 Azure Data Explorer 클러스터를 만드는 경우 중단 없는 데이터 컬렉션을 허용하도록 자동 중지 동작이 비활성화됩니다.

클러스터가 중지되면 데이터베이스 감시자 데이터 컬렉션도 중지됩니다. 데이터 컬렉션을 다시 시작하려면 클러스터를 시작해야 합니다. 클러스터가 실행 중이면 Watcher를 다시 시작합니다.

클러스터가 비활성 상태일 때에도 계속 사용할 수 있도록 하려면 자동 중지 동작을 사용하지 않도록 설정할 수 있습니다. 이로 인해 클러스터 비용이 증가할 수 있습니다.

스트리밍 수집

데이터베이스 Watcher는 데이터 저장소 데이터베이스를 포함하는 Azure Data Explorer 클러스터에 스트리밍 수집을 사용하도록 설정해야 합니다. 스트리밍 수집은 새 감시자를 만들 때 만든 새 Azure Data Explorer 클러스터에 대해 자동으로 사용하도록 설정됩니다. 실시간 분석 및 무료 Azure Data Explorer 클러스터에서도 사용하도록 설정됩니다.

기존 Azure Data Explorer 클러스터를 사용하려면 먼저 스트리밍 수집을 사용하도록 설정해야 합니다. 이 작업은 몇 분 정도 걸리며 클러스터를 다시 시작해야 합니다.

데이터 저장소에 대한 프라이빗 연결

Azure Data Explorer 클러스터에 대한 공용 액세스를 사용하지 않도록 설정한 경우 브라우저에서 클러스터에 연결하고 대시보드에서 SQL Monitoring 데이터를 보거나 데이터를 직접 쿼리하는 프라이빗 엔드포인트를 만들어야 합니다. 이 프라이빗 엔드포인트는 감시자가 모니터링 데이터를 Azure Data Explorer 클러스터의 데이터베이스로 수집할 수 있도록 만든 관리형 프라이빗 엔드포인트에 추가됩니다.

  • Azure VM에서 Azure Data Explorer 클러스터에 연결하는 경우 Azure VM이 배포된 Azure 가상 네트워크에서 Azure Data Explorer 클러스터에 대한 프라이빗 엔드포인트를 만듭니다.

  • 온-프레미스 컴퓨터에서 Azure Data Explorer 클러스터에 연결하는 경우 다음을 수행할 수 있습니다.

    1. Azure VPN Gateway 또는 Azure ExpressRoute를 사용하여 온-프레미스 네트워크에서 Azure 가상 네트워크로의 프라이빗 연결을 설정합니다.
    2. VPN 또는 ExpressRoute 연결이 종료되는 Azure 가상 네트워크 또는 사용하시는 온-프레미스 컴퓨터에서 트래픽이 도달할 수 있는 다른 Azure 가상 네트워크에서 Azure Data Explorer 클러스터에 대한 프라이빗 엔드포인트를 만듭니다.
    3. 해당 프라이빗 엔드포인트에 대한 DNS를 구성합니다.

프라이빗 연결은 무료 Azure Data Explorer 클러스터 또는 Microsoft Fabric의 실시간 분석에 사용할 수 없습니다.

대규모 자산 모니터링

대규모 Azure SQL 자산을 모니터링하려면 여러 감시자를 만들어야 할 수 있습니다.

감시자마다 데이터 저장소로 Azure Data Explorer 클러스터 또는 실시간 분석의 데이터베이스가 필요합니다. 사용자가 만드는 감시자는 단일 데이터베이스를 공통 데이터 저장소로 사용하거나 개별 데이터베이스를 별도의 데이터 저장소로 사용할 수 있습니다. 다음 고려 사항은 모니터링 시나리오 및 요구 사항에 대한 최적의 디자인을 선택하는 데 도움이 될 수 있습니다.

공통 데이터 저장소에 대한 고려 사항:

  • 전체 Azure SQL 자산의 단일 창 보기가 있습니다.
  • 감시자의 대시보드는 다른 감시자가 데이터를 수집하더라도 데이터 저장소의 모든 데이터를 표시합니다.
  • 데이터 저장소에 액세스할 수 있는 사용자는 전체 Azure SQL 자산에 대한 모니터링 데이터에 액세스할 수 있습니다.

별도의 데이터 저장소에 대한 고려 사항:

  • Azure SQL 자산의 하위 집합은 독립적으로 모니터링됩니다. Azure Portal의 데이터베이스 감시자 대시보드에는 항상 단일 데이터 저장소의 데이터가 표시됩니다.
  • 여러 데이터 저장소에 액세스할 수 있는 사용자는 클러스터 간 또는 데이터베이스 간 KQL 쿼리를 사용하여 단일 쿼리를 사용하여 여러 데이터 저장소의 모니터링 데이터에 액세스할 수 있습니다.
  • Azure Data Explorer 및 실시간 분석의 데이터 액세스는 데이터베이스별로 관리되므로 자산의 하위 집합의 모니터링 데이터에 대한 액세스 권한을 세분화된 방식으로 관리할 수 있습니다.
  • 동일한 Azure Data Explorer 클러스터에 여러 데이터베이스를 배치하여 클러스터 리소스를 공유하고 비용을 절감하면서 각 데이터베이스에서 데이터를 격리할 수 있습니다.
  • Azure Data Explorer 클러스터에 대한 네트워크 액세스를 포함하여 환경을 완전히 분리해야 하는 경우 서로 다른 클러스터에 서로 다른 데이터베이스를 배치할 수 있습니다.

관련 콘텐츠