Como configurar monitorização para Funções do Azure

O Funções do Azure integra-se com o Application Insights para lhe permitir monitorizar melhor as suas aplicações de funções. Application Insights, uma funcionalidade do Azure Monitor, é um serviço extensível de Gestão de Desempenho de Aplicações (APM) que recolhe dados gerados pela sua aplicação funcional, incluindo informações que a sua aplicação escreve nos 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. No entanto, a configuração padrão pode resultar em grandes volumes de dados. Se estiver a usar uma subscrição Visual Studio Azure, pode atingir o limite de dados para 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.

Neste artigo, você aprenderá a configurar e personalizar os dados que suas funções enviam para o Application Insights. Você pode definir configurações comuns de log no arquivo host.json . Por padrão, essas configurações também controlam os logs personalizados emitidos pelo seu código. No entanto, em alguns casos, esse comportamento pode ser desativado em favor de opções que lhe dão mais controle sobre o registro. Para obter mais informações, consulte Logs de aplicativos personalizados.

Logs de aplicações personalizadas

Por padrão, os logs de aplicativos personalizados que você grava são enviados para o host Functions, que os envia para o Application Insights na categoria Trabalhador. Algumas stacks de linguagem permitem enviar os logs diretamente para o Application Insights, o que lhe dá controle total sobre como os logs que escreve são emitidos. Nesse caso, 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 de configuração disponíveis para cada pilha:

Quando você configura logs de aplicativos personalizados para serem enviados diretamente, o host não os emite mais e host.json não controla mais seu comportamento. Da mesma forma, as opções apresentadas por cada stack aplicam-se apenas a logs personalizados e não alteram o comportamento dos outros logs de runtime descritos neste artigo. Nesse caso, para controlar o comportamento de todos os logs, talvez seja necessário fazer alterações em ambas as configurações.

Configurar categorias

O Funções do Azure logger inclui uma categoria para cada log. A categoria indica que parte do código de execução 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 das categorias são atribuídos de forma diferente em Funções em comparação com outros frameworks .NET. Por exemplo, quando usas ILogger<T> em 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.

A tabela a seguir descreve as principais categorias de logs que o tempo de execução cria:

A coluna Tabela indica em que tabela do Application Insights o log é 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:

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 seguintes definem o registo com base nas seguintes regras:

• O nível de log padrão é definido para Warning evitar log excessivo para categorias imprevistas.
• Host.Aggregator e Host.Results são definidos para níveis mais baixos. Definir níveis de log muito altos (especialmente mais altos do que 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. Se necessário, você pode substituir essa configuração no desenvolvimento local para Debug ou Trace.

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

{
  "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 regista tudo no tempo de execução, exceto Host.Aggregator, ao nível Error.

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

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

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. Por exemplo:

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

Configurar amostragem

O recurso Application Insights tem uma funcionalidade de amostragem que pode protegê-lo de produzir muitos dados de telemetria sobre 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:

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

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

Se seu projeto usa uma dependência do SDK do Application Insights para fazer o rastreamento manual de telemetria, você pode enfrentar um comportamento incomum 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 ativar o registo do texto de consulta SQL utilizando as seguintes configurações (no mínimo) no ficheiro 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.

Podes fazer com que o Funções do Azure scale controller emita logs para Application Insights ou para armazenamento Blob para melhor compreender as decisões que o scale controller está a tomar para a tua aplicação de funções.

Para habilitar esse recurso, adicione 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>. Para obter mais informações, consulte a tabela a seguir:

Por exemplo, o seguinte comando CLI do Azure ativa o registo 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 <RESOURCE_GROUP_NAME> pelo nome do seu aplicativo de função e o nome do grupo de recursos, respectivamente.

O comando CLI do Azure seguinte desativa o registo ao definir a verbosidade para None:

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

Também pode desativar o registo removendo a definição SCALE_CONTROLLER_LOGGING_ENABLED usando o seguinte comando 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:

Quando cria a sua aplicação de funções no portal Azure a partir da linha de comandos, usando Funções do Azure Core Tools ou Visual Studio Code, a integração com o Application Insights está ativada por defeito. 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.

Exigir autenticação Microsoft Entra

Pode usar a definição APPLICATIONINSIGHTS_AUTHENTICATION_STRING para permitir ligações ao Application Insights usando autenticação Microsoft Entra. Isso cria uma experiência de autenticação consistente em todos os pipelines do Application Insights, incluindo o Profiler e o Depurador de Instantâneo, bem como a partir do host do Functions e de agentes específicos do idioma.

O valor contém Authorization=AAD para uma identidade gerenciada atribuída ao sistema ou ClientId=<YOUR_CLIENT_ID>;Authorization=AAD para uma identidade gerenciada atribuída pelo usuário. A identidade gerida deve já estar disponível para a aplicação de função, com um papel atribuído equivalente a Publicador de Métricas de Monitorização. Para mais informações, consulte autenticação do Microsoft Entra para o Application Insights.

A APPLICATIONINSIGHTS_CONNECTION_STRING configuração ainda é necessária.

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 . Pode alterar o Novo nome de recurso ou selecionar uma Localização numa geografia do Azure onde quer armazenar os seus dados.

Quando seleciona Criar, é criado um recurso do Application Insights com a sua aplicação de função, que tem o APPLICATIONINSIGHTS_CONNECTION_STRING definido nas definições da aplicação. 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. Depois pode adicionar a cadeia de ligação desse recurso como uma definição de aplicação na sua aplicação de funções.

1. No portal Azure, procura e seleciona function app, e depois seleciona a tua function app.

2. Selecione o banner 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. Expandir Alterar o seu recurso e criar um recurso do "Application Insights" usando as configurações especificadas na tabela a seguir.

   Configuração	Valor sugerido	Descrição
   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 que a sua aplicação de função. Depois que o recurso for criado, feche a janela do Application Insights .

5. Na sua aplicação de funções, expanda Definições e, em seguida, selecione Variáveis de ambiente. No separador Definições da App, se vir uma definição da aplicação chamada APPLICATIONINSIGHTS_CONNECTION_STRING, a integração com o Application Insights está ativada para a sua aplicação de funções em execução no Azure. Se esta configuração não existir, adiciona-a usando a tua cadeia de ligação do Application Insights como valor.

Desativar o registo integrado

As primeiras versões do Functions usavam monitoramento integrado, o que não é mais recomendado. Quando ativar o Application Insights, desative o registo incorporado que utiliza o Armazenamento do Azure. O registo interno é útil para testes com cargas de trabalho leves, mas não é destinado ao uso em produção sob alta carga. Para monitoramento de produção, recomendamos o Application Insights. Se utilizares registo incorporado em produção, o registo pode ficar incompleto devido ao estrangulamento no Armazenamento do Azure.

Para desativar o registo incorporado, elimine a configuração da AzureWebJobsDashboard aplicação. Para mais informações sobre como eliminar as definições da aplicação no portal Azure, consulte a secção Definições de aplicação do Como gerir uma aplicação funcional. Antes de eliminar a definição da aplicação, certifique-se de que nenhuma função existente na mesma aplicação usa a definição para gatilhos ou associações do Armazenamento do Azure.

Soluções com alto volume de telemetria

Os aplicativos funcionais 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 é consumida, você precisa definir uma estratégia para reduzir o volume de dados gerados. Essa estratégia permite que você monitore, opere e diagnostique adequadamente seus aplicativos funcionais em produção. Considere as seguintes opções:

• Use o plano de tabela correto: os planos de tabela ajudam a gerenciar os custos de dados, controlando a frequência com que você usa os dados em uma tabela e o tipo de análise que você precisa executar. Para reduzir custos, você pode escolher o Basic plano, que não possui alguns recursos disponíveis no Analytics plano.

• Utilize amostragem: Como mencionado anteriormente, a amostragem ajuda a reduzir drasticamente o volume de eventos de telemetria ingeridos, mantendo uma análise estatisticamente correta. Pode ocorrer que, mesmo usando amostragem, ainda obtenhas um alto volume de telemetria. Inspecione as opções que a amostragem adaptativa lhe oferece. Por exemplo, defina o maxTelemetryItemsPerSecond como um valor que equilibra o volume gerado com suas necessidades de monitoramento. Lembre-se de que a amostragem de telemetria é aplicada por host que executa a sua aplicação de funções.

• Nível de log padrão: use Warning ou Error como o valor padrão para todas as categorias de telemetria. Mais tarde, 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 é 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 Function.<YOUR_FUNCTION_NAME> e defina-a para Information, para que possa coletar informações detalhadas. Para evitar a recolha de logs gerados pelo utilizador ao nível Information, defina a categoria Function.<YOUR_FUNCTION_NAME>.User para o nível de log Error ou Warning.

• Categoria Host.Aggregator: Conforme descrito em configurar categorias, esta categoria fornece informações agregadas de invocações de funções. A informação desta categoria é recolhida na tabela Application Insights customMetrics e é apresentada na função Overview no portal Azure. Dependendo de como você configura o agregador, considere que pode haver um atraso flushTimeout , determinado pela configuração, na telemetria coletada. Se definir esta categoria para um valor diferente de Information, interrompe a recolha de dados na customMetrics tabela e não exibe métricas no separador 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 desta categoria são coletadas na tabela Application Insights requests e mostradas na guia de função Monitor e em diferentes painéis do Application Insights (Desempenho, Falhas e assim por diante). Se você definir essa categoria para um valor diferente de Information, coletará apenas a telemetria gerada no nível de log definido (ou superior). Por exemplo, defini-lo para error resulta no rastreamento de dados de solicitações somente para execuções com falha.

  A captura de ecrã seguinte mostra os dados de telemetria Host.Results exibidos no separador de função Monitor:

  

  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:

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

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

Com esta configuração:

• O valor padrão para todas as funções e categorias de telemetria é definido para Warning (incluindo as categorias Microsoft e Trabalhador). 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 erro são coletados. Dependências, métricas geradas pelo usuário e eventos gerados pelo usuário são ignorados.

• Para a categoria Host.Aggregator, uma vez que está definida para o nível de log Error, as informações agregadas de invocações de função não são agregadas na tabela customMetrics do Application Insights, e os dados das execuções (total, bem-sucedidas e falhadas) não são exibidos 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 na tabela requests Application Insights. Todos os resultados das invocações sã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, definimos a categoria Function1.User (rastreamentos gerados pelo usuário) para Error, de forma que apenas o registo de erros personalizado seja recolhido.

  Nota

  A configuração por função não é suportada na v1.x do tempo de execução do Functions.

• A amostragem é configurada para enviar um item de telemetria por segundo por tipo, excluindo as exceções. Essa amostragem acontece 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.

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

Finalmente, pode haver situações em que se precise alterar rapidamente o comportamento de log de uma determinada categoria em produção e não se queira fazer um desdobramento inteiro apenas para uma alteração no ficheiro host.json. Para estes casos, pode substituir os valores do host.json.

Para configurar esses valores ao nível das definições da aplicação (e evitar uma nova implantação por alterações apenas no host.json), deve substituir valores específicos host.json criando uma definição equivalente como uma definição da aplicação. Quando o runtime encontra uma definição de aplicativo no formato AzureFunctionsJobHost__path__to__setting, ele substitui a definição equivalente host.json localizada em path.to.setting no JSON. Quando expresso como uma configuração de aplicativo, um sublinhado duplo (__) substitui o ponto (.) usado para indicar a hierarquia JSON. Por exemplo, você pode usar as seguintes configurações de aplicativo para configurar níveis de log de função individuais no host.json.

Pode sobrescrever as definições diretamente no painel de Configuração da Function App do Portal do Azure ou usando um script CLI do Azure ou PowerShell.

az functionapp config appsettings set --name MyFunctionApp --resource-group MyResourceGroup --settings "AzureFunctionsJobHost__logging__logLevel__Host.Aggregator=Information"

Update-AzFunctionAppSetting -Name MyAppName -ResourceGroupName MyResourceGroupName -AppSetting @{"AzureFunctionsJobHost__logging__logLevel__Host.Aggregator" = "Information"}

Monitorar aplicações de função usando o teste de integridade

Você pode usar o recurso Verificação de integridade 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 os planos Flex Consumption and Consumption. Para saber como configurá-lo, consulte Monitorizar instâncias do Serviço de Aplicações usando verificação de saúde. Seu aplicativo de função deve ter uma função de gatilho Path HTTP que responda com um código de status HTTP de 200 no mesmo ponto de extremidade configurado no parâmetro 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.

Conteúdos relacionados

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

• Monitor Funções do Azure
• Analisar dados de telemetria Funções do Azure em Application Insights
• Visão geral do Application Insights