Інтеграція SNS і SQS з CloudWatch

Моніторинг і усунення несправностей в AWS

John Q. Martin

Principal Consultant

Під'єднання сповіщень CloudWatch до SNS

aws cloudwatch put-metric-alarm \
  --alarm-name HighCPUUtilization \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:production-alerts \
  --ok-actions arn:aws:sns:us-east-1:123456789012:recovery-notifications

Потік: CloudWatch Alarm надсилає через --alarm-actions до топіка SNS, який розсилає підписникам — Email, SMS, Lambda та SQS

Базові поняття SNS

Компоненти

SNS має модель видавець/підписник: топіки, видавці, підписники
Топік: іменований канал; видавці надсилають, підписники отримують
Одне публікування — одночасна доставка всім підписникам

Протоколи підписників (один топік, багато кінцевих точок):

Email, SMS
HTTP / HTTPS
Lambda, SQS
Мобільні push, Kinesis Firehose

Типи топіків SNS

Порівняння типів топіків SNS Standard і FIFO за впорядкуванням, пропускною здатністю та гарантіями доставки

Створення топіків SNS: AWS CLI

Стандартний топік

aws sns create-topic \
  --name production-alerts

FIFO топік

aws sns create-topic \
  --name production-alerts.fifo \
  --attributes FifoTopic=true,\
    ContentBasedDeduplication=true

З шифруванням

aws sns create-topic \
  --name production-alerts \
  --attributes KmsMasterKeyId=alias/aws/sns

Додавання підписників Lambda і SMS

Lambda

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:production-alerts \
  --protocol lambda \
  --notification-endpoint arn:aws:lambda:us-east-1:123456789012:function:ProcessAlert

SMS

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:critical-alerts \
  --protocol sms \
  --notification-endpoint +1234567890

Формат повідомлення SNS від CloudWatch Alarm

{
  "AlarmName": "HighCPUUtilization",
  "NewStateValue": "ALARM",
  "OldStateValue": "OK",
  "NewStateReason": "Threshold Crossed: 2 datapoints [85.0, 90.0] were greater than the threshold (80.0).",
  "StateChangeTime": "2026-03-27T10:30:45.123+0000",
  "Trigger": {
    "MetricName": "CPUUtilization",
    "Namespace": "AWS/EC2",
    "Statistic": "AVERAGE",
    "Period": 300,
    "Threshold": 80.0,
    "ComparisonOperator": "GreaterThanThreshold"
  }
}

Фільтрація повідомлень у SNS

aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:...:production-alerts:abc123 \
  --attribute-name FilterPolicy \
  --attribute-value '{"AlarmName":["HighCPUUtilization"],"NewStateValue":["ALARM"]}'

aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:...:production-alerts:abc123 \
  --attribute-name FilterPolicyScope \
  --attribute-value MessageBody

Кастомне форматування сповіщень за допомогою Lambda

def lambda_handler(event, context):
    alarm = json.loads(event['Records'][0]['Sns']['Message'])

    message = f"""
ALERT: {alarm['AlarmName']}
Status: {alarm['NewStateValue']}
Reason: {alarm['NewStateReason']}
Resource: {alarm['Trigger']['Dimensions'][0]['value']}
Runbook: https://wiki.example.com/runbooks/high-cpu
    """

    sns.publish(
        TopicArn='arn:aws:sns:...:formatted-alerts',
        Subject=f"{alarm['AlarmName']}",
        Message=message
    )

Ланцюжок: сирий топік тривоги надходить до Lambda, яка форматує читабельне повідомлення і публікує до топіка formatted-alerts для інженера на чергуванні, тоді як машинні споживачі лишаються на сирому топіку

Fan-out архітектура з SQS

Архітектура fan-out, де одне повідомлення SNS доставляється до кількох черг SQS та споживача Lambda

Налаштування fan-out

Чотири кроки

Створіть черги SQS (по одній на споживача)
Налаштуйте політики черг (дозвольте SNS надсилати повідомлення)
Підпишіть черги на топік SNS
Побудуйте споживачів (опитування, обробка, видалення)

Політика черги

{
  "Effect": "Allow",
  "Principal": { "Service": "sns.amazonaws.com" },
  "Action": "sqs:SendMessage",
  "Resource": "arn:aws:sqs:...:alarm-logging-queue",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": "arn:aws:sns:...:production-alerts"
    }
  }
}

Підписання черг

Підпишіть кожну чергу

aws sns subscribe \
  --topic-arn arn:aws:sns:...:production-alerts \
  --protocol sqs \
  --notification-endpoint arn:aws:sqs:...:alarm-logging-queue

Обробка повідомлень

Шаблон споживача

response = sqs.receive_message(
    QueueUrl=queue_url,
    MaxNumberOfMessages=10,
    WaitTimeSeconds=20       # Long polling
)
for message in response.get('Messages', []):
    sns_msg = json.loads(message['Body'])
    alarm = json.loads(sns_msg['Message'])
    # Process alarm data
    sqs.delete_message(QueueUrl=queue_url,
                       ReceiptHandle=message['ReceiptHandle'])

Fan-out з фільтрацією та чергами безнадійних повідомлень

Точкова доставка для підписки

Черга тікетів: {"NewStateValue":["ALARM"],"Severity":["Critical"]}
Черга логів: без фільтра (отримує все)
Черга метрик: {"MessageType":["Metric"]}

Черги безнадійних повідомлень (DLQ)

aws sqs set-queue-attributes \
  --queue-url https://sqs..../alarm-logging-queue \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:...:alarm-logging-dlq\",\"maxReceiveCount\":\"3\"}"
  }'

SNS vs. SQS: коли що використовувати

Порівняння доставки на основі push у SNS проти чергування повідомлень pull у SQS

Приклади архітектур

Простий шаблон тривоги, що надсилає сповіщення SNS на email

Асинхронний шаблон обробки: API надсилає в чергу SQS, яку споживає робітник

Багатоканальне оповіщення: одна тривога розсилається на кілька каналів сповіщень

Конвеєр подій, що спрямовує вихідну подію до кількох черг SQS для обробки

Підсумок відео

Топіки SNS доставляють сповіщення тривог через email, SMS, HTTP, Lambda та SQS
Шаблон fan-out: одне повідомлення SNS → кілька черг SQS для паралельної й надійної обробки
Фільтрація повідомлень зменшує шум для кожного підписника
Черги безнадійних повідомлень перехоплюють збої доставки
SNS для push-сповіщень, SQS для надійної обробки; разом — fan-out із надійністю

Давайте потренуємось!

Моніторинг і усунення несправностей в AWS