※ 本記事は、Kumar Varunによる”Enhancing OCI metrics and creating Alerts using Logging Analytics“を翻訳したものです。

2023年8月9日

ゲストの著者 – Alexandru-Adrian Birzu, Master Principal Tech Cloud Specialist (Observability & Management)

企業がクラウドに移行するにつれて、クラウド・インフラストラクチャのパフォーマンス、セキュリティおよび安定性を確保するための堅牢な監視およびアラート・メカニズムが重要になります。Oracle Cloud Infrastructure (OCI)は、ユーザーがリソースに関連する様々なメトリックを追跡および分析できる強力な監視サービスを提供します。ただし、シナリオによっては、メトリックを最適化してインサイトに富んだアラートを作成するために、追加のカスタマイズが必要な場合があります。

この包括的なガイドでは、OCIメトリックの強化方法と、Logging Analyticsを使用したアラートの作成方法を説明します。このチュートリアルでは、大規模なバンキング顧客によって実装された「DNS Query Count」メトリックの拡張に重点を置きますが、10を超えるメトリックや500を超えるメトリックがある場合でも、モニタリング・サービス内の他のメトリックに同じ原則を適用できます。この場合、新しいメトリックはDNSゾーン名です。

Email alert
図1: DNSゾーン名を含む電子メール・アラーム

ゾーン名がモニタリング・サービスの新しいディメンションとして使用可能になる方法

この場合、DNS Query Countが特定のしきい値を超えた場合(攻撃のシグナリングなど)、アラートの必要性が非常に重要になります。これをナビゲートするには、ゾーン名がモニタリング・サービスの新しいディメンションとして使用可能になるソリューションを次に示します。

process flow
図2: アラームとメトリックのワークフロー

 

この場合、DNS Query Countが特定のしきい値を超えた場合(攻撃のシグナリングなど)、アラートの必要性が非常に重要になります。これをナビゲートするには、ゾーン名がモニタリング・サービスの新しいディメンションとして使用可能になるソリューションを次に示します。

 

depiction
図3: OCI Monitoring for DNS Query Countでの問合せの作成

 

ステップ1: メトリック収集のストリームの作成

最初のステップでは、モニタリング・メトリックを取り込んでエクスポートするストリームを作成します。OCIのストリームでは、サービス間のシームレスなデータ転送が可能であるため、私たちの目的に最適な選択となっています。

ステップ2: サービス・コネクタ・ハブの構成

次に、メトリックをストリームからLogging Analyticsにコピーするサービス・コネクタ・ハブを作成します。このハブは、サービス間の橋渡しとして機能し、データの円滑なフローを確保します。

ステップ3: Logging Analyticsでのログ・ソースおよびパーサーの作成

このステップでは、Logging Analytics管理で新しいログ・ソースおよびパーサーを作成します。パーサーは、ログ・データから関連する情報を解釈および抽出するために使用されます。JSONパーサーを作成するためのサンプル・ログがあります(次の場合はoci_dnsログ、他のユースケースの場合はその他のメトリック・パーサーを使用します):

{
  “namespace”: “oci_dns”,
  “resourceGroup”: null,
  “compartmentId”: “ocid1.compartment.oc1..aaaaYourIDhere”,
  “name”: “DNSQueryCount”,
  “dimensions”: {
    “resourceId”: “ocid1.dns-zone.oc1.. YourIDhere”
  },
  “metadata”: {},
  “datapoints”: [
    {
      “timestamp”: 1687769100000,
      “value”: 26,
      “count”: 1
    }
  ]
}

 

 

{

  “namespace”: “oci_computeagent”,

  “resourceGroup”: null,

  “compartmentId”: “ocid1.compartment.oc1..aaaaaaaagYourIDhere”,

  “name”: “LoadAverage”,

  “dimensions”: {

    “instancePoolId”: “Default”,

    “resourceDisplayName”: “Arkime”,

    “faultDomain”: “FAULT-DOMAIN-1”,

    “resourceId”: “ocid1.instance.oc1.eu-frankfurt-1.aYourIDhere”,

    “availabilityDomain”: “NoEK:EU-FRANKFURT-1-AD-1”,

    “imageId”: “ocid1.image.oc1.eu-frankfurt-1.aaaaaaYourIDhere”,

    “region”: “eu-frankfurt-1”,

    “shape”: “VM.Standard.E4.Flex”

  },

  “metadata”: {

    “displayName”: “Load Average”,

    “unit”: “NumberOfProcesses”

  },

  “datapoints”: [

    {

      “timestamp”: 1687513887000,

      “value”: 0,

      “count”: 1

    },

    {

      “timestamp”: 1687513897000,

      “value”: 0,

      “count”: 1

    },

    {

      “timestamp”: 1687513907000,

      “value”: 0,

      “count”: 1

    },

    {

      “timestamp”: 1687513917010,

      “value”: 0,

      “count”: 1

    },

    {

      “timestamp”: 1687513927009,

      “value”: 0,

      “count”: 1

    },

    {

      “timestamp”: 1687513937001,

      “value”: 0,

      “count”: 1

    }

  ]

}

 

このシナリオでは、ディメンションに複数の値が含まれている場合に、OCI_Computeagentからの拡張メトリックを利用しました。その後、JSONパスをフィールドにマップしました。ここでの重要な点はデータ・ポイント値であるため、データ型がFloatのフィールドを作成する必要があります。カスタム・フィールドを作成する場合は、問題のフィールドが複数値フィールドであるかどうかを判断することが重要です。値を計算する場合は、「Float」を選択します。

ステップ4: Logging Analyticsでのカスタム・フィールドの定義

カスタム・フィールドは、データを効果的に処理および分析するために不可欠です。「フィールド名」の近くにある「+」オプションまたは「管理」セクションを使用して、カスタム・フィールドを作成します。

ステップ5: データ転送用の別のサービス・コネクタ・ハブの構成

カスタム・フィールドを作成した後、次のステップは、ストリーミングからLogging Analyticsにデータを移動する別のサービス・コネクタ・ハブを設定することです。これにより、追加処理のためにデータが正しくチャンネリングされます。これらすべてを設定すると、数分後に、Logging Analyticsにログインするメトリック・データ・ポイントがあります:

ステップ6: OCIDからゾーン名へのマッピングの参照の作成

このステップでは、DNSゾーンのOCIDを対応するゾーン名にマップする参照を作成して、DNSゾーンの識別に関する課題に対処します。このマッピングは、後続のステップでは非常に重要です。最初の行にOCID、2番目の行にゾーン名を含むCSVファイルをアップロードします。複数のゾーンの場合は、異なる行に適切なデリミタ付きで追加します。

ステップ7: 合計DNS問合せを表示する問合せの作成

ルックアップが整ったので、Resource IDを適切なフィールドに置き換えながら、DNS問合せの合計数を表示する問合せを作成します。この問合せは、さらに分析するために必要なデータに役立ちます。

query creation
図4:  DNSゾーンの問合せ作成 
'Log Source' = OCI_Monitoring and Monitoring_Metric_Name = DNSQueryCount 

| lookup table = DNS select 'Monitoring.Dimensions.ResourceID',

   'Zone Name' using Monitoring.Dimensions.ResourceID = 'Monitoring.Dimensions.ResourceID' 

| stats sum(Monitoring_Datapoints_Value) as 'DNS Queries' by 'Zone Name'

ステップ8: 検出ルールおよびアラームの作成

計算されたデータが使用可能な場合は、データをMonitoringに戻す検出ルールを作成でき、適切なタイミングで通知のためのアラームを設定できます。これらのアラートは、ルックアップからカスタム・フィールドが移入された潜在的な問題または異常の貴重なインジケータとして機能します。

適切なポリシーを確認し、メトリックの送信先を指定します。

Logging Analyticsとそのリソースへのアクセスの有効化(oracle.com)

Alert creation
図5: DNS Query Countのアラート作成

 

完了しました。アラームが作成され、適切なゾーン名で通知が届きます。

 

DNS queries
図6: Logging Analyticsからゾーン名を使用したアラート

 

Email alert
図7: DNSゾーン名を含む電子メールアラーム

 

結論として、高度な要件がある場合は、Oracle Cloud Infrastructure Monitoringで複数のDNSゾーンを管理することで、独自の課題に直面する可能性があります。ただし、拡張メトリック、Logging Analytics、カスタマイズされたフィールド、および適切に構造化されたルックアップを利用して、ニーズを監視およびアラートするための合理化されたソリューションを考案できます。

 

リソース

Oracle Cloud InfrastructureのObservability & Managementソリューションのレルムに関する詳細なインサイトについては、次のリンクを参照してください。:

Oracle Cloud Infrastructure Monitoring

Oracle Cloud Infrastructure Logging Analytics

Oracle Cloud Infrastructure Streaming

Oracle Cloud Infrastructure Connector Hub

これらのリソースは、効果的かつ効率的なクラウド・インフラストラクチャ管理への道筋となる、Oracleの可観測性ツール・スイートに関する豊富な情報および詳細なガイドを提供します。ハッピー・モニタリング!