システムメトリック（Linuxベースのシステムに適用）
万一SQL Diagnostic Managerがこのサーバーと通信する時にSSHを使用したい場合、このタブから設定することができます。SQL Diagnostic ManagerはデフォルトでSSH通信を無効にします。それを使用するためには、Enable System Metricsのスイッチをクリックします。そうすると、サーバーのSSHを有効にするために必要な設定オプションが表示されます。
この機能に必要な権限の詳細については、システム権限を参照してください。
この登録のためにMySQLへのSSH トンネリングが正しく設定された場合、SSHトンネリングユーザーが十分な権限を持っていれば、ここでも同じ詳細を使用できます。
SSH接続の使用
SSH接続を作成するためには、以下の情報が求められます。
- SSH Host: SSHサーバーが稼働しているマシンのホスト。
- SSH Port: SSHサーバーが待ち受けているポート。デフォルトでは22。
- SSH Username: SSHサーバー（注: MySQLサーバーではない）にアクセスするためのユーザー名。
- Authentication type: 使用する認証タイプを指定します。キーベースまたはパスワードベースのいずれかです。
- 認証タイプにPasswordを指定した場合 - パスワードを入力します。
- 認証タイプにKeyを指定した場合 - SQL Diagnostic ManagerはSSH接続のキーベース認証で“OpenSSH標準キー形式”のみサポートしています。
- Private Key: プライベートキーファイルの内容を貼り付けます。プライベートキーファイルのパスを指定しないでください。
- Passphrase: プライベートキーファイルのパスフレーズを入力します（存在する場合）。プライベートキーのパスフレーズがない場合は空白のままでかまいません。
データ収集オプション
サーバーからデータを収集するためには、SQL Diagnostic ManagerがさまざまなMySQLとOSメトリックを収集して保存できるように、“Enable Data Collection”を選択する必要があります。
目的のサーバーごとに収集間隔を定義します。
連続した2回のデータ収集間の時間間隔を定義することも可能です。適切な間隔は状況によって異なります。本番システムでは、2～10分から始めるとよいでしょう。
データ保持の時間フレーム
SQL Diagnostic Managerは、大量のデータを長期にわたって保存するように設計されています。指定した時間フレームの前に収集されたデータは自動的に破棄されます。時間フレームは特定のサーバーに対して、秒、分、時間、日の単位で指定可能です。
基準時刻
アップタイムベースのカウンターの計算では、各ステータス変数の現在値が以下のいずれかと比較されます。
- サーバーステータス変数‘uptime’
- サーバーステータス変数‘uptime_since_flush_status’
- SQL Diagnostic Managerの‘基準時刻’設定
SQL Diagnostic Managerの‘基準時刻’が定義済み、かつ、サーバーステータス変数uptime_since_flush_statusが使用可能な場合、uptime_since_flush_statusが使用されます。使用できない場合は基準時刻が使用されます。
このように実装されているのは、FLUSH STATUSがMySQLサーバーで実行された場合にサーバーステータス変数がサーバー再起動後と同じ値にリセットされてしまうからです。ただし、1つの重要な例外があり、それは‘uptime’ステータス変数そのものです。この1つのステータス変数だけがFLUSH STATUSの影響を受けません。
したがって、uptime_since_flush_status変数をサポートしないサーバーを使用してSQL Diagnostic Managerで真のアップタイムベースのカウンターを実現するためには、SQL Diagnostic Managerの‘基準時刻’をFLUSH STATUSの最終実行時間以上に定義する必要があります。
ただし、uptimeやuptime_since_flush_statusが大きい（‘古い’）場合、‘基準時刻’設定を使用して、定義済みの間隔でアップタイムベースのカウンターを解析できます。例えば、サーバーが数か月稼働している場合、定義されている時のみ指定時間以降に収集されたデータに基づいてアップタイムベースのカウンターを解析することを選択できます。
また、‘基準時刻’がuptime（または、使用可能な場合はuptime_since_flush_status）より小さい場合、‘基準時刻’設定は無視されることに注意してください。‘uptime’より大きい‘基準時刻’やuptime_since_flush_statusを使用する場合、基準時刻が考慮されます。基準時刻が未来である場合、最新の収集時刻が考慮されます（デルタと同様）。
レプリケーション設定
SQL Diagnostic Manager はスレーブで“SHOW SLAVE STATUS”を発行することで MySQL レプリケーション状態を監視します。また、マスター詳細があれば、スレーブを自動登録することもできます。
スレーブのレプリケーション
MySQLレプリケーションを監視するためには、“Yes”を選択します。このオプションを使用するためには、MySQLユーザーが“Super”または“Replication Client”のグローバル権限を持っている必要があります。
スレーブの自動登録
SQL Diagnostic Managerのこの機能により、各スレーブを個別に登録する時間を節約できます。SQL Diagnostic Managerですべてのスレーブを自動登録するためには、スレーブの登録中に‘Advanced settings’タブの“Auto-Register slaves”オプションをオンにする必要があります。マスターが登録済みである場合、‘Edit Server’をクリックして‘Advanced settings’タブの‘Auto-Register slaves’をオンにします。スレーブのMySQLとSSHの詳細は‘マスター’と同じであると想定されます。スレーブの詳細がマスターと異なる場合、サーバーを手動で編集し、詳細を変更しなければなりません。
スレーブの自動登録は、レプリケーションの複数のレベルに波及します。例えば、サーバーAがマスター、サーバーBがスレーブであるとします。さらに、サーバーBのスレーブがサーバーCであるとします。この場合、サーバーAを登録しているときに‘Auto-Register Slaves’をオンにすると、AのMySQLとSSHの詳細がBと同じである場合、A、B、Cが登録されます。
では、どのようにしてSQL Diagnostic Managerは特定のマスターのすべてのスレーブを自動登録するのでしょうか？SQL Diagnostic Managerはマスターで“SHOW FULL PROCESSLIST”を発行し、接続されているすべてのスレーブを確認します（スレーブのMySQLとSSHの詳細がマスターと同じであると想定）。レプリケーショントポロジーを表示するためには、Replicationタブをクリックしてください。
Galera
このオプションを使用すると、クラスタのすべてのGaleraノードをSQL Diagnostic Managerに自動登録できます。それらのノードのMySQLとSSHの詳細がこのオプションが有効なノードと同じであると仮定されます。他のノードの詳細がこのオプションが有効なノードの詳細と異なる場合には、そのサーバーを手動で編集し、詳細を変更しなければなりません。“Test”を実行すると、SQL Diagnostic Managerが他のノードに接続できるかどうか確認できます。“Test”が成功のメッセージを出した場合、“Save”をクリックしましょう。そうすると、SQL Diagnostic Managerは検出されたノードを登録し、すべての登録済みのノードを確認できるServersページにリダイレクトされます。
MySQLエラーログ設定
MySQLエラーログは、サーバーの状態を把握するために不可欠です。エラーログ監視を有効にすることによって、SQL Diagnostic ManagerでMySQLエラーログを監視し、重要な情報について通知を受け取れるようになり、何日も眠れない夜を過ごさずに済みます。
Enable error log monitoring:
エラーログ監視を有効にするためには、[Yes] を選択します。
Read file from:
ログファイルにアクセスする方法は3通りあります。ログがSQL Diagnostic Managerが稼働しているマシンにある場合、または、SQL Diagnostic Managerが共有ネットワークドライブでログにアクセスできる場合、"Local path"を選択します。SQL Diagnostic ManagerでSSHを使用するように設定した場合、"Via SFTP"を選択します。サーバーがRDS/Auroraインスタンスである場合、"RDS/Aurora (Using API)"を選択します。ファイルベースのログにRDS/Aurora (Using API)を使用する場合、以下の4つの追加フィールドを入力する必要があります。
- DB instance identifier：RDS/Auroraインスタンスを識別するための固有名。
- Instance region：インスタンスが管理されている地域（例: us-east-1）。
- Access key ID：AWS 管理コンソールから作成可能な20文字のキーID。プログラミングによりAWSへのリクエストを行うために使用されます。
- Secret access key：AWS管理コンソールから作成可能な40文字のキー。証明書キーの生成方法については、ドキュメントGetting Your Access Key ID and Secret Access Keyを参照してください。
Fetch error log details:
SQL Diagnostic Managerは、MySQLサーバーからエラーログのパスを自動的に取得できます。このボタンをクリックするだけで、SQL Diagnostic Managerが残りの処理を実行します。
File path:
エラーログファイルのパスを手動で入力する場合、ここで入力します。
Test path:
このボタンをクリックすると、SQL Diagnostic Managerが指定されたパスのファイルにアクセスできるかどうかをチェックします。
MySQLクエリログ設定
SQL Diagnostic Managerは、接続するMySQLサーバーからGeneral（一般）クエリログとSlow（スロー）クエリログ（の全部または一部）を取り出し、それらを解析します。ここでは、SQL Diagnostic Managerでログ解析ができるように、接続の詳細情報をセットアップする方法を解説します。一般クエリログとスロークエリログそれぞれの詳細をセットアップする必要があります。代わりに、スロークエリログ‘インデックスを使用しないログクエリ’を有効にするには、SUPER権限が必要です。ロギングの有効化の方法と設定方法については、MySQLドキュメントを参照してください。MySQLサーバーログは、サーバーマシンのファイルまたはMySQLデータベースのテーブルに書き込むことができます。
MySQLサーバー（バージョン5.0以降）には、インデックスを使用しないクエリを（スローログに）記録するオプションがあります。このようなクエリは、関連テーブルに数百から数千のレコードがある場合、スローである必要はありません。しかし、それらは‘潜在的にスロー’であり、それらがテーブルにアクセスすると、サイズが増大し続けるので、識別しておく必要があります。この機能は、ここからも有効／無効にすることができます（SQL Diagnostic ManagerはMySQLに適切なSETステートメントを送信します）。注：スロークエリログに記録されるのは、DMLクエリとDDLクエリだけです。
ファイルに書き込むログ:
最初に、サーバーログがファイルとしてサーバーマシンに保存される状況を想定します。これはよくある状況であり、バージョン5.1より前のMySQLサーバーではこれしかありませんでした。初めてこのオプションを使用してサーバーを構成するとき、‘Fetch query log details’ボタンをクリックします。有効なログがどれなのか、どのようにロギングが設定されているかをMySQLサーバーは‘認識しています’（サーバー変数に保存）。パスを確認するためには、‘Test Path’をクリックします。SQL Diagnostic Managerは接続し、ファイルの存在を確認します（その内容にはアクセスしません）。
ログファイルには、（SQL Diagnostic ManagerとMySQLが同じコンピューターで稼働している場合は）ローカルファイルシステムから、（SQL Diagnostic ManagerとMySQLが別のコンピューターで稼働している場合は）SFTPを使用して、RDS/Auroraインスタンスを使用している場合はRDS/Aurora (Using API)を使用して、アクセスすることができます。ログがあるマシンのファイルとパス構文を使用しなければならないことに注意してください。
共有ドライブから、または、ネットワーク経由で、または、（Linux上のNFSのような）ネットワーク対応ファイルシステムから、ログファイルにアクセスできる場合、SQL Diagnostic Managerはそれらのファイルがローカルファイルであるかのようにアクセスできます。この場合、SSH/SFTPの追加設定は不要です。オペレーティングシステムが透過的にファイル転送を処理します。
‘via SFTP’オプションを選択すると、‘SSH server details settings’に定義されたSSHサーバーの詳細情報を使用して、リモートシステムからファイルを読み取ります。SSHユーザーはログファイルへの読み込みアクセス権限を持っていなければならないことに注意してください！
RDS/Aurora (Using API)オプションを選択する場合、ログファイルを取得するために必要なアクセス証明書があることを確認してください。アクセス証明書はAWS管理コンソールから生成できます。証明書キーの生成方法については、Getting Your Access Key ID and Secret Access Keyを参照してください。
デフォルトで、SQL Diagnostic Managerサービスはローカルシステムアカウントで実行されることに注意してください。Mapped Network DriveにSlow（スロー）クエリログまたはGeneral（一般）クエリログがある場合、SQL Diagnostic Managerはそれにアクセスできません。SQL Diagnostic Managerがそれらにアクセスできるようにするためは、UNC表記を使用する必要があります。詳細については、FAQ 31を参照してください。
MySQLテーブルに書き込んだログ:
このオプションは、バージョン5.1以降のMySQLでサポートされています。また、SQL Diagnostic Managerはこのオプションが使用可能な場合サポートします。ここで、‘Fetch Log Details From MySQL’ボタンをクリックします。このオプションを使用すると、ファイルパスを設定したり、SSHの詳細情報を考慮する必要はありません。SQL Diagnostic Managerは、単純なSELECTステートメントを送信してサーバーログを取り出すことができます。SQL Diagnostic ManagerがMySQLに接続するために使用するMySQLユーザーのみ、そのテーブルに対する SELECT権限が必要です。
監査ログ設定
これは、MySQLエラーログやMySQLクエリログとまったく同様に機能します。監査ログの監視が有効な場合、SQL Diagnostic Managerはサーバーからパスを読み出し、File Pathボックスにそれを表示します。変数“server_audit_file_path”からパスを取得し、デフォルトでその監査ログファイルの名前が返されることに注意してください。そのような場合には、監査ログのパスを手動で入力しなければなりません（デフォルトで、パスはdatadirパスと同じです）。
次に、稼働しているMySQLサーバーがある場所によって、“Read file from”で適切なオプションを選択してください。サーバーがSQL Diagnostic Managerと同じマシンにある場合、“Local path”を選択してください。リモートマシンにある場合、“Via SFTP”を選択し、該当するSSHの詳細情報を入力してください。サーバーがRDS/Auroraサーバーの場合、“RDS/Aurora (Using API)”を選択してください。
スニッファー設定
SQL Diagnostic Managerの‘query sniffer’は、‘疑似サーバーログ’を記録し、それをSQL Diagnostic Managerの組み込みデータベースに保存する機能です。‘query sniffer（クエリスニッファー）’を有効にすると、SQL Diagnostic Managerは以下の3つの方法で‘疑似サーバーログ’をユーザーが指定する間隔で追加できます。
- パフォーマンススキーマテーブル（events_statements_summary_by_digest、events_statements_history_long）を使用し、定期的にスナップショットを収集する方法
- クエリSHOW FULL PROCESSLISTをMySQLサーバーに送信する方法
- 1つ以上のクライアントがMySQLサーバーとの接続に使用するMySQL-Proxyプログラムの実行中のインスタンスに接続する方法
MySQL 5.6.14以降では、クエリ解析にPerformance schema（パフォーマンススキーマが有効な場合）、Proxy （プロキシ）、Processlist（プロセスリスト）を使用できます。MySQL 5.6.14より前のバージョンを使用する場合、Processlistモードを使用できます。
MySQLのパフォーマンススキーマには、以下の他の情報と共にサーバーで実行されるクエリが含まれます。
- number of rows sent and examined（送信され調査される行数）
- number of temporary tables created on disk（ディスクに作成される一時テーブルの数）
- number of temporary tables created on memory（メモリに作成される一時テーブルの数）
- number of joins performed and the type of join（実行されるジョイン数とジョインのタイプ）
- whether sorting happened and the type of sort（ソートが発生したかどうかと、ソートのタイプ）
- whether index used（インデックスが使用されたかどうか）
- whether good index used（適切なインデックスが使用されたかどうか）
SQL Diagnostic Managerは、パフォーマンススキーマステートメントダイジェストテーブル（events_statements_summary_by_digest）を使用して上記の情報を取得し、setup_consumersテーブルのstatements_digestに従います。デフォルトで、この機能は有効です。無効の場合、以下のステートメントを実行して有効にできます。
UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name = 'statements_digest';
サンプルクエリは、events_statements_history_longテーブルにあります。有効にする必要があり、setup_consumersテーブルのevents_statements_history_longに従って実行されます。デフォルトで、これは有効ではないので、以下のステートメントを実行して有効にしてください。
UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name = 'events_statements_history_long';
performance_schema.events_statements_summary_by_digestテーブルのサイズは、performance_schema_digests_sizeグローバル変数によって異なります。デフォルトで、このサイズは5000行に設定されます。この上限に達すると、クエリは失われます。SQL Diagnostic Managerには、パフォーマンススキーマダイジェストテーブルがperformance_schema_digests_sizeの 80%に達すると切り捨てるオプションがあります。
Proxy（プロキシ）インスタンスの設定はもう少し複雑ですが、PROXYベースのスニッファーには、PROCESSLISTベースに比べて、以下のようなメリットがあります。
- Proxy（プロキシ）が処理するすべてのクエリは、PROXYオプションの使用時に、SQL Diagnostic Managerの‘スニッファー’によって記録されます。PROCESSLISTオプションが使用されると、高速クエリは2つのSHOW FULL PROCESSLISTクエリの間で完全に実行されないことがあり、記録されません。
- 特定のクライアント／アプリケーションのみからクエリを解析することを選択できます。単純に、その時に重要視したいクライアントのみにProxy（プロキシ）で接続させることができます。
- PROXYオプションの使用時、PROXYのある場所を決定することによって、スニッファーによって生成された負荷の一部を展開シナリオに最適なマシン（使用可能な空きリソースが一番多いマシンなど）上に分散させることができます：MySQLマシン、SQL Diagnostic Managerマシン（同じマシンでなければ）、または、まったく別のマシン。MySQLを実行しているマシンでProxy（プロキシ）が実行していなければ、そのマシンにスニッファーによる新たな負荷は生じません。
このスクリプトは、WebyogウェブサイトからダウンロードしたSQL Diagnostic Managerプログラムパッケージを（WindowsとLinux RPMの場合）インストールするか、（Linux .tar.gzの場合）解凍すると、SQL Diagnostic Managerプログラムフォルダー内に見つかります。ただし、MySQL Proxy（プロキシ）プログラムは、MySQLウェブサイトからダウンロードしてください（ライセンス上の理由から組み込むことができなかったため）。SQL Diagnostic Managerは、WindowsとMacでは、Proxy（プロキシ）のバージョン0.61から0.81（最新バージョン）で動作しますが、バージョン0.7xは特定のビルドのバグのために除かれます。Proxy（プロキシ）の詳細については、MySQL Proxyをクリックしてください。
SQL Diagnostic Managerで使用するためにProxy（プロキシ）インスタンスを開始するためには、以下のコマンドを使用します。
- v0.81(Alpha)以降では、Proxyインストールフォルダから以下のコマンドを実行してください。
# mysql-proxy --proxy-backend-addresses=192.168.x.x:3305 --proxy-address=192.168.y.y:4045 --admin-username=root --admin-password=root --admin-lua-script=MONyog.lua --proxy-lua-script=MONyog.lua - 古いバージョンの場合、Proxyインストールフォルダから以下を実行してください。
# mysql-proxy --proxy-backend-addresses=192.168.x.x:3305 --proxy-address=192.168.y.y:4045 --proxy-lua-script=MONyog.lua
（‘MONyog.LUA’はPROXYバイナリファイルがあるフォルダーにコピーされたものとします）。また、ポートを指定しない場合、PROXYはポート4040で待ち受けます。これで、1つ以上のクライアント／アプリケーションからProxy（プロキシ）に接続できます。Proxy（プロキシ）は、MySQLにクエリを送信し、結果がクライアントに返ります。ただし、MonyogスニッファーをLUAスクリプトで開始すると、SQL Diagnostic Managerがスニッファー‘疑似ログ’の追加に使用する情報もSQL Diagnostic Managerに送信します。
この‘疑似ログ’が記録されると（説明した3つの方法：Performance Schema、PROCESSLISTベース、PROXYベースのいずれかで）、SQL Diagnostic Managerログ解析機能は‘リアルログ’と同様に、‘疑似ログ’で動作します。‘疑似ログ’に記録されたデータは、ユーザーが設定した‘data retention timeframe（データ保持時間フレーム）’オプションに従って自動的に破棄されます。
さらにフィルタリングオプションもいくつか用意されています。このフィルタリングはSQL Diagnostic Managerデータベースのソートの前に実行されることに注意してください。そのため、スニッファーデータベースが制御できなくなるのを防ぐことができます！フィルタリングオプションは以下のとおりです。
- User and host（ユーザーとホスト）：ユーザーとホストの両方またはいずれかの特定の組み合わせによってのみ実行されたクエリの保存を選択できます。
- Minimum time taken（最短所要時間）：SQL Diagnostic Managerに戻されたPROCESSLIST ごとに、クエリは、指定した最短実行時間を超えて実行された場合のみ、組み込みデータベースに記録されます。さらに、記録済みのクエリと同じ構造と詳細情報（プロセスIDなど）を持つクエリに遭遇すると、組み込みデータベースはUPDATEDされ、そのステートメントは1度だけ記録されます。
注意
この設定は、サンプル間隔よりも少し長くしてください（また、接続遅延時間も考慮してください）。設定時間が短いと、何の意味もありません！ - Queries starting with（クエリの開始ストリング）：特定の文字列で始まるクエリを記録したい場合、文字列を入力してください。例:“SELECT *”、“UPDATE Customer_Base”
さらに、PROCESSLIST Snifferには、ユーザーが指定した時間より長い時間実行しているクエリを通知するかキルすることによって、実行時間が長いクエリを監視できるオプション‘Long Running Query Options’があります。また、クエリが無視されるユーザーを指定することができます（すなわち、そのようなユーザーによるクエリは、SQL Diagnostic Managerがキルすることはない）。そして、ユーザーが指定した‘LONG RUNNING QUERY TIME’より小さく指定された時間より長い時間実行していてもアラートは発生しません。
‘Monitor only locked queries（ロックされているクエリのみ監視）’をクリックすると、ロックされている長いクエリのみを監視します。
クエリスニッファーは決して完全な‘一般ログ’になりません。非常に高速なステートメントは、生成された2つのPROCESSLISTの間で実行を終了することもあればそうでないこともあるため、記録されることも記録されないないこともあります。‘疑似ログ’の後続のデータ収集の時間間隔は、MySQLサーバーとの接続によって異なります。
デッドロック設定
トランザクションデータベースでは、デッドロックは昔からよくある問題ですが、これらのデッドロックは、あまりにも頻繁に発生し特定のトランザクションを実行できないという場合を除き、あまり危険ではありません。INNODB STATUSによって報告されるデッドロックを追跡するためには、“Deadlock Monitoring”オプションを有効にします。
モニターの設定
SQL Diagnostic Managerでは、モニターグループ全体の無効化が可能です。例えば、あるMySQLサーバーがレプリケーションスレーブではない場合、そのレプリケーショングループを無効にすることができます。
リアルタイム
SQL Diagnostic Managerには、リアルタイム監視のためデータ収集モードを選択するオプションがあります。ここで、“Processlist”か“Performance schema”を選択できます。MySQLのバージョンが5.6.14以上でパフォーマンススキーマが有効な場合は、“Performance schema”モードを選択できます。その他の場合は、“Processlist”モードを選択します。
接続設定
サーバーの接続タイムアウト値を指定することができます。このオプションは、SQL Diagnostic Managerがエラーを投げる前に、サーバーからの応答をこの長さの時間待機することを意味します。これは、特定のサーバーへの接続が遅い場合の誤検出を避けるのに役立ちます。そのような場合には、より大きなタイムアウトを設定できます。MySQLへのSSHトンネリングが有効な場合、SSH Tunnel Connection Timeout （SSHトンネル接続タイムアウト）を指定することができ、システムメトリックが有効な場合はSSH System Connection Timeout（SSHシステム接続タイムアウト）を指定できます。デフォルト値はいずれも30秒です。
