 |
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. はじめに
Checkmk2.4.0 では、Checkmk Cloud以降、つまり Checkmk Cloud および Checkmk MSP でOpenTelemetryメトリックを受信し、監視で処理することができます。 この目的のために、Checkmk には OpenTelemetry コレクターが付属しています。 このコレクターは、プッシュ構成の受信者としてgRPCおよびHTTP(S)転送プロトコルをサポートしています。 スクレイパーとして、Prometheus エンドポイントから（プル構成で）データを収集することもできます。
特定された OpenTelemetry サービスに基づいて、ダイナミックホストマネージメントによりホストを自動的に作成できます。 これらのホストには、スペシャルエージェントにより OpenTelemetryメトリックがCheckmkサービスとして割り当てられます。
簡単にまとめると、3 つのコンポーネント（コレクター、ダイナミックホストマネージメント、スペシャルエージェント）が相互に作用して、サービスが検出され、メトリックが生成されます。 したがって、まずこの 3 つのコンポーネントを設定し、最後に保留中の変更をアクティブにしてください。
 |
ここでご紹介している機能は、技術的なプレビュー、つまり、追って開発および拡張が行われる新機能のプレビューです。 この段階では、機能が追加されるだけでなく、既存の構成が廃止され、再作成が必要になるような変更が行われる可能性があります。 この点について、ご了解のほどよろしくお願いいたします。 |
2. 設定
2.1. OpenTelemetry コレクターの有効化
まず、サイトが停止している状態でコレクターをアクティブにする必要があります。
これは、サイトユーザーとしてコマンドラインで omd configテキストベースの構成メニューで、次のコマンドを実行します。
OMD[mysite]:~$ omd configAddons に移動し、OPENTELEMETRY_COLLECTOR を有効にします。
┌──────────────────────────Addons─────────────────────────────┐ │┌─────────────────────────────────────────────────────────┐ │ │ MKEVENTD on │ │ │ │ MKEVENTD_SNMPTRAP off │ │ │ MKEVENTD_SYSLOG off │ │ │ │ MKEVENTD_SYSLOG_TCP off │ │ │ │ OPENTELEMETRY_COLLECTOR オン │ │ │ │ OPENTELEMETRY_COLLECTOR_SELF_MONITORING_PORT 14317 │ │ │ │ TRACE_RECEIVE off │ │ │ │ TRACE_SEND off │ │ │ │ │ │ │└─────────────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────────┤ │ < 変更 > <メインメニュー> │ └─────────────────────────────────────────────────────────────┘
コレクタの自己監視用のポートは、複数のサイトを使用している場合でも 14317 から次の空きポートに設定されるため、変更する必要はありません。
コレクターを有効にした後、omd start でサイトを再起動してください。
2.2. OpenTelemetry コレクターの設定
Setup > Hosts > OpenTelemetry collector (experimental) を呼び出し、[Add OpenTelemetry collector configuration ] ボタンで新しいコレクタの設定を開始します。
General properties で、新しいコレクターに ID とタイトルを割り当ててください。Site restriction では、左側から右側に少なくとも 1 つのエントリを移動する必要があります。
上の画像では、ローカルサイト mysite が唯一利用可能です。
コレクターのプロパティで以下の点に注意してください:
2 つのプッシュエンドポイント (gRPC または HTTP) のうち少なくとも 1 つ、または Prometheus スクレイパー (プル) を設定する必要があります。 この図は、すべての IPv4 アドレス (
0.0.0.0) の標準ポート 4317 上の、暗号化および認証されていない gRPC エンドポイントを示しています。Host name computation 用に少なくとも 1 つのフィールドを作成してください。 この例では、最も簡単なオプションが選択されています。OpenTelemetry 経由で受信した
service.nameフィールドが、Checkmk のホスト名として使用されます。 インラインヘルプには、OpenTelemetry データからホスト名を作成する方法の詳細情報が記載されています。
Save を使用してコレクターを保存します。
2.3. ダイナミックホストマネージメントの設定
ホストが自動的に作成されるように、ダイナミックホストマネージメントを使用して新しいOpenTelemetry 接続を設定します。 準備として、少なくとも最初のテストでは、自動的に生成される OpenTelemetry ホストを保存する別のフォルダを作成することをお勧めします。
ダイナミックホストマネージメント用の新しい接続を設定するには、[Setup > Hosts > Dynamic host management > Add connection:
Connection properties ボックスで、次の設定を行います。
Connector type をOpenTelemetry collector data.
OpenTelemetryTestフォルダは、この例では新しいホスト (Create hosts in) のターゲットフォルダとして使用されます。システム環境に応じて、Host attributes を設定します。 OpenTelemetry コレクターの設定時に、既存のホストの名前を作成していない場合、自動的に作成されるホストは、OpenTelemetry のコンテキストでのみ使用される仮想ホストになります。 そのため、監視エージェントとしてはスペシャルエージェント (Configured API integrations, no Checkmk agent) しか使用できず、IP アドレスの設定はNo IP のままにしておく必要があります。
Service discovery のチェックボックスを有効にすると、自動的に生成されたホストでサービスディスカバリーが実行されます。 これにより、OpenTelemetry 用のスペシャルエージェントが設定され、アクティブになっている場合、望ましい結果になります。
その他のパラメータについては、ダイナミックホストマネージメントに関する記事をご覧ください。
新しい接続をSave.
2.4. スペシャルエージェントの設定
Checkmk サービスも確実に生成されるように、OpenTelemetry スペシャルエージェントの構成を少なくとも 1 つ作成する必要があります。 必要なルールは、xml-ph-0000@deepl.internal ボックスで、コレクターのアクティベーション時に表示されたポート経由で OpenTelemetry コレクター自体を監視するかどうかを決定します。Setup > Agents > Other integrations > OpenTelemetry (experimental):
OpenTelemetry (experimental) ボックスで、OpenTelemetry コレクター自体を、コレクターのアクティブ化時に表示されたポート経由で監視するかどうかを決定します。
ルールの条件では、ホストが自動的に作成されるフォルダ（この例ではOpenTelemetryTest フォルダ）にスペシャルエージェントを割り当てることは明らかです。
Save でルールを保存します。
コレクター、ダイナミックホストマネージメント、スペシャルエージェントの 3 つのコンポーネントの設定が完了しましたので、保留中の変更をアクティブにしてください。
2.5. コレクターへのテストデータの送信
IT 環境では、すでに OpenTelemetryメトリックを生 成しているものがどこかに あるため、Checkmk 用の OpenTelemetry コレクターを設定することをお勧めします。
まだ生成されていない場合、またはこの記事で説明する設定例をすばやく試してみたい場合は、GitHub リポジトリで提供されている、仮想 Python 環境で動作するサンプルアプリケーション「Hello metric」を使用できます。
最初のデータが送信されてから、ホストが作成され、サービスが検出され、監視に表示されるまで、2～3 分程度かかります。 次の図は、「Hello metric」サンプルアプリケーションのサービスを示しています。
ホスト名hello-metric は、opentelemetry-instrument コマンドのオプションとして指定されたサービス名から生成されます。これは、OpenTelemetry コレクターの設定で指定したとおりです。
Checkmk のサービス名OTel metric hellolevel は、メトリックの名前に、スペシャルエージェントによってプレフィックスOTel metric が追加されて生成されます。
スペシャルエージェントの設定で Monitor the collector オプション、つまりコレクターの自己監視を有効にすると、ホストにいくつかの追加サービスが作成されます。
|
Checkmk では、1つのデータポイントのみを含む OpenTelemetry メトリックのみが、1 つのメトリックを持つサービスとして表示されます。 |
OpenTelemetry の web サイトに掲載されている「Dice Roll」サンプルアプリケーションは、「Hello metric」と非常によく似た動作をします。
「Hello metric」の例で作成した仮想 Python 環境を使用して、「Dice Roll」の例を試すことができます。
ただし、Pythonflask モジュール (pip install flask) もインストールし、こちらで説明されているように、メトリック拡張バージョンでapp.py ファイルを作成する必要があります。
次の呼び出しでは、ターゲットとして Checkmk サーバー（ここでは198.51.100.42 と gRPC ポート 4317）を置き換えてください。
user@host:~$ opentelemetry-instrument \
--traces_exporter console \
--metrics_exporter otlp \
--exporter_otlp_metrics_endpoint http://198.51.100.42:4317 \
--logs_exporter console \
--service_name dice-server \
flask run -p 8080数分後、ホストdice-server が、サービスOTel metric dice.rolls.とともに監視に表示されます。 ただし、「Dice Roll」のサンプルアプリケーションでは、メトリック「dice.rolls」はネストされているため、常にOK という情報サービスのみが生成されます。 ネストされたメトリックを 1 つではなく、2 つの「フラット」メトリックを作成して、Checkmk で 2 つの別々のサービスを取得します。
2.6. サービスのカスタマイズ
Setup > Services > Service monitoring rules > OpenTelemetry (experimental) ルールを使用して、サービスの閾値などを定義することができます。
3. ファイルとディレクトリ
| ファイルパス | 説明 |
|---|---|
|
OpenTelemetry データが作成される場所です。ホストごとにサブディレクトリが作成されます。 そこに作成されるファイルは JSON 形式です。 |
|
コレクタから収集された集約データが、スペシャルエージェントによる評価のために保存される一時ディレクトリです。 |