Configuration reference
All configuration keys are under the quarkus.goblin prefix.
The chaos layers are not configuration keys: every application starts with HTTP_IN and HTTP_OUT armed, and the layers are armed at runtime from the Dev UI or through JSON-RPC (applyConfig with a layers array); in dev mode the choice is persisted in .goblin-state.json. DATABASE requires a JDBC datasource and MESSAGING requires quarkus-messaging.
|
Every key is read at runtime and can be overridden when the application starts (environment variable, system
property, profile), except the three quarkus.goblin.target.include-packages / exclude-packages /
exclude-annotations targeting rules: they decide at build time which beans receive the service and messaging
interceptors, so they are fixed at build time (a dev-mode live reload rebuilds the application and picks them up).
| Key | Type | Default | Description |
|---|---|---|---|
|
|
|
Enable/disable the Goblin extension. Takes effect in dev mode, and in test mode together with |
|
|
|
Whether chaos is active in test mode ( |
|
|
|
Initial assault type enabled at startup. Values: |
|
|
|
Predefined composite assault mode. Values: |
|
|
|
Minimum latency in milliseconds. Must be lower than or equal to max-milliseconds; inverted values are swapped with a |
|
|
|
Maximum latency in milliseconds |
|
|
|
Fully qualified exception class name. Must extend |
|
|
|
Exception message |
|
|
|
HTTP status code to return. Must be in the |
|
|
|
HTTP response body |
|
|
|
Response body transformation to apply. Values: |
|
|
|
Target size of the transformed body in percent of the original, rounded down ( |
|
|
|
Action applied to the |
|
|
empty |
Header value written by the |
|
|
|
Percentage of requests to affect (0-100; values are clamped with a |
|
|
empty |
Package prefixes to include (empty = all packages). Fixed at build time. |
|
|
empty |
Package prefixes to exclude from chaos; an exclusion always wins over an inclusion. Fixed at build time. |
|
|
empty |
Exclude methods/classes carrying these annotations (every layer). Fixed at build time. |
Configuration validation
Goblin validates assault parameters at startup and whenever you save a change in the Dev UI. Invalid values are never applied: Goblin logs a clear message and applies a safe fallback, so a misconfiguration cannot silently corrupt your chaos experiments.
Parameter |
Rule |
What happens |
|
|
Out-of-range values are clamped, inverted values are swapped, and a |
|
Must be in the |
Defaults to |
|
Class must exist, extend |
Falls back to |
|
Must be in |
Clamped to the valid range and a |
|
Must be in the |
Clamped and a |
At startup the checks run in AssaultEngine.onStart() and cover both the application.properties configuration and the state loaded from .goblin-state.json. When you edit a parameter in the Dev UI, the same rules apply: the corrected value is persisted back to .goblin-state.json, and the dashboard shows a warning toast explaining what changed — for example, entering min=10000, max=500 swaps them to min=500, max=10000.