This is a small container image to send a HTTP notification to a rescaled Argus endpoint to let the system know that a certain job has been completed.
rescaled Argus is a distributed monitoring platform for the modern web. It's main featureset includes simultaneous active monitoring checks from multiple locations worldwide against a HTTP or ICMP target. Due to a quorum mechanism, a defined number of locations need to agree upon a status change of an actively checked monitor in order to dispatch a monitoring notification. This concept ensures that basically no false positive notifications are being sent and thereby reducing monitoring fatigue.
Another feature of Argus are Heartbeat Monitors. These kind of monitors expect a HTTP request in a configurable interval and if they don't receive it, a notification is being triggered. It's the perfect solution for monitoring your cronjobs, backups and recurring tasks - like a dead man's switch.
To use this container image with your containerized workloads, you can either check out our documentation or follow the instructions below.
Unfortunately, as of today, Kubernetes doesn't allow you to run a certain container upon success of a previous task. You have two options to use this image with Kubernetes.
You can add the image to your CronJob or Job manifest as container. However, this will cause the heartbeat to be sent no matter if the tasks that are being executed by your other containers in the same Pod are successful or not. You need to replace the values for the environment variables ARGUS_MONITOR and ARGUS_TOKEN with the appropriate values. You'll get them from your monitor's detail page.
apiVersion: batch/v1
kind: CronJob
metadata:
name: example-backup-job
spec:
schedule: "30 3 * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: backup
image: busybox:1.28
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- date; echo Running a fake backup ...
- name: heartbeat
image: ghcr.io/rescaled/argus-heartbeat:main
imagePulPolicy: IfNotPresent
env:
- name: ARGUS_MONITOR
value: X
- name: ARGUS_TOKEN
value: X
restartPolicy: OnFailureIf your CronJob or Job only consists of a single container, you can misuse the initContainer feature of Kubernetes to run your actual job as initializing container for the Pod and then the heartbeat as sole main container. While not intended to be used that way, it works and the heartbeat only gets send if the initContainer (your actual job) exits successfully. You need to replace the values for the environment variables ARGUS_MONITOR and ARGUS_TOKEN with the appropriate values here as well. Before using this approach, make sure you understand the implications of running your actual workload as initContainer.
apiVersion: batch/v1
kind: CronJob
metadata:
name: example-backup-job
spec:
schedule: "30 3 * * *"
jobTemplate:
spec:
template:
spec:
initContainers:
- name: backup
image: busybox:1.28
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- date; echo Running a fake backup ...
containers:
- name: heartbeat
image: ghcr.io/rescaled/argus-heartbeat:main
imagePulPolicy: IfNotPresent
env:
- name: ARGUS_MONITOR
value: X
- name: ARGUS_TOKEN
value: X
restartPolicy: OnFailureIn order to dispatch the heartbeat request to Argus via Docker, use the following command and adjust the values for ARGUS_MONITOR and ARGUS_TOKEN accordingly. You can find them on the detail page of your heartbeat monitor in the Argus Web UI.
docker run --rm -e ARGUS_MONITOR="your-monitor" -e ARGUS_TOKEN="your-token" ghcr.io/rescaled/argus-heartbeat:main
Now that you've found this repository and read through the README, why not giving Argus a try?
Its Free Plan allows you to play around with all functionalities and gives you enough monitoring quota to run checks against your homelab or private infrastructure.
If you're eager to try out our paid plans, use code REPOHUNTER for your first month 100% off (which can also be used to try out Argus' more extended features for free - you can immediately cancel afterward).