Giving broker resources an owner
A broker can tell you everything about a topic except whose it is. When a consumer group stops, a queue fills or a schema has to change, the first question is which service this is and which team to call. The application catalogue is where that answer is kept, and the rest of what it shows follows from it.
An application in BROKA is a record of one of your services, bound to the broker resources it uses, each binding saying what the service does with that resource and why. From those bindings the console derives who depends on whom, checks that what each service relies on still exists, and lets an alert rule watch exactly that service's resources. The catalogue is part of BROKA Commercial.
The questions, and where they are answered
| The question | Where it is answered | What to know |
|---|---|---|
| Whose service is this, and which team? | An application's page: the team and owner under its name | Team and owner are optional, and they decide who may edit |
| What does it use, and how? | Resources: one row per binding, with Role and Purpose | A binding names one resource on one cluster |
| Who is affected if this changes? | Dependencies: Depends on and Depended on by | Derived from the bindings, never drawn by hand |
| Is everything it relies on still there? | Health | An existence check, not a performance check |
| What watches it? | Alerts: Open incidents and Rules that watch it | An empty list means nothing measures it |
1 — Write the record
New application asks for a name, a short code, an owning team, an owner, a description and tags. Name and code are unique across the catalogue. The record is descriptive: creating one grants nothing, gates nothing and changes nothing on any broker. Its value comes from what you attach to it.
2 — Bind what it uses, and say how
On the Resources tab, Add resource picks a broker, a cluster, a resource type, a Role and a resource name, with a Purpose sentence. The types follow the cluster: topics and consumer groups on Kafka, queues and exchanges on RabbitMQ, streams and key patterns on Redis, queues on Apache Artemis.
The role is the part that earns its place. Owns, Produces or Consumes: "the order gateway and the
risk engine both touch orders.equity.v2" is a fact; "the gateway produces it, the risk engine consumes it" is an
answer. It tells you who to ask before a schema changes, and who to warn when it does.
A binding is per cluster, not per name, so orders in production and orders in staging are two
bindings, and can belong to two different applications if that is how your estate works. The name is matched
exactly, not as a pattern — the dialog says so beside the field.
3 — Dependencies follow from the bindings
An application that consumes a resource another application owns or produces is downstream of it. The Dependencies tab shows both directions: Depends on lists the applications whose resources this one consumes, and Depended on by lists the applications that consume what this one owns or produces.
Two bindings link only when they name the same resource — the same exact name, of the same kind, on the same cluster. A topic in staging does not link to its namesake in production, and a RabbitMQ exchange does not link to a queue that happens to share its name.
The graph is derived, never stored. There is no dependency table to keep in step and no second place for it to go stale: if the bindings are right, the graph is right, and if the graph is wrong, the bindings are what to fix.
4 — Health asks whether it is still there
The Health tab asks one question per binding: does this resource still exist on its cluster? Present reads healthy. Bound and missing reads critical — a topic somebody deleted, a consumer group that never came back, a name that was wrong from the day it was typed.
A resource that cannot be checked is unknown, and the badge carries the reason: the connection no longer exists, the cluster could not be reached, the console has no check for that kind on that platform, or the cluster holds more than one listing reads and this resource was not among them. "The broker is down right now" and "this binding will never say anything" read differently, because they call for different responses. A key pattern is kept for the record and never matched against live keys: a cache prefix with no keys today is not a broken binding.
The Overall badge follows from the rows: anything missing makes the application critical, everything present makes it healthy, anything else leaves it unknown.
It is not a performance check. It says nothing about lag, depth or throughput, or whether anything is working — only whether what this application declares it uses is still present. Measuring how it behaves is what alert rules are for.
5 — Alert on the application, not on the cluster
The Alerts tab lists the Open incidents on any rule that reaches this application, and Rules that watch it: its own, scoped to the application, and the cluster- and environment-wide ones it inherits, each row with its real scope. New rule opens the rule dialog with the scope already set to this application.
A rule scoped to an application measures only the resources bound to it, each cluster on its own. One cluster's incident never resolves another's, and the same name on two clusters is two targets. A figure that describes a whole cluster is measured on each cluster the bindings sit on.
The binding's kind decides what a rule can measure. Consumer lag belongs to a consumer group, so an application bound only to the topic it reads gives a lag rule nothing to measure. Bind the group as well — for the scorer above, the topic it consumes and the consumer group it consumes with.
An empty rule list is not an all-clear. It says nothing measures this application, which is not the same as nothing being wrong. Reading the tab needs the permission to view alerts, and New rule the permission to manage them.
Who may change it, and what is recorded
An application can be edited by its owner, by a member of its owning team, or by someone holding the applications.manage permission; creating one needs that permission. You do not need to be an administrator to correct your own service's description or fix a binding that points at the wrong topic. The owner and team fields are the authorisation, which is why they sit under the application's name.
An application belongs to no environment, so editing one is never frozen. A binding is not: it names a cluster, and in a read-only environment a binding there cannot be added or removed, exactly as a write to that cluster could not. Unlinking asks for a reason in every environment; a guarded environment asks for one on adding a binding too.
An application that an alert rule or an unfinished maintenance window is scoped to cannot be deleted. The refusal names them, so you can change their scope or delete them on Operations ▸ Alerts first. A delete that goes through unbinds the application's resources, and other applications stop showing it in their dependencies.
Creating, changing and deleting an application, and binding or unbinding a resource, are each audited. A binding entry carries the connection and the resource name, so the trail answers "when did settlement start consuming this" without anyone having to remember.
In Community, Applications keeps its place in the navigation and opens a page that says what the catalogue is and which edition has it.
What this article does not cover
- Writing alert rules. Metrics, thresholds, hold times and channels are on Alerts.
- Every field and refusal of the catalogue. Applications is the reference.
Applies to BROKA 1.0 · Commercial.