So verwalten Sie Cloud Build Alerts

Nachdem Sie mehrere Prozesse mit Cloud Build automatisiert haben, wird es Ihnen langweilig, den Build-Status zu überprüfen. Zum Glück bietet Cloud Build Cloud Build-Melder, um das zu ändern. Leider müssen Sie den Melder für jedes Projekt einsetzen. Daher nutzt dieser Blog die benutzerdefinierten Metriken und Benachrichtigungskanäle, um Benachrichtigungen zentral zu verwalten.

Alert Management erstellen

Anwendungsprojekte veröffentlichen Metriken zum Cloud Build-Status. Das Monitoring-Projekt verwendet Alert-Richtlinien, um Vorfälle zu melden und/oder Benachrichtigungen für fehlgeschlagene Builds zu versenden.

Build Status Metrik

Cloud Build veröffentlicht derzeit keine Metrik. Daher veröffentlicht das Dienstprogramm gcp-cloud-build-status-publisher-utility eine Statusmetrik auf der Grundlage von Cloud Build-Benachrichtigungen.

Die Status-Metrik, custom.googleapis.com/build/status_count, ist eine generic_task Ressource, die einen Build-Trigger darstellt. Die Bezeichnung enthält den Build-Status (fehlgeschlagen, erfolgreich usw.) zu einem bestimmten Zeitpunkt. Die Zuordnung vom Cloud Build-Ereignis zur Status-Metrik ist unten dargestellt.

{
  "event_time": "most recent time of cloud build event, latest(createTime, startTime, finishTime)",
  "metric": {
    "type": "custom.googleapis.com/build/status_count",
    "labels": {
      "status": "build status (queued, working, etc.)",
      "failure_type": "failure reason (timeout, user error, etc.)",
      "failure_detail": "failure information (failed step logs)"
    }
  },
  "resource": {
    "type": "generic_task",
    "labels": {
      "location": "cloud build trigger location (global or region)",
      "namespace": "cloud build trigger project id",
      "job": "cloud build trigger id",
      "task_id": "cloud build job id"
    }
  }
}

Stellen Sie den Status-Publisher schnell bereit, indem Sie das Bereitstellungsbeispiel auf GitHub verwenden.

Alarme für fehlgeschlagene Builds

Wahrscheinlich überprüfen Sie den Build-Status auf Fehler. Lassen Sie uns daher einen -alert konfigurieren. Dieser Alarm sendet eine E-Mail, sobald ein Build fehlschlägt.

Alarmierungsrichtlinien konfigurieren Alarme. Jede Richtlinie besteht aus zwei Elementen: den Bedingungen für die Auslösung des Alarms und dem Benachrichtigungskanal für den Versand des Alarms. Diese Richtlinie wird bei FAILURE Statusereignissen für jedes einzelne Build ausgelöst, z.B. count(custom.googleapis.com/build/status_count{status=FAILURE}) by (task_id) und verwendet einen email-Benachrichtigungskanal:

resource "google_monitoring_alert_policy" "failed_build" {
  display_name = "Failed Build"
  ...

  conditions {
    condition_threshold {
      filter = 'resource.type = "generic_task" AND metric.type = "custom.googleapis.com/build/status_count" AND metric.labels.status = "FAILURE"'

      aggregations {
        group_by_fields = [ "resource.label.task_id" ]
      }

      comparison = "COMPARISON_GT"
      trigger {
        count = 1
      }
  }

  notification_channels = [
    google_monitoring_notification_channel.email.id,
  ]
}

Das vollständige Beispiel finden Sie auf GitHub.

Bonus: Alert-Dokumentation

Die Standardbenachrichtigung Alert firing! enthält keine Anweisungen zum Umgang mit dem Alarm. Gerne können diese Informationen in die Dokumentation aufgenommen werden.

Die unten stehende Dokumentation teilt beispielsweise die Fehlerdetails mit und verweist den Empfänger auf die Build-Protokolle.

resource "google_monitoring_alert_policy" "failed_build" {
  ...

  documentation {
    content   = <<EOT
    ## A build has failed!

    A build failed for project $${resource.label.namespace}, due to the following error:

    $${metric.label.failure_detail}

    For additional information, check the [build logs](https://console.cloud.google.com/cloud-build/builds/$${resource.label.task_id}?project=$${resource.label.namespace})
    EOT
  }

  ...
}

Diskussion

Cloud Monitoring ist ideal für Benachrichtigungen. Für Informationsbenachrichtigungen müssen Sie Ihren eigenen Benachrichtigungsmechanismus mitbringen, wie z.B. Cloud Build Melder. Diese Mechanismen sind notwendig, um die Benachrichtigung an Ihre Bedürfnisse anzupassen.

Der vorgeschlagene Implementierungsstream verwendet benutzerdefinierte Metriken. Sie könnten sich für protokollbasierte Metriken entscheiden, um den Einsatz des Status-Publishers zu verhindern und sich auf die Protokollsenke(n) zu verlassen. Ich habe das nicht getan, weil ich die Verwendung eines eingebauten Ereignisses meinem eigenen Verständnis der Protokollzeilen vorziehe. Abgesehen von den Vorlieben ist das Ereignis in Bezug auf die Informationen reicher. Während dies für die Statusmetrik keine Rolle spielt, könnten Sie die Infrastruktur auch nutzen, um eine Ausführungszeitmetrik hinzuzufügen. Weitere benutzerdefinierte Metriken hinzuzufügen, scheint jedoch nicht der richtige Weg zu sein. Idealerweise werden diese Metriken vom Cloud Build Service bereitgestellt. Es ist unklar, warum dies nicht der Fall ist. Da es jedoch mehrere Anfragen für diese Funktion gibt, gehe ich davon aus, dass sich dieses Thema in Zukunft durchsetzen wird. Vor allem, da Cloud Workflows ähnliche Metriken bietet.

Eine alternative Implementierung würde die Cloud Build-Ereignisse an ein (zentrales) Monitoring Pub/Sub-Thema weiterleiten. So können Sie die Cloud Build-Melder im Überwachungsthema konfigurieren und so die Verwaltung der Meldungen zentralisieren. Ich habe mich nicht dafür entschieden, weil dies nicht so flexibel ist wie Cloud Monitoring-Metrikbereiche. Diese Bereiche können sich über mehrere Projekte erstrecken und Projekte können zu mehreren Metrik-Bereichen gehören. Im Sinne von Pub/Sub bedeutet dies, dass Sie für jeden Metrikbereich in Ihrem Cloud Build-Projekt ein Abonnement abschließen - obwohl Sie auch ein zentrales Thema verwenden und von dort aus auffächern könnten. Damit haben Sie die Pub/Sub-Abonnementverwaltung zu Ihrem Job hinzugefügt. Da wir uns vorgenommen haben, langweilige Vorgänge zu verringern, frage ich mich, ob uns das mit dieser alternativen Implementierung gelingt.

Fazit

Die Überwachung des Status Ihrer Builds ist eine langweilige Aufgabe. Verbessern Sie Ihr Arbeitsleben, indem Sie Benachrichtigungen auf der Grundlage von Cloud Build-Ereignissen implementieren. Für ein einzelnes Projekt bleiben Sie bei den Cloud Build-Meldern. Für ein Multiprojekt verwenden Sie die benutzerdefinierte Build-Status-Metrik, um Alarme zentral zu verwalten.

Bild von Mircea Ploscar von Pixabay