Como configurar o monitoramento para o Azure Functions

As Funções do Azure podem ser integradas no Application Insights para lhe permitir monitorizar melhor as suas aplicações de funções. O Application Insights, um recurso do Azure Monitor, é um serviço extensível de Gerenciamento de Desempenho de Aplicativo (APM) que coleta dados gerados pelo seu aplicativo de função, incluindo informações que seu aplicativo grava em logs. A integração do Application Insights normalmente é habilitada quando seu aplicativo de função é criado. Se seu aplicativo não tiver a chave de instrumentação definida, você deve primeiro habilitar a integração do Application Insights.

Pode utilizar o Application Insights sem qualquer configuração personalizada. A configuração padrão pode resultar em grandes volumes de dados. Se você estiver usando uma assinatura do Visual Studio Azure, poderá atingir seu limite de dados para o Application Insights. Para obter informações sobre os custos do Application Insights, consulte Faturamento do Application Insights. Para obter mais informações, consulte Soluções com alto volume de telemetria.

Mais adiante neste artigo, você aprenderá a configurar e personalizar os dados que suas funções enviam para o Application Insights. A configuração de log comum pode ser definida no arquivo host.json. Por padrão, essas configurações também controlam os logs personalizados emitidos pelo seu código, embora em alguns casos esse comportamento possa ser desativado em favor de opções que lhe dão mais controle sobre o registro. Consulte Logs de aplicativos personalizados para obter mais informações.

Nota

Você pode usar configurações de aplicativo especialmente configuradas para representar configurações específicas em um arquivo de host.json para um ambiente específico. Isso permite que você altere efetivamente as configurações de host.json sem ter que publicar novamente o arquivo host.json em seu projeto. Para obter mais informações, veja Substituir valores host.json.

Logs de aplicativos personalizados

Por padrão, os logs de aplicativos personalizados que você escreve são enviados para o host do Functions, que os envia para o Application Insights por meio da categoria "Trabalhador". Algumas pilhas de idiomas permitem que você envie os logs diretamente para o Application Insights, dando a você controle total sobre como os logs que você escreve são emitidos. O pipeline de registro em log muda de worker -> Functions host -> Application Insights para worker -> Application Insights.

A tabela a seguir resume as opções disponíveis para cada pilha:

Pilha de idiomas	Configuração de logs personalizados
.NET (modelo em processo)	host.json
.NET (modelo isolado)	Por padrão: host.json Opção para enviar logs diretamente: Configurar o Application Insights no HostBuilder
Node.JS	host.json
Python	host.json
Java	Por padrão: host.json Opção para enviar logs diretamente: Configurar o agente Java do Application Insights
PowerShell	host.json

Quando os logs de aplicativos personalizados são enviados diretamente, o host não os emite mais e não controla mais host.json seu comportamento. Da mesma forma, as opções expostas por cada pilha só se aplicam a logs personalizados e não alteram o comportamento dos outros logs de tempo de execução descritos neste artigo. Para controlar o comportamento de todos os logs, talvez seja necessário fazer alterações em ambas as configurações.

Configurar categorias

O registador do Azure Functions inclui uma categoria para cada registo. A categoria indica que parte do código do runtime ou do código de função escreveu o registo. As categorias diferem entre a versão 1.x e versões posteriores.

Os nomes de categoria são atribuídos de forma diferente no Functions em comparação com outros frameworks .NET. Por exemplo, quando você usa ILogger<T> no ASP.NET, a categoria é o nome do tipo genérico. As funções C# também usam ILogger<T>, mas em vez de definir o nome do tipo genérico como uma categoria, o tempo de execução atribui categorias com base na fonte. Por exemplo:

• Às entradas relacionadas com a execução de uma função é atribuída uma categoria de Function.<FUNCTION_NAME>.
• As entradas criadas pelo código do usuário dentro da função, como ao chamar logger.LogInformation(), recebem uma categoria de Function.<FUNCTION_NAME>.User.

O gráfico a seguir descreve as principais categorias de logs que o tempo de execução cria:

v2.x+

Category	Table	Description
Function	vestígios	Inclui logs de função iniciada e concluída para todas as execuções de função. Para execuções bem-sucedidas, esses logs estão no Information nível. As exceções são registradas no Error nível. O tempo de execução também cria Warning logs de nível, como quando mensagens de fila são enviadas para a fila suspeita.
Function.<YOUR_FUNCTION_NAME>	dependências	Os dados de dependência são coletados automaticamente para alguns serviços. Para execuções bem-sucedidas, esses logs estão no Information nível. Para obter mais informações, veja Dependências. As exceções são registradas no Error nível. O tempo de execução também cria Warning logs de nível, como quando mensagens de fila são enviadas para a fila suspeita.
Function.<YOUR_FUNCTION_NAME>	customMetrics customEvents	Os SDKs de C# e JavaScript permitem coletar métricas personalizadas e registrar eventos personalizados. Para obter mais informações, consulte Dados de telemetria personalizados.
Function.<YOUR_FUNCTION_NAME>	vestígios	Inclui logs de função iniciada e concluída para execuções de funções específicas. Para execuções bem-sucedidas, esses logs estão no Information nível. As exceções são registradas no Error nível. O tempo de execução também cria Warning logs de nível, como quando mensagens de fila são enviadas para a fila suspeita.
Function.<YOUR_FUNCTION_NAME>.User	vestígios	Logs gerados pelo usuário, que podem ser de qualquer nível de log. Para obter mais informações sobre como gravar em logs de suas funções, consulte Gravando em logs.
Host.Aggregator	customMetrics	Esses logs gerados em tempo de execução fornecem contagens e médias de invocações de função durante um período de tempo configurável . O período padrão é de 30 segundos ou 1.000 resultados, o que ocorrer primeiro. Exemplos são o número de execuções, a taxa de sucesso e a duração. Todos esses logs são gravados no Information nível. Se você filtrar em Warning ou acima, não verá nenhum desses dados.
Host.Results	pedidos	Esses logs gerados em tempo de execução indicam o sucesso ou falha de uma função. Todos esses logs são gravados no Information nível. Se você filtrar em Warning ou acima, não verá nenhum desses dados.
Microsoft	vestígios	Categoria de log totalmente qualificada que reflete um componente de tempo de execução do .NET invocado pelo host.
Worker	vestígios	Logs gerados pelo processo de trabalho linguístico para non-.NET idiomas. Os logs de trabalhador de idioma também podem ser registrados em uma Microsoft.* categoria, como Microsoft.Azure.WebJobs.Script.Workers.Rpc.RpcFunctionInvocationDispatcher. Esses logs são gravados no Information nível.

Nota

Para funções de biblioteca de classes .NET, essas categorias pressupõem que você está usando ILogger e não ILogger<T>. Para obter mais informações, consulte a documentação do ILogger de funções.

v1.x

Category	Table	Description
Function	vestígios	Logs gerados pelo usuário, que podem ser de qualquer nível de log. Para obter mais informações sobre como gravar em logs de suas funções, consulte Gravando em logs.
Host.Aggregator	customMetrics	Esses logs gerados em tempo de execução fornecem contagens e médias de invocações de função durante um período de tempo configurável . O período padrão é de 30 segundos ou 1.000 resultados, o que ocorrer primeiro. Exemplos são o número de execuções, a taxa de sucesso e a duração. Todos esses logs são gravados no Information nível. Se você filtrar em Warning ou acima, não verá nenhum desses dados.
Host.Executor	vestígios	Inclui logs de Função iniciada e Função concluída para execuções de funções específicas. Para execuções bem-sucedidas, esses logs são Information nivelados. As exceções são registradas no Error nível. O tempo de execução também cria Warning logs de nível, como quando mensagens de fila são enviadas para a fila suspeita.
Host.Results	pedidos	Esses logs gerados em tempo de execução indicam o sucesso ou falha de uma função. Todos esses logs são gravados no Information nível. Se você filtrar em Warning ou acima, não verá nenhum desses dados.

A coluna Tabela indica em qual tabela do Application Insights o log está gravado.

Configurar níveis de log

Um nível de log é atribuído a cada log. O valor é um inteiro que indica importância relativa:

Nível de Registo	Código	Description
Rastreio	0	Logs que contêm as mensagens mais detalhadas. Essas mensagens podem conter dados confidenciais do aplicativo. Essas mensagens são desabilitadas por padrão e nunca devem ser habilitadas em um ambiente de produção.
Depurar	5	Logs que são usados para investigação interativa durante o desenvolvimento. Esses logs devem conter principalmente informações úteis para depuração e não têm valor a longo prazo.
Informação	2	Logs que controlam o fluxo geral do aplicativo. Esses logs devem ter valor a longo prazo.
Aviso	3	Logs que destacam um evento anormal ou inesperado no fluxo do aplicativo, mas não fazem com que a execução do aplicativo seja interrompida.
Error	4	Logs que destacam quando o fluxo atual de execução é interrompido devido a uma falha. Esses erros devem indicar uma falha na atividade atual, não uma falha em todo o aplicativo.
Crítico	5	Logs que descrevem uma falha irrecuperável do aplicativo ou do sistema, ou uma falha catastrófica que requer atenção imediata.
None	6	Desabilita o registro em log para a categoria especificada.

A configuração do arquivo host.json determina a quantidade de registro em log que um aplicativo de funções envia para o Application Insights.

Para cada categoria, você indica o nível mínimo de log a ser enviado. As configurações de host.json variam dependendo da versão de tempo de execução do Functions.

Os exemplos abaixo definem o registro em log com base nas seguintes regras:

• O nível de log padrão é definido para evitar log excessivo para Warning categorias imprevistas.
• Host.Aggregator e Host.Results são definidos para níveis mais baixos. Defini-los para um nível muito alto (especialmente superior a Information) pode resultar na perda de métricas e dados de desempenho.
• O registro em log para execuções de função é definido como Information. Isso pode ser superado no desenvolvimento local para Debug ou Trace, quando necessário.

v2.x+

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Warning",
      "Host.Aggregator": "Trace",
      "Host.Results": "Information",
      "Function": "Information"
    }
  }
}

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Host.Results": "Information",
        "Host.Aggregator": "Trace",
        "Function": "Information"
      }
    }
  }
}

Se host.json incluir vários logs que começam com a mesma cadeia de caracteres, os logs mais definidos serão correspondidos primeiro. Considere o exemplo a seguir que registra tudo no tempo de execução, exceto Host.Aggregator, no Error nível:

v2.x+

{
  "logging": {
    "fileLoggingMode": "debugOnly",
    "logLevel": {
      "default": "Information",
      "Host": "Error",
      "Function": "Error",
      "Host.Aggregator": "Information"
    }
  }
}

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Information",
      "categoryLevels": {
        "Host": "Error",
        "Function": "Error",
        "Host.Aggregator": "Information"
      }
    }
  }
}

Você pode usar uma configuração de nível de log de None para impedir que quaisquer logs sejam gravados para uma categoria.

Atenção

O Azure Functions integra-se ao Application Insights armazenando eventos de telemetria em tabelas do Application Insights. Definir um nível de log de categoria para qualquer valor diferente de Information impedirá que a telemetria flua para essas tabelas. Como resultado, você não poderá ver os dados relacionados na guia Application Insights ou Monitor de Função .

Das amostras acima:

• Se a categoria estiver definida como Error nível de log, ela reunirá apenas eventos de telemetria de execução do requests host na tabela para execuções de função com falha, impedindo a Host.Results exibição de detalhes de execução de host de execuções bem-sucedidas na guia Application Insights e Monitor de Função.
• Se a categoria estiver definida como Error nível de log, ela interromperá a coleta de dados de telemetria de função relacionados a dependencies, e customEvents para todas as funções, customMetricsimpedindo a Function visualização de qualquer um desses dados no Application Insights. Ele só vai reunir traces registrado com Error nível.

Em ambos os casos, você continuará a coletar dados de erros e exceções na guia Application Insights and Function Monitor . Para obter mais informações, consulte Soluções com alto volume de telemetria.

Configurar o agregador

Como observado na seção anterior, o tempo de execução agrega dados sobre execuções de função durante um período de tempo. O período padrão é de 30 segundos ou 1.000 execuções, o que ocorrer primeiro. Você pode definir essa configuração no arquivo host.json. Eis um exemplo:

{
    "aggregator": {
      "batchSize": 1000,
      "flushTimeout": "00:00:30"
    }
}

Configurar amostragem

O Application Insights tem um recurso de amostragem que pode protegê-lo contra a produção de muitos dados de telemetria em execuções concluídas em momentos de pico de carga. Quando a taxa de execuções recebidas excede um limiar especificado, o Application Insights começa a ignorar aleatoriamente algumas das execuções recebidas. A predefinição do número máximo de execuções por segundo é de 20 (cinco na versão 1.x). Você pode configurar a amostragem no host.json. Eis um exemplo:

v2.x+

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond" : 20,
        "excludedTypes": "Request;Exception"
      }
    }
  }
}

Você pode excluir certos tipos de telemetria da amostragem. Neste exemplo, os dados do tipo Request e Exception são excluídos da amostragem. Ele garantirá que todas as execuções de função (solicitações) e exceções sejam registradas, enquanto outros tipos de telemetria permanecem sujeitos à amostragem.

v1.x

{
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

Se seu projeto depender do SDK do Application Insights para fazer o rastreamento manual de telemetria, você poderá ter um comportamento estranho se sua configuração de amostragem for diferente da configuração de amostragem em seu aplicativo de função. Nesses casos, use a mesma configuração de amostragem que o aplicativo de função. Para obter mais informações, consulte Amostragem no Application Insights.

Habilitar a coleta de consultas SQL

O Application Insights coleta automaticamente dados sobre dependências para solicitações HTTP, chamadas de banco de dados e para várias associações. Para obter mais informações, veja Dependências. Para chamadas SQL, o nome do servidor e do banco de dados é sempre coletado e armazenado, mas o texto da consulta SQL não é coletado por padrão. Você pode usar dependencyTrackingOptions.enableSqlCommandTextInstrumentation para habilitar o log de texto de consulta SQL definindo (no mínimo) o seguinte em seu arquivo host.json:

"logging": {
    "applicationInsights": {
        "enableDependencyTracking": true,    
        "dependencyTrackingOptions": {
            "enableSqlCommandTextInstrumentation": true
        }
    }
}

Para obter mais informações, consulte Rastreamento SQL avançado para obter consulta SQL completa.

Configurar logs do controlador de escala

Este recurso está em pré-visualização.

Você pode fazer com que o controlador de escala do Azure Functions emita logs para o Application Insights ou para o armazenamento de Blob para entender melhor as decisões que o controlador de escala está tomando para seu aplicativo de função.

Para habilitar esse recurso, você pode adicionar uma configuração de aplicativo nomeada SCALE_CONTROLLER_LOGGING_ENABLED às configurações do seu aplicativo de função. O seguinte valor da configuração deve estar no formato <DESTINATION>:<VERBOSITY>:

Property	Description
<DESTINATION>	O destino para o qual os logs são enviados. Os valores válidos são AppInsights e Blob. Ao usar AppInsightso , verifique se o Application Insights está habilitado em seu aplicativo de função. Quando você define o destino como Blob, os logs são criados em um contêiner de blob nomeado azure-functions-scale-controller na conta de armazenamento padrão definida na configuração do AzureWebJobsStorage aplicativo.
<VERBOSITY>	Especifica o nível de registro em log. Os valores suportados são None, Warninge Verbose. Quando definido como Verbose, o controlador de escala registra um motivo para cada alteração na contagem de trabalhadores e informações sobre os gatilhos que influenciam essas decisões. Os logs detalhados incluem avisos de gatilho e os hashes usados pelos gatilhos antes e depois da execução do controlador de escala.

Gorjeta

Lembre-se de que, embora você deixe o registro em log do controlador de escala habilitado, isso afeta os custos potenciais de monitoramento do seu aplicativo de função. Considere habilitar o registro em log até que você tenha coletado dados suficientes para entender como o controlador de escala está se comportando e, em seguida, desativá-lo.

Por exemplo, o seguinte comando da CLI do Azure ativa o log detalhado do controlador de escala para o Application Insights:

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:Verbose

Neste exemplo, substitua <FUNCTION_APP_NAME> e pelo nome do seu aplicativo de função e <RESOURCE_GROUP_NAME> o nome do grupo de recursos, respectivamente.

O seguinte comando da CLI do Azure desabilita o registro em log definindo a verbosidade como None:

az functionapp config appsettings set --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--settings SCALE_CONTROLLER_LOGGING_ENABLED=AppInsights:None

Você também pode desabilitar o registro em log removendo a configuração usando o SCALE_CONTROLLER_LOGGING_ENABLED seguinte comando da CLI do Azure:

az functionapp config appsettings delete --name <FUNCTION_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--setting-names SCALE_CONTROLLER_LOGGING_ENABLED

Com o registro do controlador de escala habilitado, agora você pode consultar os logs do controlador de escala.

Ativar a integração do Application Insights

Para que um aplicativo de função envie dados para o Application Insights, ele precisa se conectar ao recurso do Application Insights usando apenas uma destas configurações do aplicativo:

Nome da definição	Description
APPLICATIONINSIGHTS_CONNECTION_STRING	Essa é a configuração recomendada, que é necessária quando sua instância do Application Insights é executada em uma nuvem soberana. A cadeia de conexão suporta outros novos recursos.
APPINSIGHTS_INSTRUMENTATIONKEY	Configuração herdada, que é preterida pelo Application Insights em favor da configuração da cadeia de conexão.

Quando você cria seu aplicativo de função no portal do Azure a partir da linha de comando usando as Ferramentas Principais do Azure Functions ou o Visual Studio Code, a integração do Application Insights é habilitada por padrão. O recurso do Application Insights tem o mesmo nome do seu aplicativo de função e é criado na mesma região ou na região mais próxima.

Nova aplicação de função no portal

Para revisar o recurso do Application Insights que está sendo criado, selecione-o para expandir a janela do Application Insights . Você pode alterar o nome do novo recurso ou selecionar um local diferente em uma geografia do Azure onde deseja armazenar seus dados.

Quando você seleciona Criar, um recurso do Application Insights é criado com seu aplicativo de função, que tem o conjunto nas configurações do APPLICATIONINSIGHTS_CONNECTION_STRING aplicativo. Está tudo pronto.

Adicionar a um aplicativo de função existente

Se um recurso do Application Insights não tiver sido criado com seu aplicativo de função, use as etapas a seguir para criar o recurso. Em seguida, você pode adicionar a cadeia de conexão desse recurso como uma configuração de aplicativo em seu aplicativo de função.

1. No portal do Azure, procure e selecione o aplicativo de função e, em seguida, selecione seu aplicativo de função.

2. Selecione a faixa O Application Insights não está configurado na parte superior da janela. Se você não vir esse banner, talvez seu aplicativo já tenha o Application Insights habilitado.

   

3. Expanda Alterar seu recurso e crie um recurso do Application Insights usando as configurações especificadas na tabela a seguir:

   Definição	Valor sugerido	Description
   Novo nome do recurso	Nome de aplicação exclusivo	É mais fácil utilizar o mesmo nome da aplicação de funções, que tem de ser exclusivo na subscrição.
   Localização	Europa Ocidental	Se possível, use a mesma região do seu aplicativo de função ou a que estiver próxima a essa região .

   

4. Selecione Aplicar.

   O recurso do Application Insights é criado no mesmo grupo de recursos e subscrição da aplicação de funções. Depois que o recurso for criado, feche a janela do Application Insights .

5. Na sua aplicação de funções, selecione Configuração em Definições e, em seguida, selecione Definições da aplicação. Se vir uma definição chamada APPLICATIONINSIGHTS_CONNECTION_STRING, a integração do Application Insights está ativada para a aplicação de funções em execução no Azure. Se, por algum motivo, essa configuração não existir, adicione-a usando sua cadeia de conexão do Application Insights como o valor.

Nota

Aplicativos de função mais antigos podem estar usando APPINSIGHTS_INSTRUMENTATIONKEY em vez de APPLICATIONINSIGHTS_CONNECTION_STRING. Quando possível, você deve atualizar seu aplicativo para usar a cadeia de conexão em vez da chave de instrumentação.

Desativar o registo integrado

As primeiras versões do Functions usavam monitoramento integrado, o que não é mais recomendado. Ao habilitar o Application Insights, desabilite o log interno que usa o Armazenamento do Azure. O registro interno é útil para testes com cargas de trabalho leves, mas não se destina ao uso de produção de alta carga. Para monitoramento de produção, recomendamos o Application Insights. Se o log interno for usado na produção, o registro de log poderá estar incompleto devido à limitação no Armazenamento do Azure.

Para desativar o registo incorporado, elimine a definição da AzureWebJobsDashboard aplicação. Para obter mais informações sobre como excluir configurações de aplicativo no portal do Azure, consulte a seção Configurações do aplicativo de Como gerenciar um aplicativo de função. Antes de excluir a configuração do aplicativo, verifique se nenhuma função existente no mesmo aplicativo de função usa a configuração para gatilhos ou associações do Armazenamento do Azure.

Soluções com alto volume de telemetria

Os aplicativos de função são uma parte essencial de soluções que podem causar grandes volumes de telemetria, como soluções de IoT, soluções orientadas a eventos rápidos, sistemas financeiros de alta carga e sistemas de integração. Nesse caso, você deve considerar uma configuração extra para reduzir custos, mantendo a observabilidade.

A telemetria gerada pode ser consumida em painéis em tempo real, alertas, diagnósticos detalhados e assim por diante. Dependendo de como a telemetria gerada será consumida, você precisará definir uma estratégia para reduzir o volume de dados gerados. Essa estratégia permitirá que você monitore, opere e diagnostique adequadamente seus aplicativos funcionais em produção. Você pode considerar as seguintes opções:

• Use amostragem: Como mencionado anteriormente, ajudará a reduzir drasticamente o volume de eventos de telemetria ingeridos, mantendo uma análise estatisticamente correta. Pode acontecer que, mesmo usando amostragem, você ainda obtenha um alto volume de telemetria. Inspecione as opções que a amostragem adaptável oferece a você. Por exemplo, defina o como um valor que equilibra o maxTelemetryItemsPerSecond volume gerado com suas necessidades de monitoramento. Lembre-se de que a amostragem de telemetria é aplicada por host que executa seu aplicativo de função.

• Nível de log padrão: use Warning ou Error como o valor padrão para todas as categorias de telemetria. Agora, você pode decidir quais categorias deseja definir no Information nível para que possa monitorar e diagnosticar suas funções corretamente.

• Ajuste a telemetria de suas funções: com o nível de log padrão definido como Error ou Warning, nenhuma informação detalhada de cada função será coletada (dependências, métricas personalizadas, eventos personalizados e rastreamentos). Para as funções que são fundamentais para o monitoramento da produção, defina uma entrada explícita para a categoria e defina-a como , para Function.<YOUR_FUNCTION_NAME>Informationque você possa coletar informações detalhadas. Neste ponto, para evitar a coleta de logs gerados pelo usuário no Information nível, defina a categoria como Error ou Warning nível de Function.<YOUR_FUNCTION_NAME>.User log.

• Categoria Host.Aggregator: Conforme descrito em configurar categorias, esta categoria fornece informações agregadas de invocações de funções. As informações dessa categoria são coletadas na tabela do Application Insights customMetrics e são mostradas na guia Visão geral da função no portal do Azure. Dependendo de como você configura o agregador, considere que haverá um atraso flushTimeout, determinado pelo , na telemetria coletada. Se você definir essa categoria para outro valor diferente do Information, interromperá a coleta de dados na tabela e não exibirá métricas na customMetrics guia Visão geral da função.

  A captura de tela a seguir mostra Host.Aggregator os dados de telemetria exibidos na guia Visão geral da função:

  

  A captura de tela a seguir mostra Host.Aggregator dados de telemetria na tabela do Application Insights customMetrics :

  

• Categoria Host.Results: Conforme descrito em configurar categorias, essa categoria fornece os logs gerados pelo tempo de execução indicando o sucesso ou a falha de uma chamada de função. As informações dessa categoria são coletadas na tabela do Application Insights e mostradas na guia Monitor da função e em diferentes painéis do Application Insights requests (Desempenho, Falhas e assim por diante). Se você definir essa categoria para outro valor diferente do Information, coletará apenas a telemetria gerada no nível de log definido (ou superior). Por exemplo, defini-lo para resulta no rastreamento de dados de solicitações somente para error execuções com falha.

  A captura de tela a seguir mostra os dados de telemetria exibidos na guia Monitor de Host.Results função:

  

  A captura de tela a seguir mostra Host.Results os dados de telemetria exibidos no painel de desempenho do Application Insights:

  

• Host.Aggregator vs Host.Results: Ambas as categorias fornecem bons insights sobre execuções de funções. Se necessário, você pode remover as informações detalhadas de uma dessas categorias, para que possa usar a outra para monitoramento e alerta. Exemplo:

v2.x+

{
  "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"
      }
    }
  }
} 

v1.x

{
  "logger": {
    "categoryFilter": {
      "defaultLevel": "Warning",
      "categoryLevels": {
        "Function": "Error",
        "Host.Aggregator": "Error",
        "Host.Results": "Information",
        "Host.Executor": "Warning"
      }
    }
  },
  "applicationInsights": {
    "sampling": {
      "isEnabled": true,
      "maxTelemetryItemsPerSecond" : 5
    }
  }
}

Com essa configuração, você terá:

• O valor padrão para todas as funções e categorias de telemetria é definido como Warning (incluindo as categorias Microsoft e Worker). Assim, por padrão, todos os erros e avisos gerados pelo tempo de execução e pelo log personalizado são coletados.

• O Function nível de log de categoria é definido como Error, portanto, para todas as funções, por padrão, apenas exceções e logs de erros serão coletados (dependências, métricas geradas pelo usuário e eventos gerados pelo usuário serão ignorados).

• Para a Host.Aggregator categoria, como ela é definida como Error nível de log, as informações agregadas de invocações de função não serão reunidas na tabela do Application Insights e as informações sobre contagens de execuções (total, bem-sucedida e falhada) não serão mostradas customMetrics no painel de visão geral da função.

• Para a Host.Results categoria, todas as informações de execução do host são reunidas requests na tabela Application Insights. Todos os resultados das invocações serão mostrados no painel Monitor da função e nos painéis do Application Insights.

• Para a função chamada Function1, definimos o nível de log como Information. Assim, para esta função concreta, toda a telemetria é reunida (dependência, métricas personalizadas e eventos personalizados). Para a mesma função, a categoria (rastreamentos gerados pelo usuário) é definida como Error, portanto, apenas o Function1.User log de erros personalizado será coletado.

  Nota

  A configuração por função não é suportada na v1.x.

• A amostragem é configurada para enviar um item de telemetria por segundo por tipo, excluindo as exceções. Essa amostragem acontecerá para cada host de servidor que executa nosso aplicativo de função. Portanto, se tivermos quatro instâncias, essa configuração emitirá quatro itens de telemetria por segundo por tipo e todas as exceções que possam ocorrer.

  Nota

  As contagens métricas, como taxa de solicitação e taxa de exceção, são ajustadas para compensar a taxa de amostragem, de modo que mostrem valores aproximadamente corretos no Metric Explorer.

Gorjeta

Experimente diferentes configurações para garantir que você atenda às suas necessidades de registro, monitoramento e alertas. Além disso, certifique-se de ter diagnósticos detalhados em caso de erros inesperados ou mau funcionamento.

Substituindo a configuração de monitoramento em tempo de execução

Finalmente, pode haver situações em que você precise alterar rapidamente o comportamento de log de uma determinada categoria em produção e não queira fazer uma implantação inteira apenas para uma alteração no arquivo host.json . Para esses casos, você pode substituir os valores host.json.

Para configurar esses valores no nível de configurações do aplicativo (e evitar a reimplantação em apenas host.json alterações), você deve substituir valores específicos host.json criando um valor equivalente como uma configuração do aplicativo. Quando o tempo de execução encontra uma configuração de aplicativo no formato AzureFunctionsJobHost__path__to__setting, ele substitui a configuração equivalente host.json localizada no path.to.setting JSON. Quando expresso como uma configuração de aplicativo, o ponto () usado para indicar a hierarquia JSON é substituído por um sublinhado duplo (.__). Por exemplo, você pode usar as configurações do aplicativo abaixo para configurar níveis de log de funções individuais como acima host.json .

Host.json caminho	Definição da aplicação
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

Você pode substituir as configurações diretamente na folha Configuração do Aplicativo de Função do portal do Azure ou usando um script da CLI ou do PowerShell do Azure.

az cli |

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host__Aggregator=Information"

PowerShell

Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"AzureFunctionsJobHost__logging__logLevel__Host__Aggregator" = "Information"}

Nota

Substituir a alteração das configurações do host.json aplicativo reiniciará seu aplicativo de função. As configurações de aplicativo que contêm um período não são suportadas quando executadas no Linux em um plano Elastic Premium ou um plano Dedicado (Serviço de Aplicativo). Nesses ambientes de hospedagem, você deve continuar a usar o arquivo host.json .

Monitorar aplicativos de função usando a verificação de integridade

O recurso Verificação de integridade pode ser usado para monitorar aplicativos funcionais nos planos Premium (Elastic Premium) e Dedicado (Serviço de Aplicativo). O exame de saúde não é uma opção para o plano de consumo. Para saber como configurá-lo, consulte Monitorar instâncias do Serviço de Aplicativo usando a verificação de integridade. Seu aplicativo de função deve ter uma função de gatilho HTTP que responda com um código de status HTTP de 200 no mesmo ponto de extremidade configurado no parâmetro 'Caminho' da verificação de integridade. Você também pode fazer com que essa função execute verificações extras para garantir que os serviços dependentes estejam acessíveis e funcionando.

Próximos passos

Para obter mais informações sobre monitoramento, consulte:

• Monitorizar as Funções do Azure
• Analisar dados de telemetria do Azure Functions no Application Insights
• Application Insights