Kubernetes クラスターの監視: Prometheus の概要と概要

Kubernetes モニタリングの概念を検討し、Prometheus ツールについて理解し、アラートについて話します。

モニタリングのトピックは膨大であり、XNUMX つの記事で分解することはできません。 このテキストの目的は、ツール、概念、アプローチの概要を提供することです。

記事の内容はから絞られています 学校「スラーム」公開講座。 フルコースを受講したい場合は、次のコースにサインアップしてください。 Kubernetes のインフラストラクチャの監視とログ記録.

Kubernetes クラスターで監視されるもの

物理サーバー。 Kubernetes クラスターがサーバー上にデプロイされている場合は、サーバーの状態を監視する必要があります。 Zabbix はこのタスクを処理します。 あなたが彼と一緒に働くなら、あなたは拒否する必要はありません、衝突はありません。 サーバーの状態を監視するのは Zabbix です。

クラスターレベルでの監視に移りましょう。

コントロール プレーンのコンポーネント: API、スケジューラなど。 少なくとも、サーバーまたは etcd の API が 0 より大きいことを確認する必要があります。Etcd は、回転しているディスクや etcd クラスターの健全性など、多くのメトリクスを返すことができます。

デッカー かなり前に登場し、その問題点は誰もがよく知っています。多くのコンテナがフリーズやその他の問題を引き起こします。 したがって、システムとしての Docker 自体も、少なくとも可用性に関しては制御される必要があります。

DNS クラスター内で DNS が停止すると、その後 Discovery サービス全体が停止し、ポッドからポッドへの呼び出しが機能しなくなります。 私の実践ではそのような問題はありませんでしたが、これは DNS の状態を監視する必要がないことを意味するものではありません。 リクエストのレイテンシやその他のメトリクスは、CoreDNS で追跡できます。

進入。 プロジェクトへのエントリ ポイントとしてのイングレス (イングレス コントローラーを含む) の可用性を制御する必要があります。

クラスターの主要コンポーネントは解体されました。次に、抽象化のレベルに進みましょう。

アプリケーションはポッド内で実行されるため、制御する必要があるように見えますが、実際はそうではありません。 ポッドは一時的なものです。今日は 10 つのサーバーで実行され、明日は別のサーバーで実行されます。 今日は 2 個ですが、明日は XNUMX 個になります。したがって、ポッドを監視する人は誰もいません。 マイクロサービス アーキテクチャ内では、アプリケーション全体の可用性を制御することがより重要です。 特に、サービス エンドポイントの可用性を確認してください。何か機能しているか? アプリケーションが利用可能な場合、その背後で何が起こっているのか、現在レプリカがいくつあるか、これらは XNUMX 番目の質問です。 個々のインスタンスを監視する必要はありません。

最後のレベルでは、アプリケーション自体の動作を制御し、注文数やユーザーの行動などのビジネス指標を取得する必要があります。

プロメテウス

クラスターを監視するのに最適なシステムは次のとおりです。 プロメテウス。 品質と使いやすさの点で Prometheus に匹敵するツールを私は知りません。 柔軟なインフラストラクチャに最適であるため、「Kubernetes モニタリング」というと、通常は Prometheus を意味します。

Prometheus を使い始めるには、いくつかのオプションがあります。Helm を使用すると、通常の Prometheus または Prometheus Operator をインストールできます。

1. いつものプロメテウス。 彼にとってはすべて問題ありませんが、ConfigMap を構成する必要があります。実際には、以前に行ったように、マイクロサービス アーキテクチャの前にテキストベースの構成ファイルを作成します。
2. Prometheus Operator はもう少し広がりがあり、内部ロジックの点では少し複雑ですが、操作は簡単です。個別のオブジェクトがあり、抽象化がクラスターに追加されるため、制御と構成がはるかに便利です。

製品を理解するには、まず通常の Prometheus をインストールすることをお勧めします。 config を通じてすべてを構成する必要がありますが、これは有益です。何が何に属し、どのように構成されているかを理解できるようになります。 Prometheus Operator では、すぐに高い抽象化に到達できますが、必要に応じてさらに深く掘り下げることもできます。

Prometheus は Kubernetes と適切に統合されており、API サーバーにアクセスして対話することができます。

Prometheus は人気があるため、多数のアプリケーションやプログラミング言語が Prometheus をサポートしています。 Prometheus には独自のメトリクス形式があり、それを転送するには、アプリケーション内のライブラリまたは既製のエクスポーターが必要なため、サポートが必要です。 そして、そのような輸出業者はかなりの数あります。 たとえば、PostgreSQL Exporter があります。これは PostgreSQL からデータを取得し、それを Prometheus 形式に変換して、Prometheus が操作できるようにします。

プロメテウスのアーキテクチャ

Prometheusサーバー バックエンド、プロメテウスの頭脳です。 メトリクスはここに保存され、処理されます。

メトリクスは時系列データベース (TSDB) に保存されます。 TSDB は別個のデータベースではなく、Prometheus に組み込まれた Go 言語のパッケージです。 大まかに言えば、すべてが XNUMX つのバイナリ内にあります。

TSDBにデータを長期間保存しないでください

Prometheus インフラストラクチャは、メトリクスの長期保存には適していません。 デフォルトの保存期間は 15 日間です。 この制限を超えることもできますが、TSDB に保存するデータが増え、保存する時間が長くなるにつれて、より多くのリソースが消費されることに注意してください。 Prometheus に履歴データを保存することは悪い習慣であると考えられています。

大量のトラフィックがあり、メトリクスの数が XNUMX 秒あたり数十万件に達する場合は、ディスク容量または期間によってストレージを制限することをお勧めします。 通常、「ホット データ」は TSDB に保存され、メトリクスはわずか数時間で保存されます。 より長いストレージの場合は、InfluxDB、ClickHouse など、これに適したデータベースで外部ストレージが使用されます。 ClickHouse についての良いレビューをさらに見ました。

Prometheus Server はモデル上で動作します プル: 彼は、私たちが彼に与えたエンドポイントへのメトリクスを探しに行きます。 彼らは「API サーバーに行って」と言ったので、彼は n 番目の秒ごとにそこに行き、メトリクスを取得しました。

スクレイピング期間の間に出現する可能性のある有効期間が短いオブジェクト (ジョブまたは cron ジョブ) の場合は、Pushgateway コンポーネントがあります。 短期オブジェクトからのメトリクスがプッシュゲートウェイにプッシュされます。つまり、ジョブが開始され、アクションが実行され、メトリクスが Pushgateway に送信され、完了しました。 しばらくすると、Prometheus は独自のペースでダウンし、Pushgateway からこれらのメトリクスを取得します。

Prometheus で通知を設定するには、別のコンポーネントがあります - アラートマネージャー。 そして、警告ルール。 たとえば、サーバー API が 0 の場合、アラートを作成する必要があります。イベントが発生すると、アラートはさらにディスパッチするためにアラート マネージャーに渡されます。 アラート マネージャーには非常に柔軟なルーティング設定があり、アラートの XNUMX つのグループを管理者のテレグラム チャットに送信し、別のグループを開発者のチャットに送信し、XNUMX 番目のグループをインフラストラクチャ作業者のチャットに送信できます。 通知は、Slack、Telegram、電子メール、その他のチャネルに送信できます。

そして最後に、Prometheus のキラー機能についてお話します - 発見する。 Prometheus を使用する場合、監視するオブジェクトの特定のアドレスを指定する必要はなく、オブジェクトのタイプを設定するだけで十分です。 つまり、「ここに IP アドレス、ここにポート - モニター」と記述する必要はなく、代わりに、どのような原則に従ってこれらのオブジェクトを見つけるかを決定する必要があります (ターゲット - 目標)。 Prometheus 自体は、現在アクティブなオブジェクトに応じて、必要なオブジェクトを取得し、監視に追加します。

このアプローチは、すべてが浮動する Kubernetes 構造によく適合します。今日は 10 台のサーバーがあり、明日は 3 台になります。サーバーの IP アドレスを毎回指定しないようにするために、サーバーはその IP アドレスを見つける方法を一度書きました。そして Discovering がそれを実行します。 。

プロメテウス言語は次のように呼ばれます。 PromQL。 この言語を使用すると、特定のメトリクスの値を取得して変換し、それらに基づいて分析計算を構築できます。

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

プロメテウス Web インターフェース

Prometheus には、独自のかなりミニマルな Web インターフェイスがあります。 デバッグまたはデモンストレーションにのみ適しています。

Expression 行では、PromQL 言語でクエリを作成できます。

[アラート] タブにはアラート ルールが含まれており、これらには次の XNUMX つのステータスがあります。

1. inactive - 現時点でアラートがアクティブでない場合、つまり、すべて問題なく、機能しなかった場合。
2. 保留中 - アラートは機能したが、送信がまだ完了していない場合です。 遅延は、ネットワークの点滅を補正するために設定されます。指定されたサービスが XNUMX 分以内に起動した場合、アラームはまだ鳴らされるべきではありません。
3. 起動は、アラートが点灯してメッセージを送信する XNUMX 番目のステータスです。

[ステータス] メニューでは、Prometheus についての情報にアクセスできます。 上で説明したターゲット（目標）への移行もあります。

Prometheus インターフェイスの詳細な概要については、次を参照してください。 Kubernetes クラスターの監視に関する Slurm の講義で.

グラファナとの統合

Prometheus Web インターフェイスには、クラスターの状態に関する結論を導き出すための美しくわかりやすいグラフはありません。 これらを構築するために、Prometheus は Grafana と統合されています。 このようなダッシュボードを入手します。

Prometheus と Grafana の統合のセットアップはまったく難しくありません。手順はドキュメントに記載されています。 GRAFANA によるプロメテウスのサポートそれでは、これで終わります。

次の記事では、監視のトピックを継続します。Grafana Loki と代替ツールを使用したログの収集と分析について説明します。

著者: Marcel Ibraev、認定 Kubernetes 管理者、社内の現役エンジニア サウスブリッジ、講演者およびコース開発者の Slurm。

出所： habr.com