Quantos recursos do Application Insights devo implantar?

Ao desenvolver a próxima versão de um aplicativo Web, não é bom misturar as telemetrias da nova versão e da versão já lançada do Application Insights.

Para evitar confusão, envie a telemetria de diferentes estágios de desenvolvimento a fim de separar os recursos do Application Insights, com chaves de instrumentação separadas.

Para facilitar a alteração da chave de instrumentação, quando uma versão muda de um estágio para outro, pode ser útil definir a chave de instrumentação dinamicamente no código em vez de no arquivo de configuração.

Se o sistema for uma instância dos Serviços de Nuvem do Azure, haverá outro método para definir chaves de instrumentação separadas.

Observação

Em 31 de março de 31, 2025, o suporte à ingestão de chave de instrumentação será encerrado. A ingestão de chave de instrumentação continuará funcionando, mas não forneceremos mais atualizações ou suporte para o recurso. Transição para cadeias de conexão para aproveitar as novas funcionalidades.

Sobre recursos e chaves de instrumentação

Ao configurar o monitoramento do Application Insights para seu aplicativo Web, você cria um recurso do Application Insights no Azure. Abra esse recurso no portal do Azure para ver e analisar a telemetria coletada de seu aplicativo. O recurso é identificado por uma chave de instrumentação. Ao instalar o pacote do Application Insights para monitorar seu aplicativo, você o configura com a chave de instrumentação, assim ele sabe para onde enviar a telemetria.

Cada recurso do Application Insights vem com métricas que estão disponíveis prontas para uso. Se componentes separados reportarem ao mesmo recurso do Application Insights, talvez não faça sentido programar um alerta relativo a essas métricas.

Quando usar um único recurso do Application Insights

Use apenas um recurso do Application Insights:

  • Para componentes de aplicativos implantados juntos. Esses aplicativos são normalmente desenvolvidos por uma única equipe e gerenciados pelo mesmo conjunto de usuários de DevOps/ITOps.
  • Se fizer sentido agregar indicadores chave de desempenho, como durações de resposta ou taxas de falha em um painel, em todos eles por padrão. Você pode optar por segmentar por nome de função no Metrics Explorer.
  • Se não for necessário gerenciar o controle de acesso baseado em função do Azure de maneira diferente entre os componentes do aplicativo.
  • Se você não precisa de critérios de alerta de métricas diferentes entre os componentes não forem necessários.
  • Se não for necessário gerenciar exportações contínuas de maneira diferente entre os componentes.
  • Se não for necessário gerenciar cobrança/cotas de maneira diferente entre os componentes.
  • Se não tiver problema em ter uma chave de API com o mesmo acesso aos dados de todos os componentes. 10 chaves de API são suficientes para as necessidades em todas elas.
  • Se não tiver problema em ter as mesmas configurações de detecção inteligente e de integração de itens de trabalho em todas as funções.

Observação

Se deseja consolidar vários recursos de Application Insights, poderá apontar seus componentes de aplicativo existentes para um novo recurso de Application Insights consolidado. A telemetria armazenada em seu recurso antigo não será transferida para o novo recurso. Exclua o recurso antigo somente quando você tiver telemetria suficiente no novo recurso para continuidade de negócios.

Outras considerações

Esteja ciente do seguinte:

  • Para garantir que os valores significativos sejam definidos no atributo Cloud_RoleName, talvez seja necessário adicionar um código personalizado. Sem valores significativos definidos para esse atributo, nenhuma das experiências do portal funcionará.
  • Para aplicativos do Azure Service Fabric e serviços de nuvem clássicos, o SDK lê automaticamente do ambiente de função do Azure e define esses serviços. Provavelmente você precisará definir isso explicitamente em todos os outros tipos de aplicativos.
  • O Live Metrics não dá suporte à divisão por nome de função.

Chave de instrumentação dinâmica

Para facilitar a alteração da chave de instrumentação à medida que o código se move entre os estágios de produção, referencie a chave dinamicamente no código em vez de usar um valor codificado ou estático.

Defina a chave em um método de inicialização (por exemplo, global.aspx.cs) em um serviço do ASP.NET:

protected void Application_Start()
{
  Microsoft.ApplicationInsights.Extensibility.
    TelemetryConfiguration.Active.InstrumentationKey = 
      // - for example -
      WebConfigurationManager.AppSettings["ikey"];
  ...

Nesse exemplo, as chaves de instrumentação para os diferentes recursos são colocadas em diferentes versões do arquivo de configuração da Web. Trocar o arquivo de configuração da Web, que pode ser realizado como parte do script versão, alternará o recurso de destino.

Páginas da Web

A chave de instrumentação também é usada nas páginas da Web do aplicativo, no script que você obteve do painel de início rápido. Em vez de codificá-la literalmente no script, gere-a a partir do estado do servidor. Por exemplo, em um aplicativo ASP.NET:

<script type="text/javascript">
// Standard Application Insights webpage script:
var appInsights = window.appInsights || function(config){ ...
// Modify this part:
}({instrumentationKey:  
  // Generate from server property:
  "@Microsoft.ApplicationInsights.Extensibility.
     TelemetryConfiguration.Active.InstrumentationKey"
  }
 )
//...

Criar mais recursos do Application Insights

Para criar um recurso do Application Insights, confira Criar um recurso do Application Insights.

Obter a chave de instrumentação

A chave de instrumentação identifica o recurso que você criou.

Você precisará das chaves de instrumentação de todos os recursos aos quais seu aplicativo enviará dados.

Filtrar por número de build

Quando publicar uma nova versão do seu aplicativo, você desejará ser capaz de separar a telemetria das compilações diferentes.

Você pode definir a propriedade Versão do Aplicativo para que possa filtrar resultados da pesquisa e do Metrics Explorer.

Há vários métodos diferentes de definir a propriedade de Versão do Aplicativo.

  • Definir diretamente:

    telemetryClient.Context.Component.Version = typeof(MyProject.MyClass).Assembly.GetName().Version;

  • Encapsule essa linha em um inicializador de telemetria para garantir que todas as instâncias de TelemetryClient sejam configuradas de maneira consistente.

  • ASP.NET: defina a versão em BuildInfo.config. O módulo da Web selecionará a versão do nó BuildLabel. Inclua esse arquivo no seu projeto e não se esqueça de definir a propriedade Copy Always no Gerenciador de Soluções.

    <?xml version="1.0" encoding="utf-8"?>
    <DeploymentEvent xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/VisualStudio/DeploymentEvent/2013/06">
      <ProjectName>AppVersionExpt</ProjectName>
      <Build type="MSBuild">
        <MSBuild>
          <BuildLabel kind="label">1.0.0.2</BuildLabel>
        </MSBuild>
      </Build>
    </DeploymentEvent>
    
    
  • ASP.NET: gere BuildInfo.config automaticamente no Microsoft Build Engine. Adicione algumas linhas ao seu arquivo .csproj:

    <PropertyGroup>
      <GenerateBuildInfoConfigFile>true</GenerateBuildInfoConfigFile>    <IncludeServerNameInBuildInfo>true</IncludeServerNameInBuildInfo>
    </PropertyGroup>
    

    Isso gera um arquivo chamado nomedoSeuProjeto.BuildInfo.config. O processo de Publicação renomeia o arquivo como BuildInfo.config.

    O rótulo do build contém um espaço reservado (AutoGen_...) quando você compila com o Visual Studio. Mas, quando compilado com o Microsoft Build Engine, ele é preenchido com o número de versão correto.

    Para permitir que o Microsoft Build Engine gere números de versão, defina a versão como 1.0.* em AssemblyReference.cs.

Versão e controle de versão

Para controlar a versão do aplicativo, certifique-se de buildinfo.config é gerado pelo processo de Microsoft Build Engine. No seu arquivo .csproj, adicione:

<PropertyGroup>
  <GenerateBuildInfoConfigFile>true</GenerateBuildInfoConfigFile>
  <IncludeServerNameInBuildInfo>true</IncludeServerNameInBuildInfo>
</PropertyGroup>

Quando o módulo da web do Application Insights tem as informações de build, ele adiciona automaticamente Versão do Aplicativo como uma propriedade para cada item de telemetria. Por esse motivo, você pode filtrar por versão ao executar pesquisas de diagnóstico ou ao explorar métricas.

O número de versão de build é gerado apenas pelo Microsoft Build Engine, não pelo build de desenvolvedor do Visual Studio.

Anotações da versão

Se usar o Azure DevOps, você poderá obter um marcador de anotação adicionado a seus gráficos sempre que lançar uma nova versão.

Próximas etapas