Coletar, consultar e visualizar estados de integridade
Para representar com precisão um modelo de integridade, você precisa coletar vários conjuntos de dados do sistema. Os conjuntos de dados incluem logs e métricas de desempenho de componentes do aplicativo e recursos subjacentes do Azure. É importante correlacionar dados entre os conjuntos de dados para criar uma representação em camadas de integridade do sistema.
Como instrumentar o código e a infraestrutura
Um coletor de dados unificado é necessário para garantir que todos os dados operacionais sejam armazenados e estejam disponíveis em um só local em que toda a telemetria será coletada. Por exemplo, quando um funcionário cria um comentário no navegador da Web, você pode acompanhar essa operação e ver que a solicitação passou pela API de Catálogo e foi para os Hubs de Eventos do Azure. A partir daí, o comentário foi coletado pelo processador em segundo plano e armazenado no Azure Cosmos DB.
O Log Analytics do Azure Monitor funciona como o principal coletor de dados unificado nativo do Azure para armazenar e analisar dados operacionais:
O Application Insights é a ferramenta de APM (Monitoramento do desempenho de aplicativos) recomendada em todos os componentes do aplicativo para coletar logs, métricas e rastreamentos do aplicativo. O Application Insights é implantado em uma configuração baseada em workspace em cada região.
No aplicativo de exemplo, o Azure Functions é usado no Microsoft .NET 6 para os serviços de back-end na integração nativa. Como os aplicativos de back-end já existem, a Contoso Shoes apenas cria um recurso do Application Insights no Azure e define a configuração
APPLICATIONINSIGHTS_CONNECTION_STRINGnos dois aplicativos de funções. O Azure Functions Runtime registra o provedor de log do Application Insights automaticamente, portanto, a telemetria aparece no Azure sem exigir outras ações. Para um registro em log mais personalizado, você pode usar a interfaceILogger.O conjunto de dados centralizado é um antipadrão para cargas de trabalho críticas. Cada região precisa ter um workspace do Log Analytics dedicado e uma instância do Application Insights. Para recursos globais, são recomendadas instâncias separadas. Para ver o padrão de arquitetura principal, confira Padrão de arquitetura para cargas de trabalho críticas no Azure.
Cada camada deve enviar dados para o mesmo workspace do Log Analytics, visando facilitar a análise e os cálculos de integridade.
Consultas de monitoramento de integridade
O Log Analytics, o Application Insights e o Azure Data Explorer usam a KQL (Linguagem de Consulta Kusto) nas consultas. Você pode usar o KQL para criar consultas e usar funções para buscar métricas e calcular pontuações de integridade.
Para serviços individuais que calculam o status de integridade, confira as consultas de exemplo a seguir.
API de catálogo
O seguinte exemplo demonstra uma consulta da API de Catálogo:
let _maxAge = 2d; // Include data only from the last two days
let _timespanStart = ago(_maxAge); // Start time for the time span
let _timespanEnd = now(-2m); // Account for ingestion lag by stripping the last 2m
// For time frame, compare the averages to the following threshold values
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
"failureCount", 10, 50, // Failed requests, anything non-200, allow a few more than 0 for user-caused errors like 404s
"avgProcessingTime", 150, 500 // Average duration of the request, in ms
];
// Calculate average processing time for each request
let avgProcessingTime = AppRequests
| where AppRoleName startswith "CatalogService"
| where OperationName != "GET /health/liveness" // Liveness requests don't do any processing, including them would skew the results
| make-series Value = avg(DurationMs) default=0 on TimeGenerated from _timespanStart to _timespanEnd step 1m
| mv-expand TimeGenerated, Value
| extend TimeGenerated = todatetime(TimeGenerated), Value=toreal(Value), MetricName= 'avgProcessingTime';
// Calculate failed requests
let failureCount = AppRequests
| where AppRoleName startswith "CatalogService" // Liveness requests don't do any processing, including them would skew the results
| where OperationName != "GET /health/liveness"
| make-series Value=countif(Success != true) default=0 on TimeGenerated from _timespanStart to _timespanEnd step 1m
| mv-expand TimeGenerated, Value
| extend TimeGenerated = todatetime(TimeGenerated), Value=toreal(Value), MetricName= 'failureCount';
// Union all together and join with the thresholds
avgProcessingTime
| union failureCount
| lookup kind = inner Thresholds on MetricName
| extend IsYellow = iff(todouble(Value) > YellowThreshold and todouble(Value) < RedThreshold, 1, 0)
| extend IsRed = iff(todouble(Value) > RedThreshold, 1, 0)
| project-reorder TimeGenerated, MetricName, Value, IsYellow, IsRed, YellowThreshold, RedThreshold
| extend ComponentName="CatalogService"
Cofre de Chave do Azure
O seguinte exemplo demonstra uma consulta do Azure Key Vault:
let _maxAge = 2d; // Include data only from the last two days
let _timespanStart = ago(_maxAge); // Start time for the time span
let _timespanEnd = now(-2m); // Account for ingestion lag by stripping the last 2m
// For time frame, compare the averages to the following threshold values
let Thresholds = datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
"failureCount", 3, 10 // Failure count on key vault requests
];
let failureStats = AzureDiagnostics
| where TimeGenerated > _timespanStart
| where ResourceProvider == "MICROSOFT.KEYVAULT"
// Ignore authentication operations that have a 401. This is normal when using Key Vault SDK. First an unauthenticated request is made, then the response is used for authentication
| where Category=="AuditEvent" and not (OperationName == "Authentication" and httpStatusCode_d == 401)
| where OperationName in ('SecretGet','SecretList','VaultGet') or '*' in ('SecretGet','SecretList','VaultGet')
// Exclude Not Found responses because these happen regularly during 'Terraform plan' operations, when Terraform checks for the existence of secrets
| where ResultSignature != "Not Found"
// Create ResultStatus with all the 'success' results bucketed as 'Success'
// Certain operations like StorageAccountAutoSyncKey have no ResultSignature; for now, also set to 'Success'
| extend ResultStatus = case ( ResultSignature == "", "Success",
ResultSignature == "OK", "Success",
ResultSignature == "Accepted", "Success",
ResultSignature);
failureStats
| make-series Value=countif(ResultStatus != "Success") default=0 on TimeGenerated from _timespanStart to _timespanEnd step 1m
| mv-expand TimeGenerated, Value
| extend TimeGenerated = todatetime(TimeGenerated), Value=toreal(Value), MetricName="failureCount", ComponentName="Keyvault"
| lookup kind = inner Thresholds on MetricName
| extend IsYellow = iff(todouble(Value) > YellowThreshold and todouble(Value) < RedThreshold, 1, 0)
| extend IsRed = iff(todouble(Value) > RedThreshold, 1, 0)
Pontuação de Integridade do serviço de catálogo
Por fim, você pode unir várias consultas de status de integridade para calcular uma pontuação de integridade de um componente. A seguinte consulta de exemplo mostra como calcular uma pontuação de integridade do serviço de catálogo:
CatalogServiceHealthStatus()
| union AksClusterHealthStatus()
| union KeyvaultHealthStatus()
| union EventHubHealthStatus()
| where TimeGenerated < ago(2m)
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed) by bin(TimeGenerated, 2m)
| extend HealthScore = 1 - (YellowScore * 0.25) - (RedScore * 0.5)
| extend ComponentName = "CatalogService", Dependencies="AKSCluster,Keyvault,EventHub" // These values are added to build the dependency visualization
| order by TimeGenerated desc
Dica
Veja mais exemplos de consulta no repositório do GitHub Azure Mission-Critical Online.
Configurar alertas baseados em consulta
Os alertas chamam a atenção imediata para problemas que refletem ou afetam o estado de integridade. Sempre que houver uma alteração no estado de integridade, seja para um estado degradado (amarelo) ou para um estado não íntegro (vermelho), as notificações deverão ser enviadas para a equipe responsável. Defina alertas no nó raiz do modelo de integridade para tomar conhecimento imediatamente de qualquer alteração no estado de integridade da solução que afete os negócios. Depois, você poderá examinar as visualizações do modelo de integridade para obter mais informações e solucionar problemas.
O exemplo usa alertas do Azure Monitor para gerar ações automatizadas em resposta a alterações no estado de integridade do aplicativo.
Usar painéis para visualização
É importante visualizar o modelo de integridade para entender rapidamente o efeito de uma interrupção de componente em todo o sistema. A meta final de um modelo de integridade é facilitar o diagnóstico rápido fornecendo uma visão informada sobre desvios do estado estável.
Uma forma comum de visualizar informações de integridade do sistema é combinar uma exibição de modelo de integridade em camadas com funcionalidades de busca detalhada de telemetria em um painel.
A tecnologia do painel deve ser capaz de representar o modelo de integridade. As opções populares incluem Painéis do Azure, Power BI e Espaço Gerenciado do Azure para Grafana.