Azure Functions에 대한 모니터링을 구성하는 방법
Azure Functions는 Application Insights와 통합되어 함수 앱을 보다 효율적으로 모니터링할 수 있습니다. Azure Monitor의 기능인 Application Insights는 앱이 로그에 쓰는 정보를 포함하여 함수 앱에 의해 생성된 데이터를 수집하는 확장 가능한 APM(애플리케이션 성능 관리) 서비스입니다. Application Insights 통합은 일반적으로 함수 앱을 만들 때 사용하도록 설정됩니다. 앱에 계측 키가 설정되어 있지 않은 경우 먼저 Application Insights 통합을 사용하도록 설정해야 합니다.
사용자 지정 구성 없이 Application Insights를 사용할 수 있습니다. 그러나 기본 구성을 사용하면 대량의 데이터가 생성될 수 있습니다. Visual Studio Azure 구독을 사용하는 경우 Application Insights에 대한 데이터 제한에 도달할 수 있습니다. Application Insights 비용에 대한 자세한 내용은 Application Insights 청구를 참조하세요. 자세한 내용은 대량의 원격 분석이 포함된 솔루션을 참조하세요.
이 문서에서는 함수가 Application Insights로 보내는 데이터를 구성하고 사용자 지정하는 방법을 알아봅니다. host.json 파일에서 일반적인 로깅 구성을 설정할 수 있습니다. 기본적으로 이러한 설정은 코드에서 내보낸 사용자 지정 로그도 제어합니다. 그러나 경우에 따라 로깅을 더 제어할 수 있는 옵션을 위해 이 동작을 사용하지 않도록 설정할 수 있습니다. 자세한 내용은 사용자 지정 애플리케이션 로그를 참조하세요.
참고 항목
특수하게 구성된 애플리케이션 설정을 사용하여 특정 환경에 대한 host.json 파일의 특정 설정을 나타낼 수 있습니다. 이렇게 하면 프로젝트에서 host.json 파일을 다시 게시할 필요 없이 host.json 설정을 효과적으로 변경할 수 있습니다. 자세한 내용은 host.json 값 재정의를 참조하세요.
사용자 지정 애플리케이션 로그
기본적으로 작성한 사용자 지정 애플리케이션 로그는 Functions 호스트로 전송된 다음, 작업자 범주 아래의 Application Insights로 보냅니다. 일부 언어 스택을 사용하면 로그를 Application Insights로 직접 보낼 수 있으므로 작성한 로그를 내보내는 방법을 완전히 제어할 수 있습니다. 이 경우 로깅 파이프라인이 worker -> Functions host -> Application Insights에서 worker -> Application Insights로 변경됩니다.
다음 표에서는 각 스택에 사용할 수 있는 구성 옵션이 요약되어 있습니다.
| 언어 스택 | 사용자 지정 로그를 구성할 위치 |
|---|---|
| .NET(In-Process 모델) | host.json |
| .NET(격리된 모델) | 기본값(Functions 호스트에 사용자 지정 로그 보내기): host.jsonApplication Insights에 직접 로그를 보내려면 HostBuilder의 Application Insights 구성을 참조하세요. |
| Node.JS | host.json |
| Python | host.json |
| Java | 기본값(Functions 호스트에 사용자 지정 로그 보내기): host.jsonApplication Insights에 직접 로그를 보내려면 Application Insights Java 에이전트 구성을 참조하세요. |
| PowerShell | host.json |
직접 보내도록 사용자 지정 애플리케이션 로그를 구성하면 호스트는 더 이상 로그를 내보내지 않으며 host.json은 더 이상 해당 동작을 제어하지 않습니다. 마찬가지로 각 스택에서 노출하는 옵션은 사용자 지정 로그에만 적용되며 이 문서에 설명된 다른 런타임 로그의 동작은 변경되지 않습니다. 이 경우 모든 로그의 동작을 제어하려면 두 구성을 모두 변경해야 할 수 있습니다.
범주 구성
Azure Functions 로거에는 모든 로그에 대한 범주가 포함되어 있습니다. 범주는 런타임 코드 또는 함수 코드의 어느 부분이 로그를 작성했는지를 나타냅니다. 버전 1.x과 이후 버전의 범주가 다릅니다.
범주 이름은 다른 .NET 프레임워크와 달리 Functions에서 다르게 할당됩니다. 예를 들어 ASP.NET에서 ILogger<T>를 사용하는 경우 범주는 제네릭 형식의 이름입니다. C# 함수도 ILogger<T>를 사용하지만 제네릭 형식 이름을 범주로 설정하는 대신 런타임은 원본에 따라 범주를 할당합니다. 예시:
- 함수 실행과 관련된 항목에는
Function.<FUNCTION_NAME>범주가 할당됩니다. logger.LogInformation()을 호출할 때와 같이 함수 내에서 사용자 코드로 만든 항목에는Function.<FUNCTION_NAME>.User범주가 할당됩니다.
다음 표에는 런타임에서 만드는 주요 로그 범주가 설명되어 있습니다.
| 범주 | 테이블 | 설명 |
|---|---|---|
Function |
traces | 모든 함수 실행에 대한 시작 함수 및 완료 로그를 포함합니다. 성공한 실행의 로그는 Information 수준에 있습니다. 예외는 Error 수준에서 로그됩니다. 런타임은 Warning 수준 로그도 만들며, 포이즌 큐로 큐 메시지가 전송되는 경우를 예로 들 수 있습니다. |
Function.<YOUR_FUNCTION_NAME> |
dependencies | 일부 서비스의 경우 종속성 데이터가 자동으로 수집됩니다. 성공한 실행의 로그는 Information 수준에 있습니다. 자세한 내용은 종속성을 참조하세요. 예외는 Error 수준에서 로그됩니다. 런타임은 Warning 수준 로그도 만들며, 포이즌 큐로 큐 메시지가 전송되는 경우를 예로 들 수 있습니다. |
Function.<YOUR_FUNCTION_NAME> |
customMetrics customEvents |
C# 및 JavaScript SDK를 사용하면 사용자 지정 메트릭을 수집하고 사용자 지정 이벤트를 로그할 수 있습니다. 자세한 내용은 사용자 지정 원격 분석 데이터를 참조하세요. |
Function.<YOUR_FUNCTION_NAME> |
traces | 특정 함수 실행의 함수 시작 및 완료 로그를 포함합니다. 성공한 실행의 로그는 Information 수준에 있습니다. 예외는 Error 수준에서 로그됩니다. 런타임은 Warning 수준 로그도 만들며, 포이즌 큐로 큐 메시지가 전송되는 경우를 예로 들 수 있습니다. |
Function.<YOUR_FUNCTION_NAME>.User |
traces | 사용자 생성 로그로서 어떤 로그 수준도 될 수 있습니다. 함수에서 로그에 쓰는 방법에 대한 자세한 내용은 로그에 쓰기를 참조하세요. |
Host.Aggregator |
customMetrics | 이러한 런타임 생성 로그는 구성 가능한 기간 동안의 함수 호출 수 및 평균을 제공합니다. 기본 기간은 30초 또는 결과 1,000개 중 먼저 도착하는 것입니다. 실행 수, 성공률 및 기간을 예로 들 수 있습니다. 이러한 로그는 모두 Information 수준에서 작성됩니다. Warning 이상에서 필터링하면 이 데이터가 표시되지 않습니다. |
Host.Results |
requests | 이러한 런타임 생성 로그는 함수의 성공 또는 실패를 나타냅니다. 이러한 로그는 모두 Information 수준에서 작성됩니다. Warning 이상에서 필터링하면 이 데이터가 표시되지 않습니다. |
Microsoft |
traces | 호스트에서 호출하는 .NET 런타임 구성 요소를 반영하는 정규화된 로그 범주입니다. |
Worker |
traces | .NET이 아닌 언어의 언어 작업자 프로세스에서 생성된 로그입니다. 언어 작업자 로그는 Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher와 같은 Microsoft.* 범주에도 기록될 수 있습니다. 이러한 로그는 Information 수준에서 작성됩니다. |
참고 항목
.NET 클래스 라이브러리 함수의 경우 이러한 범주는 사용자가 ILogger<T>가 아니라 ILogger를 사용한다고 가정합니다. 자세한 내용은 Functions ILogger 설명서를 참조하세요.
Table 열은 로그가 기록되는 Application Insights의 테이블을 나타냅니다.
로그 수준 구성
로그 수준은 모든 로그에 할당됩니다. 값은 상대적 중요도를 나타내는 정수입니다.
| LogLevel | 코드 | 설명 |
|---|---|---|
| Trace | 0 | 가장 자세한 메시지를 포함하는 로그입니다. 이러한 메시지에는 중요한 애플리케이션 데이터가 포함될 수 있습니다. 메시지는 기본적으로 사용하지 않도록 설정되며 프로덕션 환경에서 사용하면 안 됩니다. |
| 디버그 | 1 | 개발 중에 대화형 조사에 사용되는 로그입니다. 해당 로그는 기본적으로 디버깅에 유용한 정보를 포함하고 장기적인 값은 포함하지 않아야 합니다. |
| 정보 | 2 | 애플리케이션의 일반적인 흐름을 추적하는 로그입니다. 해당 로그는 장기적인 값을 포함해야 합니다. |
| 경고 | 3 | 애플리케이션 흐름에서 비정상적이거나 예기치 않은 이벤트를 강조 표시하지만, 그렇지 않으면 애플리케이션 실행을 중지하지 않는 로그입니다. |
| 오류 | 4 | 오류로 인해 현재 실행 흐름이 중지될 경우 이를 강조하는 로그입니다. 이러한 오류는 애플리케이션 전체의 오류가 아닌 현재 활동의 오류를 나타내야 합니다. |
| 위험 | 5 | 복구할 수 없는 애플리케이션 또는 시스템 크래시나 즉각적인 주의가 필요한 치명적인 오류를 설명하는 로그입니다. |
| 없음 | 6 | 지정된 범주에 대한 로깅을 사용하지 않도록 설정합니다. |
host.json 파일 구성은 함수 앱이 Application Insights에 보내는 로깅의 양을 결정합니다.
각 범주에 대해 보낼 최소 로그 수준을 나타낼 수 있습니다. host.json 설정은 Functions 런타임 버전에 따라 달라집니다.
다음 예제에서는 다음 규칙에 따라 로깅을 정의합니다.
- 기본 로깅 수준은 예기치 않은 범주에 대한 과도한 로깅을 방지하기 위해
Warning으로 설정됩니다. Host.Aggregator및Host.Results는 하위 수준으로 설정됩니다. 로깅 수준을 너무 높게 설정(특히Information보다 높음)하면 메트릭 및 성능 데이터가 손실될 수 있습니다.- 함수 실행에 대한 로깅은
Information으로 설정됩니다. 필요한 경우 로컬 개발에서 이 설정을Debug또는Trace로 재정의할 수 있습니다.
{
"logging": {
"fileLoggingMode": "debugOnly",
"logLevel": {
"default": "Warning",
"Host.Aggregator": "Trace",
"Host.Results": "Information",
"Function": "Information"
}
}
}
host.json에 동일한 문자열로 시작되는 여러 로그가 포함된 경우 더 자세히 정의된 로그가 먼저 일치됩니다. 런타임에 Host.Aggregator를 제외하고 모든 것을 Error 수준에서 로그하는 다음 예제를 생각해 보세요.
{
"logging": {
"fileLoggingMode": "debugOnly",
"logLevel": {
"default": "Information",
"Host": "Error",
"Function": "Error",
"Host.Aggregator": "Information"
}
}
}
None 로그 수준 설정을 사용하면 어떤 로그도 범주에 기록되지 않도록 할 수 있습니다.
주의
Azure Functions는 Application Insights 테이블에 원격 분석 이벤트를 저장하여 Application Insights와 통합됩니다. 범주 로그 수준을 Information이 아닌 값으로 설정하면 원격 분석이 해당 테이블로 흐르는 것을 방지하고 Application Insights 및 함수 모니터 탭에서 관련 데이터를 볼 수 없습니다.
예를 들어 이전 샘플의 경우:
Host.Results범주를Error로그 수준으로 설정한 경우 Azure에서는 실패한 함수 실행에 대한requests테이블의 호스트 실행 원격 분석 이벤트만 수집하므로 Application Insights 및 Function Monitor 탭 모두에서 성공한 실행에 대한 호스트 실행 세부 정보가 표시되지 않습니다.Function범주를Error로그 수준으로 설정하면 모든 함수에 대해dependencies,customMetrics및customEvents와 관련된 함수 원격 분석 데이터 수집이 중지되어 Application Insights에서 이 데이터를 볼 수 없습니다. Azure에서는Error수준에서 기록된traces만 수집합니다.
두 경우 모두 Azure는 Application Insights 및 함수 모니터 탭에서 오류 및 예외 데이터를 계속 수집합니다. 자세한 내용은 대량의 원격 분석이 포함된 솔루션을 참조하세요.
수집기 구성
이전 섹션에서 언급했듯이, 런타임은 일정 기간 동안 함수 실행에 대한 데이터를 집계합니다. 기본 기간은 30초 또는 실행 1,000개 중 먼저 도착하는 것입니다. host.json 파일에서 이 설정을 구성할 수 있습니다. 예시:
{
"aggregator": {
"batchSize": 1000,
"flushTimeout": "00:00:30"
}
}
샘플링 구성
Application Insights에는 최대 부하 시 실행이 완료될 때 원격 분석 데이터를 너무 많이 생성하지 않도록 방지하는 샘플링 기능이 포함되어 있습니다. 들어오는 실행 비율이 지정된 임계값을 초과하면 Application Insights는 들어오는 항목 중 일부를 임의로 무시하기 시작합니다. 초당 최대 실행 수의 기본 설정은 20입니다(1.x 버전은 5). host.json에서 샘플링을 구성할 수 있습니다. 예를 들면 다음과 같습니다.
{
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"maxTelemetryItemsPerSecond" : 20,
"excludedTypes": "Request;Exception"
}
}
}
}
샘플링에서 특정 유형의 원격 분석을 제외할 수 있습니다. 이 예제에서 Request 및 Exception 형식의 데이터는 샘플링에서 제외됩니다. 이렇게 하면 모든 함수 실행(요청)과 예외를 로그하면서 다른 형식의 원격 분석은 여전히 샘플링되도록 할 수 있습니다.
프로젝트가 Application Insights SDK에 대한 종속성을 사용하여 수동 원격 분석 추적을 수행하는 경우 샘플링 구성이 함수 앱의 샘플링 구성과 다르면 비정상적인 동작이 발생할 수 있습니다. 이러한 경우 함수 앱과 동일한 샘플링 구성을 사용합니다. 자세한 내용은 Application Insights의 샘플링을 참조하세요.
SQL 쿼리 컬렉션 사용
Application Insights는 HTTP 요청, 데이터베이스 호출 및 여러 바인딩에 대한 종속성에 대한 데이터를 자동으로 수집합니다. 자세한 내용은 종속성을 참조하세요. SQL 호출의 경우 서버 및 데이터베이스의 이름은 항상 수집 및 저장되지만 SQL 쿼리 텍스트는 기본적으로 수집되지 않습니다. dependencyTrackingOptions.enableSqlCommandTextInstrumentation을 사용하여 host.json 파일에서 다음 설정(최소한)을 사용하여 SQL 쿼리 텍스트 로깅을 사용하도록 설정할 수 있습니다.
"logging": {
"applicationInsights": {
"enableDependencyTracking": true,
"dependencyTrackingOptions": {
"enableSqlCommandTextInstrumentation": true
}
}
}
자세한 내용은 전체 SQL 쿼리를 가져오기 위한 고급 SQL 추적을 참조하세요.
스케일링 컨트롤러 로그 구성
이 기능은 미리 보기 상태입니다.
Azure Functions 스케일링 컨트롤러가 로그를 Application Insights 또는 Blob 스토리지로 내보내도록 하면 스케일링 컨트롤러가 함수 앱을 위해 내리는 결정을 더 잘 이해할 수 있습니다.
이 기능을 사용하도록 설정하려면 SCALE_CONTROLLER_LOGGING_ENABLED라는 애플리케이션 설정을 함수 앱 설정에 추가합니다. 다음 설정 값은 <DESTINATION>:<VERBOSITY> 형식이어야 합니다. 자세한 내용은 다음 표를 참조하세요.
| 속성 | 설명 |
|---|---|
<DESTINATION> |
로그가 전송되는 대상입니다. 유효한 값은 AppInsights 및 Blob입니다.AppInsights를 사용할 때 함수 앱에서 Application Insights가 사용하도록 설정되어 있는지 확인합니다.대상을 Blob로 설정하면 AzureWebJobsStorage 애플리케이션 설정에 설정된 기본 스토리지 계정에서 azure-functions-scale-controller라는 Blob 컨테이너에 로그가 생성됩니다. |
<VERBOSITY> |
로깅 수준을 지정합니다. 지원되는 값은 None, Warning 및 Verbose입니다.Verbose로 설정되면 크기 조정 컨트롤러는 모든 작업자 수 변경의 이유 및 해당 결정을 촉발한 트리거에 대한 정보를 기록합니다. 자세한 로그에는 크기 조정 컨트롤러를 실행하기 전후에 트리거에서 사용한 트리거 경고 및 해시가 포함됩니다. |
팁
크기 조정 컨트롤러 로깅을 사용하면 함수 앱 모니터링 비용에 영향을 줍니다. 크기 조정 컨트롤러의 동작을 이해하는 데 충분한 데이터를 수집할 때까지는 로깅을 사용하는 것이 좋습니다.
예를 들어 다음 Azure CLI 명령은 스케일링 컨트롤러에서 Application Insights로 자세한 정보 로깅을 설정합니다.
az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:Verbose
이 예제에서 <FUNCTION_APP_NAME> 및 <RESOURCE_GROUP_NAME>을 각각 함수 앱의 이름과 리소스 그룹의 이름으로 바꿉니다.
다음 Azure CLI 명령은 자세한 정도를 None으로 설정하여 로깅을 사용하지 않도록 설정합니다.
az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:None
다음 Azure CLI 명령으로 SCALE_CONTROLLER_LOGGING_ENABLED 설정을 제거하여 로깅을 사용하지 않도록 설정할 수도 있습니다.
az functionapp config appsettings delete --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--setting-names SCALE_CONTROLLER_LOGGING_ENABLED
스케일링 컨트롤러 로깅을 사용하도록 설정하면 스케일링 컨트롤러 로그를 쿼리할 수 있습니다.
Application Insights 통합 사용
함수 앱이 Application Insights에 데이터를 보내려면 다음 애플리케이션 설정 중 하나만 사용하여 Application Insights 리소스에 연결해야 합니다.
| 설정 이름 | 설명 |
|---|---|
APPLICATIONINSIGHTS_CONNECTION_STRING |
이 설정은 권장되며 Application Insights 인스턴스가 소버린 클라우드에서 실행되는 경우에 필요합니다. 연결 문자열은 다른 새 기능을 지원합니다. |
APPINSIGHTS_INSTRUMENTATIONKEY |
연결 문자열 설정을 위해 Application Insights에서 더 이상 사용되지 않는 레거시 설정입니다. |
Azure Portal의 명령줄에서 Azure Functions Core Tools 또는 Visual Studio Code를 사용하여 함수 앱을 만들 때 Application Insights 통합이 기본적으로 사용하도록 설정됩니다. Application Insights 리소스는 함수 앱과 동일한 이름을 가지며, 동일한 지역 또는 가장 가까운 지역에 생성됩니다.
Microsoft Entra 인증 필요
APPLICATIONINSIGHTS_AUTHENTICATION_STRING 설정을 사용하여 Microsoft Entra 인증을 사용하여 Application Insights에 연결할 수 있습니다. 이를 통해 프로파일러 및 스냅샷 디버거를 비롯한 모든 Application Insights 파이프라인과 Functions 호스트 및 언어별 에이전트에서 일관된 인증 환경이 만들어집니다.
참고 항목
로컬 개발에 대한 Entra 인증 지원은 없습니다.
이 값에는 시스템이 할당한 관리 ID에 대한 Authorization=AAD 또는 사용자가 할당한 관리 ID에 대한 ClientId=<YOUR_CLIENT_ID>;Authorization=AAD가 포함됩니다. 관리 ID를 함수 앱에서 이미 사용할 수 있어야 하며, 모니터링 메트릭 게시자에 해당하는 할당된 역할이 있어야 합니다. 자세한 내용은 Application Insights에 대한 Microsoft Entra 인증을 참조하세요.
APPLICATIONINSIGHTS_CONNECTION_STRING 설정은 여전히 필요합니다.
참고 항목
Microsoft Entra 인증을 사용하여 Application Insights에 연결하기 위해 APPLICATIONINSIGHTS_AUTHENTICATION_STRING을 사용하는 경우 Application Insights에 대한 로컬 인증을 사용하지 않도록 설정해야 합니다. 이 구성에서는 원격 분석을 작업 영역에 수집하려면 Microsoft Entra 인증이 필요합니다.
포털의 새 함수 앱
생성되는 Application Insights 리소스를 검토하려면 해당 리소스를 선택하여 Application Insights 창을 확장합니다. 새 리소스 이름을 변경하거나 데이터를 저장하려는 Azure 지리적 위치에서 다른 위치를 선택합니다.
만들기를 선택하면 함수 앱을 사용하여 Application Insights 리소스가 생성되고, 이 리소스는 애플리케이션 설정에서 APPLICATIONINSIGHTS_CONNECTION_STRING로 설정됩니다. 모든 준비가 끝났습니다.
기존 함수 앱에 추가
함수 앱을 사용하여 Application Insights 리소스를 만들지 않은 경우 다음 단계를 사용하여 리소스를 만듭니다. 그런 다음, 해당 리소스의 연결 문자열을 함수 앱의 애플리케이션 설정으로 추가할 수 있습니다.
Azure Portal에서 함수 앱을 검색하여 선택한 다음 함수 앱을 선택합니다.
창 상단에 있는 Application Insights가 구성되지 않음 배너를 선택합니다. 이 배너가 표시되지 않으면 앱이 이미 Application Insights를 사용하도록 설정되어 있을 수 있습니다.
리소스 변경을 펼치고 다음 표에 지정된 설정을 사용하여 Application Insights 리소스를 만듭니다.
설정 제안 값 설명 새 리소스 이름 고유한 앱 이름 함수 앱과 동일한 이름을 사용하는 것이 가장 간단하며, 구독 내에서 고유해야 합니다. 위치 서유럽 가능하다면 함수 앱과 동일한 지역을 사용하거나 해당 지역에 근접한 지역을 사용합니다. 
적용을 선택합니다.
함수 앱과 동일한 리소스 그룹 및 구독에 Application Insights 리소스가 만들어집니다. 리소스를 만든 후 Application Insights 창을 닫습니다.
함수 앱에서 설정을 확장한 다음 환경 변수를 선택합니다. 앱 설정 탭에서
APPLICATIONINSIGHTS_CONNECTION_STRING이라는 앱 설정이 표시되면 Azure에서 실행되는 함수 앱에 Application Insights 통합이 활성화됩니다. 이 설정이 존재하지 않는 경우 Application Insights 연결 문자열을 값으로 사용하여 추가합니다.
참고 항목
이전 함수 앱은 APPLICATIONINSIGHTS_CONNECTION_STRING 대신 APPINSIGHTS_INSTRUMENTATIONKEY를 사용할 수 있습니다. 가능하면 계측 키 대신 연결 문자열을 사용하도록 앱을 업데이트합니다.
기본 제공 로깅을 사용하지 않도록 설정
Functions 초기 버전에서는 기본 제공 모니터링을 사용했지만, 더 이상 권장하지 않습니다. Application Insight를 사용하도록 설정하는 경우 Azure Storage를 사용하는 기본 제공 로깅을 사용하지 않도록 설정하세요. 기본 제공 로깅은 가벼운 워크로드를 테스트할 때 유용하지만, 부하가 높은 프로덕션 용도로는 적합하지 않습니다. 프로덕션 모니터링에는 Application Insights를 사용하는 것이 좋습니다. 프로덕션에 기본 제공 로깅을 사용하면 Azure Storage의 제한으로 인해 로깅 레코드가 불완전할 수 있습니다.
기본 제공 로깅을 사용하지 않도록 설정하려면 AzureWebJobsDashboard 앱 설정을 삭제합니다. Azure Portal에서 앱 설정을 삭제하는 방법에 대한 자세한 내용은 함수 앱을 관리하는 방법의 애플리케이션 설정 섹션을 참조하세요. 앱 설정을 삭제하기 전에 동일한 함수 앱의 기존 함수가 Azure Storage 트리거 또는 바인딩에 대한 설정을 사용하지 않는지 확인합니다.
대량의 원격 분석이 포함된 솔루션
함수 앱은 IoT 솔루션, 신속한 이벤트 기반 솔루션, 높은 부하의 금융 시스템 및 통합 시스템과 같이 대량의 원격 분석을 유발할 수 있는 솔루션의 필수 부분입니다. 이 경우 관찰 가능성을 유지하면서 비용을 줄이기 위해 추가 구성을 고려해야 합니다.
생성된 원격 분석은 실시간 대시보드, 경고, 세부 진단 등에 사용할 수 있습니다. 생성된 원격 분석이 사용되는 방식에 따라 생성된 데이터의 양을 줄이기 위한 전략을 정의해야 합니다. 이 전략을 통해 프로덕션 환경에서 함수 앱을 적절하게 모니터링, 운영 및 진단할 수 있습니다. 다음 옵션을 살펴보세요.
샘플링 사용: 이전에 언급했듯이 샘플링은 통계적으로 정확한 분석을 유지하면서 수집된 원격 분석 이벤트의 양을 크게 줄이는 데 도움이 됩니다. 샘플링을 사용하더라도 여전히 원격 분석의 양이 많을 수 있습니다. 적응 샘플링이 제공하는 옵션을 검사합니다. 예를 들어
maxTelemetryItemsPerSecond를 모니터링 요구 사항과 생성된 볼륨의 균형을 맞추는 값으로 설정합니다. 원격 분석 샘플링은 함수 앱을 실행하는 호스트별로 적용됩니다.기본 로그 수준:
Warning또는Error를 모든 원격 분석 범주에 대한 기본값으로 사용합니다. 나중에Information수준에서 설정하려는 범주를 결정할 수 있으므로 함수를 적절하게 모니터링하고 진단할 수 있습니다.함수 원격 분석 튜닝: 기본 로그 수준이
Error또는Warning으로 설정된 경우 각 함수의 자세한 정보(종속성, 사용자 지정 메트릭, 사용자 지정 이벤트 및 추적)는 수집되지 않습니다. 프로덕션 모니터링의 핵심 함수의 경우Function.<YOUR_FUNCTION_NAME>범주에 대한 명시적 항목을 정의하고Information으로 설정하여 자세한 정보를 수집할 수 있습니다. 사용자 생성 로그가Information수준에서 수집되지 않도록 하려면Function.<YOUR_FUNCTION_NAME>.User범주를Error또는Warning로그 수준으로 설정합니다.Host.Aggregator 범주: 범주 구성에 설명된 대로 이 범주는 함수 호출에 대한 집계 정보를 제공합니다. 이 범주의 정보는 Application Insights
customMetrics테이블에 수집되며 Azure Portal의 기능 개요 탭에 표시됩니다. 수집기를 구성하는 방법에 따라 수집된 원격 분석에서flushTimeout설정으로 결정되는 지연이 있을 수 있습니다. 이 범주를Information이 아닌 값으로 설정하면customMetrics테이블의 데이터 수집이 중지되고 함수 개요 탭에 메트릭이 표시되지 않습니다.다음 스크린샷은 개요 함수 탭에 표시된
Host.Aggregator원격 분석 데이터를 보여 줍니다.
다음 스크린샷은 Application Insights
customMetrics테이블의Host.Aggregator원격 분석 데이터를 보여 줍니다.
Host.Results 범주: 범주 구성에 설명된 대로 이 범주는 함수 호출의 성공 또는 실패를 나타내는 런타임 생성 로그를 제공합니다. 이 범주의 정보는 Application Insights
requests테이블에 수집되며 모니터 함수 탭과 다양한 Application Insights 대시보드(성능, 실패 등)에 표시됩니다. 이 범주를Information이 아닌 값으로 설정하면 정의된(또는 그 이상) 로그 수준에서 생성된 원격 분석만 수집합니다. 예를 들어,error로 설정하면 실패한 실행에 대한 요청 데이터만 추적하게 됩니다.다음 스크린샷은 함수 모니터 탭에 표시된
Host.Results원격 분석 데이터를 보여 줍니다.
다음 스크린샷은 Application Insights 성능 대시보드에 표시된
Host.Results원격 분석 데이터를 보여 줍니다.
Host.Aggregator 및 Host.Results: 두 범주 모두 함수 실행에 대한 유용한 정보를 제공합니다. 필요한 경우 이러한 범주 중 하나에서 세부 정보를 제거하여 다른 범주를 모니터링 및 경고에 사용할 수 있습니다. 다음은 샘플입니다.
{
"version": "2.0",
"logging": {
"logLevel": {
"default": "Warning",
"Function": "Error",
"Host.Aggregator": "Error",
"Host.Results": "Information",
"Function.Function1": "Information",
"Function.Function1.User": "Error"
},
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"maxTelemetryItemsPerSecond": 1,
"excludedTypes": "Exception"
}
}
}
}
이 구성을 사용하면:
모든 함수 및 원격 분석 범주의 기본값은
Warning(Microsoft 및 작업자 범주 포함)로 설정됩니다. 따라서 기본적으로 런타임 및 사용자 지정 로깅에 의해 생성된 모든 오류 및 경고가 수집됩니다.Function범주 로그 수준이Error로 설정되므로 모든 함수에 대해 기본적으로 예외 및 오류 로그만 수집됩니다. 종속성, 사용자 생성 메트릭 및 사용자 생성 이벤트를 건너뜁니다.Host.Aggregator범주의 경우Error로그 수준으로 설정되어 있으므로 함수 호출에서 집계된 정보는customMetricsApplication Insights 테이블에 수집되지 않으며 실행 횟수(총, 성공 및 실패)에 대한 정보는 함수 개요 대시보드에 표시되지 않습니다.Host.Results범주의 경우 모든 호스트 실행 정보가requestsApplication Insights 테이블에 수집됩니다. 모든 호출 결과는 함수 모니터 대시보드 및 Application Insights 대시보드에 표시됩니다.Function1이라는 함수의 경우 로그 수준을Information으로 설정합니다. 따라서 이 구체적인 함수를 위해 모든 원격 분석(종속성, 사용자 지정 메트릭 및 사용자 지정 이벤트)이 수집됩니다. 동일한 함수의 경우Function1.User범주(사용자 생성 추적)를Error로 설정하므로 사용자 정의 오류 로깅만 수집됩니다.참고 항목
함수 런타임의 v1.x에서는 함수당 구성이 지원되지 않습니다.
샘플링은 예외를 제외하고 유형별로 초당 하나의 원격 분석 항목을 보내도록 구성됩니다. 이 샘플링은 함수 앱을 실행하는 각 서버 호스트에 대해 발생합니다. 따라서 4개의 인스턴스가 있는 경우 이 구성은 형식별로 초당 4개의 원격 분석 항목과 발생할 수 있는 모든 예외를 내보냅니다.
참고 항목
요청 빈도 및 예외 처리 빈도와 같은 메트릭 수는 샘플링 주기에 맞게 보정되도록 조정되므로 메트릭 탐색기에서 거의 정확한 값으로 표시됩니다.
팁
다양한 구성을 실험하여 로깅, 모니터링 및 경고에 대한 요구 사항을 충족하는지 확인합니다. 또한 예기치 못한 오류나 오작동이 발생한 경우에 대해 자세히 진단해야 합니다.
런타임 시 모니터링 구성 재정의
마지막으로 프로덕션에서 특정 범주의 로깅 동작을 신속하게 변경해야 하고 host.json 파일의 변경만을 위해 전체 배포를 수행하고 싶지 않은 경우가 있을 수 있습니다. 이러한 경우 host.json 값을 재정의할 수 있습니다.
앱 설정 수준에서 이러한 값을 구성하고 host.json 변경 시 다시 배포하지 않도록 하려면 애플리케이션 설정과 동일한 값을 생성하여 특정 host.json 값을 재정의해야 합니다. 런타임에서 AzureFunctionsJobHost__path__to__setting 형식의 애플리케이션 설정을 찾으면 JSON의 path.to.setting에 있는 동등한 host.json 설정을 재정의합니다. 애플리케이션 설정으로 표현되는 경우 이중 밑줄(__)은 JSON 계층을 나타내는 데 사용되는 점(.)으로 대체됩니다. 예를 들어 다음 앱 설정을 사용하여 위의 host.json에서 개별 함수 로그 수준을 구성할 수 있습니다.
| Host.json 경로 | 앱 설정 |
|---|---|
| logging.logLevel.default | AzureFunctionsJobHost__logging__logLevel__default |
| logging.logLevel.Host.Aggregator | AzureFunctionsJobHost__logging__logLevel__Host.Aggregator |
| logging.logLevel.Function | AzureFunctionsJobHost__logging__logLevel__Function |
| logging.logLevel.Function.Function1 | AzureFunctionsJobHost__logging__logLevel__Function.Function1 |
| logging.logLevel.Function.Function1.User | AzureFunctionsJobHost__logging__logLevel__Function.Function1.User |
Azure Portal 함수 앱 구성 창에서 직접 또는 Azure CLI 또는 PowerShell 스크립트를 사용하여 설정을 재정의할 수 있습니다.
az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host.Aggregator=Information"
참고 항목
앱 설정을 변경하여 host.json을 재정의하면 함수 앱이 다시 시작됩니다.
기간을 포함하는 앱 설정은 Elastic Premium 계획 또는 전용(App Service) 계획의 Linux에서 실행할 때 지원되지 않습니다. 이러한 호스팅 환경에서는 host.json 파일을 계속 사용해야 합니다.
상태 검사를 사용하여 함수 앱 모니터링
상태 검사 기능을 사용하여 프리미엄(Elastic Premium) 및 전용(App Service) 계획에서 함수 앱을 모니터링할 수 있습니다. 상태 검사는 사용 계획에 대한 옵션이 아닙니다. 구성하는 방법을 알아보려면 상태 검사를 사용하여 App Service 인스턴스 모니터링을 참조하세요. 함수 앱에는 상태 검사의 Path 매개 변수에 구성된 것과 동일한 엔드포인트에서 HTTP 상태 코드 200으로 응답하는 HTTP 트리거 함수가 있어야 합니다. 또한 해당 함수가 추가 검사를 수행하여 종속 서비스에 연결하고 작동하도록 할 수 있습니다.
관련 콘텐츠
모니터링에 대한 자세한 내용은 다음을 참조하세요.