Share via

Consultar APIs eventStore para eventos de cluster

  • Artigo

Este artigo aborda como consultar as APIs eventStore que estão disponíveis na versão 6.2 e posterior do Service Fabric - se quiser saber mais sobre o serviço EventStore, consulte a descrição geral do serviço EventStore. Atualmente, o serviço EventStore só pode aceder aos dados dos últimos 7 dias (isto baseia-se na política de retenção de dados de diagnóstico do cluster).

Nota

As APIs eventStore são GA a partir da versão 6.4 do Service Fabric para apenas clusters do Windows em execução no Azure.

As APIs eventStore podem ser acedidas diretamente através de um ponto final REST ou através de programação. Dependendo da consulta, existem vários parâmetros necessários para recolher os dados corretos. Normalmente, estes parâmetros incluem:

  • api-version: a versão das APIs eventStore que está a utilizar
  • StartTimeUtc: define o início do período em que está interessado em analisar
  • EndTimeUtc: fim do período de tempo

Além destes parâmetros, também existem parâmetros opcionais disponíveis, tais como:

  • timeout: substitua o tempo limite predefinido de 60 segundos para executar a operação de pedido
  • eventstypesfilter: isto dá-lhe a opção de filtrar por tipos de eventos específicos
  • ExcludeAnalysisEvents: não devolver eventos de "Análise". Por predefinição, as consultas eventStore serão devolvidas com eventos de "análise" sempre que possível. Os eventos de análise são eventos de canais operacionais mais avançados que contêm contexto ou informações adicionais para além de um evento normal do Service Fabric e fornecem mais profundidade.
  • SkipCorrelationLookup: não procure potenciais eventos correlacionados no cluster. Por predefinição, a EventStore tentará correlacionar eventos num cluster e associará os eventos sempre que possível.

Cada entidade num cluster pode ser consulta para eventos. Também pode consultar eventos para todas as entidades do tipo. Por exemplo, pode consultar eventos para um nó específico ou para todos os nós no cluster. O conjunto atual de entidades para as quais pode consultar eventos é (com a forma como a consulta seria estruturada):

  • Cluster: /EventsStore/Cluster/Events
  • Nós: /EventsStore/Nodes/Events
  • Nó: /EventsStore/Nodes/<NodeName>/$/Events
  • Aplicações: /EventsStore/Applications/Events
  • Aplicação: /EventsStore/Applications/<AppName>/$/Events
  • Serviços: /EventsStore/Services/Events
  • Serviço: /EventsStore/Services/<ServiceName>/$/Events
  • Partições: /EventsStore/Partitions/Events
  • Partição: /EventsStore/Partitions/<PartitionID>/$/Events
  • Réplicas: /EventsStore/Partitions/<PartitionID>/$/Replicas/Events
  • Réplica: /EventsStore/Partitions/<PartitionID>/$/Replicas/<ReplicaID>/$/Events

Nota

Ao referenciar um nome de aplicação ou serviço, a consulta não precisa de incluir os "recursos de infraestrutura:/" prefixo. Além disso, se os nomes da sua aplicação ou serviço tiverem um "/", mude-o para "~" para manter a consulta a funcionar. Por exemplo, se a sua aplicação aparecer como "fabric:/App1/FrontendApp", as consultas específicas da aplicação serão estruturadas como /EventsStore/Applications/App1~FrontendApp/$/Events. Além disso, os relatórios de estado de funcionamento dos serviços atualmente são apresentados na aplicação correspondente, para DeployedServiceHealthReportCreated que possa consultar eventos para a entidade de aplicação correta.

Consultar o EventStore através de pontos finais da API REST

Pode consultar o EventStore diretamente através de um ponto final REST ao fazer GET pedidos para: <your cluster address>/EventsStore/<entity>/Events/.

Por exemplo, para consultar todos os eventos do Cluster entre 2018-04-03T18:00:00Z e 2018-04-04T18:00:00Z, o seu pedido teria o seguinte aspeto:

Method: GET 
URL: http://mycluster:19080/EventsStore/Cluster/Events?api-version=6.4&StartTimeUtc=2018-04-03T18:00:00Z&EndTimeUtc=2018-04-04T18:00:00Z

Isto pode não devolver eventos ou a lista de eventos devolvidos no json:

Response: 200
Body:
[
  {
    "Kind": "ClusterUpgradeStart",
    "CurrentClusterVersion": "0.0.0.0:",
    "TargetClusterVersion": "6.2:1.0",
    "UpgradeType": "Rolling",
    "RollingUpgradeMode": "UnmonitoredAuto",
    "FailureAction": "Manual",
    "EventInstanceId": "090add3c-8f56-4d35-8d57-a855745b6064",
    "TimeStamp": "2018-04-03T20:18:59.4313064Z",
    "HasCorrelatedEvents": false
  },
  {
    "Kind": "ClusterUpgradeDomainComplete",
    "TargetClusterVersion": "6.2:1.0",
    "UpgradeState": "RollingForward",
    "UpgradeDomains": "(0 1 2)",
    "UpgradeDomainElapsedTimeInMs": "78.5288",
    "EventInstanceId": "090add3c-8f56-4d35-8d57-a855745b6064",
    "TimeStamp": "2018-04-03T20:19:59.5729953Z",
    "HasCorrelatedEvents": false
  },
  {
    "Kind": "ClusterUpgradeDomainComplete",
    "TargetClusterVersion": "6.2:1.0",
    "UpgradeState": "RollingForward",
    "UpgradeDomains": "(3 4)",
    "UpgradeDomainElapsedTimeInMs": "0",
    "EventInstanceId": "090add3c-8f56-4d35-8d57-a855745b6064",
    "TimeStamp": "2018-04-03T20:20:59.6271949Z",
    "HasCorrelatedEvents": false
  },
  {
    "Kind": "ClusterUpgradeComplete",
    "TargetClusterVersion": "6.2:1.0",
    "OverallUpgradeElapsedTimeInMs": "120196.5212",
    "EventInstanceId": "090add3c-8f56-4d35-8d57-a855745b6064",
    "TimeStamp": "2018-04-03T20:20:59.8134457Z",
    "HasCorrelatedEvents": false
  }
]

Aqui, podemos ver que entre 2018-04-03T18:00:00Z e 2018-04-04T18:00:00Z, este cluster concluiu com êxito a sua primeira atualização quando foi colocado em pé pela primeira vez, de "CurrentClusterVersion": "0.0.0.0:" para "TargetClusterVersion": "6.2:1.0", em "OverallUpgradeElapsedTimeInMs": "120196.5212".

Consultar o EventStore através de programação

Também pode consultar o EventStore através de programação através da biblioteca de cliente do Service Fabric.

Assim que tiver o cliente do Service Fabric configurado, pode consultar eventos acedendo à EventStore da seguinte forma: sfhttpClient.EventStore.<request>

Eis um pedido de exemplo para todos os eventos de cluster entre 2018-04-03T18:00:00Z e 2018-04-04T18:00:00Z, através da GetClusterEventListAsync função.

var sfhttpClient = ServiceFabricClientFactory.Create(clusterUrl, settings);

var clstrEvents = sfhttpClient.EventsStore.GetClusterEventListAsync(
    "2018-04-03T18:00:00Z",
    "2018-04-04T18:00:00Z")
    .GetAwaiter()
    .GetResult()
    .ToList();

Eis outro exemplo que consulta o estado de funcionamento do cluster e todos os eventos de nós em setembro de 2018 e os imprime.

  const int timeoutSecs = 60;
  var clusterUrl = new Uri(@"http://localhost:19080"); // This example is for a Local cluster
  var sfhttpClient = ServiceFabricClientFactory.Create(clusterUrl);

  var clusterHealth = sfhttpClient.Cluster.GetClusterHealthAsync().GetAwaiter().GetResult();
  Console.WriteLine("Cluster Health: {0}", clusterHealth.AggregatedHealthState.Value.ToString());

  
  Console.WriteLine("Querying for node events...");
  var nodesEvents = sfhttpClient.EventsStore.GetNodesEventListAsync(
      "2018-09-01T00:00:00Z",
      "2018-09-30T23:59:59Z",
      timeoutSecs,
      "NodeDown,NodeUp")
      .GetAwaiter()
      .GetResult()
      .ToList();
  Console.WriteLine("Result Count: {0}", nodesEvents.Count());

  foreach (var nodeEvent in nodesEvents)
  {
      Console.Write("Node event happened at {0}, Node name: {1} ", nodeEvent.TimeStamp, nodeEvent.NodeName);
      if (nodeEvent is NodeDownEvent)
      {
          var nodeDownEvent = nodeEvent as NodeDownEvent;
          Console.WriteLine("(Node is down, and it was last up at {0})", nodeDownEvent.LastNodeUpAt);
      }
      else if (nodeEvent is NodeUpEvent)
      {
          var nodeUpEvent = nodeEvent as NodeUpEvent;
          Console.WriteLine("(Node is up, and it was last down at {0})", nodeUpEvent.LastNodeDownAt);
      }
  }

Cenários e consultas de exemplo

Eis alguns exemplos sobre como pode chamar as APIs REST do Arquivo de Eventos para compreender o estado do cluster.

Atualizações do cluster:

Para ver a última vez que o cluster foi atualizado com êxito ou tentou ser atualizado na semana passada, pode consultar as APIs para atualizações recentemente concluídas para o cluster, ao consultar os eventos "ClusterUpgradeCompleted" no EventStore: https://mycluster.cloudapp.azure.com:19080/EventsStore/Cluster/Events?api-version=6.4&starttimeutc=2017-04-22T17:01:51Z&endtimeutc=2018-04-29T17:02:51Z&EventsTypesFilter=ClusterUpgradeCompleted

Problemas de atualização do cluster:

Da mesma forma, se houvesse problemas com uma atualização recente do cluster, poderia consultar todos os eventos para a entidade do cluster. Verá vários eventos, incluindo o início de atualizações e cada UD para o qual a atualização foi implementada com êxito. Também verá eventos do ponto em que a reversão foi iniciada e os eventos de estado de funcionamento correspondentes. Eis a consulta que utilizaria para o seguinte: https://mycluster.cloudapp.azure.com:19080/EventsStore/Cluster/Events?api-version=6.4&starttimeutc=2017-04-22T17:01:51Z&endtimeutc=2018-04-29T17:02:51Z

Alterações ao estado do nó:

Para ver as alterações ao estado do nó nos últimos dias – quando os nós subiram ou desceram ou foram ativados ou desativados (pela plataforma, pelo serviço de caos ou pela entrada do utilizador) – utilize a seguinte consulta: https://mycluster.cloudapp.azure.com:19080/EventsStore/Nodes/Events?api-version=6.4&starttimeutc=2017-04-22T17:01:51Z&endtimeutc=2018-04-29T17:02:51Z

Eventos da aplicação:

Também pode controlar as implementações e atualizações de aplicações recentes. Utilize a seguinte consulta para ver todos os eventos da aplicação no cluster: https://mycluster.cloudapp.azure.com:19080/EventsStore/Applications/Events?api-version=6.4&starttimeutc=2017-04-22T17:01:51Z&endtimeutc=2018-04-29T17:02:51Z

Estado de funcionamento histórico de uma aplicação:

Além de ver apenas eventos de ciclo de vida da aplicação, também poderá querer ver dados históricos sobre o estado de funcionamento de uma aplicação específica. Pode fazê-lo ao especificar o nome da aplicação para o qual pretende recolher os dados. Utilize esta consulta para obter todos os eventos de estado de funcionamento da aplicação: https://mycluster.cloudapp.azure.com:19080/EventsStore/Applications/myApp/$/Events?api-version=6.4&starttimeutc=2018-03-24T17:01:51Z&endtimeutc=2018-03-29T17:02:51Z&EventsTypesFilter=ApplicationNewHealthReport. Se quiser incluir eventos de estado de funcionamento que possam ter expirado (passaram o tempo de vida (TTL)), adicione ,ApplicationHealthReportExpired ao final da consulta, para filtrar dois tipos de eventos.

Estado de funcionamento histórico para todos os serviços no "myApp":

Atualmente, os eventos de relatórios de estado de funcionamento dos serviços são apresentados como DeployedServicePackageNewHealthReport eventos na entidade da aplicação correspondente. Para ver como os seus serviços têm estado a ser utilizados para a "App1", utilize a seguinte consulta: https://mycluster.cloudapp.azure.com:19080/EventsStore/Applications/myapp/$/Events?api-version=6.4&starttimeutc=2017-04-22T17:01:51Z&endtimeutc=2018-04-29T17:02:51Z&EventsTypesFilter=DeployedServicePackageNewHealthReport

Reconfiguração da partição:

Para ver todos os movimentos de partição que ocorreram no cluster, consulte o PartitionReconfigured evento. Isto pode ajudá-lo a descobrir que cargas de trabalho foram executadas em que nó em alturas específicas, ao diagnosticar problemas no cluster. Eis uma consulta de exemplo que o faz: https://mycluster.cloudapp.azure.com:19080/EventsStore/Partitions/Events?api-version=6.4&starttimeutc=2018-04-22T17:01:51Z&endtimeutc=2018-04-29T17:02:51Z&EventsTypesFilter=PartitionReconfigured

Serviço chaos:

Existe um evento para quando o serviço Chaos é iniciado ou parado que é exposto ao nível do cluster. Para ver a utilização recente do serviço Chaos, utilize a seguinte consulta: https://mycluster.cloudapp.azure.com:19080/EventsStore/Cluster/Events?api-version=6.4&starttimeutc=2017-04-22T17:01:51Z&endtimeutc=2018-04-29T17:02:51Z&EventsTypesFilter=ChaosStarted,ChaosStopped