MariaDB

MariaDB 統合では、InnoDB、バッファプール、その他のさまざまなオペレーションに関連するパフォーマンス指標を収集します。また、一般ログ、エラーログ、スロークエリログを収集して解析し、JSON ペイロードを生成します。エラーログは、エラーコードとサブシステムに対して解析されます。スロークエリログを解析して、クエリ時間や検査された行など、クエリのパフォーマンスを表す Key-Value ペアを生成します。

MariaDB の詳細については、MariaDB のドキュメントをご覧ください。

前提条件

MariaDB テレメトリーを収集するには、Ops エージェントをインストールする必要があります。

指標の場合は、バージョン 2.37.0 以降をインストールします。
ログの場合は、バージョン 2.37.0 以降をインストールします。

この統合は、MariaDB バージョン 10.1.X～10.7.X をサポートしています。

MariaDB インスタンスを構成する

MariaDB は、コミュニティによって開発された、MySQL リレーショナルデータベース管理システム（RDBMS）の商用サポートされているフォークです。MariaDB のログと指標を収集するには、mysql レシーバーを使用します。

mysql 指標レシーバーは、root ユーザーとして Unix ソケットと Unix 認証を使用し、デフォルトでローカルの MariaDB サーバーに接続します。

mysql_error ロギングレシーバーは、次の表に示すデフォルトのファイルパスからログを収集します。一部のプラットフォームでは、MariaDB はデフォルトでファイルではなく journald にログを記録します。ファイルにロギングするように MariaDB を構成するには、MariaDB 構成の log_error オプションを設定します。log_error 構成の詳細については、ファイルへのエラーログの書き込みをご覧ください。

MariaDB 用に Ops エージェントを構成する

Ops エージェントを構成するのガイドに従って、MariaDB インスタンスからテレメトリーを収集するために必要な要素を追加し、エージェントを再起動します。

構成の例

次のコマンドは、MariaDB のテレメトリーを収集して取り込む構成を作成します。

# Configures Ops Agent to collect telemetry from the app. You must restart the agent for the configuration to take effect.

set -e

# Check if the file exists
if [ ! -f /etc/google-cloud-ops-agent/config.yaml ]; then
  # Create the file if it doesn't exist.
  sudo mkdir -p /etc/google-cloud-ops-agent
  sudo touch /etc/google-cloud-ops-agent/config.yaml
fi

# Create a back up of the existing file so existing configurations are not lost.
sudo cp /etc/google-cloud-ops-agent/config.yaml /etc/google-cloud-ops-agent/config.yaml.bak

# Configure the Ops Agent.
sudo tee /etc/google-cloud-ops-agent/config.yaml > /dev/null << EOF
metrics:
  receivers:
    mysql:
      type: mysql
  service:
    pipelines:
      mysql:
        receivers:
        - mysql
logging:
  receivers:
    mysql_error:
      type: mysql_error
    mysql_general:
      type: mysql_general
    mysql_slow:
      type: mysql_slow
  service:
    pipelines:
      mysql:
        receivers:
          - mysql_error
          - mysql_general
          - mysql_slow
EOF

これらの変更を有効にするには、Ops エージェントを再起動する必要があります。

Linux

エージェントを再起動するには、インスタンスで次のコマンドを実行します。
```
sudo systemctl restart google-cloud-ops-agent
```
エージェントが再起動したことを確認するには、次のコマンドを実行して「Metrics Agent」と「Logging エージェント」のコンポーネントが起動したことを確認します。
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

RDP または同様のツールを使用してインスタンスに接続し、Windows にログインします。
PowerShell アイコンを右クリックし、[管理者として実行] を選択して、管理者権限で PowerShell ターミナルを開きます。
エージェントを再起動するには、次の PowerShell コマンドを実行します。
```
Restart-Service google-cloud-ops-agent -Force
```
エージェントが再起動したことを確認するには、次のコマンドを実行して「Metrics Agent」と「Logging エージェント」のコンポーネントが起動したことを確認します。
```
Get-Service google-cloud-ops-agent*
```

ログの収集を構成する

MariaDB からログを取り込むには、MariaDB が生成するログのレシーバーを作成してから、新しいレシーバー用のパイプラインを作成する必要があります。

mysql_error ログのレシーバーを構成するには、次のフィールドを指定します。

フィールド	デフォルト	説明
`exclude_paths`		`include_paths` の照合で除外するファイルシステムパスのパターンのリスト。
`include_paths`	`[/var/log/mysqld.log, /var/log/mysql/mysqld.log, /var/log/mysql/error.log, /run/mysqld/mysqld.err, /var/lib/mysql/${HOSTNAME}.err]`	各ファイルのテーリングで読み込むファイルシステムのパスのリスト。パスには、`/var/log/mysql/.log` のように、ワイルドカード（``）を使用できます。
`record_log_file_path`	`false`	`true` に設定すると、ログレコードの取得元のファイルのパスが `agent.googleapis.com/log_file_path` ラベルの値として出力ログエントリに表示されます。ワイルドカードを使用する場合、レコードを取得したファイルのパスのみが記録されます。
`type`		この値は、`mysql_error` にする必要があります。
`wildcard_refresh_interval`	`60s`	`include_paths` のワイルドカードファイルのパスの更新間隔。期間を指定します（例: `30s`、`2m`）。このプロパティは、ログファイルのローテーションがデフォルトの間隔よりも速く、ロギングのスループットが高い場合に有用です。

mysql_general ログのレシーバーを構成するには、次のフィールドを指定します。

フィールド	デフォルト	説明
`exclude_paths`		`include_paths` の照合で除外するファイルシステムパスのパターンのリスト。
`include_paths`	`[/var/lib/mysql/${HOSTNAME}.log]`	各ファイルのテーリングで読み込むファイルシステムのパスのリスト。パスにはワイルドカード（`*`）を使用できます。
`record_log_file_path`	`false`	`true` に設定すると、ログレコードの取得元のファイルのパスが `agent.googleapis.com/log_file_path` ラベルの値として出力ログエントリに表示されます。ワイルドカードを使用する場合、レコードを取得したファイルのパスのみが記録されます。
`type`		この値は、`mysql_general` にする必要があります。
`wildcard_refresh_interval`	`60s`	`include_paths` のワイルドカードファイルのパスの更新間隔。期間を指定します（例: `30s`、`2m`）。このプロパティは、ログファイルのローテーションがデフォルトの間隔よりも速く、ロギングのスループットが高い場合に有用です。

mysql_slow ログのレシーバーを構成するには、次のフィールドを指定します。

フィールド	デフォルト	説明
`exclude_paths`		`include_paths` の照合で除外するファイルシステムパスのパターンのリスト。
`include_paths`	`[/var/lib/mysql/${HOSTNAME}-slow.log]`	各ファイルのテーリングで読み込むファイルシステムのパスのリスト。パスにはワイルドカード（`*`）を使用できます。
`record_log_file_path`	`false`	`true` に設定すると、ログレコードの取得元のファイルのパスが `agent.googleapis.com/log_file_path` ラベルの値として出力ログエントリに表示されます。ワイルドカードを使用する場合、レコードを取得したファイルのパスのみが記録されます。
`type`		この値は、`mysql_slow` にする必要があります。
`wildcard_refresh_interval`	`60s`	`include_paths` のワイルドカードファイルのパスの更新間隔。期間を指定します（例: `30s`、`2m`）。このプロパティは、ログファイルのローテーションがデフォルトの間隔よりも速く、ロギングのスループットが高い場合に有用です。

ログの内容

logName は、構成で指定されたレシーバー ID から取得されます。LogEntry 内の詳細なフィールドは、次のとおりです。

mysql_error ログの LogEntry には次のフィールドが含まれます。

フィールド	タイプ	説明
`jsonPayload.errorCode`	文字列	ログに関連付けられた MySQL エラーコード
`jsonPayload.level`	文字列	ログエントリレベル
`jsonPayload.message`	文字列	ログメッセージ
`jsonPayload.subsystem`	文字列	ログが発生した MySQL サブシステム
`jsonPayload.tid`	数値	ログの生成元のスレッド ID
`severity`	文字列（`LogSeverity`）	ログエントリレベル（変換済み）。

mysql_general ログの LogEntry には次のフィールドが含まれます。

フィールド	タイプ	説明
`jsonPayload.command`	文字列	ログに記録されるデータベースアクションの種類
`jsonPayload.message`	文字列	データベースアクションのログ
`jsonPayload.tid`	数値	ログの生成元のスレッド ID
`severity`	文字列（`LogSeverity`）	ログエントリレベル（変換済み）。

mysql_slow ログの LogEntry には次のフィールドが含まれます。

フィールド	タイプ	説明
`jsonPayload.bytesSent`	数値	すべてのクライアントに送信されたバイト数
`jsonPayload.createdTmpDiskTables` ^†	数値	サーバーによって作成された内部ディスク上の一時テーブルの数
`jsonPayload.createdTmpTables` ^†	数値	サーバーによって作成された内部一時テーブルの数
`jsonPayload.createdTmpTableSizes` ^†	数値	サーバーによって作成された内部一時テーブルで使用されるバイト数
`jsonPayload.database`	文字列	クエリが実行されたデータベース
`jsonPayload.filesort` ^†	ブール値	ステートメントで filesort が使用された
`jsonPayload.filesortOnDisk` ^†	ブール値	ステートメントで、ディスク上の一時テーブルを必要とするファイルソートが使用された
`jsonPayload.fullJoin` ^†	ブール値	ステートメントでインデックスを使用してテーブルを結合していない
`jsonPayload.fullScan` ^†	ブール値	ステートメントでテーブル全体のスキャンが使用された
`jsonPayload.host`	文字列	クライアントが接続したホスト名
`jsonPayload.ipAddress`	文字列	クライアントが接続した IP アドレス
`jsonPayload.lockTime`	数値	ロックを取得するまでの時間（秒）
`jsonPayload.message`	文字列	クエリの全文
`jsonPayload.priorityQueue` ^†	ブール値	ステートメントで優先キューファイルソートが使用された
`jsonPayload.queryCacheHit`	ブール値	ステートメントがクエリキャッシュから提供された
`jsonPayload.queryTime`	数値	ステートメントの実行時間（秒）
`jsonPayload.rowsAffected`	整数	ステートメントによって影響を受ける行数
`jsonPayload.rowsExamined`	数値	サーバーレイヤによって検査される行数
`jsonPayload.rowsSent`	数値	クライアントに送信された行数
`jsonPayload.sortMergePasses` ^†	数値	並べ替えアルゴリズムで行う必要があったマージパスの数
`jsonPayload.storedRoutine`	文字列	現在実行中のストアドルーティンの名前
`jsonPayload.tid`	数値	クエリがログに記録されたスレッド ID
`jsonPayload.user`	文字列	クエリを実行した認証済みユーザー
`severity`	文字列（`LogSeverity`）	ログエントリレベル（変換済み）。

^† これらのフィールドは、log_slow_verbosity システム変数に 'query_plan' が含まれている場合にのみ提供されます。

指標の収集を構成する

MariaDB から指標を取り込むには、MariaDB が生成する指標のレシーバーを作成してから、新しいレシーバー用のパイプラインを作成する必要があります。

このレシーバーでは、複数のエンドポイントのモニタリングなど、構成で複数のインスタンスを使用することはできません。このようなインスタンスはすべて同じ時系列に書き込まれるため、Cloud Monitoring ではインスタンスを区別できません。

mysql 指標のレシーバーを構成するには、次のフィールドを指定します。

フィールド	デフォルト	説明
`collection_interval`	`60s`	期間の値（例: `30s`、`5m`）。
`endpoint`	`/var/run/mysqld/mysqld.sock`	MariaDB サーバーへの接続に使用される `hostname:port` または `/` で始まる Unix ソケットパス。
`password`		サーバーへの接続に使用するパスワード。
`type`		値は、`mysql` にする必要があります。
`username`	`root`	サーバーへの接続に使用するユーザー名。

モニタリング対象

次の表に、Ops エージェントが MariaDB インスタンスから収集する指標の一覧を示します。

指標タイプ
種類、タイプモニタリング対象リソース	ラベル
`workload.googleapis.com/mysql.buffer_pool_data_pages`
`GAUGE`、`INT64` gce_instance	`status`
`workload.googleapis.com/mysql.buffer_pool_limit`
`GAUGE`、`INT64` gce_instance
`workload.googleapis.com/mysql.buffer_pool_operations`
`CUMULATIVE`、`INT64` gce_instance	`operation`
`workload.googleapis.com/mysql.buffer_pool_page_flushes`
`CUMULATIVE`、`INT64` gce_instance
`workload.googleapis.com/mysql.buffer_pool_pages`
`GAUGE`、`DOUBLE` gce_instance	`kind`
`workload.googleapis.com/mysql.buffer_pool_size`
`GAUGE`、`DOUBLE` gce_instance	`kind`
`workload.googleapis.com/mysql.commands`
`CUMULATIVE`、`INT64` gce_instance	`command`
`workload.googleapis.com/mysql.double_writes`
`CUMULATIVE`、`INT64` gce_instance	`kind`
`workload.googleapis.com/mysql.handlers`
`CUMULATIVE`、`INT64` gce_instance	`kind`
`workload.googleapis.com/mysql.locks`
`CUMULATIVE`、`INT64` gce_instance	`kind`
`workload.googleapis.com/mysql.log_operations`
`CUMULATIVE`、`INT64` gce_instance	`operation`
`workload.googleapis.com/mysql.operations`
`CUMULATIVE`、`INT64` gce_instance	`operation`
`workload.googleapis.com/mysql.page_operations`
`CUMULATIVE`、`INT64` gce_instance	`operation`
`workload.googleapis.com/mysql.replica.sql_delay`
`GAUGE`、`INT64` gce_instance
`workload.googleapis.com/mysql.replica.time_behind_source`
`GAUGE`、`INT64` gce_instance
`workload.googleapis.com/mysql.row_locks`
`CUMULATIVE`、`INT64` gce_instance	`kind`
`workload.googleapis.com/mysql.row_operations`
`CUMULATIVE`、`INT64` gce_instance	`operation`
`workload.googleapis.com/mysql.sorts`
`CUMULATIVE`、`INT64` gce_instance	`kind`
`workload.googleapis.com/mysql.threads`
`GAUGE`、`DOUBLE` gce_instance	`kind`

構成を確認する

このセクションでは、MariaDB レシーバーが正しく構成されていることを確認する方法について説明します。Ops エージェントがテレメトリーの収集を開始するまでに 1～2 分かかる場合があります。

MariaDB ログが Cloud Logging に送信されていることを確認するには、次のようにします。

Google Cloud コンソールで、[ログエクスプローラ] ページに移動します。
[ログエクスプローラ] に移動

検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。

エディタに次のクエリを入力し、[クエリを実行] をクリックします。

resource.type="gce_instance"
(log_id("mysql_error") OR log_id("mysql_general") OR log_id("mysql_slow"))

MariaDB 指標が Cloud Monitoring に送信されていることを確認するには、次のようにします。

Google Cloud コンソールで Metrics explorer のページに移動します。
[Metrics Explorer] に移動

検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。
クエリビルダーペインのツールバーで、[MQL] または [PROMQL] という名前のボタンを選択します。
[言語] で [PromQL] が選択されていることを確認します。言語切り替えボタンは、クエリの書式設定と同じツールバーにあります。
エディタに次のクエリを入力し、[クエリを実行] をクリックします。
```
{"workload.googleapis.com/mysql.threads", monitored_resource="gce_instance"}
```

ダッシュボードを表示する

MariaDB 指標を表示するには、グラフまたはダッシュボードが構成されている必要があります。MariaDB では MySQL と同じダッシュボードが使用されます。インテグレーションを構成して Ops エージェントが指標データの収集を開始すると、ダッシュボードは自動的にインストールされます。

インテグレーションをインストールすることなく、ダッシュボードの静的プレビューを表示することもできます。

インストールされているダッシュボードを表示する手順は次のとおりです。

Google Cloud コンソールで [ダッシュボード] ページに移動します。
[ダッシュボード] に移動

検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。
[ダッシュボードリスト] タブを選択し、[統合] カテゴリを選択します。
表示するダッシュボードの名前をクリックします。MariaDB では MySQL と同じダッシュボードが使用されます。

インテグレーションを構成してもダッシュボードがインストールされていない場合は、Ops エージェントが実行されていることを確認します。ダッシュボードにグラフの指標データがない場合、ダッシュボードのインストールは失敗します。Ops エージェントが指標の収集を開始した後に、ダッシュボードがインストールされます。

ダッシュボードの静的プレビューを表示する手順は次のとおりです。

Google Cloud コンソールで [インテグレーション] ページに移動します。
[インテグレーション] に移動

検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。
デプロイメントプラットフォームフィルタの [Compute Engine] をクリックします。
MySQL のエントリを見つけて [詳細を表示] をクリックします。MariaDB では MySQL と同じダッシュボードが使用されます。
[ダッシュボード] タブを選択すると、静的プレビューが表示されます。ダッシュボードがインストールされている場合は、[ダッシュボードを表示] をクリックして移動できます。

Cloud Monitoring のダッシュボードについて詳しくは、ダッシュボードとグラフをご覧ください。

[インテグレーション] ページの使用方法については、インテグレーションを管理するをご覧ください。

アラートポリシーをインストールする

アラートポリシーは、指定した条件が成立した際に通知するように Cloud Monitoring に指示します。MariaDB では、MySQL と同じアラートポリシーが使用されます。これらのアラートポリシーは、Monitoring の [インテグレーション] ページで表示してインストールできます。

使用可能なアラートポリシーの説明を表示してインストールする手順は次のとおりです。

Google Cloud コンソールで [インテグレーション] ページに移動します。
[インテグレーション] に移動

検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。
MySQL のエントリを見つけて [詳細を表示] をクリックします。MariaDB では、MySQL と同じアラートポリシーが使用されます。
[アラート] タブを選択します。このタブには、利用可能なアラートポリシーの説明と、それらをインストールするためのインターフェースが表示されます。
アラートポリシーをインストールします。アラートポリシーでは、アラートがトリガーされた通知の送信先を特定する必要があるため、インストール環境の情報が必要になります。アラートポリシーをインストールする手順は次のとおりです。
1. 利用可能なアラートポリシーのリストから、インストールするアラートポリシーを選択します。
2. [通知の構成] セクションで、1 つ以上の通知チャンネルを選択します。通知チャンネルの使用を無効にすることもできますが、無効にすると、アラートポリシーは通知なく起動します。Monitoring でステータスを確認できますが、通知は受信しません。
  
  通知チャンネルの詳細については、通知チャンネルを管理するをご覧ください。
3. [ポリシーの作成] をクリックします。

Cloud Monitoring のアラートポリシーの詳細については、アラートの概要をご覧ください。