更新およびアップグレード

メジャーバージョンをアップグレードする際は、必ず利用可能な中間バージョンを順にアップグレードし、ターゲットバージョンに到達するまでスキップしないでください。 例えば、バージョン 2.2.0 からバージョン 2.4.0 にアップグレードする場合、まず中間バージョン 2.3.0 にアップグレードする必要があります。 この手順の理由は単純です。2つのメジャーバージョン間には変更点が非常に多く、バージョンをスキップすると問題が発生する可能性があるためです。

omd update コマンドでは、より低いバージョンへの「アップデート」もできます。 この手順は、リグレッションの場合にのみ使用してください。 逆方向の更新を行った場合、設定およびランタイム環境を再び互換性のある状態にするために、多くの調整が必要になります。特に、メジャーバージョンを下げる「更新」の場合は、その必要性が高くなります。 したがって、このような手順は絶対に行わないでください。また、バージョンを下げる更新については、サポートも提供いたしません。

Checkmk 拡張パッケージ (MKP) を使用すると、監視システムを非常に簡単かつ便利に拡張することができます。 一方では、一部の古い MKP はメンテナンスが終了しており、新しいバージョンの Checkmk と互換性がなくなる可能性があります。 他方では、Checkmk には新しいプラグインや機能拡張が継続的に追加されているため、MKP が廃止になる場合があります。 これらのプラグインおよび拡張機能の機能は、Checkmk 自体が標準で提供しています。

そのため、アップデートを準備する際には、インストールされているすべての MKPs を確認することを強くお勧めします。 これにより、互換性のないパッケージがアップデートに干渉したり、アップデート後に重複した、あるいは少なくとも非常に類似したサービスが生成されるのを防ぐことができます。

これを行うには、インストールされている MKPをチェックプラグインのカタログと照合し、Checkmk でネイティブに提供されている機能を含むパッケージを削除してください。 また、この機会を利用して、テスト実行のためにのみインストールされた MKP を削除することもできます。 リストは、[Setup ] メニューの [Maintenance > Extension packages] にあります。 コマンドラインでは、mkp list コマンドでインストールされている拡張機能を表示できます。 このコマンドの出力で、不要になった拡張機能や、識別できない拡張機能を確認してください。

Checkmk は、将来のアップデートに備えて、現在実行中のバージョンよりも新しいバージョンの MKP のインストールをサポートしています。 アップデートを実行すると、古いバージョンの Checkmk 用のパッケージは使用不能になり、新しいバージョンのパッケージが有効になります。 詳細については、MKP の使用に関する記事で説明しています。

注意： MKPs から元のファイルにローカル変更を加えた場合、バージョン番号を増加させた後に MKP を再パッケージ化してください。 更新時に、他の方法で変更されたファイルは MKP に含まれるファイルで上書きされます。

ローカルファイルを使用すると、Checkmk が提供する機能をカスタマイズおよび拡張することができます。 これらのファイルは、サイトディレクトリ構造のローカル部分、つまり~/local にあります。 ローカルファイルは、新しい Checkmk バージョンと一致しなくなる可能性があるため、更新時に問題が発生する可能性があります。

Checkmk は、アップデート中にローカルカスタマイズやサードパーティの拡張機能をインターセプトしてハンドルすることはできません。そのため、アップデートを行う前に、Checkmk サイトを使用して、ローカルファイルを使用しているかどうか、および使用しているローカルファイルを確認してください。

サイトユーザーとして次のコマンドを実行して、Checkmk サイトのローカルファイルの概要を確認します（-L オプションにより、シンボリックリンクも追跡されます）。

Checkmk を新規にインストールした場合、現在、README.TXT というファイルのみがリストに表示されます。 それ以外のファイルは、更新に問題が発生した場合のトラブルシューティングリストの一番上に記載してください。

理想的には、ローカルファイルはすでにMKP に完全にパッケージ化されています。mkp find を使用して、パッケージ化されていないファイルを確認してください。 パッケージの作成の詳細については、Checkmk 拡張パッケージに関する記事をご覧ください。 パッケージ化すると、各拡張機能は完全なエレメントとして無効化または再有効化できます。

更新を行う直前にバックアップを作成することの重要性については、改めて説明する必要はありません。更新中に障害が発生した場合に、監視のヒストリーを大幅に失うリスクを回避するためです。 この時点で重要なのは、定期的なバックアップは、ペンディング中の更新のテスト実行にも役立つということです。 この方法では、バックアップを別の名前で復元し、newsite サイトを使用して、更新を本番環境で適用する前にテストすることができます。

あるいは、omd cp を使用してサイトをコピーすることもできます。 ただし、この方法では、ライブサイトを短時間停止する必要があります。

次に、この新しいクローンサイト上でまずアップデートを実行し、たとえば、上記のローカル変更が新しい環境でも行われていることを確認します。 クローンサイトでのテストが成功した場合は、通常、スペースとパフォーマンスの理由から、本番サイトの実際のアップデートを行う前に、クローンサイトを削除するか、少なくとも停止しておくことをお勧めします。

はじめに」で説明したように、アップデートではまず、ご希望の新しいバージョンのCheckmkをインストールします。 この手順は、最初のインストールとまったく同じですが、依存するパッケージのほとんどはすでにインストールされているため、多少迅速に進みます。 以下の例では、Ubuntu 24.04 (Noble Numbat) 用のパッケージをインストールしています。

注： apt install を使用してローカルパッケージをインストールする場合は、.deb ファイルへのプルパスを指定する必要があります。

インストールされている Checkmk のバージョンのリストは、omd versions コマンドでいつでも表示できます。

リストされたバージョンの 1 つが、(default) でマークされています。 このデフォルトバージョンは、omd -V myversion create mysite で他のバージョンが指定されていない限り、新しいサイトを作成する際に自動的に使用されます。 現在のデフォルトバージョンは、omd version で照会でき、omd setversion で変更できます。

デフォルトのバージョンは、既存のサイトを管理する際には何の影響も与えません。omd コマンドは、常に、コマンドが呼び出されたサイトに適したバージョンで起動します。

現在のサイトとそれらが使用しているバージョンのリストは、omd sites コマンドで取得できます。

目的の新しいバージョンをインストールしたら、サイトを更新できます。 この作業には、root の許可は必要ありません。 この作業を行うには、サイトユーザーとして実行するのが最適です。

サイトが停止していることを確認します。

更新（実際には別のバージョンへの切り替え）は、omd update コマンドで簡単に実行できます。

複数のターゲットバージョンが利用可能な場合は、選択リストが開きます。

次のダイアログボックスで、新しいバージョンへのアップデートの選択を確認してください。

安全を期すため、バージョンアップと同時に Checkmk Raw から商業版へのエディションのアップグレードを行う場合、この事実が再度通知されます。

更新の重要な部分としては、最初に提供された設定ファイルの更新があります。 ここでは、ユーザーによってこれらのファイルに加えられた変更は、単に破棄されるのではなく、マージされます。 これは、複数の開発者が同時に 1 つのファイルに加えた変更を統合しようとするバージョン管理システムとよく似た機能です。

まれに、変更がファイル内の同じ位置に影響を与える場合、この機能は機能せず、衝突が発生します。 このような衝突を解決する方法については、後述します。

更新では、変更されたすべてのファイルおよびディレクトリのリストが表示されます (以下の例では省略しています)。

上記の出力で「Completed verifying site configuration 」という行が表示されている場合、サイトは新しいバージョンにスイッチされています。

… その後、サイトを起動できます：

ソフトウェアの開発には、当然ながら変更が伴います。 Checkmk は常に最新の状態に保つよう積極的に取り組んでいるため、不要な部分を削除したり、互換性がない変更を行ったりすることは避けられません。 そのため、アップデート時には、設定の変更、または少なくとも確認が必要になる場合があります。

このような状況の典型的な例は、既存のプラグインを置き換える新しいチェックプラグインです。 影響を受けるプラグインのいずれかを使用している場合、影響を受けるホストで新しいサービスディスカバリーが必要になります。

Checkmk のすべての変更の概要は、検索機能付きオンラインのWerk でご覧いただけます。

しかし、より実用的なのは、Checkmk にビルトインされている検索機能です。 サイトにログインすると、Help メニューの上部に、互換性がない、まだ確認されていない変更の数が赤で強調表示されたリンクが表示されます。

Checkmk は、現在のバージョンへのアップデート中に発生した互換性のない変更を追跡し、確認と承認を求めます。

Help メニューの赤いリンクからこのページを開くと、何か対応が必要な、つまりIncompatible - TODO でマークされた「Werk」（変更）のみが表示されます。 各Werkを個別に呼び出し、表示してマウスクリックで確認することで、未解決の互換性のない変更の数を順次減らすことができます。 さらに、Help > Change log (works) メニュー項目から、現在のメジャーバージョンにおける変更の完全なヒストリーにアクセスできます。

更新の「裏側」で何が起こっているのか気になりますか？ または、omd update 実行中にデータ競合が発生しましたか？ その場合、以下の詳細情報をご確認ください。

omd update では、次の3つのアクションが実行されます：

Checkmk のソフトウェア更新を自動化しますか？ 最初は、omd update からの対話型の応答に戸惑うかもしれません。 このシナリオには簡単な解決策があります。このコマンドには、スクリプトで使用するために特別に考案されたオプションがあります。

--conflict= の可能な値は次のとおりです：

以下は、mysite のバージョン2.4.0p8.cre への自動更新の完全なコマンドの例です。

&& をomd start の前に追加すると、omd update がエラーで中止された場合、サイトの再起動が防止されます。 このような状況でも確実に起動を試みたい場合は、&& をセミコロン (;) に置き換えてください。

サーバー上で実行されている Checkmk サイトが 1 つだけであることが確実な場合は、シェルスクリプトで使用する名前を単に 1 つの変数にトラップすることができます。

これにより、上記の行はサイト名に依存しなくなります。 たとえば、小さなシェルスクリプトは次のようになります。

上記の更新アプローチの技術的な理由は、使用されているプロトコルにあります。 セントラルサイトは、主にライブステータスを介してリモートサイトのデータにアクセスし、 セントラルセットアップの場合は、非公開の HTTP API による追加の書き込みアクセスも使用します。 どちらの場合も、新しいバージョンでは、使用されているプロトコルの真の上位セットが導入されます。 したがって、古いセントラルサイトは、新しいリモートサイトの機能の真の下位セットのみを使用します。 セントラルサイトが最初に更新された場合、リモートサイトがまだ「理解」できない API 呼び出しやライブステータス要求をリモートサイトに発行する可能性があります。

メジャーバージョンの最大バージョン差も、インターフェースの削除には正確に 1 バージョンの猶予期間があることから生じます。

このような段階的な更新を容易にするため、Checkmk では、同じ名前の拡張パッケージを異なるバージョンで保存する機能を提供しています。たとえば、古いセントラルサイトと一致するバージョンと、新しいリモートサイトと一致するバージョンを保存することができます。 各サイトには、適切なバージョンがアクティブになります。 詳細については、拡張パッケージ (MKP) に関する記事をご覧ください。

閲覧専用サイト拡張機能を使用すると、閲覧専用サイトは、そのサイトが表示するサイトのデータが更新された後にのみ更新することができます。 閲覧専用サイトがリモートサイトのデータのみを表示する場合、リモートサイトが更新されるとすぐに閲覧専用サイトも更新されます。 一方、セントラルサイトのデータも表示する場合、閲覧専用サイトの更新は最後にのみ行われます。

この章では、主に Checkmk Enterprise へのアップグレードについて説明します。 Checkmk Cloud へのアップグレードも 1 ステップで実行できますが、その場合は、次のセクションの注意事項もご参照ください。

商業版には追加のモジュールや機能が多数含まれているため、アップグレード後に留意すべき点がいくつかあります。 重要な点は、Checkmk Raw または商業版で新しいサイトを作成すると、異なるデフォルト設定が設定されることです。

監視コアと通知システムに関しては、Checkmk Enterprise と Checkmk Cloud には違いはありません。 デプロイの重点に応じて、新しいホストを追加する場合にのみ、より大規模な機能セットを使用することがよくあります。 ただし、場合によっては、既存の設定を見直すことをお勧めします。

追加機能の完全な概要については、Checkmk Cloud (セルフホスト型) の記事をご覧ください。

分散環境では、エディションのアップグレードを行う前に、必ずバージョンアップデートを行う必要があります。 異なる順序でのアップデートや、クロスグレード（バージョンアップデートとエディションのアップグレードを同時に行うこと）はサポートされていません。 一般的な手順としては、オフラインアップグレードをお勧めします。この方法では、どのエディションからでも、どのエディションへもアップグレードすることができます。

よく要求される 2 つのアップグレードシナリオ（Checkmk Raw から Checkmk Enterprise へ、およびCheckmk Enterprise から Checkmk Cloud へ）については、期間限定で混合運用が可能です。

Checkmk Cloud から Checkmk Enterprise へのダウングレードの準備として、少なくとも以下の変更を行う必要があります。

さらに、一部のクラウドサービスおよびダッシュボードは使用できなくなります。 その結果、消滅したサービスをクリーンアップする必要があります。

Checkmk Cloud で「Grafana Store」のGrafana プラグインを使用していた場合は、zip アーカイブからインストールしたプラグインに置き換える必要があります。

Checkmk Cloud と Checkmk Enterprise の違いの概要は、Checkmk Cloud (セルフホスト型) の記事でご確認いただけます。

Checkmk Enterprise から Checkmk Raw へダウングレードする準備として、少なくとも以下の変更を行う必要があります。

さらに、一部のダッシュボード、グラフ設定、通知プラグイン、およびスペシャルエージェントは使用できなくなります。 Checkmk Enterprise の記事では、Checkmk Raw にダウングレードした場合に Checkmk Enterprise の機能がどの程度失われるか、およびさらに調整が必要な箇所を確認することができます。

前の 2 つのセクションで説明したダウングレードのシナリオは、分散環境でも実行できます。 分散環境では、エディションのダウングレードを行う前に、必ずバージョンアップデートを実行する必要があることにご注意ください。 異なる順序での実行や、クロスグレード（バージョンアップデートとエディションのダウングレードを 1 つの操作で実行）はサポートされていません。

Checkmk が異なるエディション間の混合運用をサポートするダウングレードシナリオはありません。 そのため、エディションのダウングレードはオフラインで実行することを強くお勧めします。 これを行うには、次のようにします。

もちろん、すべてのサイトのダウングレードが完了してからサイトを再起動することもできます。この方法では、通知の数が多少減少します。

不要になった Checkmk バージョンのアンインストールは、オペレーティングシステムのパッケージマネージャを使用して行います。 これを行うには、インストールされているパッケージの名前（元の RPM/DEB ファイルのファイル名ではない）を入力してください。
重要：どのサイトでも使用されなくなった Checkmk バージョンのみ削除してください。

不要になった Checkmk サイトは、omd rm で簡単に削除できます（この操作により、すべてのデータも削除されます）。

以下のコマンドを使用して、インストールされているパッケージを特定します。

アンインストールは、dpkg --purge で実行します。

RPM ベースのシステムで使用されている Checkmk パッケージを識別する方法は、次のとおりです。

削除は、rpm -e で実行します: