Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Überwachen Sie die Lösung ## Protokollierung und Benachrichtigungen Instance Scheduler verwendet eine strukturierte Protokollierung, die für CloudWatch Logs Insights-Abfragen optimiert ist. Diese Lösung protokolliert Verarbeitungsinformationen für jede mit Tags versehene Instanz, die Ergebnisse der Periodenbewertung für die Instance, den gewünschten Status der Instanz während dieses Zeitraums, die angewandte Aktion und Debugging-Meldungen. Protokolle werden in zwei Protokollgruppen in Amazon CloudWatch Logs geschrieben: `{stackName}-{namespace}-administrative-logs` Protokolle für die Registrierung und Deregistrierung von Ressourcen, benutzerdefinierte Ressourcenoperationen, CLI-Anfragen und andere administrative Aktivitäten. `{stackName}-{namespace}-scheduling-logs` Protokolle für Planungsvorgänge, einschließlich Orchestrierung und Ausführung von Anforderungshandlern. Warn- und Fehlerprotokolle werden auch an ein von der Lösung erstelltes Amazon SNS SNS-Thema weitergeleitet, das so konfiguriert werden kann, dass Nachrichten an eine abonnierte E-Mail-Adresse gesendet werden. Den Namen des Amazon SNS SNS-Themas finden Sie auf der Registerkarte **Outputs** des Lösungsstapels. ## Informations-Tags Wenn informatives Tagging aktiviert ist (Standardeinstellung), schreibt Instance Scheduler Tags direkt in verwaltete Ressourcen, um at-a-glance Einblick in die Planungsaktivitäten der Lösung zu erhalten. Diese Tags werden mithilfe der AWS Resource Groups Tagging API angewendet und jedes Mal aktualisiert, wenn der Scheduler eine Ressource verarbeitet. Sie können diese Funktion mithilfe des Parameters Enable **information Tagging im Hub-Stack aktivieren** oder deaktivieren. Weitere Informationen finden Sie unter [Globale Konfigurationseinstellungen aktualisieren](update-global-configuration-settings.md). ### Tag-Schlüssel zu Informationszwecken Die folgenden Tags werden in verwaltete Ressourcen geschrieben: | Tag-Schlüssel | Description | | --- | --- | | `IS-ManagedBy` | Der ARN des Instance Scheduler-Hub-Stacks, der diese Ressource verwaltet. Wird angewendet, wenn eine Ressource zum ersten Mal für die Planung registriert wird, und bei jeder nachfolgenden Planungsaktion. | | `IS-LastAction` | Die letzte Planungsaktion, die für die Ressource ausgeführt wurde, zusammen mit einem UTC-Zeitstempel. Beispiel: `Started 2025-06-15 09:00:00 UTC` oder `Stopped 2025-06-15 17:00:00 UTC`. Dieses Tag wird nur aktualisiert, wenn der Scheduler eine Ressource aktiv startet oder stoppt (nicht, wenn er eine Ressource auswertet und feststellt, dass keine Aktion erforderlich ist). | | `IS-Error` | Wenn der Scheduler bei der Verarbeitung einer Ressource auf einen Fehler stößt, enthält dieses Tag den Fehlercode und einen UTC-Zeitstempel. Beispiel: `StartFailed 2025-06-15 09:00:05 UTC`. Dieses Tag wird bei der nächsten erfolgreichen Planungsaktion automatisch gelöscht. | | `IS-ErrorMessage` | Eine menschenlesbare Beschreibung des Fehlers. Dieses Tag ist nur vorhanden, wenn `IS-Error` es auch vorhanden ist, und wird daneben gelöscht. | ### Fehlercodes Die folgenden Fehlercodes können im `IS-Error` Tag erscheinen: | Fehlercode | Description | | --- | --- | | `UnknownSchedule` | Der im Zeitplan-Tag der Ressource angegebene Zeitplanname stimmt mit keinem in der Konfigurationstabelle definierten Zeitplan überein. | | `UnsupportedResource` | Der Ressourcentyp wird für die Planung nicht unterstützt (z. B. eine Read Replica einer anderen RDS-Instance). | | `IncompatibleSchedule` | Der der Ressource zugewiesene Zeitplan ist nicht mit dem Ressourcentyp kompatibel (z. B. ein ASG-Zeitplan, der nicht unterstützte Cron-Ausdrücke verwendet). | | `StartFailed` | Der Scheduler hat versucht, die Ressource zu starten, aber der Vorgang ist fehlgeschlagen. | | `StopFailed` | Der Scheduler hat versucht, die Ressource zu stoppen, aber der Vorgang ist fehlgeschlagen. | | `ConfigurationFailed` | Der Scheduler hat versucht, geplante Skalierungsregeln für eine Auto Scaling Scaling-Gruppe zu konfigurieren, aber der Vorgang schlug fehl. | | `UnknownError` | Bei der Verarbeitung der Ressource ist ein unerwarteter Fehler aufgetreten. | ### Verhalten von Tags + Wenn eine Ressource zum ersten Mal für die Planung registriert wird, wird das `IS-ManagedBy` Tag sofort angewendet. + Wenn die Registrierung einer Ressource aufgehoben wird (das Zeitplan-Tag wird entfernt), werden alle Informations-Tags (`IS-ManagedBy`, `IS-LastAction``IS-Error`,`IS-ErrorMessage`) aus der Ressource entfernt. + Fehler-Tags werden nicht in jedem Planungsintervall neu geschrieben, wenn derselbe Fehler weiterhin besteht und das vorhandene Tag immer noch auf der Ressource vorhanden ist. Sie werden nur aktualisiert, wenn sich der Fehlercode ändert. + Alle Tag-Werte werden auf 256 Zeichen gekürzt, um die AWS-Tagging-Beschränkungen einzuhalten. ### Überlegungen zur Tag-Governance **Wichtig** Instance Scheduler erstellt und aktualisiert die oben aufgeführten Tags auf verwalteten Ressourcen im Rahmen des normalen Betriebs. Wenn Ihre Organisation die Tag-Governance durch AWS Config-Regeln, Tag-Richtlinien, Service-Kontrollrichtlinien oder automatisierte Problembehebungen durchsetzt, stellen Sie sicher, dass Ihre Change-Management-Kontrollen so konfiguriert sind, dass sie die folgenden Tag-Schlüssel zulassen: `IS-ManagedBy` `IS-LastAction` `IS-Error` `IS-ErrorMessage` `IS-PreferredInstanceTypes`(wenn Sie alternative Instance-Typen verwenden) `IS-MinDesiredMax`(wenn Auto Scaling-Gruppen geplant werden) Wenn Sie diese Tags nicht in Ihren Governance-Richtlinien berücksichtigen können, deaktivieren Sie das Tagging zu Informationszwecken, indem Sie den Parameter **Informations-Tagging aktivieren auf dem Hub-Stack** `No` auf setzen. Beachten Sie, dass dadurch auch das `IS-ManagedBy` Tag deaktiviert wird, das zur Bestätigung der Ressourcenregistrierung verwendet wird. ### Kontroll-Tags Zusätzlich zu den Informations-Tags verwendet Instance Scheduler die folgenden Kontroll-Tags für bestimmte Funktionen: | Tag-Schlüssel | Description | | --- | --- | | `IS-PreferredInstanceTypes` | Eine durch Kommas getrennte Liste alternativer EC2-Instance-Typen, die ausprobiert werden sollen, wenn das Starten einer Instance aufgrund unzureichender Kapazität fehlschlägt. Weitere Informationen finden Sie unter [Behandlung von EC2-Fehlern](specifying-alternate-instance-types-for-ec2.md) mit unzureichender Kapazität. | | `IS-MinDesiredMax` | Die minimalen, gewünschten und maximalen Kapazitätswerte für eine Auto Scaling Scaling-Gruppe im Format`min,desired,max`. Weitere Informationen finden Sie unter [EC2 Auto Scaling Group Scheduling](ec2-auto-scaling-group-scheduling.md). | ### Tag-Kapazität **Wichtig** AWS-Ressourcen haben in der Regel ein Limit von 50 Tags pro Ressource. Instance Scheduler kann bis zu 6 Tags für eine Ressource verwenden (4 Informations-Tags plus bis zu 2 Kontroll-Tags). Stellen Sie sicher, dass Ihre Ressourcen über ausreichend Tag-Kapazität verfügen, um Instance Scheduler-Tags zusätzlich zu Ihrer bestehenden Tagging-Strategie aufzunehmen. Wenn eine Ressource das Limit von 50 Tags erreicht oder fast erreicht, schlägt das Schreiben von Informationstags möglicherweise fehl. Der Scheduler protokolliert diese Fehler, setzt aber die Planungsvorgänge fort. Überprüfen Sie die CloudWatch Protokolle, wenn Sie Probleme mit der Kennzeichnung vermuten. ## CloudWatch Protokolliert Insights-Abfragen Das strukturierte Protokollierungsformat von Instance Scheduler ermöglicht effizientes Abfragen mithilfe von CloudWatch Logs Insights. Sie können Logs Insights verwenden, um Protokolldaten zu suchen, zu analysieren und zu visualisieren, um Betriebsprobleme zu beheben und die Planungsaktivitäten zu überwachen. Instance Scheduler bietet vorformatierte Protokollabfragen, auf die Sie über den Abschnitt Gespeicherte Abfragen in der CloudWatch Logs-Konsole zugreifen können: `SchedulingHistory` Aktionen zur Abfrageplanung, die an Ressourcen ausgeführt werden, einschließlich Start- und Stoppvorgängen. `RegistrationEvents` Fragen Sie Ereignisse zur Registrierung und Abmeldung von Ressourcen ab. `Errors` Fragen Sie Fehlerprotokolle ab, um Probleme mit der Lösung zu beheben. Weitere Informationen zu CloudWatch Logs Insights finden Sie unter [Analysieren von Protokolldaten mit CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*. ## Dashboard mit operativen Erkenntnissen Das Operational Insights-Dashboard bietet einen Überblick über die Lösungsleistung und die Kosteneinsparungen durch die geplante Instanzverwaltung. Um auf das Dashboard zuzugreifen, stellen Sie sicher, dass **Operational Monitoring** in den Hub-Stack-Parametern auf „aktiviert“ gesetzt ist. Navigieren Sie zu „Dashboards“ CloudWatch und wählen Sie es im Navigationsmenü aus. Der Name des Dashboards lautet *\* {stack-name} -Operational-Insights-Dashboard\**. Das Dashboard zeigt die Anzahl der verwalteten Instanzen, die gespeicherten Betriebsstunden und Leistungskennzahlen der Lambda-Funktionen an. **Übersicht über das Dashboard mit operativen Erkenntnissen** ![OpsDashboardOverview](http://docs.aws.amazon.com/de_de/solutions/latest/instance-scheduler-on-aws/images/OpsDashboardOverview.png) **Anmerkung** Die Informationen in diesen Diagrammen hängen vom Planungsintervall ab, das auf dem Solution Hub-Stack konfiguriert ist. Bei der Aktualisierung des Planungsintervalls der Lösung zeigt das Dashboard nur Planungsmetriken von der Zeit nach der letzten Aktualisierung bis zum Planungsintervall an. Überwachen Sie die Lambda-Ausführungszeiten, um eine optimale Leistung sicherzustellen (siehe [Kontingente](solution-quotas.md)). Wenn sich die Ausführungszeiten durchweg dem Timeout-Schwellenwert nähern, sollten Sie erwägen, die Lambda-Größeneigenschaft zu erhöhen oder Instance Scheduler in einer Region mit geringerer Latenz für Ihre verwalteten Regionen bereitzustellen. **Lambda-Metriken mit Dauer und Fehleranzahl** ![OpsDashboardLambdaMetrics](http://docs.aws.amazon.com/de_de/solutions/latest/instance-scheduler-on-aws/images/OpsDashboardLambdaMetrics.png) ### Zusätzliche Kosten im Zusammenhang mit dieser Funktion Dieses operative Dashboard basiert auf benutzerdefinierten CloudWatch Kennzahlen, die von der Lösung erfasst wurden und für die zusätzliche Kosten anfallen. Diese Funktion kann ausgeschaltet werden, indem „Operational Monitoring“ auf dem Solution Hub-Stack deaktiviert wird. Diese Funktion kostet zusätzlich 3,00 USD/Monat zuzüglich zusätzlicher Skalierungskosten, die von der Größe Ihrer Bereitstellung abhängen. Die Kosten stellen sich wie folgt dar: | Benutzerdefiniertes CloudWatch Dashboard | 3$ | | --- | --- | | Per-instance-type Metriken | 0,90$ pro Instanztyp\* | | API-Nutzung | \~0,10 $ pro [aktivem Ziel\*\*](cost.md#calculating-scheduling-targets) | ***\*Diese Kosten werden pro Servicekategorie (EC2/RDS) und nur für Instance-Typen erfasst, die tatsächlich für die Planung verwendet werden.*** ** **\*** ## EventBridge Ereignisse überwachen Instance Scheduler veröffentlicht Planungs- und Registrierungsereignisse für EventBridge Event-Busse, um Einblick in den Lösungsbetrieb zu erhalten und die Integration mit anderen AWS-Services zu ermöglichen. ### Event types (Ereignistypen) Die Lösung veröffentlicht zwei Hauptkategorien von Ereignissen: **Ereignisse planen**: Wird veröffentlicht, wenn Instance Scheduler Maßnahmen zum Starten, Stoppen oder Konfigurieren verwalteter Ressourcen ergreift. Diese Ereignisse enthalten Details zur Instanz, zum Zeitplan und zu den durchgeführten Aktionen. Starten, Stoppen oder Konfigurieren verwalteter Ressourcen. Zu diesen Ereignissen gehören Details zur Instanz, zum Zeitplan und zu den ergriffenen Maßnahmen. **Registrierungsereignisse**: Werden veröffentlicht, wenn Ressourcen für die Planung auf der Grundlage von Tagging-Vorgängen registriert oder deren Registrierung aufgehoben wird. ### Eventziel **LocalEvents `IS-LocalEvents`IS-Event-Busse**: In jeder verwalteten Region jedes Mitgliedskontos (einschließlich des Hub-Kontos) wird ein Event-Bus bereitgestellt. Jeder Bus empfängt Ereignisse zur Planung von Aktionen und zur Registrierung von Ressourcen innerhalb dieser Region. **GlobalEvents IS-Event-Bus**: Der `IS-GlobalEvents` Event-Bus im Hub-Konto empfängt eine Kopie jedes Ereignisses, das an einen beliebigen `IS-LocalEvents` Event-Bus gesendet wird, und ermöglicht so eine zentrale Überwachung über alle Konten und Regionen hinweg. ### EventBridge Ereignisse verwenden Sie können EventBridge Regeln erstellen, um: + Überwachen Sie die Planungsvorgänge in Ihrer gesamten Infrastruktur + Löst Benachrichtigungen aus, wenn Instanzen gestartet oder gestoppt werden + Integration mit anderen AWS-Services für automatisierte Workflows + Implementieren Sie Compliance-Überwachung und Warnmeldungen ### Ereignisstruktur Alle Ereignisse verwenden das EventBridge Standardformat. Die folgenden Beispiele zeigen die Struktur für jeden Ereignistyp: **Veranstaltung planen:** ``` { "Source": "instance-scheduler", "DetailType": "Scheduling Action", "Resources": ["arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0"], "Detail": { "account": "123456789012", "region": "us-east-1", "service": "ec2", "resource_id": "i-1234567890abcdef0", "requested_action": "Start", "action_taken": "Started", "schedule": "office-hours" } } ``` **Veranstaltung zur Registrierung:** ``` { "Source": "instance-scheduler", "DetailType": "Resource Registered", "Resources": ["arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0"], "Detail": { "account": "123456789012", "region": "us-east-1", "service": "ec2", "resource_id": "i-1234567890abcdef0", "schedule": "office-hours" } } ``` Jede Veranstaltung enthält die folgenden Schlüsselfelder: + `Source`- Identifiziert die Ereignisquelle als „Instance-Scheduler“ + `DetailType`— Gibt die Ereigniskategorie an: „Aktion planen“ für Instanzoperationen oder „Resource Registered“ für Tagging von Ereignissen + `Resources`- Array mit den ARNs betroffenen AWS-Ressourcen + `Detail`- Enthält die Nutzdaten des Ereignisses mit Konto-ID, Region, Servicetyp (ec2/rds), Ressourcen-ID und Namen des Zeitplans. Für die Planung von Ereignissen werden sowohl die angeforderte Aktion als auch das tatsächliche Ergebnis angezeigt Mögliche `requested_action` Werte für die Planung von Ereignissen: + `Start`: Der Scheduler beabsichtigt, die Instanz zu starten + `Stop`: Der Scheduler wollte die Instanz stoppen + `Configure`: Der Scheduler soll die Instanz konfigurieren Mögliche `action_taken` Werte für die Planung von Ereignissen: + `Started`: Die Instanz wurde gestartet + `Stopped`: Die Instanz wurde gestoppt + `Hibernated`: Die Instanz wurde in den Ruhezustand versetzt + `Configured`: Die Instanzkonfiguration wurde geändert + `Error`: Während des Planungsvorgangs ist ein Fehler aufgetreten ### EventBridge Regeln erstellen So überwachen Sie Instance Scheduler-Ereignisse: 1. Navigieren Sie in Ihrem AWS-Konto zur EventBridge Konsole 1. Erstellen Sie eine neue Regel, die entweder auf den `IS-GlobalEvents` Event Bus (für die zentrale Überwachung) oder den `IS-LocalEvents` Event Bus (für die lokale Überwachung) abzielt 1. Definieren Sie Ereignismuster, die den Ereignissen von Instance Scheduler entsprechen 1. Konfigurieren Sie Ziele wie SNS-Themen, Lambda-Funktionen oder Logs CloudWatch Weitere Informationen zu EventBridge finden Sie unter [Was ist Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) im * EventBridge Amazon-Benutzerhandbuch*.