Simple Log Service (SLS) のアラート機能は、アラートモニタリング、ノイズリダクション、インシデント管理、通知ディスパッチを統合した包括的な AIOps プラットフォームです。
アーキテクチャ
アラート機能は、アラートモニタリング、アラート管理、アクション管理のサブシステムで構成されています。次の図にアーキテクチャを示します。
主な特徴
カテゴリ | サブカテゴリ | 機能 | 説明 |
アラートモニタリング | 基本機能 | ログのクエリと分析 | クエリ言語および標準 SQL-92 を使用してクエリおよび分析を実行します。詳細については、「クエリ構文」をご参照ください。 |
時系列データのクエリと分析 | 標準 SQL-92 および PromQL を使用して分析を実行します。詳細については、「時系列データのクエリと分析構文」をご参照ください。 | ||
機械学習 | AIOps アルゴリズムを使用して、予測、異常検知、根本原因分析を実行します。詳細については、「機械学習構文」をご参照ください。 | ||
相関モニタリング | 複数の Logstore または MetricStore 間の相関モニタリング | SQL JOIN 文または集合演算を使用して、複数の Logstore または MetricStore 間で相関モニタリングを実行します。 | |
Logstore と MetricStore 間の相関モニタリング | SQL JOIN 文または集合演算を使用して、Logstore と MetricStore 間で相関モニタリングを実装します。 | ||
プロジェクト間の相関モニタリング | 集合演算を使用して、プロジェクト間の相関モニタリングを実装します。 | ||
リージョン間の相関モニタリング | 集合演算を使用して、リージョン間の相関モニタリングを実装します。 | ||
アカウント間の相関モニタリング | 集合演算を使用して、アカウント間の相関モニタリングを実装します。 | ||
許可リスト／拒否リストモニタリング | Resource Data を使用して、許可リスト／拒否リストモニタリングを実行します。 | ||
モニタリングルールオーケストレーション | データなしアラートの設定 | データなしアラートを設定します。 | |
アラート重大度の設定 | 静的および動的なアラート重大度レベルを設定します。 | ||
ラベルとアノテーションの設定 | カスタムラベルおよびアノテーションをサポートします。アノテーション値には変数を使用できます。 | ||
グループ化評価 | クエリおよび分析結果をグループ化します。 | ||
アラート回復 | 解決済みアラート通知を有効にします。 | ||
連続トリガーしきい値の設定 | 連続トリガーしきい値を設定して、アラートを抑制します。 | ||
モニタリングタスクの無効化 | モニタリングタスクを一時的または恒久的に無効にします。 一時停止中は、タスクを自動的に再開する時刻を設定できます。 | ||
アラート管理 | ノイズリダクション | 同一アラートの重複排除 | タイムウィンドウ内で、同一のアラートを重複排除するか、通知を遅延させることができます。詳細については、「フィンガープリントに基づくアラートの重複排除」をご参照ください。 |
アラートグループ化 | グループ化ポリシーにより、同じ属性を持つアラートを単一の通知にまとめます。詳細については、「複数のアラートグループ化方法」をご参照ください。 | ||
アラートサイレンス | 指定された期間中にマッチするアラートが通知をトリガーしないように、サイレンスポリシーを作成します。 | ||
アクション管理 | アクションポリシー | 通知チャネルの動的ディスパッチ | ビジネス要件に基づき、アラート通知を特定の通知チャネル内のユーザー、ユーザーグループ、またはオンコールグループに動的にディスパッチします。詳細については、「アクションポリシー」をご参照ください。 |
受信者 | ユーザー | 個別のユーザーです。詳細については、「ユーザーおよびユーザーグループの作成」をご参照ください。 | |
ユーザーグループ | 複数のユーザーを含むグループです。詳細については、「ユーザーおよびユーザーグループの作成」をご参照ください。 | ||
オンコールグループ | ユーザーおよびユーザーグループを含むオンコールグループを作成します。期間および勤務時間に基づいて、ローテーションによるオンコールシフトを設定します。詳細については、「オンコールグループの作成」をご参照ください。 | ||
チャネルカレンダー | 休日認識 | 休日の認識をサポートし、休日期間中の通知方法を自動的に調整します。 | |
オンコールスケジュール | ローテーション | 指定されたサイクルに基づき、複数のユーザーおよびユーザーグループに対して自動オンコールローテーションを設定します。 | |
オーバーライド | 特定の期間について、一時的なシフトオーバーライドを設定します。 | ||
休日認識 | 休日に基づき、ローテーションまたはオーバーライドスケジュールを自動的に調整します。 | ||
独立カレンダー | オンコールグループ専用の、リセット可能な個別カレンダーを設定します。 | ||
通知チャネル | SMS 通知 | アラート内容を SMS メッセージで送信します。 | |
音声通知 | アラート内容を音声通話で送信します。 | ||
メール通知 | アラート内容をメールで送信します。 | ||
DingTalk 通知 | アラート内容を DingTalk チャットボットで送信します。 | ||
Webhook 通知 | HTTP または HTTPS 呼び出しを使用して、アラート通知をカスタム Webhook アドレスに送信します。 Webhook を使用して、WeCom、Lark、Slack などのプラットフォームへの通知チャネルを拡張できます。 | ||
メッセージセンター | Alibaba Cloud メッセージセンターを通じてアラート内容を送信します。 | ||
アラート分析 | グローバルアラートセンター | アラートモニタリングルールの実行履歴レポート | トラブルシューティングを支援するために、アラートモニタリングルールの実行履歴レポートを提供します。 |
アラートルールセンター | アラートルールの全体的な実行ステータスおよびトリガーされたアラートステータスを表示するダッシュボードを提供します。 | ||
アラートトレースセンター | 生成、管理から最終通知までのアラートライフサイクル全体を表示するダッシュボードを提供します。 | ||
アラートトラブルシューティングセンター | アラートモニタリング、管理、通知など各段階のエラーを表示するトラブルシューティングセンターを提供し、デバッグを簡素化します。 | ||
集中ストレージ | アラートの集中ストレージにより、受信済み、処理済み、送信済みのアラートおよび関連ログを簡単に確認できます。 アラート機能を初期化すると、SLS は選択されたリージョンに sls-alert-<ACCOUNT_ID>-<REGION> という名前の Project と internal-alert-center-log という名前の Logstore を自動的に作成し、アラートを保存します。 |
メリット
導入とスケーリングが容易
SLS は、ログおよび時系列データの取り込み、保存、クエリ、分析、可視化、アラート生成をワンストップで提供します。データを取り込んだ後、数分以内にモニタリングタスク、通知チャネル、アラートポリシーを作成し、潜在的なアラートイベントをリアルタイムで受信・対応できます。
小規模チームからエンタープライズ規模のシナリオまで、アラート設定をスケーリングできます。
高可用性と高信頼性
SLS の高可用性およびデータ信頼性に基づき、アラート機能はアラート関連データに対して 99.9 % のサービス可用性および 99.99999999 % 以上のデータ信頼性を提供します。
低コストでメンテナンス不要
SMS および音声通話通知に少額の料金が発生するほか、アラートモニタリングやインシデント管理には現在追加料金がありません。
SaaS ベースのプロダクトとして、包括的かつインテリジェントなモニタリングおよびインシデント管理機能により、アラートシステムの運用コストおよびワークロードを削減します。
問題への迅速な対応
包括的かつインテリジェントなモニタリングおよびインシデント管理機能により、アラートへの対応が迅速化され、問題解決が加速し、ビジネス中断による損失を軽減します。
ユースケース
DevOps
開発者は、アラート機能を使用して製品開発ライフサイクルのすべての段階をモニタリングできます。これにより、コード変更やデプロイメントによって発生するエラーや例外を迅速に検出し、対応できます。この機能は、Kubernetes の出力ログやイベントなどの基盤環境のログ、および SLS に取り込まれたアプリケーションログのモニタリングもサポートしています。開発、ステージング、本番のいずれの環境でも、レイテンシやジッターなどのメトリック異常が検出された場合、該当の開発者に即座に通知されます。
SLS アプリケーション（ログ監査サービスや SLB ログセンターなど）には、アラートモニタリングタスク向けの組み込みルールテンプレートが用意されており、開発者が一部のモニタリングタスクを簡単に作成できるようになっています。
ITOps
IT 運用担当者は、組織全体の IT インフラストラクチャの信頼性と安定性を確保する責任があります。組織が内部システムのログまたはメトリックデータを SLS に取り込んだ後、IT 担当者はアラート機能を使用して、応答時間、負荷、エラーレートなどの安定性メトリックおよびその他の潜在的なエラーをリアルタイムでモニタリングできます。これにより、24 時間 365 日のオンコール体制で異常を検出し、対応できます。この機能は、ノイズリダクション、グループ化、および特定のディメンションに基づくアラートイベントの動的ディスパッチもサポートしています。また、オンコールスケジュールおよびカレンダーに基づき、アラートをインテリジェントにオンコールエンジニアに割り当て、解決済みアラート通知の送信、ステータス更新、タイムリーに処理されない場合のエスカレーションなど、ワークフローの一部を自動化できます。
AIOps
開発者および IT 運用担当者は、SLS の機械学習機能とアラート機能を組み合わせて、大量のログおよび時系列データをインテリジェントにモニタリングできます。これには、インテリジェントクラスタリング、異常検知、予測が含まれます。SLS のクエリおよび分析機能では、単一时系列向けの平滑化、予測、分解、複数時系列向けのクラスタリング、複数フィールド向けのパターンマイニングなど、10 種類以上の機械学習アルゴリズムを提供しており、これらを直接アラートモニタリングタスクに適用できます。詳細については、「機械学習関数」をご参照ください。機械学習サービスは、ストリーミング統計またはグラフアルゴリズムを使用して異常検知を実行し、時系列データの異常を効果的に検出して、アラートシステムに直接送信し、さらなる管理を行います。
SecOps
組織が内部監査およびセキュリティ関連のデータおよびイベントを SLS に取り込んだ後、セキュリティ運用担当者はアラート機能を使用して継続的にモニタリングできます。これにより、内部または外部のセキュリティコンプライアンス違反や脅威イベントを検出できます。アラートシステムは、セキュリティイベントのレベルおよびソースに基づき自動的に通知を送信し、アラートデータに基づくセキュリティ態勢ダッシュボードの構築など、一部のワークフローを自動化することをサポートしています。
SLS のログ監査サービスは、主要な Alibaba Cloud プロダクトからコンプライアンスおよびセキュリティログおよびイベントを自動的にアカウント間で収集します。また、脅威インテリジェンスシステムおよびアラートシステムと自動的に統合され、コンプライアンスおよびセキュリティ向けに約 100 件のモニタリングルールテンプレートを提供しています。これにより、セキュリティ運用担当者がより迅速に業務を開始できます。詳細については、「ログ監査サービス」をご参照ください。
BizOps
組織が内部データおよびメトリックを SLS に取り込んだ後、マーケティング、カスタマー運用、財務スタッフなどのビジネス運用担当者は、アラート機能を使用して継続的にモニタリングできます。ユーザー数、アクティビティレベル、広告クリック率、クラウドプロダクトの請求書などのさまざまなデータポイントおよびメトリックを追跡し、異常な課金などの変化や異常を検出できます。これにより、迅速に対応し、運用効率を向上させ、ビジネスまたは財務リスクを軽減できます。詳細については、課金管理 コンソールにログインして詳細を表示してください。
基本概念
用語 | 説明 |
Logstore | SLS はログデータを保存するための Logstore を提供し、このストレージに基づいたクエリおよび分析機能 (SQL-92) を提供します。アラートモニタリングタスクは、このクエリおよび分析機能に依存します。 |
MetricStore | SLS は時系列データを保存するための MetricStore を提供し、このストレージに基づいたクエリおよび分析機能 (SQL-92 および PromQL) を提供します。アラートモニタリングタスクは、このクエリおよび分析機能に依存します。 |
alert | 単独で使用する場合、アラートイベントを指します。たとえば、アラートモニタリングルールが 1 つ以上のアラートをトリガーした後、それらはアラート管理システムを経由してアクション管理システムに渡されます。 他の単語と組み合わせて使用する場合、「alert」はアラート機能のサブシステム、機能、エンティティ、またはモジュール（例：アラートモニタリングシステム、アラートモニタリングルール）を指します。 |
アラートモニタリング | アラートを生成するサブシステムです。アラートモニタリングシステムは、アラートモニタリングルールおよび Resource Data で構成されています。 アラートモニタリングシステムは、アラートモニタリングルールに基づいて定期的にデータを評価し、ルールオーケストレーションロジックに従ってクエリおよび分析結果を評価し、アラートまたは解決済みアラートをトリガーして、アラート管理システムに送信します。 |
アラート管理 | ノイズリダクションおよびアラートステータス管理を担当するサブシステムです。アラート管理システムは、アラートポリシー、インシデント管理、アラート概要ダッシュボードで構成されています。 アラート管理システムは、受信したアラートをアラートポリシーに基づいてルーティング、重複排除、サイレンス、グループ化し、アクション管理システムに送信します。また、インシデントのステージおよび担当者の設定もサポートしています。 |
アクション管理 | アラート通知チャネルおよび受信者の管理を担当するサブシステムです。アクション管理システムは、アクションポリシー、コンテンツテンプレート、カレンダー、ユーザー、ユーザーグループ、オンコールグループ、チャネルクォータで構成されています。 アクション管理システムは、アクションポリシーに基づいてアラートを特定の通知チャネルに動的にディスパッチし、対象のユーザー、ユーザーグループ、またはオンコールグループに通知します。また、アラート通知コンテンツのカスタマイズもサポートしています。 |
アラートモニタリング
アラートモニタリングシステムはアラートを生成し、アラートモニタリングルールおよび Resource Data で構成されています。次の図に、アラートモニタリングシステムのアーキテクチャを示します。
用語 | 説明 |
アラートモニタリングルール | アラートモニタリングルールには、クエリおよび分析文、ターゲットオブジェクト (Logstore、MetricStore、Resource Data)、関連するモニタリングオーケストレーション設定など、アラートモニタリングの構成が含まれます。詳細については、「アラートモニタリングルールの作成」をご参照ください。 |
Resource Data | SLS は、アラートシステムで使用される各種リソース構成およびカスタムデータを保存するための、編集可能なテーブル形式の独立ストレージ構造を提供します。Resource Data は主に、許可リスト／拒否リストシナリオなど、アラートモニタリングにおける相関クエリに使用されます。 詳細については、「Resource Data の作成」をご参照ください。 |
アラート重大度 | アラートの識別属性ではない、重大度を示す属性です。レベルには、Critical、High、Medium、Low、Report があります。詳細については、「アラート重大度の設定」をご参照ください。 |
グループ化評価 | アラートモニタリングルールのパラメーターです。アラートモニタリングシステムがクエリおよび分析結果を計算する際、指定されたフィールドに基づいて結果をグループ化できます。各グループは、トリガー条件を満たしているかどうかを個別に評価されます。これにより、単一のアラートモニタリングルールで複数のターゲットをモニタリングでき、各グループは個別のアラートおよびインシデントとして管理されます。詳細については、「グループ化評価の設定」をご参照ください。 |
評価式 | 特定の評価構文を使用して、アラートトリガー条件を設定するか、アラート重大度を動的に評価するための計算式です。 評価式は、クエリおよび分析結果のフィールドを使用した論理比較および計算をサポートします。結果が true の場合、マッチとみなされます。詳細については、「評価式の設定」をご参照ください。 |
アラートラベル | キーと値のペア形式のアラート識別属性です。アラートモニタリングルールでカスタムラベルを定義します。アラートがトリガーされると、対応するラベルがアタッチされます。ラベルはコンテンツテンプレートで参照でき、アラート管理およびアクション管理での管理および通知ディスパッチ用のアラート属性としても使用できます。
詳細については、「ラベル」をご参照ください。 |
アラートアノテーション | キーと値のペア形式のアラート非識別属性です。アラートモニタリングルールでカスタムアノテーションを定義します。アラートがトリガーされると、対応するアノテーションがアタッチされます。アノテーションはコンテンツテンプレートで参照でき、管理および通知ディスパッチ用のアラート属性としても使用できます。詳細については、「アノテーション」をご参照ください。 |
解決済みアラート | アラート条件が解決されたことを示す特殊なタイプのアラート通知です。通常のアラートは「トリガー済み」ステータスを持ち、解決済みアラートは「解決済み」ステータスを持ちます。この機能を有効にすると、アラートモニタリングシステムの前回のチェックでアラートがトリガーされたが、現在のチェック結果がトリガー条件を満たしていない場合、解決済みアラートが送信されます。高頻度モニタリングシナリオでは、解決済みアラートを有効にすることで、問題が解決された際に即座に通知を受け取れます。詳細については、「解決済みアラートの設定」をご参照ください。 |
アラート管理
アラート管理システムは、アラートのノイズリダクションおよびステータス管理を処理します。アラートポリシー、インシデント管理、アラート概要ダッシュボードで構成されています。次の図に、アラート管理システムのアーキテクチャを示します。
用語 | 説明 |
アラートポリシー | アラート管理システムの構成エンティティであり、アラートモニタリングルールのパラメーターです。アラート管理システムがアラート（解決済みアラートを含む）を受信すると、自動的にアラートポリシーに基づいてノイズリダクションおよびグループ化を実行します。結果として得られるグループ化されたアラートは、アクション管理システムに送信され、通知されます。 |
アラートフィンガープリント | アラート管理システムは、処理する各アラートのフィンガープリントを計算します。同じフィンガープリントを持つアラートは同一とみなされます。フィンガープリントは、Alibaba Cloud アカウント ID、アラートが存在する Project、アラートルール ID、アラートラベルなど、アラートの識別属性に基づいて計算されます。詳細については、「フィンガープリントに基づくアラートの重複排除」をご参照ください。 |
アラートサイレンス | アラートポリシーの設定項目であり、アラート管理のステップです。サイレンスポリシーに基づき、アラート管理システムは指定されたサイレンス期間中に条件に一致するアラートを無視し、通知を送信しません。詳細については、「アラートサイレンスメカニズム」をご参照ください。 |
アラートグループ化 | アラートポリシーの設定項目であり、アラート管理のステップです。アラートを受信した後、アラート管理システムはグループ化ポリシーに従って一致するアラートを 1 つのセットにグループ化します。遅延および重複排除などの処理の後、このセットはアクション管理システムに送信され、通知されます。詳細については、「複数のアラートグループ化方法」をご参照ください。 |
グループ化セット | グループ化されたアラートを格納するコレクションで、異なるフィンガープリントを持つ 1 つ以上のアラートを含みます。遅延および重複排除などの処理の後、グループ化セットはアクション管理システムに送信され、通知されます。 |
アクション管理
アクション管理システムは、アラート通知チャネルおよび受信者を管理します。アクションポリシー、コンテンツテンプレート、カレンダー、ユーザー、ユーザーグループ、オンコールグループ、チャネルクォータで構成されています。次の図に、アクション管理システムのアーキテクチャを示します。
用語 | 説明 |
アクションポリシー | アクションポリシーは、アクション管理システムの構成エンティティです。アクション管理システムがアラート管理システムからグループ化されたアラートセット（解決済みアラートを含む）を受信すると、アクションポリシーを使用して通知を特定のチャネルに動的にディスパッチします。これらのチャネルは、対象のユーザー、ユーザーグループ、またはオンコールグループに通知します。 アクションポリシーの作成方法については、「アクションポリシー」をご参照ください。 |
Webhook 統合 | Webhook 通知チャネルを管理するために使用します。作成済みの Webhook をアクションポリシーで直接使用できます。SLS は現在、DingTalk、WeCom、Lark、Slack、およびカスタム汎用 Webhook をサポートしています。詳細については、「Webhook の作成」をご参照ください。 |
コンテンツテンプレート | SLS は、定義されたコンテンツテンプレートに基づいてアラートコンテンツを送信します。各主要チャネルには対応するテキストテンプレートがあり、変数を使用してアラート属性を参照できます。Webhook チャネルでは、WeCom で必要なフォーマットなど、特定のプロトコルに適応するためのメッセージエンティティフォーマットも設定できます。詳細については、「コンテンツテンプレートの作成」をご参照ください。 |
カレンダー | アクション管理システムの独立した構成で、グローバルデフォルトカレンダーおよびカスタムカレンダーが含まれます。
|
ユーザー | 特定の受信者を表す構成エンティティです。ユーザー ID、ユーザー名、電話番号、メールアドレスなどの情報が含まれます。アクションポリシーを使用して、対象ユーザーにアラートを送信します。インシデント管理で対象ユーザーを担当者に設定します。 ユーザーの作成方法については、「ユーザーの作成」をご参照ください。 |
ユーザーグループ | ユーザーの仮想コレクションを表す構成エンティティです。ユーザーグループ識別子、グループ名、ユーザー一覧が含まれます。ユーザーグループには 1 人以上のユーザーを含めることができます。アクションポリシーを使用して、対象ユーザーグループにアラートを送信します。 ユーザーグループの作成方法については、「ユーザーグループの作成」をご参照ください。 |
オンコールグループ | オンコールユーザーおよびユーザーグループのコレクションを表す構成エンティティです。オンコールグループ識別子、グループ名、ローテーションおよびオーバーライド構成、関連カレンダーが含まれます。オンコールグループには 1 人以上のユーザーまたはユーザーグループを含めることができます。アクションポリシーを使用して、対象オンコールグループにアラートを送信します。 オンコールグループの作成方法については、「オンコールグループの作成」をご参照ください。 |
ローテーション | オンコールグループの設定項目で、ユーザーまたはユーザーグループのローテーションスケジュールを設定するために使用します。オンコールグループに複数のローテーションスケジュールを追加できます。ローテーションは、非連続的な時間帯およびカレンダーに基づく動的ハンドオーバーをサポートします。 詳細については、「ローテーションおよびオーバーライドシナリオ」をご参照ください。 |
オーバーライド | オンコールグループの設定項目で、ユーザーまたはユーザーグループのオーバーライドスケジュールを設定するために使用します。オンコールグループに複数のオーバーライドスケジュールを追加できます。 詳細については、「ローテーションおよびオーバーライドシナリオ」をご参照ください。 |
制限事項
カテゴリ | 項目 | 説明 |
アラートモニタリング | アラートモニタリングルールの最大数 | Project ごとに最大 100 件のアラートモニタリングルールを作成できます。 |
クエリおよび分析の一般的な制限 | クエリおよび分析操作の制限については、「データのクエリおよび分析」をご参照ください。 | |
クエリおよび分析の同時実行制限 | Project 内で多数のクエリおよび分析操作を同時に実行する場合（例：SDK 経由）、多くのアラートモニタリングルールを作成すると、同時クエリ数が Project の制限を超えてモニタリングが失敗する可能性があります。アラートモニタリングルールを作成する際は、専用 SQL を 自動 に設定して、より高い同時実行をサポートすることを推奨します。専用 SQL を使用する場合は、対象 Project に十分な専用 SQL CU があることを確認してください。アラートモニタリングルールの作成方法については、「アラートモニタリングルールの作成」をご参照ください。専用 SQL の有効化方法については、「高性能かつ完全正確なクエリおよび分析（専用 SQL）」をご参照ください。 | |
クエリおよび分析構文の制限 | クエリ文、SQL 分析文、SQL+PromQL 文のみサポートされます。フレーズクエリ文およびスキャンモードのクエリおよび分析文はサポートされません。 説明 フレーズクエリまたはスキャンモードのクエリおよび分析文（SPL 構文）を使用するアラートモニタリングルールは作成できますが、ランタイム中に失敗したり、予期しない結果を生成したりする可能性があります。 | |
単一のクエリおよび分析結果の制限 |
| |
結合クエリの数 | 1 ～ 3。 | |
フィールド値の長さ | フィールド値が 1,024 文字を超える場合、分析には最初の 1,024 文字のみが使用されます。 | |
クエリおよび分析の時間範囲 | 各クエリおよび分析文の時間範囲は 24 時間を超えることはできません。 | |
Resource Data の更新遅延 | Resource Data の更新は即時ではありません。変更は 15 分以内に有効になります。 | |
アラート管理 | アラートポリシーの評価間隔 | 最小評価間隔は 15 秒です。これよりも小さい値を設定しても、チェックは 15 秒間隔で実行されます。 |
ポリシーのマッチング条件 | アラートポリシーやアクションポリシーなどの構成では、Project 名、アラートルール ID、アラート名、重大度、または短いラベルまたはアノテーションに基づく条件を使用することを推奨します。
| |
インシデント数 | 最大 1,000 件のインシデントが 30 日間保持されます。古いインシデントデータは自動的に上書きされます。 | |
インシデントコメント | 各インシデントには最大 10 件のコメントを追加できます。古いコメントは自動的に上書きされます。 | |
ポリシー構成の更新遅延 | アラートポリシー、アクションポリシー、コンテンツテンプレート、ユーザー、ユーザーグループ、オンコールグループなど、アラート関連のポリシーに対する変更は、通常 1 分以内に有効になります。 | |
アクション管理 | 通知チャネル | 通知チャネルには以下の制限が適用されます。これらの制限を超えると、アラート通知を受信できなくなる可能性があります。通知を受信できない場合は、グローバルアラートトラブルシューティングセンターで関連エラーを確認できます。詳細については、「グローバルアラートトラブルシューティングセンター」をご参照ください。
詳細については、「通知チャネル」をご参照ください。 |
通知コンテンツ | 各通知チャネルにはコンテンツ長の制限があります。配信を確実に行うため、システムはサイズ超過のコンテンツを切り詰める場合があります。切り詰めによりコンテンツの整合性や 100 % の配信成功が保証されるわけではなく、特に切り詰められたコンテンツが無効な Markdown または HTML になる場合があります。SMS や音声通話などのプレーンテキスト形式では、切り詰めによる配信失敗は一般的に発生しません。 サイズ超過による配信失敗を回避するため、チャネルの制限に従ってコンテンツテンプレートを設定してください。各チャネルの制限は次のとおりです（漢字、英字、数字、句読点はすべて 1 文字としてカウントされます）： 説明 フィールド値が 1,024 文字を超える場合、最初の 1,024 文字のみが使用されます。
| |
コンテンツテンプレート構成 | コンテンツテンプレートの構成が誤っていると、レンダリングが失敗してエラーが返される可能性があります。 | |
コンテンツテンプレート変数 | コンテンツ長は 2 KB に制限されています。この制限を超えるコンテンツは切り詰められます。 |
課金
SMS および音声通話通知には料金が発生します。詳細な料金については、「料金」をご参照ください。
操作 | 説明 |
SMS 通知 | 送信されたアラート SMS 通知ごとに料金が発生します。 説明 一部のキャリアでは、長い SMS メッセージ（例：70 文字以上）を 2 つのメッセージに分割する場合があります。メッセージが長い場合、2 つの別々のメッセージを受信する可能性がありますが、SLS は 1 回のみ課金します。 |
音声通知 | アラート音声通話ごとに料金が発生します。 説明
|