--- sourceDocument: Yokohama IT Operations Management sourceDocumentLink: https://www.servicenow.com/docs/r/ja-JP/yokohama/it-operations-management Release : - yokohama ft:locale : - ja-JP ft:publication_title : - Yokohama IT Operations Management ft:clusterId : - itom bundleId : - itom workflow : - Technology --- # アラートのグループ化とユースケース # アラートのグループ化とユースケース {#ariaid-title1} * リリースバージョン: Yokohama * * 更新日 2025年01月30日 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：9分 アラートのグループ化の手法は、手動、ルールベース、タグクラスターなど、ユーザーが定義する方法から、自動、CMDB、テキストベース、ログアナリティクス、ネットワークトラフィックベースのグループ化などの高度で調整可能なアルゴリズムまで多岐にわたります。 {#alert-group-use-cases__table_dwb_r55_hcc__entry__3} | タイプ | 説明 | ユースケース | |-|-|-| | ログアナリティクスによるグループ化 | アラートは、ログデータの分析に基づいてグループ化されます。これには、関連するアラートと問題を特定するためのログエントリーの関連付けが含まれます。この方法では、ログのパターンとシーケンスを活用することで、IT 環境全体で複数ステップの複雑な問題を検出できます。 | あるオンラインゲーム会社は、プロアクティブなログアナリティクスを実装することでサーバーの安定性を強化しています。ゲームサーバーからのログをリアルタイムで監視し、分析ツールを使用して、クラッシュの前に発生するエラーのパターンを検出します。 たとえば、サーバーがクラッシュする約 30 分前に特定のエラーパターンが発生することが分析で明らかになっています。このようなパターンに対して自動アラートを設定することで、クラッシュが発生する前に、サービスの再起動やリソースの再割り当てなどの修復アクションを開始できます。このプロアクティブな方法は、プレイヤーに影響が及ぶ前に問題に対処することで、中断を防ぎ、ダウンタイムを最小限に抑え、ゲーム体験を向上させます。 | | ルールベースのグループ化 | アラートは、ユーザーが設定した事前定義済みのルールとクライテリアに従ってグループ化されます。こうしたルールには、しきい値やイベントタイプなどの特定の条件を含めることができます。この方法は、一貫性のある繰り返し可能なパターンに効果を発揮しますが、ルールのメンテナンスが必要です。 | e コマース Web サイトを管理するあるデータセンターでは、ルールベースのアラートのグループ化を、フラッシュセールなどのイベント中に大量のトラフィックを処理する際に役立てています。高 CPU 使用率など、サーバーの問題に関するアラートは、親アラートとして指定されます。このような親アラートは、データベースクエリが遅いなどの関連する問題を報告する子アラートにリンクされています。 こうしたルールにより、サーバー関連のアラートが症状とともにグループ化されるため、IT チームはサーバーの過負荷の問題を迅速に特定して対処できます。この方法は、問題解決を効率化し、ダウンタイムを最小限に抑えます。 | | 自動グループ化 | 高度なアルゴリズムにより、アラートデータのパターンと類似性に基づいて、関連するアラートが自動的に識別され、グループ化されます。この方法では、機械学習と AI を活用して新しい問題や未知の問題に適応し、先見的なアラート管理を実現します。 イベント管理は、類似しているが必ずしも同一ではないアラートを、前回のイベント生成との時間的近さに基づいてグループ化します。同じ CI と同じパターン識別子を持つアラートがグループ化されます。 自動アラートグループ化は、以下のコンポーネントで構成されています。 * アラートアグリゲーション学習 (サービスアナリティクスでのアラートアグリゲーション学習 - 日次)：このオフラインジョブは、過去のアラートを処理するために毎日実行され、統計分析を実行してアラートのパターンを構築します。詳細については、「[パターンベースのアラートグループ化の構成](https://www.servicenow.com/docs/0m7A5UTZ1h~hgvpcJ8DrxA "アラートアグリゲーション学習 (サービスアナリティクスでのアラートアグリゲーション学習 - 日次) を構成します。これは過去のアラートを処理するために毎日実行されるオフラインジョブです。パターンベースの手法と確率論的手法の組み合わせを使用して関連アラートのパターンを識別し、繰り返し発生する問題の迅速な検出と解決を可能にします。")」を参照してください。 * リアルタイムアラートアグリゲーションジョブ (RCA/アラートアグリゲーションを使用したサービスアナリティクスグループアラート)：このジョブは毎分実行され、アラートパターン、CMDB 関係、テキストの類似性、ユーザー定義のアラートクラスタリングタグ、およびプロセス間のネットワークトラフィック接続に基づいてアラートアグリゲーショングループを生成します。 {#alert-group-use-cases__ul_jyj_qn2_jcc} | ある大規模な金融機関では、機械学習を使用して多数のサーバーやアプリケーションからのアラートに対処する必要があります。システムによってアラートの履歴データが分析され、クライアント接続エラーを伴って頻繁に発生するデータベースサーバーの障害などのパターンが認識されます。その後、関連するアラートが自動的にグループ化されます。たとえば、新しいデータベースサーバーの障害アラートが検出されると、以前の接続エラーアラートとともにグループ化されます。 この自動グループ化により、IT チームとセキュリティチームは問題を迅速に特定して対処し、応答時間を短縮し、ダウンタイムを削減できます。 | | CMDB ベースのグループ化 | アラートは、構成管理データベース (CMDB) の構成アイテム (CI) の関係と依存関係に基づいてグループ化されます。こ方法により、特定のインフラストラクチャコンポーネントまたはサービスに関連するアラートがグループ化されるようになり、コンテキストに応じてアラートが管理されます。 | 通信会社では、CMDB データを使用して、ネットワークインフラストラクチャに関連するアラートを管理します。特定のネットワークルーターとその接続デバイスに関連するアラートは、CMDB の関係に基づいてグループ化されるため、ネットワークチームは関連するすべての問題を確認して、根本原因に効率よく対処できるようになります。 | | ネットワークトラフィックベースのグルーピング | ネットワークトラフィックベースのアラートグループ化は、ホスト間のプロセス間のネットワーク接続を分析して、関連するアラートを特定します。この方法では、ML サービスマッピングによって検出されたサービス候補を活用し、ネットワークトラフィックの問題に関連するアラートがグループ化されるようにして、コンテキストを改善し、アラートを迅速に解決します。 | クラウドベースの e コマース プラットフォームではトランザクションが遅くなり、支払い処理に遅延が生じます。従来のアラートでは、API タイムアウト、データベース遅延、ネットワークの問題に対して個別のアラートが生成されるため、根本原因を特定することが困難でした。 ネットワークトラフィックベースのグループ化では、ML サービスマッピングによって識別されたプロセス間の接続に基づいて、アラートが自動的にグループ化されます。システムは、支払ゲートウェイサービス、不正検出、および注文処理が同じサービス候補の一部であることを検出します。これにより、過負荷の不正検出プロセスがトランザクションのボトルネックを引き起こしていることが明らかになります。サービスをスケールアップすることで、チームは問題を迅速に解決し、ダウンタイムを最小限に抑え、カスタマーエクスペリエンスを向上させます。 | | テキストベースのグループ化 | アラートは、アラートのテキストコンテンツを分析して類似性と関連する問題を特定することでグループ化されます。アラートの説明、メトリクス名、および CI クラスの共通点を見つけるために、自然言語処理 (NLP) 技術が使用され、この手法が非構造化データに対して効果を発揮します。 | バーチャル会議に Zoom Rooms を使用しているある組織では、Zoom Room サーバーで機能停止が発生すると、IT チームは多数のアラートを受け取ります。Zoom Room No.10 がダウンしている、Zoom room No.11 がダウンしているなど、各アラートは異なる Zoom Room がダウンしていることを示しますが、相違点はルーム番号だけです。 CMDB を使用している組織の場合、CMDB 関係を使用してこれらのアラートをグループ化できます。関連するすべての Zoom Room に対するサーバーの影響に基づいて、システムでアラートが関連付けられるためです。ただし、CMDB を使用していない組織の場合は、テキストベースのグループ化を使用できます。システムによって自然言語処理が適用され、類似した説明を持つアラートがグループ化され、同じ根本的なサーバーの問題が複数の Zoom Room に影響していることを IT チームが迅速に特定できるようになります。こ方法では、IT チームは問題の根本原因に効率的に対処し、ダウンタイムを削減し、応答時間を短縮できます。 | | タグクラスターのグループ化 | アラートは、アプリケーション、サーバータイプ、地理的な場所などの共通属性を表すタグまたはラベルを使用して分類およびグループ化されます。この方法により、進化するタグ付け戦略に基づいて柔軟かつ動的なグループ化が可能になります。 | CMDB を使用していないある組織は、さまざまなサービスを実行している Linux サーバーを管理しています。IT チームは、各アラートのノードフィールドを使用してサーバーを特定し、このノード値に基づいて同じサーバー上のサービスに関連するすべてのイベントをグループ化します。たとえば、サービス A のダウンやサービス B の高 CPU 使用率などのアラートが同じノード値を共有している場合は、それらのアラートをクラスター化します。 この方法では、IT チームはサーバー関連の問題により効率的に対処できます。同じノード、アプリケーション、または IP アドレスのアラートをクラスター化することで、チームは対応作業を簡素化し、CMDB がなくても問題をより効果的に解決できます。 | | 手動でのグループ化 | ユーザーは、システムの専門知識と理解に基づいて、関連するアラートを手動で選択してグループ化します。この方法では、正確な制御が可能になりますが、時間がかかり、自動化された関連付けを見逃す恐れがあります。 | システムアドミニストレーターは、単一サーバー上のさまざまなサービスの障害に関する複数のアラートを受信します。アドミンは、こうしたアラートを手動でグループ化し、すべてがそのサーバーの単一のハードウェア障害に関連していることを認識して、ハードウェアの問題の修正を優先させてすべてのサービスを復元します。 | [表 : 1. アラートのグループ化タイプとユースケース] {#alert-group-use-cases__table_dwb_r55_hcc} 手動およびルールベースのアラートのグループ化は、主に親アラートの選択方法において、アルゴリズムベースのグループ化とは異なります。手動、ルールベース、またはログアナリティクスによるグループ化では、実際のアラートのいずれかが親アラートとして指定されます。自動、CMDB、テキストベース、タグクラスターの各モード、およびネットワークトラフィックでは、グループ内で最も古く、最も重大なアラートを表す仮想アラートが親アラートとして作成されます。 注: ドメインセパレーション環境では、同じドメイン内のアラートに対してのみアラートグループが作成されます。 スケジュール済みジョブとパラメーターの詳細については、「[アラートのグループ化のスケジュール済みジョブとパラメーター](https://www.servicenow.com/docs/31~fXQKOKhikG0QMhNpq1A "事前定義されたクライテリアとパラメーターに基づいてアラートをグループ化するジョブを構成して、アラート編成を自動化します。")」を参照してください。さまざまなグループ化タイプの詳細については、「[アラートのグループ化のタイプと作成方法](https://www.servicenow.com/docs/g6Cp1bNZ6O0rfOwzC9yPuQ "アラートのグループ化のさまざまなタイプを確認し、その説明を理解し、作成方法について学習して、問題を特定する能力を高め、アラート管理を簡素化します。")」を参照してください。