 |
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 をバージョン 2.3.0 から 2.4.0 にアップデートする際に重要なトピックについてご説明します。
アップデートを実施する前に、この記事全体をご一読いただき、アップデート前、アップデート中、アップデート後の各段階で何が起こるかを確認することをおすすめします。
 |
この記事は、Checkmk 2.4.0 のリリース後も引き続き改訂されます。 重要なトピックが欠落している場合は、GitHub を通じて問題をご報告ください。 |
2. 準備
この章では、アップデートを実行する前に考慮すべき事項の概要について説明します。 おそらく、すべての項目がお客様に関係するわけではありません。 各トピックについて、ご自分の参考のために該当するボックスをチェックして、次のトピックにすぐに進むことができます。
2.1. バックアップ
生産用ソフトウェアのアップデートと同様に、Checkmk のアップデートを実行する前に、バックアップが最新であることを確認してください。
これはあなたに関係がありますか？ はい。
何をする必要がありますか？ Setup > Maintenance > Backups を使用してバックアップを自動的に作成している場合は、バックアップが最新であり、最新のバックアップジョブがエラーなしで完了していることを確認してください。
詳細については、「バックアップ」および「サイトのバックアップと復元」の記事をご覧ください。
|
2.3.0 へのアップデート以降、アップデートが失敗した場合、変更はロールバックされます (Werk #16408)。
アップデートは、予期しない内部エラーにより失敗する場合がありますが、アップデートプロセス中にユーザーが入力した内容（メニューオプション「 |
2.2. ハードウェアの利用率をチェック
Checkmk2.4.0 は、2.3.0 よりも若干高いシステムリソースを必要とします。 そのため、更新を行う前に、Checkmk に使用されているサーバーの空き容量を確認しておくことをお勧めします。
これはお客様に影響がありますか？ はい、ただし、その影響の程度は Checkmk の使用方法によって大きく異なります。
何をする必要がありますか？ 十分な空き容量があることを確認してください。 アクティブチェックを多く使用する場合、プロセッサの負荷が若干高くなることが予想されます。 必要に応じて他の領域を最適化することで、多くの場合、プロセッサの負荷を軽減することができます。 経験則として、CPU 負荷 がプロセッサコア数 × 0.8未満、CPU 使用率が70 % 未満であれば、問題はないと考えられます。
Checkmk2.4.0 のメモリ使用量は、2.3.0 と比較して約 30 % 高くなります。 その理由は、頻繁に使用されるデータのキャッシュが広範囲に及ぶため、メモリ使用量は増加しますが、レイテンシーが短縮され、パフォーマンスが向上するためです。
分散監視でピギーバックを使用する場合、RabbitMQ メッセージブローカーには追加の RAM および CPU リソースが必要です。 これは Open Telemetry Receiver にも当てはまります。
Checkmk2.4.0 を使用する場合、ホスト 1 台あたり最大 5 MB のハードディスク容量が追加で必要になります。 この追加のディスク容量は、アップデート直後に使用されます。
2.3. Linux ディストリビューションのバージョン
一部の旧ディストリビューションは、Checkmk バージョン2.4.0 以降ではサポートされなくなります。
これはお客様に影響がありますか？ 2.3.0でまだサポートされている以下の Linux ディストリビューションのいずれかが Checkmk サーバーにインストールされている場合、この変更の影響を受けます。
Debian 10
SLES 12 SP5
Ubuntu 20.04
必要な作業 Checkmk をアップデートする前に、まずLinux ディストリビューションのバージョンをアップグレードしてください。 Checkmk の Linux ディストリビューションのターゲットバージョンが2.3.0 であり、 2.4.0 がサポートされていることを確認してください。 Checkmk がサポートする Linux ディストリビューションのバージョンは、2.4.0 のアップデートマトリックス、および Checkmk バージョンと Linux ディストリビューションを選択した後のダウンロードページで確認できます。
Red Hat Enterprise Linux 10 のリリース後、このディストリビューションバージョン用の Checkmk2.3.0 および2.4.0 パッケージをまもなく提供いたします。 これにより、まず Checkmk2.3.0 の最新パッチバージョンにアップデートし、次に Red Hat Enterprise Linux 9 から 10 にアップデートし、最後に Checkmk2.4.0 の最新パッチバージョンにアップデートすることができます。
2.4. ブラウザのサポート
Checkmk2.4.0 は、古いブラウザでは利用できない新しい JavaScript 機能を使用しています。 サポートされているブラウザのバージョンについては、リリースノートをご覧ください。
これに影響はありますか？ デスクトップシステムでは通常、最新バージョンへの自動更新が有効になっています。
何をする必要がありますか？ お使いのブラウザのバージョンを確認し、必要に応じて新しいブラウザをインストールしてください。 ダッシュボードの表示にシングルボードコンピュータ、スマートテレビ、デジタルサイネージソリューションを使用しており、システムのブラウザを制御できない場合は、アップデート前に必要なダッシュボードが正しく表示されることを確認してください。 必要に応じて、ハードウェアの製造元にお問い合わせください。
|
Firefox ESR を使用している場合は、Firefoxをバージョン 128 から 140 にアップデートするまで、Checkmk のアップデートを待ってください。 Firefox ESR 140 は 6 月末から利用可能になり、9 月末時点ではサポートされる唯一の ESR バージョンとなります。 |
2.5. GET パラメータによる認証
Checkmk2.2.0 までは、すべてのオートメーションユーザーは、GET パラメータで渡されたユーザー名とパスワードを使用してログインすることができました。 このオプションは、Checkmk2.3.0 以降で削減され、バージョン2.5.0 (Werk #16223) で完全に削除されます。 したがって、中期的には、スクリプトを HTTP ヘッダによる認証に切り替える必要があります。
まず、2.3.0 では、GET パラメータによるログインのオプションを設定可能になりました。 ただし、グローバル設定Enable automation user authentication via HTTP parameters では、当初、デフォルトとしてon が使用されていました。 Checkmk2.4.0 では、デフォルトがoff に変更されました。
この変更はお客様に影響がありますか？ この変更は、主に、キーボードが接続されていないシングルボードコンピュータ、スマートテレビ、デジタルサイネージソリューションを使用してダッシュボードを表示するユーザーに影響します。
どのような対応が必要ですか？
GET パラメータによる自動ログインを使用している場合は、グローバル設定のAutomation user authentication via HTTP parameters をon に変更する必要があります。
Checkmk2.5.0 では、GET パラメータによるログインのオプションが完全に削除されるため、このようなダッシュボードのログインをBasic Auth に切り替える必要があります（たとえば、ブラウザの拡張機能を使用）。
2.6. ntopng 5.6 以前のバージョンはサポートされなくなりました
Checkmk2.3.0 は、ntopngバージョン 5.xおよび6.x をサポートする最後のバージョンです (Werk #16483)。 Checkmk2.4.0 以降、ntopng 5.x のサポートは終了し、ntopng 6.x のみサポートされます。
この変更はお客様に影響がありますか？ この変更は、ntopng との統合を使用している商業版のユーザーに影響があります。
何をする必要がありますか？ Checkmk を2.4.0 にアップデートする前に、ntopng を 6.x にアップデートしてください。
2.7. スペシャルエージェントの実行に関する変更
ホストにスペシャルエージェントが設定されている場合、Checkmk2.4.0 では、これらのスペシャルエージェントがすべて実行されます。 以前のバージョンでは、アルファベット順で最初のスペシャルエージェントのみが実行されていました。
この変更は、お客様に影響がありますか？ この変更は、プロパティでCheckmk agent / API integrations 属性がAPI integrations if configured, else Checkmk agent に設定されているホストにのみ関係します。
誤って、ホストに必要以上のスペシャルエージェントを割り当てたルールを作成している可能性があります。
これらの追加のルールは、アルファベット順で最初のルールよりも後に指定されていた場合、以前は無視されていました。
例：agent_acme のルールとagent_cyberdyne のルールを作成し、ちょっとした見落としでこれらのルールを同じホストに割り当てました。
Checkmk2.4.0 では、これらのホストに対して、agent_acme だけでなくagent_cyberdyne も実行されます。
どのような対応が必要ですか？ コストを不必要に増加させたり、レート制限に抵触したりする可能性のある API にアクセスするスペシャルエージェントを使用する場合は、事前の準備を行い、正しい割り当てを行ってください。 また、CPU 負荷やネットワークトラフィックを増加させるスペシャルエージェントについても、正しい割り当てを行ってください。 さらに、スペシャルエージェントがホストに誤って割り当てられている場合、本来は存在しないサービスが突然表示される可能性があることにご注意ください。
2.8. Python モジュールのアンインストール
Checkmk の2.4.0 は、Python を3.12.3にアップデートします。 このアップデートは、Checkmk サイトにインストールされているモジュールに影響します。 多くの場合、インストール後に追加されたモジュールは Python 3.12.3 と互換性がありません。 最悪の場合、古いモジュールが Checkmk が提供するモジュールの機能を上書きしてしまいます。
これはお客様に影響がありますか？ これは、お客様が、ご自身で作成した、または Exchange から入手した、スペシャルエージェントまたはエージェントベースのチェックプラグイン用に Python モジュールを明示的にインストールしている場合にのみ影響します。 不明な場合は、次のセクションで説明するチェックを行ってください。
ただし、アクティブチェック「check_sql 」を使用して Oracle データベースを監視している場合も、この問題の影響を受けます。
Checkmk2.3.0p27 までは、このチェックを使用するには、oracledb モジュールをインストールする必要がありました。2.3.0p28 以降、このモジュールは Checkmk に付属しています (Werk #17370)。
何をする必要がありますか？
まず、サイトに Python モジュールがインストールされているかどうかを確認し、インストールされている場合はそのモジュールを特定します。
これを行うには、dist-info およびegg-info ディレクトリを検索します。
OMD[mysite]:~$ find ~/local/lib/python3/ -type d -name '*.*-info'
local/lib/python3/cryptography-41.0.5.dist-info
local/lib/python3/ecdsa-0.18.0.dist-infoインストールされているモジュールをメモし、それらをアンインストールします。
OMD[mysite]:~$ pip3 uninstall cryptography ecdsaアップデート後にアンインストールした Python モジュールを処理する方法については、以下をご覧ください。
2.9. パッケージ化（MKPs）されたローカルファイルとパッケージ化されていないローカルファイル
ローカルファイルを使用すると、Checkmk が提供する機能をカスタマイズおよび拡張することができます。
これらのファイルは、サイトディレクトリ構造のローカル部分、つまり~/local にあり、拡張パッケージ内に、あるいは単に「散在」している場合もあります。
ローカルファイルは、新しい Checkmk バージョンと一致しなくなった場合、アップデート中に問題を引き起こす可能性があります。
これはお客様に影響がありますか？ Checkmk では、アップデート中にローカルでの変更の互換性を完全に保証することはできません。そのため、アップデートを行う前に、Checkmk サイトをチェックして、ローカルファイルが使用されているかどうか、使用されているファイルはどれか、そのファイルはどのように整理されているかを確認してください。
何を行う必要がありますか？
mkp listを使用して、既存の拡張パッケージ（MKP）とそのソースの概要を作成してください。 通常、ご自身で開発した拡張機能は簡単にテストし、必要に応じて調整することができます。 外部ソースのMKPについては、Checkmk2.3.0 で既知の問題がないか、新しいバージョンが利用可能かどうかを確認してください。 MKPで提供されていた機能がCheckmk2.3.0 で提供されている場合は、アップデート前にパッケージを無効にしてください。サイトユーザーとしてコマンド
mkp findを実行して、Checkmk サイト内のパッケージ化されていないローカルファイルの概要を確認します。python3を含むパスが表示された場合は、Python モジュールに戻ってください。 その他のファイルについては、以下が適用されます。関連するファイルはMKP にまとめてください。 これにより、アップデート後に非互換性が検出された場合に、これらのファイルをまとめて無効化することが容易になります。Checkmk2.2.0 と2.3.0 で異なるバージョンを必要とする MKP の場合、アップデートを実行する前に、Checkmk に両方のパッケージバージョンを正しい互換性情報とともにインストールしておく必要があります。 パッケージの異なるバージョンが利用可能な場合、Checkmk はアップデート中に適切なバージョンを自動的に有効にします。 Checkmk2.2.0 を使用するセントラルサイトは、2.3.0 のパッケージを保存し、リモートサイトに配布することができるため、この機能は、セントラルセットアップによる分散監視でのアップデートにも役立ちます。
|
2.3.0 で提供されている Redfish スペシャルエージェントの MKP をアクティブにしている場合は、アップデート前に無効にしてください。 このパッケージが存在すると、アップデート中にエラーメッセージ（ステータス2.4.0b5）が表示されます。 |
2.10. プログラミングインターフェース
Checkmk2.3.0 では、旧バージョンでアドホックに定義されていた一部のプログラミングインターフェース (API) が、バージョン管理され、明確に定義されたものに置き換えられました。 旧 API は引き続き並行して使用することができます。 Checkmk2.4.0 では、旧 API との互換性を維持するための追加の措置は講じられていません (Werk #17201)。 つまり、旧 API を使用するプラグインは、Checkmk2.4.0 では動作しなくなります。
これはお客様に影響がありますか？ API のトピックは、Checkmk に付属のチェックプラグインを、お客様独自に作成したプラグインで拡張している場合、および/または他のソースのプラグインを使用している場合に影響します。
何をする必要がありますか？ 2.4.0 にアップデートする前に、まず、2.3.0 の最新パッチバージョンにアップデートしていることを確認してください。2.4.0 にアップデートすると機能しなくなる既存の拡張機能は、MKP を管理する許可を持つすべてのユーザーに対して、GUI に繰り返しメッセージが表示されます (Werk #17649)。
ご自身で作成した拡張機能、およびサードパーティプロバイダが提供する拡張機能について、現在の API (cmk.agent_based.v2 、 cmk.server_side_calls.v1 、cmk.graphing.v1 、およびcmk.rulesets.v1) を使用しているかどうかを確認してください。
古い、バージョン指定のない API またはcmk.agent_based.v1 が使用されている場合は、新しい API および新しいフォルダ構造に移行してください。
移行に関する情報は、Werk #16259 およびチェックプラグインの開発に関する記事でご覧いただけます。
GitHub には、移行に役立つスクリプトもご用意しています。
|
|
プラグインで非公開の API を使用する場合は、2.3.0 および2.4.0 を使用して、より徹底的にテストしてください。 「内部ツールボックス」に、デバッグフラグの検出への影響など、いくつかの変更が加えられました。
2.11. REST API の廃止
Checkmk REST API の廃止予定のエンドポイントまたはパラメータは、API ドキュメントでアイコンで表示されています。
これはお客様に影響がありますか？ たとえば、お客様のスクリプトで Checkmk REST API を使用している場合、この変更の影響を受ける可能性があります。
どのような対応が必要ですか？ Help > Developer Resources > REST API documentation で REST API ドキュメントを開きます。
ブラウザでページ内の「Deprecated 」を検索し、スクリプトで廃止されたエレメントを使用しているかどうかを確認し、更新する前に置き換えてください。
REST API ドキュメントには、通常、新しいバージョンで廃止された関数の置き換え方法に関する説明があります。
2.12. 互換性のない変更
他の Checkmk バージョンと同様、現在の2.4.0 バージョンにも、お客様の Checkmk インストールに影響を与える可能性のあるソフトウェアの変更が含まれています。Checkmk では、これらの変更は「CheckmkWerks」として整理、文書化されています。 互換性のない変更と呼ばれる変更では、既存の機能を通常どおり実行し続けるため、および/または新しい機能を使用するために、手動で変更を行う必要があります。
これはお客様に影響がありますか？ 一般的に、お客様の Checkmk インストールにも影響する互換性のない変更がありますが、一概には言えません。 この記事では、すべての、またはほとんどの Checkmk インストールに該当する問題を集めました。 いずれの場合も、お客様のインストールで使用しているチェックなど、お客様に関連する追加の変更がある場合があります。
何をする必要がありますか？ パッチバージョンを含むすべてのアップデート後に、Checkmk は互換性のない変更の数と内容を表示し、確認して記録するよう求めます。 アップデートを実行する前に、2.3.0 からアップデートに影響を与える可能性のある変更がないかどうかを確認してください。 Checkmk2.3.0 以降、このような Werk は引き継がれず、確認ダイアログ（Werk #15292）で承認すると、アップデート中に削除されます。
また、アップデートを行う前に、バージョン2.4.0 の互換性のない変更の概要を確認しておくことをお勧めします。 Checkmk の web サイトでWerkのリストを開きます。 Werk の説明には、変更を互換性のあるものにするために必要な作業に関する情報が記載されています。
アップデートを実行すると、互換性のない変更の数と内容が Checkmk インターフェースに表示され、確認してメモするよう求められます。 リンクを使用すると、影響を受けるコンポーネントを使用しているかどうかを数回のクリックで確認できます。 Werk が影響を与えないことが確実である場合、または必要な変更を行った場合は、Acknowledge で Werk を確認してください。
3. 更新
3.1. 更新時のベストプラクティス
このセクションでは、大規模な Checkmk 環境を更新する場合にも当社が従っているベストプラクティスについて説明します。 これらは、すべての環境において必須というわけではありませんが、更新プロセスを容易にするために役立ちます。
Checkmk バージョンの更新
2.4.0 にアップデートする前に、2.3.0 が Checkmkサイトにインストールされていることが前提条件となります。
2.4.0 へのアップデートには、現在、少なくとも2.3.0p29 が必要です。 ただし、将来、特定の2.4.0 パッチバージョンでは、アップデートのために、より新しい2.3.0 パッチバージョンが必要になる場合があります。 一般的には、まず Checkmk を最新の2.3.0 パッチバージョンにアップデートしてから、最新の2.4.0 パッチバージョンにアップデートすることをお勧めします。
アップデートのテスト実行を実施してください
大規模な環境では、Checkmk 環境の現在のバックアップを復元するだけでもかなりの時間がかかることが予想されるため、本番環境を更新する前に、クローンしたサイトでテストを実行することをお勧めします。 この目的のために、たとえば、サイトの最後の定期バックアップを別の名前で復元することができます。
root@linux# omd restore newsite /path/to/backupあるいは、omd cp を使用してサイトをコピーすることもできます。
ただし、この場合は、サイトを短時間停止する必要があります。
root@linux# omd stop mysite
root@linux# omd cp mysite newsite次に、この新しいクローンサイトに対して最初にアップデートを実行し、たとえば、新しい環境で上記のローカル変更をチェックします。
エージェントの更新を一時的に無効にする
商業版で自動エージェント更新を使用している場合は、Checkmk を更新する前に、一時的に無効にして、後でホストの新しいエージェントに制御して切り替えることを検討してください。 これを行うには、まず [Setup > Agents > Windows, Linux, Solaris, AIX ] を選択し、次のページで [Agents > Automatic updates.] メニュー項目を選択します。Master switch の前の ボタンをクリックすると、エージェント更新を完全に無効にすることができます。
Checkmk のアップデートが正常に完了したら、同じ方法でエージェントのアップデートを再度有効にすることができます。
この時点で、最初は個々のホストまたはホストグループに対してのみ、エージェントの自動更新を再度有効にすることをお勧めします。 そうすることで、新しいエージェントがすべてのサーバーにすぐに展開されることはなく、いくつかのシステムで新しく配信されるデータに慣れることができます。 また、提供されているチェックプラグインの数が大幅に増加しているため、まったく新しいサービスセットが見つかるかもしれません。その場合は、お好みのテストシステムで適切に設定してください。 また、新しいサービスには新しい閾値を設定する必要がある場合もあります。 まず小規模で対応することで、不要な偽陽性を最小限に抑えることができます。
上記の「Automatic agent updates 」ページで、対応するフィールドにいくつかのホストまたはホストグループを入力し、Master switch を再度有効にしてください。
|
結果に満足したら、明示的に指定したホストおよびホストグループに対する制限を必ず解除してください。 |
通知を一時的に無効にする
また、前のセクションで説明したエージェントの自動更新の場合と同様の理由から、更新前にサイトでの通知を無効にすることも検討してください。 これにより、監視チームの同僚が不要な通知を受け取ることを回避できます。
通知は、マスターコントロールスナップインのメインの「Notifications 」スイッチで一元的に無効にすることができます。
アップデート後に、以前はそうではなかったサービスがCRIT になる場合があります。 アップデート後に、たとえば [概要]スナップインで新しい問題に対処してください。
|
更新後に未処理の問題の数が更新前のレベルに戻った場合など、通知を再びオンにすることを忘れないでください。 |
3.2. 分散監視の更新
分散監視に含まれるすべてのサイトの更新を実行するには、2 つの手順があります。
すべてのサイトを停止し、バルクアクションですべてのサイトの更新を実行してから、すべてのサイトを再起動します。
厳密な条件下では、一定期間、リモートサイトを最初に更新し、その後、セントラルサイトの更新によってバージョン同等性が復元される、混合操作を行うことができます。
特に、システムが稼働中に更新を行う場合は、更新とアップグレードに関する一般的な記事の注意事項をご確認ください。
3.3. アップデートの実施
Checkmk2.4.0 におけるソフトウェアの実際のアップデートについては、基本的な変更はありません。 つまり、新しいバージョンをインストールし、Checkmk サイトのアップデートを実行し、競合の可能性を修正し、互換性のない変更を確認して確認します。
更新手順は、更新とアップグレードに関する記事に記載されているとおりに実行してください。
4. フォローアップ
4.1. ユーザーインターフェースの変更
2.0.0 で完全に再設計された Checkmk ユーザーインターフェース (GUI) は、2.4.0 では基本的に変更されていません。2.0.0 から2.3.0 まででおなじみの一般的な手順は、2.4.0 でもそのまま使用できます。 ただし、新しい機能を利用できるように、また既存の機能を改善するために、メニュー、メニュー項目、アイコンなどの詳細が変更されています。
これらの変更点については、このユーザーガイドの記事でご説明します。また、初心者ガイドでは、ユーザーインターフェースの最も重要なエレメントを含む、詳細な紹介を掲載しています。 4.2. サービスの更新
4.2. サービスの更新
すべてのメジャーバージョンと同様に、Checkmk2.4.0 では、まったく新しいチェックプラグインのセットが導入されています。 ディスカバリーチェック、つまり定期的なサービスディスカバリーによるサービス設定の自動更新を使用しない場合は、かなりの数のホストでサービスを検索する必要があります。
ホストが適切に整理されている場合（フォルダに整理されている場合など）、通常はBulk discovery 機能を使用できます。 この機能は、Setup > Hosts > Hosts 、そしてHosts > Run bulk service discovery メニューにあります。
サービス名
Checkmk を更新するたびに、Checkmk の監視およびドキュメント内の命名の一貫性を高めるため、サービス名が変更されます。 サービス名を変更すると、ルールを変更する必要がある場合があり、履歴監視データが失われる可能性があるため、Checkmk は更新時には、最初は旧名をそのまま残します。 旧監視データの損失が許容でき、ルールの変更作業もそれほど難しくないサービスについては、できるだけ早く新しいサービス名に切り替えてください。
これを行うには、Setup > General > Global settings > Execution of checks に移動し、Use new service names のリストを確認して、チェックボックスがまだアクティブになっていないサービスを特定し、それらをアクティブにしてください。 変更を適用すると、新しいサービス名がアクティブになり、数分後に、影響を受けるサービスの定義された状態が監視に再び表示されます。
4.3. 消えたサービス
場合によっては、チェックプラグインを削除したり、チェックプラグインを新しい API に切り替える必要がありました。
この問題の影響がありますか？ ライフサイクルが非常に長いハードウェア、特にスペシャルエージェントを使用して監視している場合は、この問題の影響を受ける可能性があります。 たとえば、2.3.0 から2.4.0 へのアップデートの準備中に、多くの NetApp デバイス用のスペシャルエージェントが、製造中止となったZAPIから、より新しい REST API に切り替える必要があることがわかりました (Werk #16767)。 ライセンス上の理由により、Dell PowerConnect 用のエージェントを、Exchange で入手可能な別のパッケージに移す必要がありました (Werk #15359)。
お客様にはどのような作業が必要ですか？ アップデート後にサービスが消えた場合は、Werks で監視対象製品のメーカーを検索してください。 ほとんどの場合、新しい API に切り替える必要がありますが、まれに、特定のハードウェアまたはソフトウェアコンポーネントを監視するために Exchange のパッケージを使用する必要がある場合もあります。
4.4. Python モジュールのインストール
これはお客様に影響がありますか？ これは、お客様が、ご自身で作成した、または Exchange から入手したスペシャルエージェントまたはエージェントベースのチェックプラグイン用に Python モジュールを明示的にインストールし、アップデートの準備中にそれらを削除した場合にのみ適用されます。
どのような作業が必要ですか？ まず、以前にアンインストールしたモジュールが新しい Checkmk バージョンにすでに含まれているかどうかを確認してください。
OMD[mysite]:~$ pip3 list | grep '^cryptography'モジュールがすでに確認された場合は、メモで「不要」とマークしてください。 含まれていないモジュールは、最新バージョンをインストールしてください。
OMD[mysite]:~$ pip3 install ecdsa次に、サイトにインストールされている Python モジュールに依存するチェックプラグインまたはスペシャルエージェントをテストします。
5. 今後の見通し
この章では、現在の Checkmk バージョン2.4.0 には直接関係のないトピックスについて、開発中の将来のバージョンについてご説明いたします。
5.1. 旧 HTTP チェックが削除されます
2.3.0 以降、Checkmk には HTTP 接続および証明書に関する新しいアクティブチェックがすでに含まれています。Check HTTP web service は、Networking ボックスのSetup > Services > HTTP, TCP, Email, … にあります。 新しいチェックは、以前のCheck HTTP service よりもパフォーマンスが大幅に改善され、堅牢性が高く、設定も簡単です。 さらに、1 つのルールで、HTTP 応答コード、応答時間、証明書の有効期限など、複数の項目を同時に監視することが可能になりました。
Checkmk2.4.0 では、移行を容易にするため、旧チェックではほとんど使用されていなかったオプションが新しいチェックに追加されています。 さらに、既存の呼び出しと結果のサービスを 1 対 1 でマッピングする移行スクリプトも提供しています。 Checkmk2.5.0 では、旧チェック用に新しいルールを設定することはできないため、このスクリプトを使用して、旧アクティブチェックから新しいアクティブチェックにサービスを変換してください。 旧チェックは後で完全に削除されます。
移行が完了すると、複数のルールをマージして 1 回のチェック実行で複数の出力を生成できるようになり、CPU オーバーヘッドが削減されるため、パフォーマンスが大幅に向上します。 多くの場合、新しいチェックでは 1 つのルールを使用して複数のサービスを生成することもできます。
新しいチェックに関する一般的な情報は、2 つの Werk#15514および#15515 に記載されています。 Werk#17725には、移行スクリプトについて説明しています。 詳細なブログ記事では、移行の準備とフォローアップに関する可能性、制限、およびベストプラクティスの詳細について説明しています。
新しいチェックで古いチェックを置き換えることができないアプリケーションがある場合は、ここで説明した手順と同じ方法で、使用されているコマンドラインを表示することができます。
その後、Setup > Other services > Integrate Nagios plugins から、古いチェック、またはシステム全体にインストールされているcheck_http を呼び出すことができます。
5.2. 管理ボード
管理ボードとは、インストールされているオペレーティングシステムに加えて、ハードウェアを監視および管理するための個別のプラグインカードまたは拡張 BIOS 機能 (Baseboard Management Controller/BMC、Management Engine/ME、Lights Out Management/LOM) を指します。
Checkmk2.4.0 までは、管理ボードは 2 つの方法で設定できます。 ホストプロパティとして、または個別のホストとして。 ホストプロパティとしての設定可能性は非常に限られているため、将来はこのオプションは使用できなくなります。
Redfish 互換の管理ボードのサポートは、Checkmk2.3.0 のライフサイクル中に、当初はオプションの MKP (Werk #16589) として追加され、改良されました。 Checkmk2.4.0 では、Redfish 監視はソフトウェアの不可欠な部分となっています (Werk #17404)。 追加の背景情報と可能な代替案については、ブログ記事「管理ボードの監視」で説明しています。