OCI Logging AnalyticsでDatabaseの監査表やユーザー表を分析する

Logging Analyticsは、テキストやJSONファイルといったログデータを取り込んで分析することが多いですが、データベースの表に直接アクセスして、監査表(Unified Audit)やAutonomous Databaseのアラート表、ユーザー・アプリケーションの表などをLogging Analytics(以下、略LA)に取り込んで分析することが可能です。
ここでは、まずターゲットをAutonomous Databaseとして、ADBの監査表とアラート表を取り込む手順を一通り説明していきます。

構築イメージは以下の通りです。VMにインストールされた管理エージェントが実際に対象データベースにアクセスし、その結果をLAに送信する役目を持ちます。管理エージェントを動作させるVMは、DBとLAの両方にアクセスできなければなりません。今回はパブリックサブネットに新規のVMを一つ作成します。

本内容は、OCIの設定経験がある方向けに多少説明を割愛し、設定の流れがイメージできるように構成しています。より丁寧な手順についてはOCIチュートリアルにもありますので、こちらも参考にして下さい。

必要となるIAM権限

OCIチュートリアルの動的グループ、ポリシーを参照して設定

管理エージェント用のVMを作成

イメージ -> Oracle Linux8、 シェイプ -> VM Standard E4 1core、 パブリック IP有
拡張オプションを展開し、Oracle Cloudエージェントの管理エージェントのプラグインをチェックして作成する

ADBの準備

既存のADBを使用、またはATP/ADBの最小構成で作成。今回は、名前をATP1DemoとしてATPで作成
データベースの接続に必要なウォレット(Wallet_ATP1Demo.zip)を作成したVMの/home/opcディレクトリにコピーする
解凍したファイルの中から、tnsnames.oraファイルを開き、使用したいデータベースへの接続サービス名をメモしておく。ここでは、atp1demo_mediumを使用する

$ ls
cwallet.sso  ewallet.pem   ojdbc.properties  sqlnet.ora    truststore.jks
ewallet.p12  keystore.jks  README            tnsnames.ora
$ cat tnsnames.ora
atp1demo_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=xxxx.adb.us-ashburn-1.oraclecloud.com))(connect_data=(service_name=xxxx_opitestpv2_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=yes)))

Logging Analyticsのログ・グループの作成

ログ・グループは、ADBから取り込んだログをどのグループに所属させるかという指定が必要なため、任意のグループ名を指定

• 管理 -> ロググループ -> ログ・グループの作成
  

Logging Analyticsのエンティティの作成

エンティティは、Logging Analyticsのログ収集ターゲットのことで、ここではATPまたはADWのエンティティを指定し新規に作成する

• 管理 -> エンティティ -> エンティティの作成
• エンティティ・タイプ->対象のADBタイプ、名前->任意、管理エージェント->作成したVM、service_name->ADBの接続サービス名
  

管理エージェントがADBに接続するための設定

• 認証用のjSONファイルを準備。赤字の部分を自身の環境に合わせて修正し、creds.jsonとして/home/opcに保存する
  {
  "source": "lacollector.la_database_sql",
  "name": "LCAgentDBCreds.ATP1Demo",
  "type": "DBTCPSCreds",
  "usage": "LOGANALYTICS",
  "disabled": "false",
  "properties":[
  {"name":"DBUserName","value":"ADMIN"},
  {"name":"DBPassword","value":"password"},
  {"name":"ssl_trustStoreType","value":"JKS"},
  {"name":"ssl_trustStoreLocation","value":"/home/opc/truststore.jks"},
  {"name":"ssl_trustStorePassword","value":"password"},
  {"name":"ssl_keyStoreType","value":"JKS"},
  {"name":"ssl_keyStoreLocation","value":"/home/opc/ATP1Demo/keystore.jks"},
  {"name":"ssl_keyStorePassword","value":"password"},
  {"name":"ssl_server_cert_dn","value":"CN=adb.us-ashburn-1.oraclecloud.com"}]
  }

• 管理エージェントはoracle-cloud-agentユーザで動作するため、oracle-cloud-agentがWalletディレクトリにアクセスできるように権限を付与する

# sudo setfacl -m user:oracle-cloud-agent:rx  /home/opc
# sudo setfacl -m user:oracle-cloud-agent:rx  /home/opc/Wallet_ATP1Demo
# sudo -u oracle-cloud-agent head -5 /home/opc/Wallet_ATP1Demo/truststore.jks <--結果が返ってくればOK

• rootにスイッチして、Logging Analyticsに認証情報を登録するスクリプトを実行

# sudo su -
# cat /home/opc/creds.json | sh /var/lib/oracle-cloud-agent/plugins/oci-managementagent/polaris/agent_inst/bin/credential_mgmt.sh -o upsertCredentials -s logan
    Effect Credential         Source
---------- ------------------ -------------------------------------------------
     ADDED LCAgentDBCreds.ATP1Demo lacollector.la_database_sql                  
             Type: DBTCPSCreds [DBUserName, DBPassword, ssl_trustStoreType, ssl_trustStoreLocation, ssl_trustStorePassword, ssl_keyStoreType, ssl_keyStoreLocation, ssl_keyStorePassword, ssl_server_cert_dn]
1 credential(s) added to the logan service. <--作成メッセージが出ればOK

監査表(Unified Audit)を収集する

以下の設定をすると、管理エージェントが上記で作成した認証情報を使ってADBの監査表に直接アクセスする

• 管理 -> ソース -> Oracle Unified DB Audit Log Source Stored in Database 12.2のソースをクリック
  関連付られていないエンティティから作成したエンティティをチェックし、アソシエーションの追加。ログ・グループは作成したものを指定する
  

• 設定に何か不足がある場合は、対象のエンティティ -> エージェントの収集報告に下記のようなエラーメッセージが出力される
  

• ログ・エクスプローラーにログソース名 'Oracle Unified DB Audit Log Source Stored in Database 12.2'が出力されていればOK
  

アラート表(V$DIAG_ALERT_EXT)を収集する

アラート表の定義は、Logging Analyticsにはデフォルト存在していないので新規の作成が必要

• 管理 -> ソース -> ソースの作成
  名前->任意、ソースタイプ->Database、エンティティ・タイプ->Autonomous Transaction Processingを選択し、SQL問い合わせに以下を追記し、構成をクリック
  SELECT ORIGINATING_TIMESTAMP, PROCESS_ID, MESSAGE_TEXT FROM V$DIAG_ALERT_EXT
  
  アラート表の列名とLogging Analyticsのフィールド名をマッピングする。フィールド名は既存のものから選択。マッピング完了後、ソースを作成する
  

• 作成したソースをエンティティに紐づける。管理 -> ソース -> ATP_Alertのソースをクリック
  監査表の場合と同様に、関連付られていないエンティティから作成したエンティティをチェックし、アソシエーションの追加をする、
  

• Logging AnalyticsにATP_Alertが表示されれば完了
  

データ・ディクショナリビューから任意の情報を収集する

共有のADBは、OCI Monitoringに各表領域の使用状況の表すメトリックがありません。ここでは表領域の使用率を取得するデータ・ディクショナリにアクセスするクエリー定義を新たに作成してみる。手順は、アラート表の場合と同じ

データベース問い合わせに使うSQLはこちら
select sysdate , a.TABLESPACE_NAME , min(a.BYTES)/1024/1024 "Size/M" , round(min(a.BYTES)/(10241024) - sum(b.BYTES)/ (10241024),2) "Used/M" , round((min(a.BYTES)/(10241024) - sum(b.BYTES)/(10241024))/ (min(a.BYTES)/1024/1024)100,2) "Usage/%" , round(sum(b.BYTES)/(10241024),2) "Free/M" from dba_data_files a, dba_free_space b where a.FILE_ID = b.FILE_ID group by a.TABLESPACE_NAME

クエリーの列とマッピングするLogging Analyticsのフィールドは、+ボタンをクリックして新規作成

• 取得したログからLogging Analyticsのグラフで描写
  

トラブル・シューティング

うまく取り込めない場合の多くは、DBの認証に関連する場合が多いです。LAのエージェント・ユーザがウォレット・ファイルにアクセスできていない、認証のJSON内のDBパスワードや指定ディレクトリの間違い、ADBのリスニングポートがブロックされている等々

コンソール上でもエラーメッセージは確認できますが、管理エージェントのログから調査も可能です

管理エージェントに関するログの場所
/var/lib/oracle-cloud-agent/plugins/oci-managementagent/polaris/agent_inst/log
特に、mgmt_agent_logan.logには、不具合の原因を追究できる情報が出力されている場合があります

今回は、ターゲットにADBを対象に設定しましたが、同様にBaseDBやExaDB-Dのようなクラウド・データベースから監査表やユーザー表のレコードを収集することも可能です。その場合、今回の作成したVMからそれらのDBにアクセスして収集する方式が取れるので、1台のVM+管理エージェントで複数のデータベースの表をターゲットとして収集することが可能です