Terraform & OpenTofu
Monitore, Incident Management, Statusseiten und Nutzer als Code verwalten: der Uptimeify-Provider für OpenTofu und Terraform.
Dein Monitoring als Code. Monitore, Incident Management, Statusseiten und Nutzer liegen direkt neben der Infrastruktur, die sie überwachen: gleicher Pull-Request-Review, gleicher Rollout für jeden Kunden. Abweichungen zeigt der nächste plan, nicht der nächste Ausfall.
Der Provider uptimeify/uptimeify läuft mit OpenTofu 1.11+ und Terraform 1.11+. Jede Ressource ist per Akzeptanztest gegen eine echte Uptimeify-Instanz geprüft.
Erste Schritte
Kunden-Token
Bestand importieren
Secrets und Updates
Installation
terraform {
required_version = ">= 1.11"
required_providers {
uptimeify = {
source = "uptimeify/uptimeify"
version = "~> 0.2"
}
}
}
# endpoint und api_token fallen auf UPTIMEIFY_ENDPOINT und UPTIMEIFY_API_TOKEN zurück.
provider "uptimeify" {}Der Provider steht in der OpenTofu-Registry und in der Terraform-Registry, jeweils unter derselben Adresse.
Provider-Konfiguration
| Argument | Umgebungsvariable | Standard |
|---|---|---|
api_token (String, Sensitive) | UPTIMEIFY_API_TOKEN | keiner, Pflicht |
endpoint (String) | UPTIMEIFY_ENDPOINT | https://uptimeify.io |
api_token ist ein Organisations-API-Token oder ein Kunden-Token, beide beginnen mit wsm_. Anlegen im Dashboard unter Einstellungen > API, siehe API-Token erstellen und Token-Bereiche. Das Token gehört in die Umgebung oder einen Secret-Store, nicht in die Konfiguration.
Was du verwalten kannst
Alles, was die Uptimeify-API einem API-Token zu ändern erlaubt. Alle Namen tragen das Präfix uptimeify_.
| Bereich | Ressourcen |
|---|---|
| Monitore | website (HTTP und Heartbeat), dns_monitor, tcp_monitor, icmp_monitor, smtp_monitor, ssh_monitor, ftp_monitor, imap_pop_monitor |
| Ordnen | tag, monitor_tag, custom_field, maintenance_window |
| Alarmierung | notification_channel, escalation_config |
| Kunden | customer, customer_ip, customer_domain |
| Incident Management | im_team, im_team_member, im_escalation_tier, im_schedule, im_schedule_override, im_team_override, im_alert_source, im_routing_rule, im_channel, im_outbound_integration, im_statuspage_rule, im_org_settings, user_notification_settings, notification_template |
| Statusseiten | status_page, status_page_design, status_page_audience_groups, status_page_component, status_page_component_group, status_page_maintenance, status_page_domain, status_page_domain_activation |
| Organisation | organization_settings, organization_branding, whitelabel_domain, report, smtp_settings, user, sso_oidc, sso_domain_verification |
Datenquellen lesen Monitore und die Nachschlagewerte, die du zum Verknüpfen brauchst, zum Beispiel uptimeify_customer und uptimeify_im_team per Name, uptimeify_im_on_call, uptimeify_monitoring_locations und uptimeify_package_configs.
apply und destroy wirken echt. uptimeify_user verschickt beim Anlegen die Einladungsmail und löscht den Nutzer beim Destroy.Über kein API-Token erreichbar und deshalb nicht im Provider: API-Tokens selbst, persönliche Benachrichtigungseinstellungen, die MFA-Richtlinie der Organisation und das SMS-Überziehungslimit.
Fehler
Der Provider reicht den Fehler der API unverändert durch, samt maschinenlesbarem Code und Request-ID, zum Beispiel:
uptimeify API: HTTP 400 checkKeywordEnabled requires searchTerm (code checkRequiresValue) [requestId 0e8f8f12-...]Alle Codes stehen unter Fehlercodes und bekannte Stolperfallen. Nenn die Request-ID, wenn du dich an den Support wendest.
Support
Fragen und Wünsche: hello@uptimeify.io. Der Provider ist Open Source unter MPL-2.0.