Azure 리소스 로그 데이터 보내기
Azure 리소스 로그는 Azure 리소스 내에서 수행된 작업에 대한 인사이트를 제공하는 플랫폼 로그입니다. 이러한 로그의 내용은 Azure 서비스와 리소스 종류에 따라 달라집니다. 리소스 로그는 기본적으로 수집되지 않습니다. 이 문서에서는 각 Azure 리소스가 리소스 로그를 다른 대상으로 보내는 데 필요한 진단 설정에 대해 설명합니다.
Log Analytics 작업 영역으로 보내기
리소스 로그를 Log Analytics 작업 영역으로 보내 Azure Monitor 로그의 기능을 사용하도록 설정하면 다음을 수행할 수 있습니다.
- Azure Monitor에서 수집한 다른 모니터링 데이터와 리소스 로그 데이터의 상관관계를 파악합니다.
- 여러 Azure 리소스, 구독, 테넌트의 로그 항목을 분석을 위해 한곳에 취합합니다.
- 로그 쿼리를 사용하여 복잡한 분석을 수행하고 로그 데이터에 대한 심층적인 인사이트를 확보합니다.
- 복잡한 경고 논리와 함께 로그 검색 경고를 사용합니다.
리소스 로그를 Log Analytics 작업 영역으로 전송하는 진단 설정을 만듭니다. 이 데이터는 Azure Monitor Logs의 구조에 설명된 대로 테이블에 저장됩니다. 리소스 로그에서 사용하는 테이블은 리소스에서 사용하는 컬렉션 유형에 따라 달라집니다.
- Azure Diagnostics: 모든 데이터가 AzureDiagnostics 테이블에 기록됩니다.
- 리소스 관련: 데이터가 리소스의 각 범주에 대한 개별 테이블에 작성됩니다.
특정 리소스
이 모드에서는 진단 설정에서 선택한 각 범주에 대해 선택한 작업 영역의 개별 테이블이 생성됩니다. 다음과 같은 이유로 이 방법을 권장합니다.
- 로그 쿼리의 데이터 작업을 더 쉽게 만듭니다.
- 스키마 및 해당 구조의 더 나은 검색 가능성을 제공합니다.
- 수집 대기 시간 및 쿼리 시간 전반에 걸쳐 성능을 개선합니다.
- 특정 테이블에 대한 Azure 역할 기반 액세스 제어 권한을 부여하는 기능을 제공합니다.
모든 Azure 서비스는 결국 Resource-Specific 모드로 마이그레이션됩니다.
아래 예제에서는 세 개의 테이블을 만듭니다.
테이블:
Service1AuditLogs리소스 공급자 범주 A B C 서비스 1 AuditLogs x1 y1 z1 서비스 1 AuditLogs x5 y5 z5 ... 테이블:
Service1ErrorLogs리소스 공급자 범주 D E F 서비스 1 ErrorLogs q1 w1 e1 서비스 1 ErrorLogs q2 w2 e2 ... 테이블:
Service2AuditLogs리소스 공급자 범주 G H I 서비스 2 AuditLogs j1 k1 l1 서비스 2 AuditLogs j3 k3 l3 ...
Azure 진단 모드
이 모드에서는 모든 진단 설정의 모든 데이터가 AzureDiagnostics 테이블에 수집됩니다. 이 레거시 방법은 현재 대부분의 Azure 서비스에서 사용됩니다. 여러 리소스 종류가 동일한 테이블에 데이터를 전송하므로 해당 스키마는 수집되는 다른 모든 데이터 형식 스키마의 상위 세트입니다. 이 테이블의 구조와 잠재적으로 많은 수의 열에서 작동하는 원리에 대한 자세한 내용은 AzureDiagnostics 참조를 참조하세요.
진단 설정이 다음 데이터 형식에 대해 동일한 작업 영역에서 수집되는 예를 살펴보세요.
- 서비스 1의 감사 로그에는 A, B, C 열로 구성된 스키마가 있습니다.
- 서비스 1의 오류 로그에는 D, E 및 F 열로 구성된 스키마가 있습니다.
- 서비스 2의 감사 로그에는 G, H 및 I 열로 구성된 스키마가 있습니다.
AzureDiagnostics 테이블은 다음 예와 같습니다.
| ResourceProvider | 범주 | A | B | C | D | E | F | G | H | I |
|---|---|---|---|---|---|---|---|---|---|---|
| Microsoft.Service1 | AuditLogs | x1 | y1 | z1 | ||||||
| Microsoft.Service1 | ErrorLogs | q1 | w1 | e1 | ||||||
| Microsoft.Service2 | AuditLogs | j1 | k1 | l1 | ||||||
| Microsoft.Service1 | ErrorLogs | q2 | w2 | e2 | ||||||
| Microsoft.Service2 | AuditLogs | j3 | k3 | l3 | ||||||
| Microsoft.Service1 | AuditLogs | x5 | y5 | z5 | ||||||
| ... |
컬렉션 모드 선택
대부분의 Azure 리소스는 사용자에게 선택권 없이 Azure Diagnostics 또는 리소스별 모드로 작업 영역에 데이터를 씁니다. 자세한 내용은 Azure 리소스 로그에 대한 공통 및 서비스별 스키마를 참조하세요.
모든 Azure 서비스는 결국 resource-specific 모드를 사용합니다. 이러한 전환의 일부로, 일부 리소스는 진단 설정에서 모드를 선택할 수 있습니다. 이 모드를 사용하면 데이터를 더 쉽게 관리할 수 있으므로 새 진단 설정에 대해 리소스별 모드를 지정합니다. 또한 나중에 복잡한 마이그레이션을 방지하는 데 도움이 될 수 있습니다.
참고 항목
Azure Resource Manager 템플릿을 사용하여 컬렉션 모드를 설정하는 예는 Azure Monitor의 진단 설정을 위한 Resource Manager 템플릿 샘플을 참조하세요.
기존 진단 설정을 리소스 관련 모드로 변경할 수 있습니다. 이 경우 이미 수집된 데이터는 작업 영역에 대한 보존 설정에 따라 제거될 때까지 AzureDiagnostics 테이블에 남아 있습니다. 새 데이터가 전용 테이블에 수집됩니다. 합집합 연산자를 사용하여 두 테이블에서 데이터를 쿼리합니다.
리소스별 모드를 지원하는 Azure 서비스에 대한 공지를 보려면 Azure 업데이트 블로그를 계속 시청하세요.
Azure Event Hubs로 전송
리소스 로그를 이벤트 허브로 보내 Azure 외부로 보냅니다. 예를 들어 리소스 로그는 타사 SIEM 또는 기타 로그 분석 솔루션으로 전송될 수 있습니다. 이벤트 허브의 리소스 로그는 각 페이로드의 레코드가 포함된 records 요소와 함께 JSON 형식으로 사용됩니다. 이 스키마는 Azure 리소스 로그에 대한 공통 및 서비스 관련 스키마에 설명된 대로 리소스 종류에 따라 달라집니다.
다음 샘플 출력 데이터는 리소스 로그에 대한 Azure Event Hubs에서 가져온 것입니다.
{
"records": [
{
"time": "2019-07-15T18:00:22.6235064Z",
"workflowId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
"resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA/RUNS/08587330013509921957/ACTIONS/SEND_EMAIL",
"category": "WorkflowRuntime",
"level": "Error",
"operationName": "Microsoft.Logic/workflows/workflowActionCompleted",
"properties": {
"$schema": "2016-04-01-preview",
"startTime": "2016-07-15T17:58:55.048482Z",
"endTime": "2016-07-15T18:00:22.4109204Z",
"status": "Failed",
"code": "BadGateway",
"resource": {
"subscriptionId": "00000000-0000-0000-0000-000000000000",
"resourceGroupName": "JohnKemTest",
"workflowId": "243aac67fe904cf195d4a28297803785",
"workflowName": "JohnKemTestLA",
"runId": "08587330013509921957",
"location": "westus",
"actionName": "Send_email"
},
"correlation": {
"actionTrackingId": "29a9862f-969b-4c70-90c4-dfbdc814e413",
"clientTrackingId": "08587330013509921958"
}
}
},
{
"time": "2019-07-15T18:01:15.7532989Z",
"workflowId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA",
"resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/JOHNKEMTEST/PROVIDERS/MICROSOFT.LOGIC/WORKFLOWS/JOHNKEMTESTLA/RUNS/08587330012106702630/ACTIONS/SEND_EMAIL",
"category": "WorkflowRuntime",
"level": "Information",
"operationName": "Microsoft.Logic/workflows/workflowActionStarted",
"properties": {
"$schema": "2016-04-01-preview",
"startTime": "2016-07-15T18:01:15.5828115Z",
"status": "Running",
"resource": {
"subscriptionId": "00000000-0000-0000-0000-000000000000",
"resourceGroupName": "JohnKemTest",
"workflowId": "243aac67fe904cf195d4a28297803785",
"workflowName": "JohnKemTestLA",
"runId": "08587330012106702630",
"location": "westus",
"actionName": "Send_email"
},
"correlation": {
"actionTrackingId": "042fb72c-7bd4-439e-89eb-3cf4409d429e",
"clientTrackingId": "08587330012106702632"
}
}
}
]
}
Azure Storage에 보내기
리소스 로그를 보관하기 위해 Azure Storage로 보내 보존합니다. 진단 설정을 만든 후에는 사용 가능한 로그 범주 중 하나에서 이벤트가 발생하는 즉시 스토리지 계정에 스토리지 컨테이너가 만들어집니다.
참고 항목
보관의 대체 전략은 보관 정책을 사용하여 리소스 로그를 Log Analytics 작업 영역으로 보내는 것입니다.
컨테이너 내의 Blob은 다음과 같은 명명 규칙을 사용합니다.
insights-logs-{log category name}/resourceId=/SUBSCRIPTIONS/{subscription ID}/RESOURCEGROUPS/{resource group name}/PROVIDERS/{resource provider name}/{resource type}/{resource name}/y={four-digit numeric year}/m={two-digit numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json
네트워크 보안 그룹의 Blob은 다음 예와 유사한 이름을 가질 수 있습니다.
insights-logs-networksecuritygrouprulecounter/resourceId=/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUP/TESTNSG/y=2016/m=08/d=22/h=18/m=00/PT1H.json
각 PT1H.json Blob에는 Blob URL에 지정된 시간 동안 수신된 로그 파일의 이벤트와 함께 JSON 개체가 포함됩니다. 현재 시간 동안 이벤트는 생성된 시기에 관계없이 수신될 때 PT1H.json 파일에 추가됩니다. Blob이 시간당 기준으로 생성되므로 URL m=00의 분 값은 항상 00입니다.
PT1H.json 파일 내에서 각 이벤트는 다음 형식으로 저장됩니다. 일반적인 최상위 스키마를 사용하지만 리소스 로그 스키마에 설명된 대로 각 Azure 서비스에 대해 고유합니다.
참고 항목
로그는 생성된 시간에 관계없이 로그가 수신된 시간에 따라 Blob에 기록됩니다. 즉, 지정된 Blob은 Blob의 URL에 지정된 시간을 벗어나는 로그 데이터를 포함할 수 있습니다. 이 경우 Application Insights와 같은 데이터 원본이 Blob에서 이전 48시간 동안의 데이터를 포함할 수 있는 부실 원격 분석 업로드를 지원합니다.
새로운 1시간이 시작될 때 새 로그가 새 시간의 Blob에 기록되는 동안 기존 로그는 여전히 이전 시간의 Blob에 기록될 수 있습니다.
{"time": "2016-07-01T00:00:37.2040000Z","systemId": "46cdbb41-cb9c-4f3d-a5b4-1d458d827ff1","category": "NetworkSecurityGroupRuleCounter","resourceId": "/SUBSCRIPTIONS/s1id1234-5679-0123-4567-890123456789/RESOURCEGROUPS/TESTRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/TESTNSG","operationName": "NetworkSecurityGroupCounters","properties": {"vnetResourceGuid": "{12345678-9012-3456-7890-123456789012}","subnetPrefix": "10.3.0.0/24","macAddress": "000123456789","ruleName": "/subscriptions/ s1id1234-5679-0123-4567-890123456789/resourceGroups/testresourcegroup/providers/Microsoft.Network/networkSecurityGroups/testnsg/securityRules/default-allow-rdp","direction": "In","type": "allow","matchedConnections": 1988}}
Azure Monitor 파트너 통합
리소스 로그를 Azure에 완전히 통합된 파트너 솔루션으로 보낼 수도 있습니다. 이러한 솔루션 목록과 구성 방법에 대한 자세한 내용은 Azure Monitor 파트너 통합을 참조하세요.