Wykonywanie zapytań o interfejsy API magazynu zdarzeń dla zdarzeń klastra

W tym artykule opisano sposób wykonywania zapytań dotyczących interfejsów API magazynu zdarzeń dostępnych w usłudze Service Fabric w wersji 6.2 lub nowszej — jeśli chcesz dowiedzieć się więcej o usłudze EventStore, zobacz Omówienie usługi EventStore. Obecnie usługa EventStore może uzyskiwać dostęp tylko do danych z ostatnich 7 dni (jest to oparte na zasadach przechowywania danych diagnostycznych klastra).

Uwaga

Interfejsy API magazynu zdarzeń są ogólnie dostępne jako usługa Service Fabric w wersji 6.4 tylko dla klastrów systemu Windows działających na platformie Azure.

Dostęp do interfejsów API magazynu zdarzeń można uzyskać bezpośrednio za pośrednictwem punktu końcowego REST lub programowo. W zależności od zapytania istnieje kilka parametrów, które są wymagane do zebrania odpowiednich danych. Te parametry zwykle obejmują:

• api-version: wersja używanych interfejsów API magazynu zdarzeń
• StartTimeUtc: definiuje początek okresu, na którym chcesz się przyjrzeć
• EndTimeUtc: koniec okresu

Oprócz tych parametrów dostępne są również opcjonalne parametry, takie jak:

• timeout: zastępuje domyślny limit czasu 60 sekund na potrzeby wykonywania operacji żądania
• eventstypesfilter: zapewnia to opcję filtrowania pod kątem określonych typów zdarzeń
• ExcludeAnalysisEvents: nie zwracaj zdarzeń "Analysis". Domyślnie zapytania magazynu zdarzeń będą zwracane ze zdarzeniami "analysis", jeśli to możliwe. Zdarzenia analizy to bogatsze zdarzenia kanału operacyjnego, które zawierają dodatkowy kontekst lub informacje poza zwykłym zdarzeniem usługi Service Fabric i zapewniają większą głębię.
• SkipCorrelationLookup: nie wyszukuj potencjalnych skorelowanych zdarzeń w klastrze. Domyślnie magazyn zdarzeń podejmie próbę skorelowania zdarzeń w klastrze i połączy zdarzenia razem, gdy jest to możliwe.

Każda jednostka w klastrze może być zapytaniami dotyczącymi zdarzeń. Możesz również wykonywać zapytania dotyczące zdarzeń dla wszystkich jednostek typu. Można na przykład wykonywać zapytania dotyczące zdarzeń dla określonego węzła lub dla wszystkich węzłów w klastrze. Bieżący zestaw jednostek, dla których można wykonywać zapytania dotyczące zdarzeń, to (ze strukturą zapytania):

• Klaster: /EventsStore/Cluster/Events
• Węzłów: /EventsStore/Nodes/Events
• Węzeł: /EventsStore/Nodes/<NodeName>/$/Events
• Aplikacji: /EventsStore/Applications/Events
• Aplikacja: /EventsStore/Applications/<AppName>/$/Events
• Usługi: /EventsStore/Services/Events
• Usługa: /EventsStore/Services/<ServiceName>/$/Events
• Partycji: /EventsStore/Partitions/Events
• Partycja: /EventsStore/Partitions/<PartitionID>/$/Events
• Repliki: /EventsStore/Partitions/<PartitionID>/$/Replicas/Events
• Replika: /EventsStore/Partitions/<PartitionID>/$/Replicas/<ReplicaID>/$/Events

Uwaga

W przypadku odwoływania się do aplikacji lub nazwy usługi zapytanie nie musi zawierać prefiksu "fabric:/". Ponadto jeśli nazwy aplikacji lub usługi mają w nich wartość "/", przełącz ją na "~", aby zachować działanie zapytania. Jeśli na przykład aplikacja będzie wyświetlana jako "fabric:/App1/FrontendApp", zapytania specyficzne dla aplikacji będą ustrukturyzowane jako /EventsStore/Applications/App1~FrontendApp/$/Events. Ponadto raporty kondycji dla usług są obecnie wyświetlane w odpowiedniej aplikacji, więc zapytania dotyczące DeployedServiceHealthReportCreated zdarzeń dla odpowiedniej jednostki aplikacji.

Wykonywanie zapytań względem magazynu zdarzeń za pośrednictwem punktów końcowych interfejsu API REST

Magazyn zdarzeń można wykonać bezpośrednio za pośrednictwem punktu końcowego REST, wysyłając GET żądania do: <your cluster address>/EventsStore/<entity>/Events/.

Aby na przykład wykonać zapytanie dotyczące wszystkich zdarzeń klastra między 2018-04-03T18:00:00Z i 2018-04-04T18:00:00Z, żądanie wygląda następująco:

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

Może to spowodować zwrócenie żadnych zdarzeń lub wyświetlenie listy zdarzeń zwróconych w formacie 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
  }
]

W tym miejscu widać, że między 2018-04-03T18:00:00Z i 2018-04-04T18:00:00Zten klaster pomyślnie zakończył swoje pierwsze uaktualnienie, gdy został on po raz pierwszy wstał, od "CurrentClusterVersion": "0.0.0.0:" do "TargetClusterVersion": "6.2:1.0", w ."OverallUpgradeElapsedTimeInMs": "120196.5212"

Programowe wykonywanie zapytań względem magazynu zdarzeń

Możesz również programowo wykonać zapytanie dotyczące magazynu zdarzeń za pośrednictwem biblioteki klienta usługi Service Fabric.

Po skonfigurowaniu klienta usługi Service Fabric możesz wykonywać zapytania dotyczące zdarzeń, korzystając z magazynu zdarzeń w następujący sposób: sfhttpClient.EventStore.<request>

Oto przykładowe żądanie dla wszystkich zdarzeń klastra między 2018-04-03T18:00:00Z i 2018-04-04T18:00:00Z, za pośrednictwem GetClusterEventListAsync funkcji .

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

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

Oto kolejny przykład, który wysyła zapytania dotyczące kondycji klastra i wszystkich zdarzeń węzłów we wrześniu 2018 r. i wyświetla je.

  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);
      }
  }

Przykładowe scenariusze i zapytania

Poniżej przedstawiono kilka przykładów dotyczących sposobu wywoływania interfejsów API REST magazynu zdarzeń, aby zrozumieć stan klastra.

Uaktualnienia klastra:

Aby zobaczyć, kiedy klaster został pomyślnie uaktualniony lub podjęto próbę uaktualnienia w zeszłym tygodniu, możesz wykonać zapytanie o interfejsy API pod kątem ostatnio ukończonych uaktualnień do klastra, wykonując zapytanie dotyczące zdarzeń "ClusterUpgradeCompleted" w magazynie zdarzeń: 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

Problemy z uaktualnianiem klastra:

Podobnie, jeśli wystąpiły problemy z niedawnym uaktualnieniem klastra, możesz wykonać zapytanie o wszystkie zdarzenia dla jednostki klastra. Zobaczysz różne zdarzenia, w tym inicjację uaktualnień i każdą wersję zdefiniowaną przez użytkownika, dla której uaktualnienie zostanie pomyślnie przerzucone. Zobaczysz również zdarzenia dla punktu, w którym rozpoczęto wycofywanie i odpowiednie zdarzenia kondycji. Oto zapytanie, którego należy użyć w tym celu: 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

Zmiany stanu węzła:

Aby wyświetlić zmiany stanu węzła w ciągu ostatnich kilku dni — kiedy węzły poszły w górę lub w dół albo zostały aktywowane lub dezaktywowane (przez platformę, usługę chaosu lub dane wejściowe użytkownika) — użyj następującego zapytania: 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

Zdarzenia aplikacji:

Możesz również śledzić ostatnie wdrożenia i uaktualnienia aplikacji. Użyj następującego zapytania, aby wyświetlić wszystkie zdarzenia aplikacji w klastrze: 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

Kondycja historyczna aplikacji:

Oprócz wyświetlania tylko zdarzeń cyklu życia aplikacji możesz również zobaczyć dane historyczne dotyczące kondycji określonej aplikacji. Można to zrobić, określając nazwę aplikacji, dla której chcesz zebrać dane. Użyj tego zapytania, aby pobrać wszystkie zdarzenia kondycji aplikacji: 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. Jeśli chcesz uwzględnić zdarzenia kondycji, które mogły wygasły (minęły czas wygaśnięcia), dodaj ,ApplicationHealthReportExpired do końca zapytania, aby odfiltrować dwa typy zdarzeń.

Kondycja historyczna dla wszystkich usług w usłudze "myApp":

Obecnie zdarzenia raportu kondycji dla usług są wyświetlane jako DeployedServicePackageNewHealthReport zdarzenia w ramach odpowiedniej jednostki aplikacji. Aby zobaczyć, jak usługi są używane dla aplikacji "App1", użyj następującego zapytania: 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

Ponowna konfiguracja partycji:

Aby wyświetlić wszystkie ruchy partycji, które wystąpiły w klastrze, wykonaj zapytanie o PartitionReconfigured zdarzenie. Może to ułatwić ustalenie, jakie obciążenia działały w określonym czasie, podczas diagnozowania problemów w klastrze. Oto przykładowe zapytanie, które wykonuje: 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

Usługa chaosu:

Występuje zdarzenie, gdy usługa Chaos jest uruchomiona lub zatrzymana, która jest widoczna na poziomie klastra. Aby zobaczyć ostatnie użycie usługi Chaos, użyj następującego zapytania: 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