다음을 통해 공유

Azure Operator Insights 수집 에이전트 설치 및 데이터를 업로드하도록 구성

  • 아티클

이 문서를 따르면 네트워크의 VM(가상 머신)에 Azure Operator Insights 수집 에이전트를 설정하고 데이터 제품에 데이터를 업로드하도록 구성하게 됩니다. 이 수집 에이전트는 다음 업로드를 지원합니다.

  • SFTP 서버에 저장된 파일입니다.
  • MCC(모바일 콘텐츠 클라우드) EDR(이벤트 데이터 레코드) 데이터 스트림이 확인되었습니다.

수집 에이전트 개요는 수집 에이전트 개요를 참조하세요.

필수 조건

데이터 제품 설명서에서 다음을 가져옵니다.

  • VM 에이전트를 설치하려는 VM의 사양입니다.
  • 수집 에이전트의 샘플 구성입니다.

VM 보안 권장 사항

수집 에이전트에 사용되는 VM은 보안 모범 사례에 따라 설정해야 합니다. 다음 작업을 수행하는 것이 좋습니다.

네트워킹

Azure VM을 사용하는 경우:

  • VM에 개인 IP 주소를 제공합니다.
  • 에이전트를 실행하고 VM을 유지 관리하는 데 필요한 포트에서만 네트워크 트래픽을 허용하도록 NSG(네트워크 보안 그룹)를 구성합니다.
  • 이 외에도 네트워크 구성은 데이터 제품에 제한된 액세스가 설정되었는지 여부(서비스 엔드포인트를 사용하여 데이터 제품의 입력 스토리지 계정에 액세스하는지 여부)에 따라 달라집니다. VM과 데이터 제품의 입력 스토리지 계정 간의 Azure Virtual Network와 같은 일부 네트워킹 구성에는 추가 비용이 발생할 수 있습니다.

온-프레미스 VM을 사용하는 경우:

  • 에이전트를 실행하고 VM을 유지 관리하는 데 필요한 포트에서만 네트워크 트래픽을 허용하도록 방화벽을 구성합니다.

디스크 암호화

Azure Disk Encryption이 사용하도록 설정되어 있는지 확인합니다(VM을 만들 때 기본값임).

OS 버전

  • 알려진 취약성을 방지하려면 OS 버전을 최신 상태로 유지합니다.
  • 누락된 시스템 업데이트를 주기적으로 확인하도록 VM을 구성합니다.

Access

VM에 대한 액세스를 최소한의 사용자 집합으로 제한합니다. VM에서 감사 로깅을 구성합니다(예: Linux 감사 패키지 사용). 로그인 시도와 로그인한 사용자가 수행한 작업을 기록합니다.

다음 형식의 액세스를 제한하는 것이 좋습니다.

  • VM에 대한 관리자 액세스(예: 수집 에이전트 중지/시작/설치)
  • 로그가 저장된 디렉터리에 대한 액세스: /var/log/az-aoi-ingestion/.
  • 이 절차 중에 만드는 서비스 주체에 대한 관리 ID 또는 인증서와 프라이빗 키에 대한 액세스입니다.
  • 이 절차 중에 VM에 만드는 비밀의 디렉터리에 대한 액세스

Microsoft Defender for Cloud

Azure VM을 사용하는 경우 클라우드용 Microsoft Defender의 모든 권장 사항도 따릅니다. VM으로 이동한 다음 보안을 선택하면 포털에서 이러한 권장 사항을 찾을 수 있습니다.

Azure에 대한 인증 설정

수집 에이전트는 스토리지 자격 증명을 검색하기 위해 데이터 제품에서 만들어진 Azure Key Vault로 인증할 수 있어야 합니다. 인증 방법은 다음 중 하나일 수 있습니다.

  • 인증서 자격 증명이 있는 서비스 주체입니다. 수집 에이전트가 온-프레미스 네트워크와 같이 Azure 외부에서 실행되는 경우 이 방법을 사용해야 합니다.
  • 관리 ID. 수집 에이전트가 Azure VM에서 실행 중인 경우 이 방법을 권장합니다. 서비스 주체와 달리 자격 증명을 처리할 필요가 없습니다.

Important

이 설정을 수행하려면 조직의 Microsoft Entra 테넌트 관리자가 필요할 수 있습니다.

인증을 위한 관리 ID 사용

수집 에이전트가 Azure에서 실행 중인 경우 관리 ID를 권장합니다. 자세한 내용은 관리 ID 개요를 참조하세요.

참고 항목

Azure VM의 수집 에이전트는 시스템 할당 및 사용자 할당 관리 ID를 모두 지원합니다. 여러 에이전트의 경우 에이전트를 실행하는 모든 VM에 대해 Data Product Key Vault에 대한 ID에 권한을 부여할 수 있으므로 사용자 할당 관리 ID가 더 간단합니다.

  1. 사용자 할당 관리 ID 관리의 지침에 따라 사용자 할당 관리 ID를 만들거나 가져옵니다. 시스템 할당 관리 ID를 사용하려는 경우 사용자 할당 관리 ID를 만들지 마세요.
  2. 사용 중인 관리 ID 유형에 따라 Azure Portal을 사용하여 VM에서 Azure 리소스에 대한 관리 ID 구성의 지침을 따릅니다.
  3. 관리 ID의 개체 ID를 적어둡니다. 개체 ID는 xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 형식의 UUID입니다. 여기서 각 문자는 16진수입니다.

이제 Data Product Key Vault에 대한 권한을 부여할 수 있습니다.

인증에 서비스 주체 사용

수집 에이전트가 온-프레미스 네트워크와 같은 Azure 외부에서 실행되는 경우에는 관리 ID를 사용할 수 없으며 대신 인증서 자격 증명이 있는 서비스 주체를 사용하여 Data Product Key Vault에 인증해야 합니다. 각 에이전트에는 가상 머신에 저장된 인증서 복사본도 있어야 합니다.

서비스 주체 만들기

  1. Microsoft Entra ID 서비스 주체를 만들거나 가져옵니다. 포털에서 Microsoft Entra 앱 및 서비스 주체 만들기에서 설명하는 지침을 따릅니다. 리디렉션 URI 필드를 비워 둡니다.
  2. 애플리케이션(클라이언트) ID와 Microsoft Entra 디렉터리(테넌트) ID를 적어둡니다. 이러한 ID는 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 형식의 UUID이며, 여기서 각 문자는 16진수입니다.

서비스 주체에 대한 인증서 준비

수집 에이전트는 서비스 주체에 대한 인증서 자격 증명만 지원합니다. 동일한 인증서와 키를 각 VM에 사용하는지 아니면 고유한 인증서와 키를 각 VM에 사용하는지 여부는 사용자가 결정합니다. VM당 인증서를 사용하면 보안이 향상되고, 키가 유출되거나 인증서가 만료되는 경우 영향이 줄어듭니다. 그러나 이 방법은 유지 관리 가능성과 운영 복잡성을 더 높입니다.

  1. 하나 이상의 인증서를 가져옵니다. 인증 기관의 신뢰할 수 있는 인증서를 사용하는 것이 좋습니다. Azure Key Vault에서 인증서를 생성할 수 있습니다. Azure Portal을 사용하여 Key Vault에서 인증서 설정 및 검색을 참조하세요. 이렇게 하면 만료 경고를 구성할 수 있고 새 인증서를 다시 생성하여 만료되기 전에 수집 에이전트에 적용할 시간을 얻을 수 있습니다. 인증서가 만료되면 에이전트는 Azure에 인증할 수 없으며 더 이상 데이터를 업로드하지 않습니다. 이 방식에 대한 자세한 내용은 Azure Key Vault 인증서 갱신을 참조하세요. Azure Key Vault를 사용하기로 선택한 경우 다음을 수행합니다.
    • 이 Azure Key Vault는 이미 제어하고 있는 데이터 제품 Key Vault와 다른 인스턴스이거나 새 인스턴스여야 합니다.
    • 인증서를 Key Vault에 추가하려면 이 Azure Key Vault에 대한 'Key Vault 인증서 책임자' 역할이 필요합니다. Azure에서 역할을 할당하는 방법에 대한 자세한 내용은 Azure Portal을 사용하여 Azure 역할 할당을 참조하세요.
  2. 포털에서 Microsoft Entra 앱 및 서비스 주체 만들기에 따라 인증서를 서비스 주체에 대한 자격 증명으로 추가합니다.
  3. 인증서를 보호하는 암호 구 없이 P12(PKCS#12) 형식으로 사용할 수 있는지 확인합니다.
    • 인증서가 Azure Key Vault에 저장된 경우 인증서를 PFX 형식으로 다운로드합니다. PFX는 P12와 동일합니다.
    • Linux에서는 OpenSSL을 사용하여 인증서와 프라이빗 키를 변환할 수 있습니다. 내보내기 암호를 묻는 메시지가 나타나면 Enter 키를 눌러 빈 암호를 입력합니다. 그런 다음 1단계에 설명된 대로 Azure Key Vault에 저장할 수 있습니다.
    openssl pkcs12 -nodes -export -in <certificate.pem> -inkey <key.pem> -out <certificate.p12>

Important

P12 파일은 암호로 보호하면 안 됩니다.

  1. P12 파일의 유효성을 검사합니다. 인증서 및 프라이빗 키를 포함하여 P12 파일에 대한 정보가 표시됩니다.

    openssl pkcs12 -nodes -in <certificate.p12> -info

  2. P12 파일이 base64로 인코딩되었는지 확인합니다. Linux에서는 base64 명령을 사용하여 P12 인증서를 base64로 인코딩할 수 있습니다.

    base64 -w 0 <certificate.p12> > <base64-encoded-certificate.p12>

Data Product Key Vault에 대한 권한 부여

  1. 입력 스토리지 계정에 대한 스토리지 자격 증명을 보유하는 Azure Key Vault를 찾습니다. 이 Key Vault는 <data-product-name>-HostedResources-<unique-id>라는 리소스 그룹에 있습니다.
  2. 이 Key Vault에 대한 'Key Vault 비밀 사용자' 역할을 서비스 주체에 부여합니다. Azure 구독에 대한 소유자 수준 권한이 필요합니다. Azure에서 역할을 할당하는 방법에 대한 자세한 내용은 Azure Portal을 사용하여 Azure 역할 할당을 참조하세요.
  3. Key Vault 이름을 적어둡니다.

SFTP 서버 준비

이 섹션은 SFTP 풀 원본에만 필요합니다.

SFTP 서버에서:

  1. VM에 대한 22/TCP 포트가 열려 있는지 확인합니다.
  2. 새 사용자를 만들거나 수집 에이전트에서 SFTP 서버에 연결하는 데 사용할 SFTP 서버의 기존 사용자를 결정합니다.
    • 기본적으로 수집 에이전트는 기본 경로 아래의 모든 디렉터리를 검색하므로 이 사용자는 해당 디렉터리를 모두 읽을 수 있어야 합니다. 사용자에게 액세스 권한이 없는 모든 디렉터리는 exclude_pattern 구성을 사용하여 제외되어야 합니다.

    참고 항목

    포함된 패턴에 디렉터리를 지정하지 않고 암시적으로 디렉터리를 제외하는 것만으로는 해당 디렉터리 검색을 중지하는 데 충분하지 않습니다. 디렉터리 제외에 대한 자세한 내용은 구성 참조를 확인합니다.

  3. 수집 에이전트가 SFTP 서버에 연결하는 데 사용해야 하는 인증 방법을 결정합니다. 에이전트는 다음을 지원합니다.
    • 암호 인증
    • SSH 키 인증
  4. 일정 기간(보존 기간)이 지나면 파일을 제거하도록 SFTP 서버를 구성합니다. SFTP 서버가 파일을 삭제하기 전에 에이전트가 파일을 처리해야 할 만큼 보존 기간이 충분히 긴지 확인합니다. 예제 구성 파일에는 5분마다 새 파일을 확인하기 위한 구성이 포함되어 있습니다.

Important

디스크 공간이 부족하지 않도록 적절한 보존 기간 후에는 SFTP 서버에서 파일을 제거해야 합니다. 수집 에이전트는 파일을 자동으로 제거하지 않습니다.

보존 시간이 짧을수록 디스크 사용량이 줄어들고, 에이전트 속도가 향상되며, 중복 업로드 위험이 줄어듭니다. 그러나 보존 기간이 짧을수록 에이전트에서 데이터를 검색하거나 Azure Operator Insights에 업로드할 수 없는 경우 데이터가 손실될 위험이 높아집니다.

VM 준비

에이전트를 설치하려는 각 VM에 대해 다음 단계를 반복합니다.

  1. VM에 대한 SSH 세션이 열려 있고 sudo 권한이 있는지 확인합니다.

  2. 아직 없는 경우 systemd, logrotate 및 zip을 VM에 설치합니다. 예시:

    sudo dnf install systemd logrotate zip

  3. 서비스 주체를 사용하는 경우 base64로 인코딩된 P12 인증서(인증서 준비 단계에서 만들어짐)를 수집 에이전트가 액세스할 수 있는 위치의 VM에 복사합니다.

  4. 수집 원본 형식에 따라 에이전트 VM을 구성합니다.

    1. VM에 다음 포트가 열려 있는지 확인합니다. 이러한 포트는 클라우드 네트워크 보안 그룹과 VM 자체에서 실행되는 방화벽(예: firewalld 또는 iptables) 모두에서 열려 있어야 합니다.
      • Azure로 나가는 443/TCP 아웃바운드 포트
      • SFTP 서버로 나가는 22/TCP 아웃바운드 포트
    2. 에이전트의 비밀을 저장하는 데 사용할 디렉터리를 만듭니다. 이 디렉터리를 secrets 디렉터리라고 합니다. 해당 경로를 기록해 두세요.
    3. SFTP 서버의 암호 또는 프라이빗 SSH 키가 포함된 secrets 디렉터리에 파일을 만듭니다.
      • 파일에 파일 확장명이 없어야 합니다.
      • 이 파일에 적절한 이름을 선택하고 나중에 기록해 두세요. 이 이름은 에이전트 구성에서 참조됩니다.
      • 파일에는 추가 공백 없이 비밀 값(암호 또는 SSH 키)만 포함되어야 합니다.
    4. 인증할 암호가 있는 SSH 키를 사용하는 경우 동일한 방법을 사용하여 암호가 포함된 별도의 파일을 만듭니다.
    5. SFTP 서버의 공용 SSH 키가 /etc/ssh/ssh_known_hosts에 있는 VM의 전역 Known_hosts 파일에 나열되어 있는지 확인합니다.

    팁

    Linux 명령 ssh-keyscan을 사용하여 서버의 SSH 공개 키를 VM의 known_hosts 파일에 수동으로 추가합니다. 예들 들어 ssh-keyscan -H <server-ip> | sudo tee -a /etc/ssh/ssh_known_hosts입니다.

VM이 Microsoft 호스트 이름을 확인할 수 있는지 확인

VM이 공용 호스트 이름을 IP 주소로 확인할 수 있는지 확인합니다. 예를 들어, SSH 세션을 열고 dig login.microsoftonline.com을 사용하여 VM이 login.microsoftonline.com을 IP 주소로 확인할 수 있는지 확인합니다.

VM이 DNS를 사용하여 공용 Microsoft 호스트 이름을 IP 주소로 확인할 수 없는 경우 필요한 호스트 이름을 IP 주소에 매핑합니다. 구성을 완료하면 이 절차로 돌아옵니다.

에이전트 소프트웨어 설치

에이전트 소프트웨어 패키지는 https://packages.microsoft.com의 "Microsoft 제품용 Linux 소프트웨어 저장소"에서 호스팅됩니다

수집 에이전트 패키지의 이름은 az-aoi-ingestion입니다.

소프트웨어 리포지토리에서 패키지를 다운로드하고 설치하려면 Linux 리포지토리를 사용하여 Microsoft 소프트웨어 패키지를 설치하는 방법에서 VM의 Linux 배포에 대한 관련 단계를 수행합니다.

예를 들어 RHEL(Red Hat Enterprise Linux) 8을 실행하는 VM에 설치하는 경우 Red Hat 기반 Linux 배포판 제목 아래의 지침에 따라 다음 매개 변수를 대체합니다.

  • 배포: rhel
  • 버전: 8
  • package-name: az-aoi-ingestion

에이전트 소프트웨어 구성

필요한 구성은 원본 형식과 데이터 제품에 따라 다릅니다. 필수 값을 보려면 데이터 제품 설명서에 액세스할 수 있는지 확인합니다. 예시:

  1. SSH를 통해 VM에 연결합니다.

  2. 구성 디렉터리로 변경합니다.

    cd /etc/az-aoi-ingestion

  3. 기본 구성 파일의 복사본을 만듭니다.

    sudo cp example_config.yaml config.yaml

  4. agent_id 필드를 에이전트 인스턴스의 고유 식별자(예: london-sftp-1)로 설정합니다. 이 이름은 이 에이전트에서 수집한 모든 데이터에 대해 Operator Insights에서 검색 가능한 메타데이터가 됩니다. 예약된 URL 문자는 백분율로 인코딩해야 합니다.

  5. secret_providers 섹션을 구성합니다.

    SFTP 원본에는 두 가지 형식의 비밀 공급자가 필요합니다.

    • 데이터 제품의 Azure Key Vault에 연결하고 데이터 제품의 입력 스토리지 계정에 대한 연결을 허용하는 데 필요한 세부 정보가 포함된 key_vault 형식의 비밀 공급자입니다.
    • SFTP 서버에 연결하기 위한 자격 증명을 저장하기 위해 VM의 디렉터리를 지정하는 file_system 형식의 비밀 공급자입니다.
    1. 형식이 key_vault이고 이름이 data_product_keyvault인 비밀 공급자에 대해 다음 필드를 설정합니다.
      • vault_name은 데이터 제품에 대한 Key Vault의 이름이어야 합니다. 이 이름은 Data Product Key Vault에 대한 권한 부여에서 확인했습니다.
      • Azure에 대한 인증 설정에서 선택한 인증 형식에 따라 managed_identity 또는 service_principal을 설정합니다.
        • 관리 ID의 경우: object_id를 인증에 관리 ID 사용에서 만든 관리 ID의 개체 ID로 설정합니다.
        • 서비스 주체의 경우: tenant_id를 Microsoft Entra ID 테넌트로 설정하고, client_id를 서비스 주체 만들기에서 만든 서비스 주체의 애플리케이션(클라이언트) ID로 설정하고, cert_path를 VM에 있는 base64로 인코딩된 P12 인증서의 파일 경로로 설정합니다.
    2. 형식이 file_system이고 이름이 local_file_system인 비밀 공급자에 대해 다음 필드를 설정합니다.
      • secrets_directory는 VM 준비 단계에서 만들어진 에이전트 VM의 secrets 디렉터리에 대한 절대 경로입니다.

    더 많은 비밀 공급자를 추가하거나(예: 여러 데이터 제품에 업로드하려는 경우) 기본 비밀 공급자의 이름을 변경할 수 있습니다.

  6. 예 구성과 데이터 제품 설명서를 사용하여 pipelines 섹션을 구성합니다. 각 pipeline에는 세 개의 구성 섹션이 있습니다.

    • id. ID는 파이프라인을 식별하며 이 수집 에이전트의 다른 파이프라인 ID와 동일해서는 안 됩니다. 모든 URL 예약 문자는 백분율로 인코딩되어야 합니다. 권장 사항은 데이터 제품 설명서를 참조하세요.

    • source. 원본 구성은 수집되는 파일을 제어합니다. 여러 원본을 구성할 수 있습니다.

      sftp_pull 원본 구성이 포함된 contoso-logs 예를 제외하고 예에서 모든 파이프라인을 삭제합니다.

      요구 사항에 맞게 예를 업데이트합니다. 각 원본에는 다음 필드가 필요합니다.

      • host: SFTP 서버의 호스트 이름 또는 IP 주소
      • filtering.base_path: 파일이 Azure Operator Insights에 업로드되는 SFTP 서버의 폴더 경로
      • known_hosts_file: /etc/ssh/ssh_known_hosts에 있는 전역 known_hosts 파일에 대한 VM의 경로입니다. 이 파일에는 VM 준비에서 설명한 대로 SFTP 호스트 서버의 공개 SSH 키가 포함되어야 합니다.
      • user: 에이전트에서 연결하는 데 사용해야 하는 SFTP 서버의 사용자 이름
      • VM 준비에서 선택한 인증 방법에 따라 password 또는 private_key를 설정합니다.
        • 암호 인증의 경우 secret_name을 secrets_directory 폴더에 암호가 포함된 파일 이름으로 설정합니다.
        • SSH 키 인증의 경우 key_secret_name을 secrets_directory 폴더의 SSH 키가 포함된 파일 이름으로 설정합니다. 프라이빗 키가 암호로 보호되는 경우 passphrase_secret_name을 secrets_directory 폴더의 암호가 포함된 파일 이름으로 설정합니다.
        • 모든 비밀 파일에는 600(rw-------) 권한과 az-aoi-ingestion 소유자가 있어야 합니다. 따라서 수집 에이전트와 권한이 있는 사용자만 읽을 수 있습니다.
        sudo chmod 600 <secrets_directory>/*
sudo chown az-aoi-ingestion <secrets_directory>/*

      다른 필드의 필수 또는 권장 값은 데이터 제품 설명서를 참조하세요.

      팁

      에이전트는 다음에 대한 추가 선택적 구성을 지원합니다.

      • 업로드할 base_path 폴더의 파일 패턴 지정(기본적으로 폴더의 모든 파일이 업로드됨).
      • 업로드하지 않아야 하는 base_path 폴더의 파일 패턴 지정.
      • base_path 폴더의 파일이 업로드되지 않는 이전 시간 및 날짜입니다.
      • 수집 에이전트가 파일을 업로드하는 빈도입니다(예 구성 파일에 제공된 값은 매시간에 해당함).
      • 파일이 마지막으로 수정된 후 업로드될 때까지 에이전트에서 기다리는 시간인 정착 시간(예제 구성 파일에 제공된 값은 5분).

      이러한 구성 옵션에 대한 자세한 내용은 Azure Operator Insights 수집 에이전트 구성 참조를 참조하세요.

    • sink. 싱크 구성은 데이터 제품의 입력 스토리지 계정에 데이터 업로드를 제어합니다.

      • sas_token 섹션에서 secret_provider를 데이터 제품에 대한 적절한 key_vault 비밀 공급자로 설정하거나, 이전에 기본 이름을 사용한 경우 기본 data_product_keyvault를 사용합니다. secret_name을(를) 변경하지 않은 상태로 유지합니다.
      • 기타 매개 변수의 필수 값에 대한 정보는 데이터 제품 설명서를 참조하세요.

        Important

        container_name 필드는 데이터 제품 설명서에 지정된 대로 정확하게 설정되어야 합니다.

에이전트 소프트웨어 시작

  1. 에이전트를 시작합니다. 
    sudo systemctl start az-aoi-ingestion
  2. 에이전트가 실행 중인지 확인합니다. 
    sudo systemctl status az-aoi-ingestion
    1. active (running) 이외의 상태가 표시되면 Azure Operator Insights용 수집 에이전트 모니터링 및 문제 해결에서 설명한 대로 로그를 검토하여 오류를 파악합니다. 일부 구성이 잘못되었을 수도 있습니다.
    2. 문제가 해결되면 에이전트를 다시 시작해 봅니다.
    3. 문제가 지속되면 지원 티켓을 제출합니다.
  3. 에이전트가 실행되면 다시 부팅 후 자동으로 시작되는지 확인합니다. 
    sudo systemctl enable az-aoi-ingestion.service

[선택 사항] Azure Monitor를 통해 액세스하기 위한 로그 수집 구성

Azure VM 또는 Azure Arc로 연결된 온-프레미스 VM에서 수집 에이전트를 실행하는 경우 Azure Monitor 에이전트를 사용하여 Azure Monitor에 수집 에이전트 로그를 보낼 수 있습니다. Azure Monitor를 사용하여 로그에 액세스하는 것은 VM에서 직접 로그에 액세스하는 것보다 더 간단할 수 있습니다.

수집 에이전트 로그를 수집하려면 Azure Monitor 설명서에 따라 Azure Monitor 에이전트를 설치하고 로그 수집을 구성합니다.

  • 이러한 문서는 Az PowerShell 모듈을 사용하여 로그 테이블을 만듭니다. 먼저 Az PowerShell 모듈 설치 설명서를 따릅니다.
    • 샘플 $tableParams JSON의 YourOptionalColumn 섹션은 수집 에이전트에 필요하지 않으며 제거할 수 있습니다.
  • 데이터 수집 규칙에 데이터 원본을 추가할 때 파일 패턴 /var/log/az-aoi-ingestion/stdout.log을(를) 사용하여 Custom Text Logs 원본 형식을 추가합니다.
  • 또한 VM에서 실행 중인 모든 프로세스를 감사할 수 있도록 Linux Syslog 데이터 원본을 추가하는 설명서를 데이터 수집 규칙에 따르는 것이 좋습니다.
  • 데이터 수집 규칙을 추가한 후 Log Analytics 작업 영역을 통해 수집 에이전트 로그를 쿼리할 수 있습니다. 다음 쿼리를 사용하여 작업을 더 쉽게 수행할 수 있습니다. 
    <CustomTableName>
| extend RawData = replace_regex(RawData, '\\x1b\\[\\d{1,4}m', '')  // Remove any color tags
| parse RawData with TimeGenerated: datetime '  ' Level ' ' Message  // Parse the log lines into the TimeGenerated, Level and Message columns for easy filtering
| order by TimeGenerated desc

    참고 항목

    이 쿼리는 데이터 원본 변환에서 사용할 수 없으므로 replace_regex은(는) 데이터 원본 변환으로 사용할 수 없습니다.

샘플 로그

[2m2024-04-30T17:16:00.000544Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Starting run with 'last checkpoint' timestamp: None
[2m2024-04-30T17:16:00.000689Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Starting Completion Handler task
[2m2024-04-30T17:16:00.073495Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::sftp_file_tree_explorer[0m[2m:[0m Start traversing files with base path "/"
[2m2024-04-30T17:16:00.086427Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::sftp_file_tree_explorer[0m[2m:[0m Finished traversing files
[2m2024-04-30T17:16:00.086698Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m File explorer task is complete, with result Ok(())
[2m2024-04-30T17:16:00.086874Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Send files to sink task is complete
[2m2024-04-30T17:16:00.087041Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Processed all completion notifications for run
[2m2024-04-30T17:16:00.087221Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Run complete with no retryable errors - updating last checkpoint timestamp
[2m2024-04-30T17:16:00.087351Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::source[0m[2m:[0m Run lasted 0 minutes and 0 seconds with result: RunStats { successful_uploads: 0, retryable_errors: 0, non_retryable_errors: 0, blob_already_exists: 0 }
[2m2024-04-30T17:16:00.087421Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_sftp_pull_source::sftp::file[0m[2m:[0m Closing 1 active SFTP connections
[2m2024-04-30T17:16:00.087966Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m[1mexecute_run[0m[1m{[0m[3mstart_time[0m[2m=[0m"2024-04-30 17:16:00.000524 UTC"[1m}[0m[2m:[0m [2maz_ingestion_common::scheduler[0m[2m:[0m Run completed successfully. Update the 'last checkpoint' time to 2024-04-30T17:15:30.000543200Z
[2m2024-04-30T17:16:00.088122Z[0m [32m INFO[0m [1msftp_pull[0m[1m{[0m[3mpipeline_id[0m[2m=[0m"test-files"[1m}[0m[2m:[0m [2maz_ingestion_common::scheduler[0m[2m:[0m Schedule next run at 2024-04-30T17:17:00Z

관련 콘텐츠

다음의 방법을 알아보세요.