Endpunkte zur Zustandsprüfung

Stellen Sie sicher, dass alle Ihre Dienste betriebsbereit sind, indem Sie API-Aufrufe an spezielle Endpunkte, sogenannte Zustandsprüfungsendpunkte, senden.

Diese Endpunkte führen Systemdiagnosen aus und geben einen Status zurück, der Ihnen mitteilt, ob der Dienst, den Sie überprüfen, funktionsfähig ist oder nicht.

Orchestrator – Endpunkt zur Zustandsprüfung

Um die Verfügbarkeit Ihrer Orchestrator-Instanz und ihrer Abhängigkeiten zu überprüfen, verwenden Sie die folgenden Endpunkte:

• Abrufen

  https://{yourDomain}/api/health—überprüft nur kritische Abhängigkeiten

• Abrufen

  https://{yourDomain}/api/health/startup—überprüft jede Abhängigkeit

Standardmäßig geben die obigen Endpunkte der Zustandsprüfung einen leeren Antworttext zurück.

So sehen Sie, welche Systemdiagnosen durchgeführt wurden und welchen Status sie haben:

1. In der Konfigurationszuordnung orchestrator-customconfig (konfiguriert über orchestrator-configurator.sh) und
   Fügen Sie <add key="HealthCheck.DetailsKey" value="12345" /> im Abschnitt <appsettings> hinzu. 12345 dient als Kennwort, mit dem Sie auf die Zustandsprüfungen zugreifen können, also vergessen Sie nicht, es durch einen eigenen Wert zu ändern.
2. Starten Sie IIS neu, um sicherzustellen, dass die Änderung wirksam wird.
3. Verwenden Sie das zuvor festgelegte Kennwort als Abfrageparameter im API-Aufruf zur Zustandsprüfung (z. B. /api/health?detailsKey=password). Wenn erfolgreich, gibt der Aufruf einen Antworttext mit Details zu den Zustandsprüfungen und deren Status zurück.

Sobald Sie diese Schritte ausgeführt haben, ist die Zustandsprüfung auch von einer anderen Maschine als dem Orchestrator-Server aus zugänglich.

Identity Server-Endpunkt zur Zustandsprüfung

Um zu überprüfen, ob der Identity Server funktioniert, verwenden Sie den folgenden Endpunkt:

• GET https://{yourDomain}/identity/health

Der Antworttext dieses Endpunkts fasst die Identity Server-Konfiguration zusammen.

{
    "status": "Healthy",
    "results": {
        "ApplicationDbContext": {
            "status": "Healthy",
            "description": null,
            "data": {}
            },
        "AuditDbContext": {
            "status": "Healthy",
            "description": null,
            "data": {}
            },
        "PersistedGrantDbContext": {
            "status": "Healthy",
            "description": null,
            "data": {}
            },
        "IdentityServerConfigurationDbContext": {
            "status": "Healthy",
            "description": null,
            "data": {}
            }
    }
}

Ein 500-Fehlercode signalisiert einen fehlerhaften Status, kann jedoch immer noch einen Antworttext zurückgeben. Überprüfen Sie den Inhalt des Antworttexts, um die Gründe herauszufinden.

Webhooks-Endpunkt zur Zustandsprüfung

Um die Verfügbarkeit Ihres Webhooks-Dienstes zu überprüfen, verwenden Sie den folgenden Endpunkt:

• GET https://{yourDomain}/webhooks/api/status

Ressourcenkatalogdienst-Endpunkt zur Zustandsprüfung

Um die Verfügbarkeit Ihrer Instanz des Ressourcenkatalogdiensts zu überprüfen, verwenden Sie den folgenden Endpunkt:

• GET/https://{yourDomain}/ResourceCatalog/health

Der Antworttext enthält Healthy, wenn der Dienst in Betrieb ist.

Interpretation des Antwortcodes

Interpretieren Sie den Antwortcode wie folgt:

• 200 OK– Ihr Dienst ist in Betrieb
• 5xx Fehler – Ihr Dienst ist ausgefallen

Einige Systemdiagnosen geben möglicherweise einen 200 OK -Antwortcode und einen Degraded -Status zurück, was bedeutet, dass sich die überprüfte Komponente in einem herabgesetzten Zustand befindet.