Automate Incident Response with BlueKing Fault Self‑Healing and Zabbix

Self‑Healing Benefits

Before using self‑healing, the author spent about one hour per day handling basic alerts; after enabling the feature, the time dropped to under five minutes while still processing 25+ alerts daily.

Supported Alert Sources

BlueKing currently supports native BlueKing monitoring, Zabbix, Open‑Falcon, Nagios, and custom REST API pushes, which are prerequisites for achieving unattended operation.

Integrating Zabbix with BlueKing FTA

Enable the Zabbix monitoring product, configure the alarm source, and map Zabbix metric keys to alarm types in BlueKing.

Creating a Quick‑Fix Package

In the Package Management section, select a quick‑fix package or a custom job‑platform package, define the alarm type, and save the package.

Defining Convergence Rules

Use Advanced Configuration → Alarm Convergence → New Rule to set rules such as “four alerts from the same host within one minute trigger a skip‑after‑success strategy.”

Linking Job Platform Scripts

Create a job in the job platform (e.g., a script that cleans old log files or restarts a process) and bind it to a self‑healing package, then enable the package in BlueKing.

Case Study

The author built a script that, upon memory‑size alerts, identifies the top‑memory‑consuming Spark executor processes on a cluster and gracefully restarts them, reducing out‑of‑memory incidents.

Conclusion

After deploying BlueKing self‑healing, the author no longer needs to wake up at night for disk or memory alerts, freeing time for business stability work. The solution currently covers Zabbix disk, memory, and swap alerts, with more scenarios being added.