 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. 概要
Checkmk は、Oracle データベースの監視のための包括的なオプションを提供しています。 エージェントプラグインを使用すると、データベースのテーブルスペースやアクティブなセッションだけでなく、他の多くの種類のメトリックも取得できます。 チェックプラグインによる監視オプションの完全なリストは、チェックプラグインのカタログでご覧いただけます。 当社は定期的に新しいプラグインを追加し、既存のプラグインを更新していますので、カタログを定期的にご確認ください。 Checkmk は、とりわけ以下の値を監視することができます。
データベースを監視するには、データベースサーバー上のエージェントに加えて、エージェントプラグインのみが必要です。
現在、Linux、Solaris、AIX、および Windows オペレーティングシステムがサポートされています。
Linux、Solaris、AIX 用のエージェントプラグインは「mk_oracle 」と呼ばれ、Windows 用のエージェントプラグインは「mk_oracle.ps1 」と呼ばれています。
Checkmk サーバーまたはデータベースサーバーで監視を行うために、追加のソフトウェアは必要ありません。
監視の設定手順の多くは、Linux と Windows で同じです。 そのため、ここではまず一般的な手順を説明し、次にそれぞれのオペレーティングシステムグループ固有の手順、最後に商業版のエージェントベーカリーについて説明します。
2. 初期セットアップ
この章および次の章で示すサンプル内容を含む設定ファイルは、Checkmk サーバー上で、コマンドラインまたはCheckmk web インターフェイスから確認できます。 Checkmk Raw では「Setup > Agents 」、商業版では「Setup > Agents > Windows, Linux, Solaris, AIX > Related 」を選択してください。 すべてのエディションで、さまざまなオペレーティングシステム用のメニュー項目があります。 設定ファイルは、「Example Configurations 」ボックス内にあります。
2.1. データベースユーザーの作成
原則として、最初のセットアップは 3 ステップで簡単に完了します。
まず、データベースのクエリを実行できるユーザーを作成します。
Real Application Cluster (RAC) を使用していない場合は、監視するデータベースごとにユーザーを作成してください。
インスタンスへのアクセス方法は、インストールされているオペレーティングシステムによって異なります。
Linux の場合、たとえば、まず、ユーザーを作成する環境変数に、関連するインスタンスを常に設定します。
通常、まずoracle ユーザーにスイッチしますが、
セットアップによっては異なる場合があります。
root@linux# su - oracle
oracle@linux$ export ORACLE_SID=MYINST1次に、インスタンスにログインし、監視用のユーザーを作成します。
すべてのデータを取得するには、以下の許可が必要です。
以下の例では、新しく作成したユーザーの名前はcheckmk です。
他の任意の名前も指定できます。
sqlplus> create user checkmk identified by myPassword;
sqlplus> grant select_catalog_role to checkmk;
sqlplus> grant create session to checkmk;
sqlplus> connect checkmk/myPassword
sqlplus> exit特定のインスタンスへのログイン方法の詳細については、Oracle のドキュメントを参照してください。
マルチテナントデータベース
マルチテナントデータベースのログインも設定できます。
これは通常、特別なユーザーとプレフィックスC## を使用して設定で実行します。
許可の割り当ては、通常のユーザーとは少し異なり、現在のすべてのコンテナと将来のすべてのコンテナに対して指定する必要があります。
sqlplus> create user c##checkmk identified by myPassword;
sqlplus> alter user c##checkmk set container_data=all container=current;
sqlplus> grant select_catalog_role to c##checkmk container=all;
sqlplus> grant create session to c##checkmk container=all;
sqlplus> exit2.2. 構成の作成
ユーザーを作成したら、次に、エージェントプラグインが後でこの情報を受信できるようにします。
最も簡単な方法は、すべてのインスタンスに同じログインデータを定義し、設定でデフォルトを設定することです。
次に、Oracle ホストで、Linuxの場合はmk_oracle.cfg 、 Windows の場合は mk_oracle_cfg.ps1 という新しい設定ファイルを作成します。
次の例は、Unix 系システム用のファイルです。
# Syntax:
# DBUSER='USERNAME:PASSWORD'
DBUSER='checkmk:myPassword'Windows でも、この手順は非常によく似ています。 そこで、パワーシェルスクリプトで変数を設定します。
# Syntax:
# $DBUSER = @("USERNAME","PASSWORD")
$DBUSER = @("checkmk","myPassword")エージェントプラグインが実際に必要とするのは、標準ユーザーだけです。 Unix 系システムまたは Windowsで設定できるその他のオプションはすべてオプションです。
2.3. Oracle Wallet の使用
構成ファイルでユーザーとパスワードを直接指定する代わりに、Oracle Wallet を使用することもできます。 この方法には、アクセスデータを暗号化されていないフォームで Checkmk サーバーおよび Oracle ホストに保存する必要がなくなるという利点があります。 したがって、Oracle ホストで構成ファイルのアクセス権を適切に定義した場合でも、エージェントベーカリーを使用している限り、アクセスデータはサーバーから削除され、Checkmk サーバーに保存されます。
Oracle Wallet は、監視対象のホストに暗号化されたアクセスデータを保存するため、ログインデータは明示的に指定する必要はありません。 したがって、Checkmk はこのウォレットを使用することで、アクセスデータはデータベース管理者 (DBA) だけが知っていれば済みます。 適切なサーバーにウォレットを作成します (DBA が作成することもできます)。
root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -createエージェントプラグインは、インスタンスへの接続を確立するたびに、このファイルにアクセスします。
必要なユーザーデータも検索できるように、このデータをウォレットに一度入力しておく必要があります。
次の例では、インスタンスMYINST1 に対してユーザーcheckmk を追加しています。
root@linux# mkstore -wrl /etc/check_mk/oracle_wallet -createCredential MYINST1 checkmk myPasswordエージェントプラグインがウォレットの場所を認識するには、2 つのファイルを見つける必要があります。
1 つ目のファイルは、ウォレットの場所に関する情報が格納されているsqlnet.ora です。
2 つ目のファイルtnsnames.oraは、インスタンスのアドレスを定義し、エイリアスからもインスタンスにアクセスできるようにします。
エージェントプラグインがこれらのファイルにアクセスできるように、Linux、Solaris、および AIX では、環境変数 TNS_ADMIN。
これは、ファイルが既に存在する場合に特に便利です。
または、明示的に作成することもできます。
Windows では、手動で指定する必要があります。
まず、sqlnet.ora ファイルを作成します。
エージェントプラグインは、このファイルでもログインデータを検索するため、ここで、先ほど作成したウォレットファイルへの正しいファイルパスを入力する必要があります。SQLNET.WALLET_OVERRIDE パラメータをTRUE に設定してください。
LOG_DIRECTORY_CLIENT = /var/log/check_mk/oracle_client
DIAG_ADR_ENABLED = OFF
SQLNET.WALLET_OVERRIDE = TRUE
WALLET_LOCATION =
(SOURCE=
(METHOD = FILE)
(METHOD_DATA = (DIRECTORY=/etc/check_mk/oracle_wallet))
)これで、プラグインは使用する認証情報を認識します。
正しいアドレスにアクセスするように、2 番目のファイルとしてtnsnames.ora を作成してください。
正確な構文は Oracle のドキュメントに記載されていますが、例としては、ファイルは次のようになります。
MYINST1
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = MYINST1_ALIAS)
)
)この手順で、エージェントプラグインの設定ファイルからアクセスデータを削除するための前提条件が整いました。
アクセスデータの代わりに、/ （スラッシュ）を入力してください。
DBUSER='/:'もちろん、後からウォレットに追加のアクセスデータを追加することも可能です。 tnsnames.ora ファイルは、必要に応じて適宜修正してください。
最後に、このセクションで手動で作成したファイルおよびディレクトリの許可を変更して、実行時のアクセス権が正しく設定されるようにします。root として実行されたエージェントプラグインは、Oracle バイナリ（$ORACLE_HOME/bin/sqlplus など）を実行する前に、その所有者に切り替わります。
したがって、Oracle バイナリの所有者のグループは、少なくとも/etc/check_mk/ に手動で作成したファイルへの読み取りアクセス権を持っている必要があります。
次の例では、グループがoinstall であると仮定しています。
次のコマンドを実行すると、グループがoinstall に変更されます。
root@linux# chgrp oinstall /etc/check_mk/sqlnet.ora /etc/check_mk/tnsnames.ora
root@linux# chgrp -R oinstall /etc/check_mk/oracle_walletこれらのコマンドにより、グループはoracle_wallet ディレクトリとその内容を確実に読み込めるようになります。
root@linux# chmod g+x /etc/check_mk/oracle_wallet
root@linux# chmod -R g+r /etc/check_mk/oracle_wallet許可は、次のように表示されます。
root@linux# tree -ugpR /etc/check_mk
[drwxr-xr-x root root ] /etc/check_mk
├── [drwxr-x--- root oinstall ] oracle_wallet
│ └── [-rw-r----- root oinstall ] cwallet.sso
│ └── [-rw-r----- root oinstall ] cwallet.sso.lck
│ └── [-rw-r----- root oinstall ] ewallet.p12
│ └── [-rw-r----- root oinstall ] ewallet.p12.lck
├── [-rw-r--r-- root oinstall ] sqlnet.ora
├── [-rw-r--r-- root oinstall ] tnsnames.oraコマンドの出力には、対象のファイルとディレクトリのみが表示されます。
3. Linux、Solaris、AIX の設定
3.1. プラグインおよび設定パス
Unix 系システムでは、Checkmk は統一されたエージェントプラグインを使用します。 これにより、SQL クエリが複製されないため、メンテナンスの負担が軽減される一方、注意すべきエージェントプラグインも 1 つだけで済みます。 サポートされているすべてのシステムで、エージェントのファイルパスは同じか、または非常に似ています。 具体的には、以下のディレクトリが必要です。
| オペレーティングシステム | プラグインパス | 設定パス |
|---|---|---|
Linux、Solaris、AIX |
|
|
Linux |
|
|
AIX |
|
|
3.2. エージェントプラグインのインストール
初期セットアップでユーザーを作成し、それを設定ファイルに保存したら、エージェントプラグインをインストールします。mk_oracle ファイルを、Checkmk サーバーのディレクトリ~/share/check_mk/agents/plugins/ から、上記の Oracle ホストのプラグインディレクトリにコピーします。
|
Unix 系システム用のエージェントプラグイン |
エージェントプラグインを実行可能にしてください。必要に応じて、次のように修正してください。
root@linux# cd /usr/lib/check_mk_agent/plugins/
root@linux# ls -lA
-rw-r--r-- 1 root root 120808 Jan 25 11:29 mk_oracle
root@linux# chmod +x mk_oracle
root@linux# ls -lA
-rwxr-xr-x 1 root root 120808 Jan 25 11:29 mk_oracle3.3. 高度なオプション
最初のセットアップでは、Oracle インスタンスから監視データを取得するための最初の変数について学びました。 ただし、アプリケーションのシナリオによっては、各インスタンスの監視をより適切に個別に制御するためのさらなる機能が必要になる場合があります。 これらのオプションについては、次のセクションで説明します。
高度なユーザー設定
標準のログインでは、データベースの通常のインスタンス、場合によってはすべてのインスタンスを使用できます。 ただし、特定のインスタンスに個別のアクセスデータが必要な特別な場合があります。 そのため、設定ファイルでは、ユーザーを指定するために次の 3 つのオプションがあります。
| パラメーター | 説明 |
|---|---|
|
データベースインスタンスに対して個別のアクセスデータが定義されていない場合のデフォルトです。 |
|
特定のデータベースインスタンスへのアクセスデータ — この場合は、インスタンス |
|
自動ストレージ管理 (ASM) 用の特別なアクセスデータ。 |
これらの変数を使用すると、ユーザー名とパスワード以外のさらに多くのオプションを設定できます。
また、ユーザーがSYSDBA またはSYSASM のいずれであるか、インスタンスがリッスンするアドレスとポートの組み合わせ、さらには使用するTNS エイリアス(TNSALIAS) も指定できます。
ただし、これらの指定は、ユーザー名やパスワードとは異なり、常にオプションです。
上記の例に加えて、設定は次のようになります。
# Syntax
# DBUSER='USERNAME:PASSWORD:ROLE:HOST:PORT:TNSALIAS'
DBUSER='checkmk:myPassword'
DBUSER_MYINST1='cmk_specific1:myPassword1:SYSDBA:localhost:1521'
DBUSER_MYINST2='cmk_specific2:myPassword2::localhost::INST2'
ASMUSER='cmk_asm:myASMPassword:SYSASM'上記の例に関するいくつかの説明:
任意の数の個別のアクセスデータを定義できます。 これらは常に標準設定よりも優先されます。
各オプションは、
:（コロン）で区切られます。文字列の中間でオプションのフィールドが省略された場合、
DBUSER_MYINST2エントリのように、ロールとポートが指定されていない場合と同様に、コロンをコード化する必要があります。ある時点以降、オプションフィールドが不要になった場合は、ホスト、ポート、TNS エイリアスが指定されていない
ASMUSERエントリと同様に、コロンを省略することができます。
インスタンスの包含または除外
場合によっては、特定のインスタンスを監視対象から除外したいことがあります。 これは、開発者用のプレイグラウンドであるなどの理由によるものです。 個々の状況に応じて設定をできるだけシンプルにするため、1 つまたは複数のインスタンスを完全にまたは部分的に除外するさまざまなオプションがあります。
| パラメーター | 説明 |
|---|---|
|
ここでは、監視するインスタンスを指定できます。 インスタンスは、システム識別子 (SID) によって名前が付けられます。 これは、明示的にリストされていないすべてのインスタンスを無視するポジティブリストです。 このパラメータは、監視するインスタンスの数が無視するインスタンスの数よりも少ない場合に非常に便利です。 |
|
|
|
このパラメータを使用すると、インスタンスの特定のセクションを監視から除外することで、インスタンスを部分的に除外することができます。
このようにして、インスタンスのセクションのネガティブリストを定義します。
また、値を「 |
ご想像のとおり、
これらのパラメータが処理される順序によって結果が決まります。
実際、エントリは、上記の表に示されている順序で、インスタンスごとに正確に処理されます。
したがって、変数ONLY_SIDS が設定されている場合、SKIP_SIDS は評価されず、EXCLUDE_<SID> 変数がこのインスタンスに対してALL に設定されているかどうかはチェックされません。ONLY_SIDS が設定されていない場合、システムは順序に従って処理を進めます。
疑わしい場合、つまりデフォルトの動作では、インスタンスはそれに応じて監視されます。
以下は、すべての変数が設定されている場合の動作例です：
ONLY_SIDS='INST1 INST2 INST5'
SKIP_SIDS='INST7 INST3 INST2'
EXCLUDE_INST1='ALL'
EXCLUDE_INST2='tablespaces rman'1 行目のポジティブリストが常に優先されるため、2 行目と 3 行目は評価されません。 インスタンスはここで部分的にしか評価されないため、4 行目（最後の行）だけが後日考慮されます。
実際には、監視するインスタンスの数を決定するには、変数の1 つだけを使用するのが妥当です。
取得するデータの決定
前のセクションで学んだように、インスタンスを完全に無効にするだけでなく、部分的にのみ監視することも可能です。
運用要件はさまざまであり、たとえば、実行時間の長い特定のセクションをすべて含めることが望ましくない場合や、テストインスタンスの基本情報のみが必要な場合などに、この機能は特に実用的です。
セクションをグローバルに制限するには、対応する変数を直接設定します。特定のインスタンスのみを制限するには、前のセクションで学んだEXCLUDE_<SID> 変数をスロットに挿入します。
グローバル変数は次のとおりです。
| パラメーター | 説明 |
|---|---|
|
同期的に、つまりエージェントが実行されるたびにクエリを実行するセクション。 デフォルトのクエリ間隔は 60 秒であるため、使用する SQL クエリもそれに応じて高速に実行する必要があります。 この変数が指定されていない場合は、すべてのセクションがクエリされます。 |
|
非同期的に、つまり x 分ごとにクエリを実行するセクション。
データの有効期間は、この表の下にある |
|
ASM セクションについては、 |
|
ここでは、ASM セクションについては、 |
|
この変数は、非同期で取得されたデータの有効期間を決定するために使用されます。 この変数の値が指定されていない場合、デフォルトの 600 秒 (10 分) が使用されます。 時間範囲が、Checkmk エージェントがデータを配信する間隔 (デフォルトは 60 秒) よりも短くないことを確認してください。 そうしないと、データが古くなったとみなされ、エージェントによって配信されない場合があります。 |
|
並行して処理される SID の数です。デフォルト値は 1 です。 |
したがって、このメカニズムを使用すると、設定ファイルでデフォルトを設定し、必要に応じて個々のインスタンスで上書きすることができます。 設定は、たとえば次のように指定します。
# DEFAULTS:
# SYNC_SECTIONS="instance sessions logswitches undostat recovery_area processes recovery_status longactivesessions dataguard_stats performance locks"
# ASYNC_SECTIONS="tablespaces rman jobs ts_quotas resumable"
# SYNC_ASM_SECTIONS="instance processes"
# ASYNC_ASM_SECTIONS="asm_diskgroup"
# CACHE_MAXAGE=600
SYNC_ASM_SECTIONS='instance'
ASYNC_SECTIONS='tablespaces jobs rman resumable'
CACHE_MAXAGE=300
EXCLUDE_INST1='undostat locks'
EXCLUDE_INST2='jobs'この例でわかるように、ASM インスタンスについてはinstance セクションのみが照会され、すべての通常インスタンスでは非同期セクションの最小セットが指定されています。
さらに、INST1 インスタンスでは、同期セクションundostat およびlocks は省略されます。
同期セクションは明示的に指定されていないため、すべての同期セクションは他のすべてのインスタンスから取得されます。
一方、INST2 インスタンスでは、jobs が追加で除外されているため、4 つの非同期セクションのうち 3 つだけがクエリされます。
そして最後に、10 分間のキャッシュが 5 分間 (300 秒) に短縮されます。これは、すべてのデータを取得するのに十分な時間だからです。
|
取得するセクションと、その方法を設定ファイルで定義する場合（非同期セクションを同期セクションに変更することもできます）、それぞれの領域で実行するすべてのセクションを指定する必要があります。 たとえば、同期クエリから xml-ph-0000@deepl.internal のみを取得したい場合は、同期リスト全体を指定し、xml-ph-0001@deepl.internal を単に省略します。 |
たとえば、同期クエリからlocks のみを取得したい場合は、同期リスト全体を指定し、locks を省略します。
# Just exclude 'locks' from sync sections:
SYNC_SECTIONS='instance sessions logswitches undostat recovery_area processes recovery_status longactivesessions dataguard_stats performance'セクションを決定できる他の 3 つの変数についても同様です。
TNS アリアスと TNS_ADMIN の設定
TNS エイリアスは、データベース接続のユーザーフレンドリーな名前です。
TNS は、Oracle ネットワークテクノロジーTransparent Network Substrate の略です。
TNS エイリアスを使用すると、毎回接続の詳細 (ホスト名、ポート番号、サービス名など) を入力しなくても、データベースインスタンスへの接続を確立することができます。
TNS エイリアスは、tnsnames.ora ファイルで定義されます。
Oracle Walletのセクションには、TNS エイリアスの定義例があります。
TNS_ADMIN は、 や などの Oracle 設定ファイルが保存されているディレクトリを指す環境変数です。
デフォルトでは、 は Oracle によって に設定されています。
設定ファイルでは、特定の Oracle インストールに対して、 に別のパスを割り当てることができます。sqlnet.ora tnsnames.ora TNS_ADMIN $ORACLE_HOME/network/admin TNS_ADMIN
export TNS_ADMIN=/opt/oracle/product/19c/dbhome_1/network/admin/この変数がまったく設定されていない場合にのみ、エージェントプラグインによって/etc/check_mk/ に設定されます。
実行時のアクセス権限
セキュリティ上の理由から、エージェントプラグインmk_oracle は、root ユーザーでOracleバイナリを実行しなくなりました。
この変更は、sqlplus 、tnsping 、および（使用可能な場合）crsctl プログラムに影響します。
代わりに、mk_oracle は、sqlplus を実行する前に、$ORACLE_HOME/bin/sqlplus ファイルの所有者を変更します。
これにより、Oracleプログラムは、特権のないユーザーによってのみ実行され、悪意のあるOracleユーザーがsqlplus などのバイナリを置き換え、root ユーザーとして実行することを防ぎます。
非特権ユーザーによる Oracle プログラムの実行は、Oracle ウォレットを使用する場合に問題を引き起こす可能性があります。これは、このユーザーがウォレット固有のファイルにアクセスできない可能性があるためです。
非特権ユーザーは、$TNS_ADMIN/sqlnet.ora および$TNS_ADMIN/tnsnames.ora ファイルを読み取り、ウォレットフォルダを実行し、ウォレットフォルダ内のファイルを読み取るための許可が必要です。
Oracle Wallet のセクションの最後で説明したように、ファイルおよびディレクトリのグループを変更している限り、アクセス権に関する問題はありません。
エージェントプラグインは、上記のファイルへのアクセスに問題がないかを診断およびチェックし、接続テストで表示します。 アクセス権の診断および修正の正確な手順は、Checkmk 知識ベースをご覧ください。
3.4. リモートデータベースの監視
Unix 系システムでは、ローカルで実行中のインスタンスを取得するだけでなく、リモートインスタンスにログインして、そこで実行中のデータベースを取得することもできます。 これは、たとえば、基盤システムにアクセスできないが、データベースを監視したい場合に便利です。 エージェントプラグインは実行しているが、Oracle データベースは実行していないホストから、リモートデータベースを監視することも可能です。
リモートデータベースを監視するには、エージェントプラグインがインストールされているホストで以下の要件を満たしている必要があります。
Linux AIO アクセス・ライブラリがインストールされている。 Red Hat Enterprise Linux およびバイナリ互換のディストリビューションでは、このパッケージは
libaioOracle Instant Clientがインストールされている。
sqlplusプログラムがインストールされているか、クライアントの拡張パッケージとしてインストールされている必要があります。
通常、ホストに Oracle がインストールされている場合は、この条件はすでに満たされています。 そうでない場合は、適切なパッケージをインストールしてください。
エージェントプラグインがリモートデータベースに接続するには、まず、アクセスデータを設定ファイルに保存する必要があります。
これらは、上級ユーザーの設定で既に説明したDBUSER の詳細と似ています。
ただし、追加で必須の指定がいくつかあります。
# Syntax:
# REMOTE_INSTANCE_[ID]='USER:PASSWORD:ROLE:HOST:PORT:PIGGYBACKHOST:SID:VERSION:TNSALIAS'
REMOTE_INSTANCE_1='check_mk:mypassword::myRemoteHost:1521:myOracleHost:MYINST3:11.2'
REMOTE_INSTANCE_myinst1='/:::myRemoteHost:1521::MYINST1:11.2:INST1'
REMOTE_ORACLE_HOME='/usr/lib/oracle/11.2/client64'この例では、2 行で 2 つのリモートインスタンスが設定されています。 各テキスト行が一意になるように、各変数の最後に ID が定義されています。 ID は自由に選択できますが、各設定ファイル内で一意である必要があります。 お気づきかもしれませんが、ポートの指定の後にさらに値が続きます。 これらの値は、一部はオプションであり、一部は接続を確立するために必要です。
最初の新しい値PIGGYBACKHOST は、MYINST3 インスタンスに対してmyOracleHost に設定されています。
この指定により、ピギーバックメカニズムによるクエリの結果が、指定されたホストに割り当てられます。
これが Checkmk にホストとして存在する場合、新しいサービスは、エージェントプラグインが実行されているホストやデータが取得されたホストではなく、そのホストに表示されます。
2 番目のインスタンスMYINST1にはこの指定は表示されません。別のホストへの割り当てはオプションです。
2 番目の新しい値SID はインスタンス名です。
エージェントプラグインは、リモートホストで実行されているインスタンスを確認できないため、リモートインスタンスごとに設定行を指定する必要があります。したがって、この値は必須であり、オプションではありません。
3 番目の値VERSION は必須であり、これは、多くのメタデータがホストに直接接続している場合にのみ利用可能であるためです。
したがって、バージョン指定も省略することはできません。この指定により、インスタンスに渡すことができる SQL クエリが決まります。
この例では、両方のリモートインスタンスはバージョン11.2 を使用しています。
4 番目の最後の値TNSALIAS は、再びオプションであり、Oracle Walletまたは LDAP/Active Directory 経由でリモートインスタンスにアクセスする場合に使用できます。
インスタンスが特定の TNS エイリアスのみに応答する場合、このエイリアスをここで指定できます。
2 番目のリモートインスタンスの場合、TNSALIAS の値はINST1 です。
sqlplus プログラムも確実に検索されるように、REMOTE_ORACLE_HOME 変数を使用して、エージェントプラグインを実行するホスト上の Oracle クライアントの場所を指定してください。
そうして初めて、クエリに必要なすべてのリソースが利用可能になります。
リモートインスタンスをクエリする場合、いくつかの制限および特別な機能があります。
リモートインスタンスは構成ファイルに明示的に入力しているため、
SKIP_SIDSを使用してこれらのインスタンスを除外することはできません。その代わり、ONLY_SIDSを使用してこれらのインスタンスを含める必要はありません。同じ名前 (
SID) のインスタンスは、同じホストに割り当ててはいけません。 これは、同じ名前が使用されている複数のリモートホストおよび/またはローカルホストからインスタンスを取得する場合に特に重要です。
4. Windows の設定
4.1. プラグインおよび構成パス
Windows では、Oracle データベースを監視するためのスクリプト言語としてパワーシェルが使用されます。 この機能は、Unix 系システムでのエージェントプラグインと似ていますが、その一部しか含まれていません。 Windows でエージェントプラグインを使用するには、パワーシェルバージョン 5.x 以降と、以下のディレクトリが必要です。
| オペレーティングシステム | プラグインパス | 設定パス |
|---|---|---|
Windows |
|
|
4.2. エージェントプラグインのインストール
初期セットアップでユーザーを作成し、それを設定ファイルに保存したら、エージェントプラグインをインストールします。
Windows 用のエージェントプラグインは、Checkmk エージェント for Windows のインストール時にホストに保存されます。
Oracle ホストでは、ファイル「mk_oracle.ps1 」をディレクトリ「C:\Program Files (x86)\checkmk\service\plugins\ 」から上記のプラグインディレクトリにコピーします。
または、Checkmk エージェントの設定ファイルを更新して、インストールパスにあるファイルを参照することもできます。
4.3. Windows での特別な機能
Windows では通常、署名されていない PowerShell スクリプトの実行は阻止されます。 この問題は、Checkmk エージェントを実行しているユーザーの PowerShell スクリプトの実行に関するポリシーを変更することで、非常に簡単に回避できます。
PS C:\ProgramData\checkmk\agent\> Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine
PS C:\ProgramData\checkmk\agent\> Get-ExecutionPolicy -Scope LocalMachine
Bypassこのオプションは、スクリプトや Checkmk エージェントの一般的な機能を短期間テストする場合に便利です。 システムのセキュリティを損なうことを避けるため、テストが完了したら、本番サーバーでこの設定を元に戻してください。
PS C:\Program\checkmk\agent\> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine
PS C:\Program\checkmk\agent\> Get-ExecutionPolicy -Scope LocalMachine
RemoteSigned当然のことながら、60 秒ごとにガイドラインを変更することは望ましくないでしょう。 そのため、関連するスクリプトのみに永続的な例外を設定します。 エージェントプラグインの設定ファイルも例外に追加する必要があります。 読みやすくするため、この例では出力を完全に省略しています。
PS C:\ProgramData\checkmk\agent\> Unblock-File -Path .\plugins\mk_oracle.ps1
PS C:\ProgramData\checkmk\agent\> Unblock-File -Path .\config\mk_oracle_cfg.ps14.4. 高度なオプション
初期セットアップでは、Oracle インスタンスから監視データを取得するための最初の変数について学びました。 ただし、アプリケーションのシナリオによっては、インスタンスごとに監視をより適切に個別に制御するために、さらにオプションが必要になる場合があります。 Windows でも使用できるオプションについては、以下のセクションで説明します。
高度なユーザー設定
Linux と同様に、Windows エージェントプラグインの標準ログインだけでなく、個々のインスタンスの個別のアクセスデータも定義できます。 したがって、ユーザーを指定するには、同じ 3 つのオプションがあります。
| パラメーター | 説明 |
|---|---|
|
データベースインスタンスに対して個別のアクセスデータが定義されていない場合のデフォルトです。 |
|
特定のデータベースインスタンスのアクセスデータ — この場合は、インスタンス |
|
Automatic Storage Management (ASM) 用の特別なアクセスデータ。 |
さらに、ユーザー名やパスワード以外のオプションもここで指定できます。これらの追加のエントリもオプションですが、 使用する場合は各エントリに必ず入力する必要があります。 たとえば、設定は次のようになります。
# Syntax
# DBUSER = @("USERNAME", "PASSWORD", "ROLE", "HOST", "PORT")
# Default
# DBUSER = @("", "", "", "localhost", "1521")
$DBUSER = @("checkmk", "myPassword", "SYSDBA", "localhost", "1521")
@DBUSER_MYINST1 = @("cmk_specific1", "myPassword1", "", "10.0.0.73")
@DBUSER_MYINST2 = @("cmk_specific2", "myPassword2", "SYSDBA", "localhost", "1531")
@ASMUSER = @("cmk_asm", "myASMPassword", "SYSASM")上記の例に関する説明：
任意の数の個別のアクセスデータを定義できます。 これらは常に標準設定よりも優先されます。
各オプションはリストで定義されます。 エントリの順序は任意ではないため、順序を変更することはできません。
オプションのフィールドは変更せず、その後に続くフィールドを編集する場合は、両方のフィールドを正しく指定する必要があります。たとえば、
DBUSER_MYINST2エントリでは、PORTのみを変更するにもかかわらず、HOSTはlocalhostのまま設定されています。特定の時点以降、オプションフィールドが不要になった場合は、
ASMUSERエントリのように、ユーザーの役割のみを指定して、オプションフィールドを省略することができます。ユーザーに特別な役割を割り当てないが、
HOSTまたはPORTをカスタマイズする場合は、この位置に逆引用符/二重引用符 ("") のペアを入力してください。
インスタンスの有効化および無効化
Windows でも、特定のインスタンスを常に含めたいとは限りません。 その理由は、Linux に関するセクションで既に説明しました。 Linux で知っている 3 つのパラメータのうち 2 つは、Windows でも使用できます。
| パラメーター | 説明 |
|---|---|
|
ここでは、監視するインスタンスを指定できます。 インスタンスは、システム識別子 (SID) によって名前が付けられます。 これは、明示的にリストされていないすべてのインスタンスを無視する肯定リストです。 このパラメータは、監視するインスタンスの数が無視するインスタンスの数よりも少ない場合に非常に便利です。 |
|
|
処理は、上記の表の順序で各インスタンスに対して行われます。
まず、インスタンスがONLY_SIDS に含まれているかどうかがチェックされ、次に特定のセクションを除外するかどうかがチェックされます。
変数EXCLUDE_<SID> がALL に設定されている場合、どのセクションも実行されません。
以下は、各変数を1回ずつ表示した例です：
$ONLY_SIDS = @("MYINST1", "MYINST3")
$EXCLUDE_INST1 = "tablespaces rman"
$EXCLUDE_INST3 = "ALL"ONLY_SIDS はリストであるのに対し、EXCLUDE_INST1 はスペースで区切られたセクションを含む文字列であることに注意してください。
取得するデータの決定
実際に取得するセクションの指定は、Linux と同じ方法で行います。 以下は、Windows 構成の例です。
# DEFAULTS:
# $SYNC_SECTIONS = @("instance", "sessions", "logswitches", "undostat", "recovery_area", "processes", "recovery_status", "longactivesessions", "dataguard_stats", "performance", "locks")
# $ASYNC_SECTIONS = @("tablespaces", "rman", "jobs", "ts_quotas", "resumable")
# $SYNC_ASM_SECTIONS = @("instance", "processes")
# $ASYNC_ASM_SECTIONS = @("asm_diskgroup")
# $CACHE_MAXAGE = 600
$SYNC_ASM_SECTIONS = @("instance")
$ASYNC_SECTIONS = @("tablespaces", "jobs", "rman", "resumable")
$CACHE_MAXAGE = 300
$EXCLUDE_INST1 = "undostat locks"
$EXCLUDE_INST2 = "jobs' |
取得するセクションと、その方法を設定ファイルで定義する場合（非同期セクションを同期セクションに変更することもできます）、それぞれの領域で実行する すべてのセクションを指定する必要があります。 |
たとえば、同期クエリからlocks のみを取得したい場合は、同期リスト全体を指定し、locks を省略するだけです。
# Just exclude 'locks' from sync sections:
$SYNC_SECTIONS = @("instance", "sessions", "logswitches", "undostat", "recovery_area", "processes", "recovery_status", "longactivesessions", "dataguard_stats", "performance")セクションが指定されている他の 3 つの変数についても同様です。
実行時のアクセス権限
セキュリティ上の理由から、エージェントプラグインmk_oracle.ps1 は、これらのプログラムが管理者によってのみ変更できる場合にのみ、管理者としてOracleバイナリを実行します。
Windowsの管理者は、LocalSystemアカウントおよびビルトインのAdministrators グループのメンバーです。
これは、sqlplus.exe 、tnsping.exe 、および（使用可能な場合）crsctl.exe の各プログラムに適用されます。
エージェントプラグインmk_oracle.ps1 は、非管理者ユーザーがファイルに対してWrite 、Modify 、またはFull control のいずれかの許可を持っている場合、これらのプログラムを実行しません。
これにより、特権のないユーザーが管理者としてプログラムを実行するセキュリティリスクが防止されます。
 |
この変更が Checkmk のどのパッチバージョンで実施されたかは、Werk #15843 で確認できます。 |
必要に応じて、プログラムに対する非管理者ユーザーの上記のアクセス権を削除して、アクセス権を変更してください。 エージェントプラグインは、診断を支援し、非管理者ユーザーが上記のファイルにアクセスできるかどうかをチェックし、接続テストで表示します。 アクセス権の診断および修正の正確な手順は、Checkmk 知識ベースに記載されています。
Oracle プログラムの許可を安全に調整できない場合は、個々のユーザーおよびグループに対してプログラムの実行を許可することができます。
# Oracle plugin will allow users and groups in the list to have write access to the Oracle binaries
$WINDOWS_SAFE_ENTRIES=@("NT AUTHORITY\Authenticated Users", "<Domain>\<User>")Oracle の監視を確保する他の方法がない場合にのみ、最後の手段としてアクセス権チェックをオフにすることができます。
|
アクセス権チェックを無効にすると、エージェントプラグインは安全に実行できなくなります。 |
# Oracle plugin will not check if the used binaries are write-protected for non-admin users
$SKIP_ORACLE_SECURITY_CHECK=1ただし、管理者権限がなくてもエージェントプラグインを実行する別の方法もあります。
エージェントプラグインの実行をカスタマイズし、たとえば、ローカル Windows グループUsers で実行することができます。
これを行うには、Windows エージェントの設定ファイルcheck_mk.user.yml を、たとえば次のように編集します。
plugins:
enabled: yes
execution:
- pattern: $CUSTOM_PLUGINS_PATH$\mk_oracle.ps1
async: yes
group: Users
run: true商業版では、エージェントルールRun plug-ins and local checks using non-system account を使用して、エージェントベーカリーでこれらのエントリを作成することができます。
4.5. リモートデータベースの監視
現在、Windows エージェントプラグインでは、リモートデータベースの監視はできません。 したがって、リモートデータベースを監視する場合は、互換性のあるUnix 系オペレーティングシステムを搭載したホストが必要です。
5. エージェントベーカリーを使用した設定
商業版では、エージェントベーカリーを使用すると、設定を大幅に簡略化できます。 これは、設定ファイル内の構文エラーが回避され、環境の変化への適応がより容易になるためです。 手動設定との主な違いは、Oracle 独自の特別な設定を行う場合のみ、Oracle ホストのコマンドラインで作業を行う必要があることです。 エージェントベーカリーは、Linux、Solaris、AIX、および Windows でセットアップを実行できます。
ただし、エージェントプラグインのすべての機能をエージェントベーカリーで設定できるわけではありません。 たとえば、大規模な介入や深い専門知識が必要な機能などは設定できません。 したがって、カスタム SQL クエリはエージェントベーカリーでは設定できません。
Setup > Agents > Windows, Linux, Solaris, AIX 、および「Agents > Agent rules 」メニューから、「Oracle databases (Linux, Solaris, AIX, Windows) 」ルールセットのページに移動します。 「Add rule 」で新しいルールを作成します。 ここでは、エージェントプラグインの設定に使用できるすべてのオプションが表示されます。
多くのオプションは、手動セットアップで既にご存じのものだと思います。 そこで説明したように、一部のオプションは、すべてのオペレーティングシステムで使用できるわけではありません。 これらのオプションのタイトルには、使用できるオペレーティングシステムが表示されています。
5.1. ユーザーの設定
Unix 系オペレーティングシステムの最も単純な設定では、ルールは次のようになります。
エージェントベーカリーでは、標準ユーザーを作成したり、特定のインスタンスの例外を作成したりすることもできます。 設定ファイルでコロン (Linux など) またはリストエントリ (Windows) で区切られたオプションは、Login Defaults に個別のオプションとして表示され、必要に応じて入力することができます。 もちろん、Authentication method をUse manually created Oracle password wallet に変更するだけで、Oracle Walletを使用することもできます。
自動ストレージ管理 (ASM) の設定は、Login for ASM オプションを使用して同様に実行し、 特定のインスタンスの例外は、Linux、Solaris、AIX、およびWindows の高度なユーザー設定で説明されているように、Login for selected databases に指定します。
5.2. 高度なオプション
次の表は、Oracle databases (Linux, Solaris, AIX, Windows) ルールセットの残りのオプションと、そのオプションの説明の参照先の一覧です。
| オプション | 説明 |
|---|---|
Host uses xinetd or systemd (Linux/AIX/Solaris only) |
このオプションは、 |
Instances to monitor |
このオプションは、Linux、Solaris、AIX、またはWindows のインスタンスを含めるか除外するかを指定する、設定ファイルの複数のオプションをまとめたものです。 |
Add pre or postfix to TNSALIASes (Linux/AIX/Solaris only) |
このオプションを使用すると、TNS エイリアスをグローバルに、または特定のインスタンスに対して拡張することができます。 |
Sections - data to collect |
このオプションには、使用可能なすべてのセクションがリストされており、グローバルレベルで個別に設定できます。
したがって、これらは、 |
Exclude some sections on certain instances |
|
Cache age for background checks |
非同期セクションの有効期間を指定します。 デフォルト値は 600 秒 (10 分) です。 |
Sqlnet Send timeout |
このオプションは、 |
Remote instances (Linux/AIX/Solaris only) |
このオプションを使用して、リモートインスタンスを設定します。 このオプションには、既知のすべての設定エレメントが含まれています。Unique ID を使用して、変数の ID を指定するには、さまざまなオプションから選択できます。 ID は、設定内で一意である必要があります。 |
ORACLE_HOME to use for remote access (Linux/AIX/Solaris only) |
ここで、エージェントプラグインが |
TNS_ADMIN to use for sqlnet.ora and tnsnames.ora (Linux/AIX/Solaris only) |
2 つのファイルが |
sqlnet.ora permission group (Linux/AIX/Solaris only) |
エージェントベーカリーによって作成される |
Oracle binaries permissions check (Windows only) |
ここでは、個々の非管理者ユーザーおよびグループにプログラムの実行を許可することにより、Oracle バイナリのアクセス権チェックを設定できます。 このチェックをオフにする場合は、その操作の内容をよく理解している場合にのみ行ってください。 このトピックの詳細については、Windows での実行時のアクセス権セクションを参照してください。 |
6. クラスタ化されたインスタンス
6.1. スタンバイ・データベース
Oracle は、指定されたタスクを実行できる、通常は本番データベースまたはプライマリデータベースの単純なコピーである、いわゆるスタンバイ・データベースをサポートしています。 これらのデータベースの概念には、特別な監視メカニズムも必要です。 これらのメカニズムの詳細については、次のセクションを参照してください。
Active Data Guard (ADG) を使用する場合
ADG をライセンス認証してアクティブ化すると、プライマリ・インスタンスとの同期を中断することなく、いつでもスタンバイ・インスタンスから読み込むことができるため、エージェント・プラグインの構成を変更する必要はありません。
Active Data Guard（ADG）を使用しない場合
インスタンスに ADG がインストールされていない場合、スタンバイ・インスタンスから監視データを取得するためのユーザーには、SYSDBA ロールが必要です。
この許可により、プライマリ・インスタンスが障害に発生し、スタンバイ・サーバー上のインスタンスがMOUNTED からOPEN にまだ変更されていない場合でも、ユーザーはデータの一部少なくともを取得することができます。
インスタンスからデータを取得することを許可されたユーザーにこの許可を割り当てます。 重要：この動作は、以下の例とは異なる場合があります。 ここでは、初期セットアップの例で作成したユーザーにロールが割り当てられています。
sqlplus> grant sysdba to checkmk;エラーが発生した場合に、スタンバイサーバーのエージェントプラグインがデータを照会できるようにするには、プライマリインスタンスでユーザーを作成し、パスワードファイルをスタンバイサーバーにコピーします。
最後に、プラグインの設定ファイルで、ユーザーの役割をSYSDBA に設定します。
# Syntax:
# DBUSER='USER:PASSWORD:ROLE:HOST:PORT:TNSALIAS'
DBUSER='checkmk:myPassword:sysdba'ホスト、ポート、TNS エイリアスの指定はオプションであり、省略可能です。 また、エージェントプラグインは、プライマリインスタンスのホストだけでなく、スタンバイインスタンスのホストにもインストールする必要があります。
クラスタサービスの設定
Checkmk 側では、ADG を使用しているかどうかに関係なく、サービスをカスタマイズし、クラスタホストに割り当てる必要があります。 対応するチェックプラグインは、クラスタサービスとしても設定できる程度まですでに準備されています。 Checkmk でクラスタホストを作成し、プライマリインスタンスおよびスタンバイインスタンスが実行されている個々の Oracle ホストをノードとして追加します。 次に、このクラスタホストに以下のサービスを割り当てます。
ORA .* RMAN BackupORA .* JobORA .* Tablespaces
これで、データがどのインスタンスから送信されるかを気にする必要がなくなり、プライマリインスタンスが切り替わった場合でも、上記のサービスをシームレスに監視できるようになります。
6.2. Real Application Cluster (RAC)
RAC にはデータの一元的な保存場所があるため、エージェントプラグイン用のユーザーは 1 回だけ作成すれば十分です。 Oracle クラスタの各ノードには、エージェントプラグインをインストールして設定するだけで済みます。
重要：クラスタのノードは、必ずご自身で設定し、OracleSCAN リスナーを照会しないでください。 そうすることで、エージェントプラグイン経由のアクセスが正しく機能するようになります。
クラスタ サービスの設定
RAC にはクラスタサービスを設定することも有効です。 (Active) Data Guard でクラスタホストに割り当てるサービスに加えて、スイッチオーバー時に監視が中断されないように、クラスタホストに以下のサービスも割り当ててください。
ASM.* DiskgroupORA .* Recovery Area
7. カスタム SQL クエリ (カスタム SQL)
7.1. カスタム SQL クエリの必要性
Checkmk は、エージェントプラグインにより、データベースインスタンスを監視するための多数の SQL クエリをすでに提供しています。 これらのクエリは、技術的および内容的な要件を可能な限り幅広く満たすよう、非常に一般的なフォームで作成されています。
特定のデータベースの監視に関する各企業の個別の要件に対応するため、Checkmk では、独自のカスタム SQL クエリ（略してカスタム SQL）を作成し、エージェントプラグインで取得することができます。 これらのカスタム SQL クエリは、Web インターフェイスで独自のサービスとして自動的に認識され、監視されます。
|
カスタム SQL クエリは、Linux、Solaris、および AIX でのみ使用できます。 このオプションは Windows では使用できません。 |
7.2. シンプルなカスタムSQLクエリ
SQL クエリの記述
このような SQL を接続する最も簡単な方法は、Oracle データベース：カスタム SQLチェックプラグインを使用することです。
これを行うには、まず、SQL を実行するホストのエージェントの構成ディレクトリにMyCustomSQL.sql ファイルを作成します。
以下の例は、構文を説明するダミーです：
/*Syntax help in comments. The first word is alwyas the key word and ends with a ":"*/
/*details:Text to display in the service detail output*/
prompt details: Some details for the service output;
/*perfdata:METRIKNAME=CURRENTVALUE;WARN;CRIT;MAX METRIKNAME=CURRENTVALUE2;WARN;CRIT;MAX*/
prompt perfdata:MyMetricName1=10;15;20;30 MyMetricName2=16;15;20;30;
prompt perfdata:MyMetricName3=21;15;20;30 MyMetricName4=15;15;20;30;
/*long:Text to display in the long output of the service*/
prompt long: Here comes some long output for the service;
prompt long: Here comes some more long output for the service;
/*exit:Status of the service as a number*/
prompt exit:2;この例は、このようなファイルに任意の数のステートメントを定義できることを示しています。 一方、構文は、特にメトリックに関して、ローカルチェックの構文と非常によく似ています。 詳細には、この構文は、複数行の出力を生成でき、それが Checkmk サーバーでサービスとして処理されるため、ここではより強力です。 原則として、すべての行はオプションであり、入力する必要はありません。
使用可能なキーワードの詳細は次のとおりです。
details: ここでは、生成されたサービスのSummary に出力する内容を決定できます。 この行は、キーワードとコロンで開始します。 行の残りの部分が、出力内容となります。perfdata: このキーワードでメトリックが渡されます。 1 行内に、スペースで区切って任意の数のメトリックを作成できます。 メトリックの出力を複数の行に分散することもできます。 ただし、必ずキーワードperfdata:で開始してください。long: サービスのDetails フィールドの出力結果が長い場合は、ここで指定することができます。 このキーワードを複数回使用して、Details に複数の行を作成することもできます。exit: 出力に特定のステータスを指定する場合は、ここで指定できます。 既知の割り当て0、1、2、3は、ステータスOK 、WARN 、CRIT 、UNKNOWNに使用できます。
|
キーワード |
エージェントプラグインの設定
最初の非常に単純な SQL を定義しましたので、エージェントプラグインmk_oracle にそれを認識させます。
これは、おなじみの設定ファイルを使用して行います。このファイルは、必要に応じて拡張することができます。
SQLS_SECTIONS="mycustomsection1"
mycustomsection1 () {
SQLS_SIDS="INST1"
SQLS_DIR="/etc/check_mk"
SQLS_SQL="MyCustomSQL.sql"
}最初のオプション (SQLS_SECTIONS) で、実行する個々のセクションを指定します。
ここでいうセクションとは、エージェントプラグインの出力の一部であり、データベースインスタンスの一部ではないことにご注意ください。
この例では、1 つのセクション (mycustomsection1) だけを指定し、その直後に詳細を説明しています。
各セクションは、実際にはエージェントプラグインによって呼び出される小さな関数です。
この関数では、さらに詳細を決定し、このセクションが適用されるインスタンス (SQLS_SIDS) を指定することができます。
さらに、SQL ステートメントを含むファイルの場所 (SQLS_DIR) およびこのファイルの名前 (SQLS_SQL) も定義します。
この簡単な設定で、Checkmk に結果を表示することができます。 これを行うには、サービスディスカバリーを実行し、新しいサービスを有効にしてください。 その後、ホストの概要に、この新しいサービスが他のサービスとともに表示されます。
7.3. 高度なオプション
カスタム SQL クエリによる監視の可能性は、上記の簡単な例だけにとどまりません。
以下では、mk_oracle.cfg 設定ファイルで使用できる変数の概要を説明します。
詳細については、エージェントプラグインmk_oracle を--help オプションで呼び出してください。
|
セクション関数の外側または内側でのみ設定できる変数は、その旨が明記されています。 それ以外の変数は、どちらのセクションでも定義できます。 セクションの外側で設定した場合、その変数はすべてのセクションにグローバルに適用されます。 |
| 変数 | 短い説明 | オプション |
|---|---|---|
|
エージェントプラグインによって実行される、自己定義のセクション関数。 |
|
|
セクションを実行するインスタンス。 |
なし |
|
カスタム SQL クエリを含むファイルが保存されているディレクトリのパス名。 |
いいえ |
|
セクションの SQL ステートメントを含むファイル。 |
なし |
|
カスタム SQL クエリ用に独自のチェックプラグインで評価するセクションの名前です。 |
はい |
|
出力の 1 行における個々のエレメントの区切り文字。10 進ASCIIID として定義されます。
この変数は、 |
はい |
|
生成されるサービス名の一部を指定します。
デフォルトでは、サービス名は SID とカスタム SQL クエリを含むファイル名で構成されます。
この変数の値は、サービス名内のファイル名に置き換えられます。 |
はい |
|
同じタスクを実行します |
はい |
|
セクションの個々のユーザーを定義します。 |
はい |
|
|
はい |
|
|
はい |
|
セクションに個別のTNS エイリアスを定義します。 |
はい |
7.4. 独自のチェックプラグインの使用
上記の構文の可能性では不十分な場合は、SQLS_SECTION_NAME 変数を使用して、1 つ以上の SQL クエリ用の独自のセクション名を出力し、SQLS_SECTION_SEP で独自の区切り文字を定義することもできます。
ただし、このためには、適切なチェックプラグインも作成し、Checkmk サイトに含める必要があります。
このようなチェックプラグインを作成した場合は、エージェントプラグインの自己定義セクションの出力を完全に自由に評価でき、独自の方法で処理することができます。 この方法は最も包括的ですが、最も難しいため、ここでは完全のために記載しています。 この方法では、エージェントベースのチェックプラグインの記述方法と、それをサイトに統合する方法を知っていることを前提としています。 その後、変数を含むカスタム SQL クエリをこのチェックプラグインに割り当てます。
8. 診断オプション
Linux では、エージェントプラグインmk_oracle をさまざまなオプションで呼び出すことで診断が行われます。mk_oracle --help を使用すると、使用可能なすべてのオプションの概要を表示できます。
8.1. 接続のテスト
|
以下で説明する接続テストでは、LinuxまたはWindows での実行時に必要なアクセス権が設定されているかどうかもチェックされます。 アクセス権が設定されていない場合は、その旨と具体的な修正方法が表示されます。 アクセス権の診断および修正の正確な手順については、Checkmk 知識ベースをご覧ください。 |
Linux、Solaris、AIX
Oracle サーバー上の 1 つ以上のインスタンスに接続できない場合は、まず基本パラメータをチェックしてください。-t オプションを指定してエージェントプラグインを起動すると、接続の詳細が表示されます。
エージェントプラグインには、その設定ファイルとプラグインのキャッシュデータのパスを事前に指定しておく必要があります。
出力では、読みやすくするためにダミーのセクションは省略しています。
次の例は、systemd がインストールされ、エージェントプラグインが 60 秒ごとに非同期で実行される Linux サーバーの場合です。
root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -t --no-spool
---login----------------------------------------------------------------
Operating System: Linux
ORACLE_HOME (oratab): /u01/app/oracle/product/11.2.0/xe
Logincheck to Instance: XE
Version: 11.2
Login ok User: checkmk on ORA-SRV01 Instance XE
SYNC_SECTIONS: instance dataguard_stats processes longactivesessions sessions recovery_status undostat logswitches recovery_area performance
ASYNC_SECTIONS: tablespaces rman jobs ts_quotas resumable
------------------------------------------------------------------------xinetd を実行している Linux サーバーでは、代わりに次のようにmk_oracle を呼び出して接続テストを行ってください。
root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -tこの呼び出しは、エラーが発生した場合に実行される可能性が高いため、さらに詳しい情報も受け取ることができます。 接続に使用された接続文字列と、接続の試行中に返されたエラーメッセージの最初の 100 文字です。 この情報を使用して、単純な設定の問題をすばやく特定し、必要に応じて修正することができます。
Windows
エージェントプラグインは、Windows ではパラメータを受け付けません。
ここで接続をテストするには、取得するセクションを一時的にinstance に制限し、DEBUG オプションを有効にしてください。
# Syntax:
# $DBUSER = @("USERNAME", "PASSWORD")
$DBUSER = @("checkmk", "myPassword")
SYNC_SECTIONS = @("instance")
ASYNC_SECTIONS = @("")
DEBUG = 1次に、エージェントプラグインを手動で実行します。 再び、プラグインがインスタンスにアクセスしようとした結果に関する情報が表示されます。 出力は、たとえば次のようなものになります。
PS C:\ProgramData\checkmk\agent\plugins\> .\mk_oracle.ps1
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of DBVERSION software = xxx112020xxx
<<<oracle_instances>>>
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of inst_name = xxxXExxx
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of DBVERSION database = xxx112020xxx
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of the_section = sql_instance
2020-08-23T12:48:20.3930944+02:00 DEBUG:now calling multiple SQL
2020-08-23T12:48:20.3930944+02:00 DEBUG:value of sql_connect in dbuser = checkmk/myPassword@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SID=XE))) as sysdba
<<<oracle_instance>>>
XE|FAILURE|...8.2. ログ記録
Linux、Solaris、AIX
単純な接続のチェックでエラーが見つからない場合は、次のステップとして、エージェントプラグインのすべてのステップをログに記録するログファイルを作成します。 ここでも、必要な環境変数を設定することを忘れないでください。 以下の例では、読みやすくするために、セクションの出力を省略しています。
以下は、systemd を実行している Linux サーバーで、エージェントプラグインが 60 秒ごとに非同期で実行される場合の呼び出しです。
root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -l --no-spool
Start logging to file: /var/lib/check_mk_agent/log/mk_oracle.logxinetd を使用して、Linux サーバーにログを記録するためのmk_oracle の呼び出しは次のとおりです。
root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -l生成されたログファイルを使用して、問題が発生したスクリプトの行を正確に特定することができます。
Windows
Windows でのロギングは、上記の接続テストと同様に機能します。 接続自体が安定している場合は、実際のセクションを構成ファイルに追加して、完全なロギング出力を取得することができます。
8.3. デバッグ
Linux、Solaris、AIX
ログの助けを借りても問題の原因を特定できない場合、最後の手段として、エージェントプラグインがエラー分析のためにすべてのステップの完全な出力を提供します。 この出力は、問題の原因を特定するための最も包括的な方法ですが、読み取るのが最も難しい方法でもあるため、最後の手段としてのみ使用してください。
以下は、systemd をインストールした Linux サーバーで、エージェントプラグインが 60 秒ごとに非同期で実行されている場合のデバッグの例です。
root@linux# export MK_CONFDIR="/etc/check_mk/"; export MK_VARDIR="/var/lib/check_mk_agent"
root@linux# /usr/lib/check_mk_agent/plugins/60/mk_oracle -d --no-spoolxinetd を実行している Linux サーバーでデバッグを行うためのmk_oracle の呼び出しは、次のとおりです。
root@linux# /usr/lib/check_mk_agent/plugins/mk_oracle -d重要：この出力では、パスワードなどの機密情報はマスクされていません。 したがって、すべてがプレーンテキストで読み取ることができます。
Windows
Windows でも同様の機能をご利用いただけます。 ただし、エージェントプラグインに引数を渡すことはできませんので、トレースは手動でスイッチをオンにしてください。
PS C:\ProgramData\checkmk\agent\plugins\> Set-PSDebug -Trace 1
PS C:\ProgramData\checkmk\agent\plugins\> .\mk_oracle.ps18.4. Oracle ログファイル内のエラーメッセージ
通常、監視用のデータベースユーザーには SYSDBA ロールは必要ありません。
ただし、エージェントプラグインmk_oracle は、マルチテナントデータベースでエラーメッセージ（監視には関係ありません）を生成する場合があり、SYSDBA 権限がないため、Oracleデータベースのログファイルに書き込まれない場合があります。
その結果、たとえば、アラートログファイルにORA-01031: insufficient privileges タイプのOracleエラーメッセージが表示される場合があります。
9. ファイルおよびディレクトリ
9.1. Linux、Solaris、AIX の Oracle ホスト上
| ファイルパス | 説明 |
|---|---|
|
ホストに関するすべてのデータを収集する Checkmk エージェント。 |
|
エージェントプラグインの通常のディレクトリにある Oracle エージェントプラグイン。
AIX ではパス名が若干異なることにご注意ください。 |
|
エージェントプラグインの設定ファイル。
ここでも、AIX は異なります。 |
|
Oracle Wallet に必要な構成ファイルです。 |
|
TNS エイリアスを含む設定ファイルです。 サンプルファイルも Oracle のインストール先にありますが、パスはインストールごとに異なるため、標準的な方法で指定することはできません。 |
9.2. Windows の Oracle ホスト
| ファイルパス | 説明 |
|---|---|
|
ホストに関するすべてのデータを収集する Checkmk エージェント。 |
|
エージェントプラグインの通常のディレクトリにある Oracle エージェントプラグイン。 |
|
エージェントプラグインの設定ファイル。 |
|
Oracle Wallet に必要な構成ファイルです。 |
|
TNS エイリアスを含む設定ファイル。 サンプルファイルは Oracle のインストール先にもありますが、インストール先によってパスが異なるため、標準的な方法で指定することはできません。 |
9.3. Checkmk サーバー上
| ファイルパス | 説明 |
|---|---|
|
Oracle ホストのデータを取得する、Unix 系システム用のエージェントプラグインです。 |
|
Unix 系システム用のこのエージェントプラグインは、Oracle Cluster Manager にデータを提供します。 |
|
Oracle ホストのデータを取得する Windows 用のエージェントプラグインです。 |
|
Unix 系システム用のサンプル設定ファイルは、 |
|
Windows 用の設定ファイルの例です。 |