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 wymaganych do zebrania odpowiednich danych. Te parametry zazwyczaj obejmują:

• api-version: wersja używanych interfejsów API magazynu zdarzeń
• StartTimeUtc: definiuje początek okresu, na który 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 dla wykonania operacji żądania
• eventstypesfilter: umożliwia to filtrowanie określonych typów zdarzeń
• ExcludeAnalysisEvents: nie zwracaj zdarzeń "Analiza". 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łębokość.
• 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żna również wykonywać zapytania dotyczące zdarzeń dla wszystkich jednostek typu. Na przykład można 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):

• Klastra: /EventsStore/Cluster/Events
• Węzłów: /EventsStore/Nodes/Events
• Węzła: /EventsStore/Nodes/<NodeName>/$/Events
• Aplikacji: /EventsStore/Applications/Events
• Aplikacji: /EventsStore/Applications/<AppName>/$/Events
• Usług: /EventsStore/Services/Events
• Usługi: /EventsStore/Services/<ServiceName>/$/Events
• Partycji: /EventsStore/Partitions/Events
• Partycji: /EventsStore/Partitions/<PartitionID>/$/Events
• Repliki: /EventsStore/Partitions/<PartitionID>/$/Replicas/Events
• Repliki: /EventsStore/Partitions/<PartitionID>/$/Replicas/<ReplicaID>/$/Events

Uwaga

Podczas odwoływania się do aplikacji lub nazwy usługi zapytanie nie musi zawierać ciągu "fabric:/" Prefiks. Ponadto jeśli nazwa aplikacji lub usługi ma 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", określone zapytania aplikacji będą ustrukturyzowane jako /EventsStore/Applications/App1~FrontendApp/$/Events. Ponadto raporty o kondycji usług są obecnie wyświetlane w odpowiedniej aplikacji, dzięki czemu można wysyłać zapytania o DeployedServiceHealthReportCreated zdarzenia dla odpowiedniej jednostki aplikacji.

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

Magazyn zdarzeń można wykonywać zapytania 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 będzie 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 listę 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:00Z, ten klaster pomyślnie zakończył swoje pierwsze uaktualnienie, gdy został po raz pierwszy wstał, z "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 wykonywać zapytania względem 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 sposobu wywoływania interfejsów API REST magazynu zdarzeń, aby zrozumieć stan klastra.

Uaktualnienia klastra:

Aby zobaczyć ostatni raz 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, wysyłając zapytanie o zdarzenia "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ą uddę, dla której uaktualnienie zostanie pomyślnie przerzucone. Zostaną również wyświetlone zdarzenia dla punktu, w którym rozpoczęto wycofywanie i odpowiednie zdarzenia kondycji. Oto zapytanie, którego chcesz 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 zobaczyć 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 zdezaktywowane (według platformy, usługi chaosu lub danych wejściowych 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 zdarzeń cyklu życia aplikacji możesz również zobaczyć dane historyczne dotyczące kondycji określonej aplikacji. Możesz 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 filtrować dwa typy zdarzeń.

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

Obecnie zdarzenia raportu kondycji dla usług są wyświetlane jako DeployedServicePackageNewHealthReport zdarzenia w odpowiedniej jednostce 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 uruchomiono w węźle 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 uwidoczniona na poziomie klastra. Aby wyświetlić najnowsze 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