Recursos baseados em workspace do Application Insights
Os recursos baseados no espaço de trabalho do Application Insights do Azure Monitor integram o Application Insights e o Log Analytics.
Com recursos baseados em workspace, o Application Insights envia dados telemétricos para um workspace comum do Log Analytics, fornecendo acesso total a todos os recursos do Log Analytics e mantendo seu aplicativo, infraestrutura e logs da plataforma em um único local consolidado. Isso também permite o Controle de acesso baseado em função do Azure comum em seus recursos e elimina a necessidade de consultas entre aplicativos/espaço de trabalhos.
Observação
A ingestão de dados e a retenção de recursos do Application Insights baseados em espaço de trabalho são cobradas por meio do espaço de trabalho do Log Analytics onde ficam os dados. Para saber mais sobre a cobrança de recursos do Application Insights baseados em workspace, confira os Detalhes de preços dos Logs do Azure Monitor.
Novos recursos
O Application Insights baseado em workspace se integra ao Azure Monitor e ao Log Analytics para aprimorar recursos:
- A chave gerenciada pelo cliente criptografa seus dados inativos com chaves que só você acessa.
- O Link Privado do Azure conecta com segurança os serviços PaaS do Azure à sua rede virtual usando pontos de extremidade privados.
- BYOS (Traga seu próprio armazenamento) para o .NET Profiler e o Depurador de Instantâneos permite gerenciar dados de .NET Profiler e Depurador de Instantâneos com políticas de criptografia, tempo de vida e acesso à rede.
- Os níveis de compromisso oferecem até 30% de economia em relação aos preços de pagamento conforme o uso.
- O streaming do Log Analytics processa dados mais rapidamente.
Criar um recurso com base no workspace
Entre no portal do Azure e crie um recurso do Application Insights.
Se você ainda não tiver um workspace do Log Analytics, confira a documentação de criação de workspace do Log Analytics.
Os recursos baseados em workspace estão disponíveis atualmente em todas as regiões comerciais e no Azure Governamental. Ter o Application Insights e o Log Analytics em duas regiões diferentes pode afetar a latência e reduzir a confiabilidade geral da solução de monitoramento.
Depois de criar o seu recurso, você verá as informações do workspace correspondente no painel Visão geral.
Selecione o texto do link azul para ir para o workspace do Log Analytics associado, no qual você poderá aproveitar o novo ambiente unificado de consulta de workspace.
Observação
Ainda fornecemos uma total compatibilidade com versões anteriores para consultas de recursos, pastas de trabalho e alertas baseados em log clássicos do Application Insights. Para consultar ou exibir a nova estrutura/esquema de tabela baseada em workspace, você deverá primeiro acessar o seu workspace do Log Analytics. Selecionar Logs (análise) de dentro dos painéis do Application Insights para ter acesso à experiência clássica de consulta do Application Insights.
Copiar a cadeia de conexão
A cadeia de conexão identifica o recurso com o qual você deseja associar os dados de telemetria. Você também pode usá-la para modificar os pontos de extremidade que o recurso usa como um destino para a telemetria. Você deve copiar a cadeia de conexão e adicioná-la ao código do seu aplicativo ou a uma variável de ambiente.
Configurar monitoramento
Depois de criar um recurso do Application Insights baseado em workspace, configure o monitoramento.
Monitoramento de aplicativos baseado em código
Para o monitoramento de aplicativos baseados em código, instale o SDK do Application Insights apropriado e aponte-o para a cadeia de conexão do seu recurso recém-criado.
Para obter informações sobre como configurar um SDK do Application Insights para monitoramento baseado em código, confira a seguinte documentação específica para o idioma ou a estrutura:
- ASP.NET
- ASP.NET Core
- Tarefas em segundo plano e aplicativos de console modernos (.NET/.NET Core)
- Aplicativos de console clássicos (.NET)
- Java
- JavaScript
- Node.js
- Python
Monitoramento sem código
Para o monitoramento sem código de serviços como o Azure Functions e os Serviços de Aplicativo do Azure, crie primeiro o seu recurso do Application Insights baseado em espaço de trabalho. Em seguida, aponte para esse recurso ao configurar o monitoramento. Como alternativa, crie um novo recurso do Application Insights como parte da habilitação do Application Insights.
Criar um recurso automaticamente
CLI do Azure
Para acessar a versão prévia dos comandos da CLI do Azure do Application Insights, primeiro você precisa executar:
az extension add -n application-insights
Se você não executar o comando az extension add, verá uma mensagem de erro que diz az : ERROR: az monitor: 'app-insights' is not in the 'az monitor' command group. See 'az monitor --help'.
Agora você pode executar o seguinte código para criar o recurso do Application Insights:
az monitor app-insights component create --app
--location
--resource-group
[--application-type]
[--ingestion-access {Disabled, Enabled}]
[--kind]
[--only-show-errors]
[--query-access {Disabled, Enabled}]
[--tags]
[--workspace]
Exemplo
az monitor app-insights component create --app demoApp --location eastus --kind web -g my_resource_group --workspace "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/test1234/providers/microsoft.operationalinsights/workspaces/test1234555"
Para obter a documentação completa da CLI do Azure para este comando, confira a documentação da CLI do Azure.
Azure PowerShell
Crie um novo recurso do Application Insights baseado em workspace.
New-AzApplicationInsights -Name <String> -ResourceGroupName <String> -Location <String> -WorkspaceResourceId <String>
[-SubscriptionId <String>]
[-ApplicationType <ApplicationType>]
[-DisableIPMasking]
[-DisableLocalAuth]
[-Etag <String>]
[-FlowType <FlowType>]
[-ForceCustomerStorageForProfiler]
[-HockeyAppId <String>]
[-ImmediatePurgeDataOn30Day]
[-IngestionMode <IngestionMode>]
[-Kind <String>]
[-PublicNetworkAccessForIngestion <PublicNetworkAccessType>]
[-PublicNetworkAccessForQuery <PublicNetworkAccessType>]
[-RequestSource <RequestSource>]
[-RetentionInDays <Int32>]
[-SamplingPercentage <Double>]
[-Tag <Hashtable>]
[-DefaultProfile <PSObject>]
[-Confirm]
[-WhatIf]
[<CommonParameters>]
Exemplo
New-AzApplicationInsights -Kind java -ResourceGroupName testgroup -Name test1027 -location eastus -WorkspaceResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/test1234/providers/microsoft.operationalinsights/workspaces/test1234555"
Para obter a documentação completa do PowerShell para esse cmdlet e saber como recuperar a cadeia de conexão, confira a documentação do Azure PowerShell.
Modelos do Azure Resource Manager
@description('Name of Application Insights resource.')
param name string
@description('Type of app you are deploying. This field is for legacy reasons and will not impact the type of App Insights resource you deploy.')
param type string
@description('Which Azure Region to deploy the resource to. This must be a valid Azure regionId.')
param regionId string
@description('See documentation on tags: https://learn.microsoft.com/azure/azure-resource-manager/management/tag-resources.')
param tagsArray object
@description('Source of Azure Resource Manager deployment')
param requestSource string
@description('Log Analytics workspace ID to associate with your Application Insights resource.')
param workspaceResourceId string
resource component 'Microsoft.Insights/components@2020-02-02' = {
name: name
location: regionId
tags: tagsArray
kind: 'other'
properties: {
Application_Type: type
Flow_Type: 'Bluefield'
Request_Source: requestSource
WorkspaceResourceId: workspaceResourceId
}
}
Arquivo de parâmetro.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"name": {
"value": "my_workspace_based_resource"
},
"type": {
"value": "web"
},
"regionId": {
"value": "westus2"
},
"tagsArray": {
"value": {}
},
"requestSource": {
"value": "CustomDeployment"
},
"workspaceResourceId": {
"value": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/testxxxx/providers/microsoft.operationalinsights/workspaces/testworkspace"
}
}
}
Modificar o workspace associado
Depois de criar um recurso do Application Insights baseado em workspace, você poderá modificar o workspace do Log Analytics associado.
No painel de recursos do Application Insights, selecione Propriedades>Alterar workspace>Workspaces do Log Analytics.
Exportar telemetria
A funcionalidade de exportação contínua herdada não tem suporte para recursos baseados em espaço de trabalho. Em vez disso, selecione Configurações de diagnóstico>Adicionar configurações de diagnóstico no seu recurso do Application Insights. Você pode selecionar todas as tabelas ou um subconjunto de tabelas para arquivar em uma conta de armazenamento. Você também pode transmitir para um hub de eventos do Azure.
Observação
A exportação de configurações de diagnóstico pode aumentar os custos. Para obter mais informações, confira Exportar telemetria do Application Insights. Para obter informações sobre preços para essa funcionalidade, confira a página de preços do Azure Monitor. As notificações serão enviadas antes do início da cobrança. Se você continuar usando a exportação de telemetria após o período de aviso, será cobrada a taxa aplicável.
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 para separar os recursos do Application Insights com cadeias de conexão separadas.
Se seu sistema for uma instância dos Serviços de Nuvem do Azure, haverá outro método de definição de cadeias de conexão separadas.
Sobre recursos e cadeias de conexão
Ao configurar o monitoramento do Application Insights para seu aplicativo Web, você cria um recurso do Application Insights no Azure. Abra o recurso no portal do Azure para ver e analisar a telemetria coletada de seu aplicativo. Uma cadeia de conexão identifica o recurso. Ao instalar o pacote do Application Insights para monitorar seu aplicativo, configure-o com a cadeia de conexão para que ele saiba 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 um único recurso do Application Insights:
- Para simplificar o gerenciamento de DevOps/ITOps para aplicativos implantados juntos, normalmente desenvolvidos e gerenciados pela mesma equipe.
- Para centralizar os indicadores chave de desempenho, como tempos de resposta e taxas de falha, em um painel por padrão. Segmente por nome de função no Metrics Explorer se necessário.
- Quando não é necessário um gerenciamento diferente de controle de acesso baseado em função do Azure entre componentes do aplicativo.
- Quando critérios de alerta de métricas idênticas, exportações contínuas e gerenciamento de cobranças/cotas entre componentes são suficientes.
- Quando é aceitável para uma chave de API acessar dados de todos os componentes igualmente, e 10 chaves de API atendem às necessidades em todos os componentes.
- Quando as mesmas configurações de detecção inteligente e de integração de itens de trabalho são adequadas 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
Para ativar as experiências do portal, adicione código personalizado para atribuir valores significativos ao atributo Cloud_RoleName. Sem esses valores, os recursos do portal não funcionam.
Para aplicativos do Azure Service Fabric e serviços de nuvem clássicos, o SDK configura os serviços automaticamente ao ler do Ambiente de Função do Azure. Para outros tipos de aplicativo, normalmente você precisa defini-lo explicitamente.
As métricas dinâmicas não podem dividir dados por nome de função.
Criar mais recursos do Application Insights
Para criar um recurso do Application Insights, confira Criar um recurso do Application Insights.
Aviso
Você poderá incorrer em custos de rede adicionais se o recurso do Application Insights estiver monitorando um recurso do Azure (ou seja, produtor de telemetria) em uma região diferente. Os custos variam dependendo da região de onde vem a telemetria e para onde está indo. Consulte Preços da largura de banda do Azure para obter detalhes.
Obtenha a cadeia de conexão
A cadeia de conexão identifica o recurso que você criou.
Você precisa das cadeias de conexão de todos os recursos para os quais seu aplicativo envia dados.
Filtrar por número de build
Quando publicar uma nova versão do seu aplicativo, você poderá separar a telemetria de 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
TelemetryClientsejam configuradas de maneira consistente.ASP.NET: defina a versão em
BuildInfo.config. O módulo Web obtém 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.configautomaticamente 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 comoBuildInfo.config.O rótulo da compilação contém um espaço reservado
(*AutoGen_...*)quando você cria 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.*emAssemblyReference.cs.
Versão e controle de versão
Para rastrear a versão do aplicativo, verifique se o processo do Microsoft Build Engine gera buildinfo.config. 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 Microsoft Build Engine gera exclusivamente o número da versão do build, não o build do 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.
Perguntas frequentes
Esta seção fornece respostas para perguntas comuns.
Como fazer para mover um recurso do Application Insights para uma nova região?
Não há suporte para a transferência de recursos existentes do Application Insights entre regiões, e você não pode migrar dados históricos para uma nova região. A solução alternativa envolve:
- Criar um novo recurso do Application Insights baseado no workspace na região desejada.
- Recriar todas as personalizações exclusivas do recurso original no novo.
- Atualizar seu aplicativo com a cadeia de conexão do novo recurso de região.
- Testar para garantir que tudo funcione conforme o esperado com o novo recurso do Application Insights.
- Decidir manter ou excluir o recurso original do Application Insights. A exclusão de um recurso clássico significa perder todos os dados históricos. Se o recurso for baseado em workspace, os dados permanecerão no Log Analytics, permitindo o acesso aos dados históricos até que o período de retenção expire.
As personalizações exclusivas que normalmente precisam ser recriadas ou atualizadas manualmente para o recurso na nova região incluem, entre outros:
- Recriar pastas de trabalho e painéis personalizados.
- Recriar ou atualizar o escopo de qualquer alerta de log/métrica personalizado.
- Recriar alertas de disponibilidade.
- Recriar qualquer configuração personalizada do controle de acesso baseado em função do Azure que é necessária para os usuários acessarem o novo recurso.
- Replicar as configurações que envolvem amostragem de ingestão, retenção de dados, limite diário e habilitação de métricas personalizadas. Essas configurações são controladas por meio do painel Uso e custos estimados.
- Qualquer integração que dependa de chaves de API, como anotações de versão e canal de controle seguro do Live Metrics. Você precisa gerar novas chaves de API e atualizar a integração associada.
- A exportação contínua em recursos clássicos deve ser configurada novamente.
- As configurações de diagnóstico em recursos baseados em workspace devem ser definidas novamente.
Posso usar providers('Microsoft.Insights', 'components').apiVersions[0] nas minhas implantações do Azure Resource Manager?
Não é recomendável usar esse método de preenchimento da versão da API. A versão mais recente pode representar versões prévias que podem conter alterações interruptivas. Mesmo com versões não prévias mais recentes, as versões da API nem sempre são compatíveis com versões anteriores com modelos existentes. Em alguns casos, a versão da API pode não estar disponível para todas as assinaturas.