wu-sheng opened a new pull request, #157:
URL: https://github.com/apache/skywalking-query-protocol/pull/157
## Summary
Adds the comprehensive alarm query API and supersedes the
argument-by-argument extension started in #155.
### New: `queryAlarms(condition: AlarmQueryCondition!): Alarms`
Bundles every filter the OAP alarm record can support under a single input
type. Future filter additions land on the input type rather than the method
signature.
\`\`\`graphql
input AlarmQueryCondition {
duration: Duration!
paging: Pagination!
scope: Scope
layers: [String!]
serviceIds: [String!]
serviceInstanceIds: [String!]
endpointIds: [String!]
ruleNames: [String!]
keyword: String
tags: [AlarmTag]
}
\`\`\`
| Filter | Semantics |
|---|---|
| \`scope\` | Category filter (Service / ServiceInstance / Endpoint / their
relations / Process). |
| \`layers\` | Multi-select layer filter; matches \`AlarmMessage.layers\`. |
| \`serviceIds\`, \`serviceInstanceIds\`, \`endpointIds\` | Entity-ID
filters matched against the alarm record's primary (\`id0\`) OR
relation-destination (\`id1\`) entity column. A \`serviceId\` in \`serviceIds\`
hits both Service alarms on that service AND ServiceRelation alarms where the
service is source or dest. |
| \`ruleNames\` | Filter by the alarm rule(s) that fired. |
| \`keyword\` | Phrase match on the alarm message (same semantics as
\`getAlarm.keyword\`). |
| \`tags\` | Searchable-tag filter (same as \`getAlarm.tags\`). |
Within each list-typed field values are OR'd (set union), across fields the
predicates are AND'd.
### Response: \`AlarmMessage.layers: [String!]!\`
The layer field on AlarmMessage stays. Multi-layer services emit one entry
per layer the underlying entity served at alarm time; pre-upgrade rows surface
as an empty list. Same shape this repo carried after #155.
### Deprecation: \`getAlarm\`
Marked \`@deprecated\` with a reason pointing at \`queryAlarms\`. Its
signature also drops the \`layers\` argument added in #155 — that filter now
lives on \`queryAlarms.condition.layers\` instead. The OAP backend will route
both queries to the same DAO so existing clients calling \`getAlarm\` (now
without the layers arg) keep working; only the new entity-ID / rule-name /
layer filters require the new query.
Operators who consume \`getAlarm\` today should migrate to \`queryAlarms\`
on their own schedule. No removal is planned.
## Backward compatibility
- \`AlarmMessage.layers\` is non-null on the wire. For pre-upgrade alarm
records (no layer recorded on disk), the OAP backend returns an empty list —
clients that don't request the field stay unaffected.
- \`getAlarm\` continues to work for clients that don't switch.
- The new \`queryAlarms\` is additive.
## Companion changes
- Revert #156 — straightforward back-out of #155's \`getAlarm.layers\` arg
only. (\`AlarmMessage.layers\` returned in this PR; OK to merge this PR alone
and skip #156.)
- OAP backend PR (\`apache/skywalking\`) — pins this submodule SHA, adds the
new \`layer\` column to AlarmRecord, flips \`id0\`/\`id1\` from \`storageOnly\`
to indexed (existing indices keep their old shape; new daily-rolled indices
pick up the indexed columns), wires \`queryAlarms\` end to end across BanyanDB
/ ES / JDBC, and routes the deprecated \`getAlarm\` to the same DAO with an
empty entity-ID filter.
## Test plan
- [ ] OAP backend PR builds against this commit
- [ ] e2e: \`queryAlarms(condition: { duration: ..., paging: ...,
serviceIds: [\"...\"] })\` returns alarms scoped to the requested service
- [ ] e2e: \`queryAlarms(condition: { ..., layers: [\"general\"] })\`
filters by layer
- [ ] \`getAlarm(...)\` (without layers) still works against the same DAO
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
