https://github.com/openfero/openfero
OpenFero is intended as an event-triggered job scheduler for code agnostic recovery jobs.
https://github.com/openfero/openfero
kubernetes prometheus remediation self-healing
Last synced: 6 months ago
JSON representation
OpenFero is intended as an event-triggered job scheduler for code agnostic recovery jobs.
- Host: GitHub
- URL: https://github.com/openfero/openfero
- Owner: OpenFero
- License: apache-2.0
- Created: 2021-11-17T23:09:02.000Z (almost 4 years ago)
- Default Branch: main
- Last Pushed: 2025-04-06T00:56:05.000Z (6 months ago)
- Last Synced: 2025-04-06T04:43:54.078Z (6 months ago)
- Topics: kubernetes, prometheus, remediation, self-healing
- Language: Go
- Homepage:
- Size: 1.47 MB
- Stars: 7
- Watchers: 3
- Forks: 1
- Open Issues: 12
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- Funding: .github/FUNDING.yml
- License: LICENSE
- Code of conduct: CODE_OF_CONDUCT.md
- Security: SECURITY.md
Awesome Lists containing this project
README
# OpenFero
Open Fero is a little play on words from the Latin "opem fero", which means "to help" and the term "OpenSource". Hence the name "openfero". The scope of OpenFero is a framework for self-healing in a cloud-native environment.
[](https://scorecard.dev/viewer/?uri=github.com/OpenFero/openfero) [](https://www.bestpractices.dev/projects/6683)
## Getting started
The recommended method is installation via helm chart.
```bash
helm pull oci://ghcr.io/openfero/openfero/charts/openfero --version 0.1.0
helm install openfero oci://ghcr.io/openfero/openfero/charts/openfero --version 0.1.0
```
### Testing the Installation
You can test if OpenFero is working properly in multiple ways:
#### Using the Swagger UI
Access the Swagger UI at `http://openfero-service:8080/swagger/` to interact with the API directly through a web interface. The Swagger UI provides a complete documentation of all available endpoints and allows you to test them directly.
#### Using the OpenFero UI
The OpenFero UI is available at `http://openfero-service:8080/` and provides:
- Overview of all received alerts and their current status
- Configuration viewer for operarios definitions
#### Using curl
```bash
curl -X POST http://openfero-service:8080/alert \
-H 'Content-Type: application/json' \
-d '{
"status": "firing",
"alerts": [{
"status": "firing",
"labels": {
"alertname": "TestAlert",
"severity": "warning"
}
}]
}'
```
## Component-Diagram
![Shows the Prometheus, Alertmanager components and that Alertmanager notifies the OpenFero component so that OpenFero starts the jobs via Kubernetes API.][comp-dia]
## Operarios definitions
The operarios definitions are stored in the namespace in ConfigMaps with the naming convention `openfero--`.
### Example-Names
- `openfero-KubeQuotaAlmostReached-firing`
- `openfero-KubeQuotaAlmostReached-resolved`
### Operarios-Example
```yaml
apiVersion: batch/v1
kind: Job
metadata:
name: openfero-kubequotaalmostfull-firing
labels:
app: openfero
spec:
parallelism: 1
completions: 1
template:
labels:
app: openfero
spec:
containers:
- name: python-job
image: python:latest
args:
- bash
- -c
- |-
echo "Hallo Welt"
imagePullPolicy: Always
restartPolicy: Never
serviceAccount:
serviceAccountName:
```
## Security note
The service account that is installed when deploying openfero is for openfero itself. For the operarios, separate service accounts must be rolled out, which have the appropriate permissions for the remediation.
For operarios that need to interact with the Kubernetes API, it is recommended to define a suitable role for and authorize it via ServiceAccount in the job definition.
[comp-dia]: ./docs/component-diagram.png