このトピックでは、脅威の分析と応答 と Simple Log Service (SLS) のクラウド可観測性機能を使用して、サービスヘルスやログ使用量などの Agentic SOC のコアメトリックに対する自動モニタリングとアラートを設定し、サービスの可用性と運用保守 (O&M) 効率を向上させる方法について説明します。
利用シーン
脅威の分析と応答 は、その安定性とヘルス状態が極めて重要なコアセキュリティサービスです。日々の運用保守において、次のような問題に直面することがあります。
サービスの可用性リスク:Agentic SOC のログ収集の中断やコアモジュールの異常動作などの問題が迅速に検出されない可能性があります。これにより、セキュリティ分析機能が低下または無効になることがあります。
コスト管理の難しさ:ログ収集トラフィックが想定を超えると、SLS で予期せぬストレージコストやクエリコストが発生する可能性があります。効果的なモニタリングと早期のアラートが必要です。
運用保守効率の低下:統一された監視ビューとアラートメカニズムがないため、Agentic SOC の運用状態を既存の O&M システムに統合することが困難です。
仕組み
このソリューションでは、Agentic SOC のクラウド可観測性機能を使用してランタイムログを SLS に配信します。その後、SLS のアラート機能を使用してログを監視し、通知を送信します。
ログ生成:脅威の分析と応答 の使用量測定やモジュールのヘルス状態などのモジュールが、ランタイムにモニタリングログを生成します。
ログ配信:クラウド可観測性機能を有効にすると、Agentic SOC はこれらのモニタリングログをリアルタイムで指定した SLS プロジェクトに配信します。
ログストレージ:ログは SLS の Logstore に保存されます。
アラートとモニタリング:SLS でアラートルールを作成し、定期的にクエリ文 (SQL) を実行できます。システムはクエリ結果に基づいてトリガー条件が満たされているかどうかを判断します。
通知送信:アラートがトリガーされると、アクションポリシーを使用して、ショートメッセージ、DingTalk、メールなどの指定されたチャンネルに通知が送信されます。
操作手順
ステップ 1:クラウド可観測性機能の有効化
まず、脅威の分析と応答 コンソールでクラウド可観測性機能を有効にし、モニタリングログを Simple Log Service (SLS) に配信する必要があります。
移動先: Cloud Observability 構成ページ
[Security Center コンソール] > [システム設定] > [機能設定] に移動し、ページの左上隅で、アセットが配置されているリージョン ([Chinese Mainland] または [Outside Chinese Mainland]) を選択します。
設定 タブで、Cloud Observability をクリックします。
オン/オフスイッチ
Cloud Observability 設定タブの Basic Settings エリアで、Enable Cloud Observability スイッチをオンにします。
ログストレージ情報の設定
Cloud Observability 設定タブの Detailed Configuration エリアで、次の設定を行います。
Monitoring Module:配信したいログのスイッチをオンにします。
Module Health:各機能モジュールの運用状態、接続状態、パフォーマンスを監視します。
Usage Metering:ログ収集トラフィックとログストレージ容量の使用状況を監視します。
Log Storage Location:
Region::初期設定時に、クラウド可観測性のログを保存するリージョンを選択する必要があります。
警告ログストレージのリージョンは、初期設定後に変更することはできません。システムは、このリージョンに専用の SLS プロジェクトと Logstore を自動的に作成します。
[プロジェクト]:システムはリージョンに基づいてプロジェクトを自動的に作成します。フォーマットは
sas-observability-AccountUID-RegionIDです。Logstore Mapping::システムは自動的に 2 つの Logstore を作成します。
health-log: Module Health ログを格納します。metering-log:Usage Metering ログを保存します。
Data Retention Days:SLS でのクラウド可観測性データの保持期間を指定します。デフォルト値は 30 日です。必要に応じてこの値を変更できます。
説明保持期間が長いほど、ストレージコストが高くなります。
Save Configuration:Save Configuration をクリックします。設定が保存されると、Agentic SOC は指定された SLS プロジェクトへのログ配信を開始します。
重要クラウド可観測性機能のログストレージには追加料金が発生し、SLS によって請求されます。
ステップ 2:アラート通知ルールの設定
手順
Cloud Observability タブで、右下隅にある Alert Center をクリックして、クラウド可観測性プロジェクトのアラートセンター設定ページに移動します 。
[アラートルール] タブで、[アラート作成] をクリックします。パラメーターは次のとおりです。
説明詳細については、「アラート監視ルールの作成」をご参照ください。
パラメーター
説明
[ルール名]
アラートルールの名前。
チェック頻度
SLS は、設定した頻度でクエリ分析結果をチェックします。
時間単位: 1時間ごとにクエリと分析結果をチェックします。
[毎日]:毎日固定された時刻にクエリ分析結果をチェックします。
[毎週]:週の特定の曜日の固定された時刻にクエリ分析結果をチェックします。
[固定間隔]:固定された間隔でクエリ分析結果をチェックします。
[Cron]:cron 式で指定された間隔でクエリ分析結果をチェックします。
説明アラートルールの cron 式の最小精度は 1 分です。フォーマットは 24 時間表記を使用します。例:
0/5 * * * *:0 分から開始し、5 分ごとにチェックします。0 0/1 * * *:00:00 から開始し、1 時間ごとにチェックします。0 18 * * *:毎日 18:00 にチェックします。0 0 1 * *:毎月 1 日の 00:00 にチェックします。
cron 式の構文の詳細については、「Cron ジョブ」をご参照ください。
[クエリ統計]
入力ボックスをクリックします。[クエリ統計] ダイアログボックスで、クエリ文を設定します。
[関連レポート] タブ:ダッシュボードを選択します。
[高度な設定] タブ:
[タイプ] リストから、データ型を選択します。
[Logstore]:ログを保存します。クエリ分析設定の詳細については、「ログのクエリと分析の概要」をご参照ください。
[Metricstore]:メトリックを保存します。クエリ分析設定の詳細については、「メトリックデータのクエリと分析」をご参照ください。
[リソースデータ]:アラートルールに関連付けられた外部データを設定します。詳細については、「リソースデータの作成」をご参照ください。
[タイプ] を [Logstore] または [Metricstore] に設定し、クエリ文を指定した場合、専用 SQL を有効にするかどうかを指定できます。詳細については、「高性能かつ完全な精度のクエリと分析 (専用 SQL)」をご参照ください。
[自動]:デフォルトでは専用 SQL は使用されません。クエリの同時実行数制限に達した場合やクエリ結果が不正確な場合、SLS は専用 SQL を使用して自動的にクエリを再試行します。
[有効化]:クエリ分析には常に専用 SQL が使用されます。
[無効化]:専用 SQL は無効になります。
複数のクエリ文を設定した場合、[セット操作] を指定してクエリ結果を関連付けることができます。詳細については、「クエリ文の設定」をご参照ください。
[グループ評価]
SLS はクエリ分析結果をグループ化できます。詳細については、「グループ評価の設定」をご参照ください。
[カスタムラベル]:SLS は指定したフィールドに基づいてクエリ分析結果をグループ化します。結果がグループ化された後、各グループに対してトリガー条件が評価されます。各チェックサイクルで、グループ内の結果がトリガー条件を満たす場合、そのグループに対してアラートが生成されます。
複数のフィールドを指定できます。
[グループ化なし]:各チェックサイクルで、トリガー条件が満たされたときに生成されるアラートは 1 つだけです。
[自動ラベル]:[クエリ統計] セクションで [Metricstore] を選択してメトリックのクエリ分析結果を監視する場合、SLS は結果を自動的にグループ化します。
結果がグループ化された後、各グループに対してトリガー条件が評価されます。各チェックサイクルで、グループ内の結果がトリガー条件を満たす場合、そのグループに対してアラートが生成されます。
[トリガー条件]
トリガー条件とアラートの重大度を設定します。
トリガー条件
[データが存在する]:クエリ分析結果にデータが存在する場合にアラートがトリガーされます。
[特定の数のデータエントリが存在する]:クエリ分析結果に N 個のデータエントリが存在する場合にアラートがトリガーされます。
[データが式に一致する]:クエリ分析結果に条件式に一致するデータが存在する場合にアラートがトリガーされます。
[特定の数のデータエントリが式に一致する]:クエリ分析結果に条件式に一致する N 個のデータエントリが存在する場合にアラートがトリガーされます。
重大度
このパラメーターは、主にアラートのノイズ除去と通知制御に使用されます。アラートポリシーまたはアクションポリシーを作成する際に、アラートの重大度に基づいて条件を追加できます。詳細については、「アラートの重大度の設定」をご参照ください。
シンプル設定:アラートの重大度を選択します。このルールによって生成されるすべてのアラートは同じ重大度になります。
条件付き設定:[追加] をクリックして、異なる条件に基づいてアラートの重大度を設定します。
条件式の構文の詳細については、「条件式の構文」をご参照ください。
[ラベルを追加]
生成されたアラートにキーと値の形式で識別属性を追加します。ラベルは主にアラートのノイズ除去と通知制御に使用されます。アラートポリシーまたはアクションポリシーを作成する際に、ラベルに基づいて条件を追加できます。詳細については、「ラベルとアノテーションの追加」をご参照ください。
[アノテーションを追加]
生成されたアラートにキーと値の形式で非識別属性を追加します。アノテーションは主にアラートのノイズ除去と通知制御に使用されます。アラートポリシーまたはアクションポリシーを作成する際に、アノテーションに基づいて条件を追加できます。詳細については、「ラベルとアノテーションの追加」をご参照ください。
また、[アノテーションの自動追加] スイッチをオンにすることもできます。これにより、システムは __count__ などの情報をアラートに自動的に追加します。詳細については、「自動アノテーション」をご参照ください。
復旧通知
[リカバリー通知] スイッチをオンにすると、アラートが解決されたときにリカバリーアラートがトリガーされます。たとえば、各ホストの CPU メトリックを監視するアラートルールを作成します。CPU 使用率が 95% を超えるとアラートがトリガーされます。CPU 使用率が通常値 (95% 以下) に低下すると、リカバリー通知が送信されます。詳細については、「リカバリー通知の設定」をご参照ください。
[高度な設定] > [連続トリガーしきい値]
アラートが生成される前にトリガー条件が満たされる連続チェックの回数。条件が満たされないチェックはカウントされません。
[高度な設定] > [データなしアラート]
[データなしアラート] スイッチをオンにすると、クエリ分析結果でデータが返されない回数が [連続トリガーしきい値] を超えた場合にアラートが生成されます。複数のクエリ文が使用されている場合、カウントはセット操作の結果に基づきます。詳細については、「データなしアラート」をご参照ください。
[出力]
アラートイベントの送信先を設定します。1 つまたは複数の出力を設定できます。
[イベントストア]:アラートイベントをイベントストアに書き込みます。
[CloudMonitor イベントセンター]:アラートイベントを CloudMonitor のイベントセンターに書き込みます。その後、CloudMonitor を使用してアラートを管理し、通知を送信できます。
[SLS 通知]:アラートイベントを SLS の通知サービスに送信します。その後、アラートポリシーとアクションポリシーを使用してアラートを管理し、通知を送信できます。
[出力] - [イベントストア]
[有効化]:このスイッチをオンにすると、アラートが指定されたイベントストアに書き込まれます。
[リージョン]:宛先イベントストアが配置されているリージョン。
[プロジェクト]:宛先イベントストアが属するプロジェクト。
[イベントストア]:アラートを保存するイベントストア。
[権限付与方法]:
デフォルトロール: [権限付与に進む] をクリックし、指示に従って権限付与を完了します。 これにより、Simple Log Service に、宛先の EventStore にアラートを書き込むための AliyunLogETLRole システムロールの権限が付与されます。 詳細については、「デフォルトロールを使用して権限を付与する」をご参照ください。
[カスタムロール]:カスタムロールを引き受けて、アラートを宛先イベントストアに書き込みます。ロールの Alibaba Cloud リソースネーム (ARN) を入力します。詳細については、「カスタムロールを使用した権限付与」をご参照ください。
[出力] - [CloudMonitor イベントセンター]
[有効化]:このスイッチをオンにすると、アラートが CloudMonitor のイベントセンターに送信されます。詳細については、「システムイベントの表示」をご参照ください。
[出力] - [SLS 通知]
[有効化]:このスイッチをオンにすると、アラートが SLS の通知サービスに送信され、管理と通知が行われます。
アラートポリシー
シンプルモード
SLS は、デフォルトで組み込みの動的アラートポリシー (sls.builtin.dynamic) を使用してアラートを管理します。
アクショングループを設定します。
アクショングループを設定すると、SLS は自動的に
ルール名-アクションポリシーという名前のアクションポリシーを作成します。このアラートルールによってトリガーされるすべてのアラートは、このアクションポリシーを使用して通知を送信します。アクショングループの設定方法の詳細については、「通知チャンネル」をご参照ください。重要このアクションポリシーは、[アクションポリシー] ページで変更できます。詳細については、「アクションポリシー」をご参照ください。アクションポリシーの変更時に条件式を追加すると、[アラートポリシー] モードは自動的に [標準モード] に変更されます。
[繰り返し間隔]:この間隔内では、重複するアラートはアクションポリシーを 1 回だけトリガーします。つまり、アラート通知は 1 回しか送信されません。
標準モード
SLS は、デフォルトで組み込みの動的アラートポリシー (sls.builtin.dynamic) を使用してアラートを管理します。
アラート通知を送信するために、組み込みまたはカスタムのアクションポリシーを選択します。アクションポリシーの作成方法の詳細については、「アクションポリシー」をご参照ください。
[繰り返し間隔]:この間隔内では、重複するアラートはアクションポリシーを 1 回だけトリガーします。つまり、アラート通知は 1 回しか送信されません。
高度なモード
アラートを管理するために、組み込みまたはカスタムのアラートポリシーを選択します。アラートポリシーの作成方法の詳細については、「アラートポリシーの作成」をご参照ください。
アラート通知を送信するために、組み込みまたはカスタムのアクションポリシーを選択します。アクションポリシーの作成方法の詳細については、「アクションポリシー」をご参照ください。また、[カスタムアクションポリシー] を有効または無効にすることもできます。詳細については、「動的アクションポリシーメカニズム」をご参照ください。
[繰り返し間隔]:この間隔内では、重複するアラートはアクションポリシーを 1 回だけトリガーします。つまり、アラート通知は 1 回しか送信されません。
設定が完了したら、[OK] をクリックします。
設定例
トラフィックがゼロに低下
シナリオ:ログ収集トラフィックが突然 0 に低下し、脅威の分析と応答 にデータが書き込まれなくなります。
ソリューション:システムは 10 分ごとに過去 10 分間のログ量をチェックします。ログ量が 0 の場合、システムはデータレポートが中断されたと判断し、アラートをトリガーします。アラートは指定された受信者にショートメッセージで送信されます。10 分間のクールダウン期間が設定され、データリンクの異常を迅速に検出し対応できるようにします。
設定パラメーター:
[チェック頻度]:10 分の固定間隔。
[クエリ統計]:[追加] をクリックします。[クエリ統計] ダイアログボックスの [高度な設定] タブで、次の設定を使用します。
[タイプ]:Logstore
[権限付与方法]:デフォルト。
Logstore:
metering-log[専用 SQL]:無効化。
[クエリ間隔]:10 分 (相対時間)。クエリ SQL は次のとおりです。
* and type: log_traffic | select if(t.log_size is null, 0, t.log_size) from (select sum(log_size) log_size from log) t

[グループ評価]:グループ化なし。
トリガー条件:
データが条件に一致。 [評価式] は_col0<=0です。[出力先]:[SLS 通知] を選択し、スイッチをオンにします。
[アラートポリシー]:
[モード]:シンプルモード。
[アクショングループ]:
[チャンネル]:ショートメッセージ。他のチャンネルの設定方法については、「通知チャンネルの概要」をご参照ください。
[受信者タイプ]:静的受信者。
[コンテンツテンプレート]:SLS 組み込みコンテンツテンプレート。
[送信期間]:任意。
説明動的受信者を設定するには、「動的受信者の設定」をご参照ください。
[再試行間隔]:10 分。
アクセス問題
シナリオ:統合センターのデータソースのアクセス状態が異常です。
設定:Module Health の Logstore を 15 分ごとにチェックします。
statusの値がnormalでないデータが含まれている場合、アラートがトリガーされます。設定項目:
[チェック頻度]:15 分の固定間隔。
[クエリ統計]:[追加] をクリックします。[クエリ統計] ダイアログボックスの [高度な設定] タブで、次の設定を使用します。
タイプ: Logstore
[権限付与方法]:デフォルト。
Logstore:
health-log[専用 SQL]:無効化。
[クエリ間隔]:15 分 (相対時間)。クエリ SQL は次のとおりです。
* and type: data_ingestion_health | select count(*) count from log where status != 'normal'

[トリガー条件]:
データが条件に一致する。[評価式] はcount>0です。[出力先]:[SLS 通知] を選択し、スイッチをオンにします。
[アラートポリシー]:
[モード]:シンプルモード。
[アクショングループ]:
[チャンネル]:ショートメッセージ。他のチャンネルの設定方法については、「通知チャンネルの概要」をご参照ください。
[受信者タイプ]:静的受信者。
[コンテンツテンプレート]:SLS 組み込みコンテンツテンプレート。
[送信期間]:任意。
説明動的受信者を設定するには、「動的受信者の設定」をご参照ください。
[再試行間隔]:15 分。
コストとリスク
コストの説明:Cloud Observability 機能を有効にすると、モニタリングログが継続的に SLS に配信されます。これにより、ログストレージ (デフォルトの保持期間は 30 日) とクエリ分析の料金が発生します。これらの料金は SLS によって請求されます。
主なリスク:ログストレージのリージョンは、初期設定後にコンソールで変更することはできません。したがって、初期設定時にはリージョンを慎重に選択してください。リージョンを誤って選択すると、データリンクのレイテンシーが増加し、管理が複雑になる可能性があります。