Push Endpoints

HTTP webhooks for anything not running in Kubernetes: bare-metal hosts, external S3 buckets, RDS, VMs. First push auto-creates the service; subsequent pushes update status. Every endpoint accepts the same one-string path identifier as the GitOps YAML.

Authentication

All three endpoints share the same API key (X-API-Key header) as the agent. Find it in the platform chart's secretEnv.ITOPS_SECURITY_OPERATOR_API_KEY.

Health push

curl -X POST https://api.yourdomain.com/api/v1/health/report \
  -H "X-API-Key: $OPERATOR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "path": "myorg/infra/prod/baremetal/galera-node1",
    "status": "OPERATIONAL",
    "message": "wsrep_cluster_size=3",
    "criticality": "critical",
    "slaGroup": "database-cluster",
    "serviceType": "database",
    "tags": ["database", "baremetal"]
  }'

Status values: OPERATIONAL, DEGRADED, DOWN, MAINTENANCE, UNKNOWN. Unknown status is stored as UNKNOWN with a warning in the response.

Storage push

curl -X POST https://api.yourdomain.com/api/v1/storage/report \
  -H "X-API-Key: $OPERATOR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "path": "myorg/platform/prod/cluster1/postgresql",
    "allocatedBytes": 107374182400,
    "usedBytes": 53687091200,
    "storageType": "pvc",
    "mountPath": "/var/lib/postgresql"
  }'

Auto-appends storage tag so the service appears on the Storage tab. Status levels: healthy (>30% free), warning (10–30%), critical (<10%).

Backup push

curl -X POST https://api.yourdomain.com/api/v1/backup/report \
  -H "X-API-Key: $OPERATOR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "path": "myorg/platform/prod/cluster1/postgresql",
    "status": "success",
    "sizeBytes": 5242880,
    "message": "pg_dump completed"
  }'

Three addressing modes: per-service (path), per-SLA-group (slaGroup — propagates to every member with backup.expected=true), per-namespace (namespace). Status values: success, failed, partial.

Loud over silent

Missing / malformed fields are never silently rejected. Instead the handler pads or clamps and returns a warnings[] array so the push client can self-diagnose:

• Missing / <5-segment path → padded to unknown/unknown/unknown/unknown/<service>. Service lands under a red “unknown” branch in the UI with a misconfigured pushes banner.
• Negative allocatedBytes / usedBytes / sizeBytes → clamped to 0.
• freePercent out of [0, 100] → clamped.
• Unknown status on health push → stored as UNKNOWN.

CronJob pattern

apiVersion: batch/v1
kind: CronJob
metadata:
  name: health-push-galera
  namespace: monitoring
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: pusher
              image: curlimages/curl:latest
              env:
                - name: API_KEY
                  valueFrom: { secretKeyRef: { name: itops-operator-api-key, key: key } }
              command: ["/bin/sh","-c"]
              args:
                - |
                  STATUS=$(nc -zv galera-node1 3306 2>&1 | grep -q succeeded && echo OPERATIONAL || echo DOWN)
                  curl -sfX POST https://api.yourdomain.com/api/v1/health/report \
                    -H "X-API-Key: $API_KEY" \
                    -d "{
                      \"path\":\"myorg/infra/prod/baremetal/galera-node1\",
                      \"status\":\"$STATUS\",
                      \"slaGroup\":\"database-cluster\",
                      \"criticality\":\"critical\",
                      \"serviceType\":\"database\"
                    }"

Full schema reference

API reference has every field and response shape.