feat(0056): route ops alarms to prices' own Slack channel via Chatbot#98
Merged
Conversation
…channel
BE has no ops email — it delivers all CloudWatch alarms to Slack through an
AWS Chatbot SlackChannelConfiguration (its ${env}-soroban-explorer-alarms
topic → Slack), with workspace/channel IDs in SSM. Match that instead of
inventing an email/mailing list for prices.
- Add optional opsAlarms.slack = { workspaceIdSsmParam, channelIdSsmParam }
(+ validation) to the config type.
- ObservabilityStack creates a SlackChannelConfiguration named
prices-{env}-ops-alarms on the ops topic when the config is present, reading
the workspace/channel IDs from SSM at deploy (kept out of this public repo)
and attaching a chatbot IAM role with CloudWatchReadOnlyAccess (mirrors BE).
- production.json points at BE's existing
/soroban-explorer/production/slack-{workspace,channel}-id params in the
shared account, so prices alarms land in BE's existing ops channel — one
surface, no click-to-confirm, no new mailing list. Workspace already
authorized in Chatbot for BE.
- Config is optional/non-breaking: omit to leave the topic subscriber-less.
The email path (notificationEmail / aws sns subscribe) stays as a fallback.
Synth-verified (SlackChannelConfiguration prices-production-ops-alarms →
OpsAlarmsTopic, SSM lookups for both IDs); tsc/eslint/prettier clean.
Point opsAlarms.slack at prices-owned SSM params
(/prices/{env}/slack-{workspace,channel}-id) so alarms land in the
dedicated #stellar-prices-api-bot channel rather than BE's ops channel,
on the same shared Slack workspace (no Chatbot re-auth). Add addOkAction
to all 7 alarms so recoveries notify alongside breaches.
Deployed to production and smoke-tested: forcing ledger-processor-errors
ALARM->OK posted both a breach and a recovery to the channel.
karczuRF
changed the title
Collaborator
Author
|
Updated: routes to prices' own channel, not BE's, and deployed + verified.
Note: AWS Chatbot management API is us-east-2-only ( |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Wires task 0056's
prices-{env}-ops-alarmstopic to Slack via AWS Chatbot, matching how BE routes its own CloudWatch alarms. Follow-up to the merged PR #97; answers "what ops address?" — BE has no ops email, it uses Slack/Chatbot, so we reuse BE's existing channel rather than inventing a mailing list.What BE does (verified in
soroban-block-explorer/infra/src/lib/stacks/cloudwatch-stack.ts)${env}-soroban-explorer-alarms→AWS Chatbot SlackChannelConfiguration→ Slack./soroban-explorer/{env}/slack-{workspace,channel}-id), kept out of the repo.ACME_EMAIL, not alarm routing.This change
opsAlarms.slack = { workspaceIdSsmParam, channelIdSsmParam }— new optional config (+ validation).ObservabilityStackcreates aSlackChannelConfigurationnamedprices-{env}-ops-alarmson the ops topic when the config is present, reading the IDs from SSM at deploy + a chatbot IAM role withCloudWatchReadOnlyAccess(mirrors BE).production.jsonpoints at BE's existing/soroban-explorer/production/slack-*params in the shared account → prices alarms land in BE's existing ops channel. No click-to-confirm, no new mailing list. The Slack workspace is already authorized in Chatbot for BE.Verification
cdk synth Prices-production-ObservabilityshowsAWS::Chatbot::SlackChannelConfiguration(prices-production-ops-alarms) subscribed toOpsAlarmsTopic, with SSM lookups for both IDs. tsc/eslint/prettier clean.Deploy note
The named SSM params must exist before deploying Observability (they do — BE's alarms already depend on them); the deploy fails on the lookup otherwise. This replaces step 5's
aws sns subscribe --protocol emailin the operator runbook.