Yet Another Cloudwatch Exporter (YACE) が正式に Prometheus コミュニティに参加しました！この移行により、ユーザーはよりアクセスしやすくなり、コントリビューターがプロジェクトを強化・維持するための新たな機会が生まれます。Cristian Greco の視点からのブログ記事 もあります。

初期の頃

YACE を最初に始めたとき、ここまで成長するとは思いもしませんでした。当時、私はワークフォース管理ソフトウェアに特化した企業であるInvision AG (デザインアプリと混同しないでください) で働いていました。彼らはこのツールのオープンソース化を全面的に支援してくれ、同僚のKai Forsthövel の助けも借りて、YACE は誕生しました。

最初のコミットは2018年に行われました。その主な目標の1つは、CloudWatch メトリクスのスケーリングを容易にし、測定すべきものを自動的に検出し、ユーザーエクスペリエンスをシンプルかつ直感的に保つことでした。InVision AG は機械学習ワークロードのためにインフラストラクチャをスケールアップ・ダウンしており、新しいインフラストラクチャを簡単に検出できるものが必要でした。このシンプルさへの重点は、常に最優先事項として維持されてきました。それ以来、YACE はそのオーディエンスを見つけ始めました。

ベルリンで開催された PromCon でのPrometheus 3.0 ベータ版の最近のリリースに続き、Prometheus チームは Prometheus バージョン 3.0 の即時利用可能を発表できることを嬉しく思います！

この最新バージョンは、7年ぶりのメジャーリリースであり、重要なマイルストーンとなります。この間、Prometheus は初期採用者向けのプロジェクトから、クラウドネイティブな監視スタックの標準的な一部へと進化しました。Prometheus 3.0 は、安定性と以前のバージョンとの互換性を維持しながら、いくつかのエキサイティングな新機能を追加することで、その旅を続けることを目指しています。

3.0 のフルリリースでは、ベータ版に加えていくつかの新機能が追加され、この記事で説明するいくつかの追加の破壊的変更も導入されています。

Prometheus チームは、Prometheus バージョン 3.0-beta の提供開始を発表できることを誇りに思います！こちらからダウンロードできます。ベータリリースでは通常、重要な本番システムへの Prometheus 3.0-beta のインストールは推奨しませんが、ぜひ皆様にテストしてバグを見つけていただきたいと考えています。

一般的に、唯一の破壊的変更は非推奨の機能フラグの削除です。Prometheus チームは、後方互換性を確保し、既存のインストールを破壊しないよう努力しました。そのため、以下に説明するすべての新機能は既存の機能の上に構築されています。ほとんどのユーザーは、設定変更なしでPrometheus 3.0をすぐに試すことができるはずです。

OpenTelemetry プロジェクト は、トレース、メトリクス、ログなどのテレメトリデータを生成・管理するために設計された可観測性フレームワークおよびツールキットです。シグナル間の整合性のある仕様と、ベンダーロックインを削減するという約束により、広く採用されつつあり、私たちはこれに興奮しています。

2023年を振り返る

過去数年間、私たちは OpenTelemetry コミュニティと協力して、OpenTelemetry と Prometheus が双方向で相互にサポートできるように努めてきました。これにより、2つのシステム間の変換に関する公式仕様の草案作成や、Prometheus メトリクスを OpenTelemetry Collector に取り込み、またその逆も可能にする実装が行われました。

それ以来、私たちは Prometheus にメトリクスを保存する際にOpenTelemetry ユーザーが直面する課題を理解するためにかなりの時間を費やし、それらに基づいてどのように対処できるかを検討しました。提案された変更の中には、プッシュとプルの両方をサポートするなど、どちらかの側が提供する約束を破らないよう慎重な検討が必要なものがあります。PromCon Berlin 2023 では、講演の1つで私たちのアイデアを要約しようと試みました。

ベルリンでの開発サミットでは、これらの変更と OpenTelemetry に対する一般的な姿勢を深く議論することに時間の大部分を費やし、広く合意されたのは「OpenTelemetry メトリクスのデフォルトストアになりたい」というものでした！

この取り組みを主導する開発者の中核グループを結成し、2024年にOTelサポートを最も重要な機能の一つとしてPrometheus 3.0をリリースする予定です。2024年に登場する機能の一部を先行公開します。

PromCon Europeは、Prometheus監視システムに完全に特化した8回目のカンファレンスです

ドイツ、ベルリン – 2023年9月1日 – CNCF と Prometheus チームは、2023年9月28日から29日までドイツのベルリンで開催されるPromCon Europe 2023 カンファレンスの2日間のシングル・トラック・スケジュールを公開しました。参加者は、Prometheusに関連する多様なトピックにわたる21の全編セッション（25分）と最大20の5分間のライトニングトークセッションから選択できます。

第8回目となるPromConは、世界中のPrometheusユーザーと開発者が集まり、Prometheusの使用を通じて得られた知識、ベストプラクティス、経験を交換する場です。プログラム委員会は66件の提出物を審査し、今日のPrometheusに関する最も差し迫ったトピックについて、新鮮で有益な見解を提供します。

"PromCon がベルリンに帰ってくることを大変嬉しく思います。Prometheus は2012年に SoundCloud のベルリンで始まりました。最初の PromCon はベルリンで開催され、その後ミュンヘンに移りました。今年は、ベルリンのフリードリヒスハインにある Radialsystem に約300人の参加者を迎えます。ベルリンには活気ある Prometheus コミュニティがあり、多くの Prometheus チームメンバーが近隣に住んでいます。これは、システムとサービス監視に情熱を傾ける Prometheus ファミリーとネットワークを築き、つながる絶好の機会です」と、Polar Signals のシニアソフトウェアエンジニアであり、今年の PromCon プログラム委員会を率いる Prometheus チームメンバーの Matthias Loibl は述べました。「Prometheus チーム自身からの最新の開発状況を学び、Prometheus の大規模ユーザーと間近でつながる素晴らしいイベントになるでしょう。"

Prometheus 2.43 がリリースされ、いくつかのエキサイティングな機能と機能強化が導入されました。重要な改善点の1つは、ラベルに新しいデータ構造を使用する stringlabels リリースです。このブログ記事では、2.43 リリースと stringlabels 最適化に関するよくある質問にお答えします。

stringlabels リリースとは何ですか？

stringlabels リリースは、ラベルに新しいデータ構造を使用する Prometheus 2.43 バージョンです。すべてのラベル/値を1つの文字列に保存するため、ヒープサイズが小さくなり、ほとんどの場合で速度が向上します。これらの最適化はデフォルトのバイナリには含まれておらず、Go タグ stringlabels を使用して Prometheus をコンパイルする必要があります。

Bartek Płotkaは2019年からPrometheusメンテナーを務め、Red Hatのプリンシパルソフトウェアエンジニアです。CNCF Thanosプロジェクトの共同著者でもあります。CNCFアンバサダーであり、CNCF TAG Observabilityのテックリードでもあります。空いた時間には、O'Reillyから「Efficient Go」という本を執筆しています。意見は私自身のものです！

私が個人的に Prometheus プロジェクトで愛していること、そしてチームに参加した多くの理由の1つは、プロジェクトの目標にレーザーのように集中していることでした。Prometheus は常に、実用的で信頼性が高く、安価でありながら非常に貴重なメトリクスベースの監視を提供するために、限界を押し広げてきました。Prometheus の超安定かつ堅牢な API、クエリ言語、統合プロトコル（Remote Write やOpenMetricsなど）は、Cloud Native Computing Foundation (CNCF) メトリクスエコシステムがこれらの強力な基盤の上に成長することを可能にしました。その結果、素晴らしいことが起こりました。

• たとえば、コンテナ、eBPF、Minecraft サーバーの統計、さらにはガーデニングにおける植物の健康状態に関するメトリクスを取得するためのコミュニティエクスポーターがあります。
• 最近では、ほとんどの人が、Prometheus がスクレイピングできる HTTP/HTTPS の /metrics エンドポイントをクラウドネイティブソフトウェアに期待しています。これは、Google内で密かに開発され、Prometheus プロジェクトによって世界的に開拓されたコンセプトです。
• 可観測性のパラダイムが変化しました。SRE と開発者は最初からメトリクスに大きく依存するようになり、ソフトウェアの回復力、デバッグ可能性、データ駆動型意思決定が向上しました！

結局のところ、Prometheus が稼働していない Kubernetes クラスターはほとんど見かけません。

本日、Prometheus 監視分野における異なるプロジェクトやベンダー間の相互運用性を確保することを目的としたPrometheus 適合プログラムを開始します。法的な手続きはまだ最終決定されていませんが、テストを実行し、以下の結果を最初のラウンドと見なします。この発表の一環として、Julius Volz は PromQL テスト結果を更新しました。

簡単な注意喚起：このプログラムは Prometheus **適合 (Conformance)** と呼ばれ、ソフトウェアは特定のテストに**準拠 (compliant)** することができ、その結果として**互換性 (compatibility)** 評価が得られます。専門用語は複雑に見えるかもしれませんが、これによって終わりのない言葉の連鎖を使うことなくこのトピックについて話すことができます。

オスカー・ワイルドの言葉にもあるように、模倣は最大級の賛辞である。

"Prometheus" と "Thanos" という名前が、最近、あるランサムウェアグループに採用されました。これについて私たちにできることは、この状況をお知らせすることしかありません。あなたにも、これが起こっていることを認識すること以外にできることはあまりありません。

このグループが私たちのプロジェクトの偽のバイナリをダウンロードさせようと企むと信じる理由はありませんが、一般的なサプライチェーンおよびセキュリティ慣行に従うことをお勧めします。ソフトウェアを展開する際は、これらのメカニズムのいずれかを介して行ってください。

CNCFによる発表と私たち自身の発表の通り、Prometheus 適合プログラムを開始します。

テストを正式に実行する前にエコシステムの全体像を把握してもらうため、私たちはテストスイートの新しい仲間を紹介したいと思います。Prometheus のリモート書き込み適合テストスイートは、リモート書き込みプロトコルの送信側部分を私たちの仕様に対してテストします。

月曜日のPromConでは、Tom Wilkieが数週間前の記録時点でのテスト結果を発表しました。ライブセクションでは、すでにアップデートがありました。2日後にはさらに2つのアップデートがありました。オブザーバビリティパイプラインツール Vectorの追加と、既存システムの新しいバージョンです。

Prometheus は、クラウドネイティブ空間およびそれ以外のメトリクス監視の標準です。相互運用性を確保し、ユーザーを予期せぬ事態から保護し、より並列的なイノベーションを可能にするため、Prometheus プロジェクトは、CNCFの協力を得て、コンポーネントの適合性と Prometheus の互換性を認定するためのPrometheus 適合プログラムを導入します。

CNCF 理事会は、次の会議でプログラムを正式に審査し承認する予定です。この立ち上げ段階で、広範なコミュニティにテストの改善への協力を呼びかけます。

私たちの広範かつ拡大中のテストスイートの助けを借りて、プロジェクトやベンダーは、仕様への適合性と Prometheus エコシステム内での互換性を判断できます。

何かについて上位10個の時系列を選択したのに、10個ではなく100個も取得してしまった経験はありませんか？もしそうなら、この記事はあなた向けです。根本的な問題とその解決方法について説明します。

現在、topk() クエリは、正確に k 個の結果が得られる即時クエリとしてのみ意味がありますが、範囲クエリとして実行すると、各ステップが独立して評価されるため、k 個よりもはるかに多くの結果が得られる可能性があります。この @ 修飾子を使用すると、範囲クエリのすべてのステップでランキングを修正できます。

Prometheus v2.25.0 では、新しい PromQL 修飾子 @ を導入しました。offset 修飾子を使用すると、ベクトルセレクタ、範囲ベクトルセレクタ、およびサブクエリの評価を評価時間に対して固定期間だけオフセットできるのと同様に、@ 修飾子を使用すると、クエリ評価時間に関係なく、これらのセレクタの評価を固定できます。この構文はBjörn Rabensteinに帰属します。

<vector-selector> @ <timestamp>
<range-vector-selector> @ <timestamp>
<subquery> @ <timestamp>

<timestamp> は Unix タイムスタンプで、浮動小数点リテラルで記述されます。

私たちは常に、SemVer モデルに従い、安定性と破壊的変更に関して厳密な約束をしてきました。これは今後も変わりません。

実験にもっと大胆に取り組みたいと考えており、機能フラグをもっと活用する予定です。

v2.25.0 から、--enable-feature フラグの背後に隠された機能を持つ無効化された機能という新しいセクションを導入しました。今後のリリースで、このセクションにますます多くの機能が追加されることが予想されます。

このリストにある機能は実験的と見なされ、--enable-feature の背後にある限り、以下の考慮事項が適用されます。

1. 機能にAPI（Web API、コードインターフェースなど）がある場合、API仕様が変更される可能性があります。
2. 機能の動作が変更される可能性があります。
3. Prometheus についてあなたが持っていたかもしれないいくつかの仮定を破る可能性があります。
   • 例えば、クエリが評価時間の先をサンプルで参照しないという仮定は、@ 修飾子と負のオフセットによって破られます。
4. 不安定になる可能性もありますが、もちろん安定性を保つよう努力します。

新しい Prometheus バージョン 2.13.0 が利用可能になり、いつものように、多くの修正と改善が含まれています。こちらで変更点を確認できます。しかし、いくつかのプロジェクトやユーザーが待ち望んでいた機能があります。リモート読み取り API のチャンク化されたストリームバージョンです。

この記事では、リモートプロトコルで何が変更されたのか、なぜ変更されたのか、そしてそれを効果的に使用する方法について深く掘り下げて説明したいと思います。

リモート API

バージョン 1.x 以降、Prometheus はリモート API を使用してストレージと直接対話する機能を備えています。

このAPIは、サードパーティシステムが2つの方法でメトリクスデータと対話することを可能にします。

• 書き込み - Prometheus からプッシュされたサンプルを受け取る
• 読み取り - Prometheus からサンプルをプルする

どちらの方法もHTTPを使用し、メッセージはprotobufsでエンコードされています。両方の方法のリクエストとレスポンスはsnappyを使用して圧縮されています。

Prometheusユーザーへのインタビューシリーズを継続し、ForgeRockのLudovic Poitou氏が同社の監視の旅について語ります。

あなた自身とForgeRockの事業内容について教えていただけますか？

私は Ludovic Poitou です。ForgeRockのプロダクトマネジメントディレクターで、フランスのグルノーブル近郊に拠点を置いています。ForgeRock は国際的なアイデンティティ＆アクセス管理ソフトウェア企業で、従業員数は500人を超え、2010年にノルウェーで設立され、現在は米国のサンフランシスコに本社を置いています。お客様、従業員、デバイス、モノとのあらゆるオンラインインタラクションをセキュアにするソリューションを提供しています。金融会社から政府機関まで800を超えるお客様がいます。

Prometheus 以前の監視経験について教えていただけますか？

ForgeRock Identity Platform は常に監視インターフェースを提供してきました。しかし、このプラットフォームは4つの主要な製品で構成されており、それぞれ異なるオプションがありました。例えば、Directory Services 製品は SNMP、JMX、LDAP、あるいは最新バージョンでは HTTP 上の RESTful API を介して監視情報を提供していました。他の製品は REST または JMX しかありませんでした。その結果、プラットフォーム全体を監視することは複雑で、これらのプロトコルを統合できるツールが必要でした。

Prometheusユーザーへのインタビューシリーズを継続し、HostingerのDonatas Abraitis氏が同社の監視の旅について語ります。

あなた自身とHostingerの事業内容について教えていただけますか？

私は Hostinger のシステムエンジニア、Donatas Abraitis です。Hostinger はその名の通り、ホスティング会社です。2004年以来、000webhost.com プロジェクト（無料ウェブホスティングプロバイダ）を含め、約3000万のクライアントを抱えています。

Prometheus 以前の監視経験について教えていただけますか？

Hostinger がまだ小さな会社だった頃、オープンソースの監視ツールとしては Nagios、Cacti、Ganglia しか市場に存在しませんでした。これは若い人たちにフロッピーディスクドライブが何だったかを説明するようなものですが、Nagios と Cacti は今日も開発サイクルにあります。

自動化ツールは存在しませんでしたが。Bash + Perl がその役割を果たしていました。チームと自分自身をスケールアップしたいなら、自動化を無視してはいけません。自動化がなければ、人間による手作業が増えます。

当時、物理サーバーは約150台でした。それに比べて、今日までに仮想マシンと物理ボックスを含めて約2000台のサーバーがあります。

ネットワーキング機器の場合、SNMP は依然として広く使用されています。「ホワイトボックス」スイッチの台頭により、通常のツールをインストールできるため、SNMP は必要性が低くなっています。

SNMP の代わりに、スイッチ内で _node_exporter_ やその他のエクスポーターを実行して、必要なメトリクスを人間が読める形式で公開することができます。美しい方が醜いより良いですよね？

私たちは CumulusOS を使用していますが、この場合ほとんどが x86 なので、どんな種類の Linux ソフトウェアを実行しても全く問題ありません。

はじめに

タイトルが示唆するように、サブクエリはクエリの一部であり、以前は不可能だったクエリ内で範囲クエリを実行することができます。これは長らく要望されてきた機能でした。prometheus/prometheus/1227。

サブクエリサポートのプルリクエストは最近 Prometheus にマージされ、Prometheus 2.7 で利用可能になります。以下で詳細を見ていきましょう。

モチベーション

rate を低い解像度/範囲 (例: 5m) で使用して問題を特定し、このデータを高い範囲 (例: 1h の max_over_time) で集計したい場合があります。

以前は、単一の PromQL クエリでは上記は不可能でした。アラートルールやグラフのためにクエリで範囲選択をしたい場合、そのクエリに基づいたレコーディングルールを作成し、そのレコーディングルールによって作成されたメトリクスに対して範囲選択を実行する必要がありました。例: max_over_time(rate(my_counter_total[5m])[1h])。

数日または数週間にわたるデータに対して迅速な結果を求める場合、レコーディングルールに十分なデータが蓄積されるまで待つのはかなりの時間になります。レコーディングルールを追加するのを忘れると、イライラすることもあります。そして、クエリの各ステップに対してレコーディングルールを作成するのは面倒でしょう。

サブクエリのサポートにより、すべての待機とフラストレーションが解消されます。

Prometheusユーザーへのインタビューシリーズを継続し、PresslabsのMile Rosu氏が同社の監視の旅について語ります。

あなた自身とPresslabsの事業内容について教えていただけますか？

Presslabsは、出版社、エンタープライズブランド、デジタルエージェンシーを対象とした、高性能なマネージドWordPressホスティングプラットフォームであり、常にウェブサイト訪問者にシームレスな体験を提供することを目指しています。

最近、私たちはコア製品である WordPress Business Intelligence に革新的なコンポーネントを開発しました。ユーザーは、包括的なダッシュボードでリアルタイムで実用的なデータを取得できるようになり、短い課題解決から展開までのプロセスとサイトの継続的な改善をサポートします。

私たちは、要求の厳しい顧客向けのマネージド WordPress ホスティングに完全に特化した100台のマシンで、月間最大20億ページビューのシームレスな配信をサポートしています。

私たちは現在、世界中の WordPress パブリッシャーに最高の体験を提供するというミッションに取り組んでいます。この旅において、Kubernetes は、高可用性 WordPress ホスティングインフラストラクチャにおける今後の標準への道筋を促進しています。

本日、Prometheus がCNCFの卒業プロジェクトとなったことを発表できることを嬉しく思います。

Prometheus は、この階層に到達した史上2番目のプロジェクトです。Prometheus を卒業させることで、CNCF は私たちのコードと機能の速度、成熟度と安定性、ガバナンスとコミュニティプロセスに自信を持っていることを示しています。これは、監視ツールの選択に関する内部議論において、品質の外部検証としても機能します。

インキュベーションレベルに達して以来、多くのことが起こりました。その中でも特に際立っているものをいくつか挙げます。

• サービスにおける高い churn をサポートするため、ストレージバックエンドを完全に書き換えました。
• 特に 2.3.2 で、安定性向上に大きく取り組みました。
• Prometheus の導入とコミュニティへの参加を容易にすることに重点を置いたドキュメント作成を開始しました。

Prometheus には、Consul、Kubernetes、Azure などのパブリッククラウドプロバイダーなど、多くのサービスディスカバリ (SD) システムの組み込み統合が含まれています。しかし、すべての SD オプションの統合実装を提供することはできません。Prometheus チームは、現在の SD 統合セットのサポートで手一杯であり、すべての可能な SD オプションの統合を維持することは現実的ではありません。多くの場合、現在の SD 実装はチーム外の人物によって貢献されており、その後適切に維持またはテストされていません。私たちは、維持可能であり、意図どおりに機能することがわかっているサービスディスカバリメカニズムとの直接統合のみを提供することを約束したいと考えています。このため、現在、新しい SD 統合については一時停止しています。

しかし、Docker Swarm のような他の SD メカニズムと統合したいという要望がまだあることも承知しています。最近、Prometheus リポジトリ内のドキュメントディレクトリに、メインの Prometheus バイナリにマージすることなくカスタムサービスディスカバリ統合を実装するための小さなコード変更と例がコミットされました。このコード変更により、内部の Discovery Manager コードを利用して、新しい SD メカニズムと対話し、Prometheus の file_sd と互換性のあるファイルを出力する別の実行可能ファイルを記述できます。Prometheus と新しい実行可能ファイルを共存させることで、Prometheus が実行可能ファイルの file_sd 互換出力を読み取り、そのサービスディスカバリメカニズムからターゲットをスクレイピングするように設定できます。将来的には、これにより SD 統合をメインの Prometheus バイナリから移動できるだけでなく、アダプターを利用する安定した SD 統合を Prometheus discoveryパッケージに移動することも可能になります。

アダプターコードで実装されているものなど、file_sd を使用する統合はこちらにリストされています。

例のコードを見てみましょう。

Prometheus ユーザーへのインタビューシリーズを継続し、Datawire の Richard Li が Prometheus への移行について語ります。

あなた自身と Datawire の事業内容について教えていただけますか？

Datawireでは、Kubernetes上で開発者がより速くコーディングできるように支援するオープンソースツールを作成しています。私たちのプロジェクトには、Kubernetesサービスのローカル開発用のTelepresence、Envoy Proxy上に構築されたKubernetesネイティブAPIゲートウェイのAmbassador、そしてビルド/デプロイシステムであるForgeがあります。

私たちはオープンソースの取り組みをサポートするために、AWS の Kubernetes でいくつかのミッションクリティカルなクラウドサービスを運用しています。これらのサービスは、自動テストインフラストラクチャで使用される数十の Kubernetes クラスターを毎日動的にプロビジョニングするなどのユースケースをサポートしています。

Prometheus 以前の監視経験について教えていただけますか？

AWS CloudWatch を使用していましたが、セットアップは簡単でした。しかし、分散開発モデル (マイクロサービス) を採用するにつれて、より柔軟性と制御が必要であることがわかりました。例えば、各チームが運用上の助けを必要とせずに、必要に応じて監視をカスタマイズできることを望んでいました。

Prometheus ユーザーへのインタビューシリーズを継続し、Scalefastr の Kevin Burton 氏が Prometheus の利用状況について語ります。

あなた自身と Scalefastr の事業内容について教えていただけますか？

私は Kevin Burton、ScalefastrのCEOです。私は分散システムを専門としており、以前はペタバイト規模の分散ソーシャルメディアクローラーと検索エンジンを構築した Datastreamer という会社を経営していました。

Datastreamer では、インフラストラクチャに関するスケーラビリティの問題に直面し、Debian、Elasticsearch、Cassandra、Kubernetes に基づく高性能クラスターを構築しました。

多くのお客様がインフラストラクチャで苦労していることを知り、AWS や Google Cloud で大量のコンテンツをホスティングするために支払っている金額に驚きました。

私たちはクラウドで運用するコストを継続的に評価し、私たちの場合、ホスティング費用は現在の約5〜10倍になるだろうと判断しました。

私たちは、Kubernetes、Prometheus、Elasticsearch、Cassandra、Grafana、Etcd などのオープンソースおよびクラウドネイティブ技術に基づいた新しいクラウドプラットフォームを立ち上げることを決定しました。

現在、ペタバイト規模の顧客を数社ホスティングしており、今月中に新しいプラットフォームをソフトローンチする予定です。

12月6日水曜日は CloudNativeCon Austin での Prometheus Day です。素晴らしい講演やイベントが盛りだくさんです。Prometheus サロンでは Kubernetes の監視に関する実践的なアドバイスを受けたり、Prometheus の様々な側面に関する一連の講演に参加したり、CNCF ブースで Prometheus 開発者たちと交流したりできます。そして、Prometheus Happy Hour が続きます。詳細はこちらをご覧ください...

およそ1年半前、私たちは Prometheus 1.0 をリリースしました。このリリースはプロジェクトにとって重要なマイルストーンとなりました。Prometheus のシンプルでありながら非常に強力な監視哲学を構成する幅広い機能セットに到達しました。

それ以来、さまざまなサービスディスカバリ統合の追加と改善、PromQL の拡張、そしてプラグイン可能な長期ストレージソリューションを可能にするリモート API の最初の反復での実験を行ってきました。

しかし、新しいメジャーリリースに値するほど他に何が変わったのでしょうか？

何が起こったか

2週間前、世界中の Prometheus ユーザーと開発者がミュンヘンに集まり、Prometheus 監視システムに関する2回目の会議であるPromCon 2017が開催されました。このイベントの目的は、Prometheus を使用した監視に関する知識とベストプラクティスを交換し、専門的なつながりを築くことでした。今年は Google のミュンヘンオフィスがより広いスペースを提供してくれたおかげで、参加者数を80人から220人に増やし、それでも満員御礼となりました！

イベントの様子をまとめたビデオをご覧ください。

本日、Prometheus 2.0 の3番目のアルファ版をリリースしました。新しいストレージレイヤーにおける様々なバグ修正に加え、いくつかの計画された破壊的変更が含まれています。

フラグの変更

まず、新しいフラグライブラリに移行しました。これは、Prometheus がこれまで使用していた単一のダッシュ - プレフィックスではなく、より一般的な二重ダッシュ -- プレフィックスをフラグに使用します。展開はそれに応じて調整する必要があります。さらに、このアルファ版でいくつかのフラグが削除されました。Prometheus 1.0.0 以降の全リストは次のとおりです。

• web.telemetry-path
• すべての storage.remote.* フラグ
• すべての storage.local.* フラグ
• query.staleness-delta
• alertmanager.url

Prometheusユーザーへのインタビューシリーズを続行し、L’Atelier AnimationのPhilippe Panaite氏とBarthelemy Stevens氏が、アニメーションスタジオをNagios、Graphite、InfluxDBの組み合わせからPrometheusに切り替えた経緯について語ります。

あなたとL’Atelier Animationが何をしているか教えていただけますか？

L’Atelier Animation は、カナダの美しい都市モントリオールを拠点とする3Dアニメーションスタジオです。私たちの最初の長編映画「バレリーナ」（「Leap」としても知られる）は、2017年に世界中で公開され、米国では今年後半に公開予定です。

私たちは現在、アニメーションTVシリーズと2作目の長編映画に精力的に取り組んでいます。当社のインフラは、約300台のレンダーブレード、150台のワークステーション、20台の各種サーバーで構成されています。数台のMacを除いて、すべてLinux（CentOS）で動作しており、Windowsマシンは一台もありません。

Prometheusユーザーへのインタビューシリーズを続け、iAdvizeのLaurent COMMARIEU氏が、従来のNagiosおよびCentreonの監視をPrometheusに置き換えた経緯について語ります。

iAdvizeが何をしているか教えていただけますか？

私はiAdvizeのシステムエンジニア、ローラン・コマリエウです。60人規模のR&D部門で、5人のシステムエンジニアチームの一員として働いています。私たちの主な仕事は、アプリケーション、サービス、および基盤となるシステムが稼働していることを確認することです。開発者と協力して、コードが本番環境に最も簡単に到達できるようにし、すべての段階で必要なフィードバックを提供しています。これが監視が重要である理由です。

iAdvizeは、フルスタックの会話型コマースプラットフォームです。ブランドが、コミュニケーションチャネル（チャット、通話、ビデオ、Facebookページ、Facebook Messenger、Twitter、Instagram、WhatsApp、SMSなど）に関係なく、顧客と一元的に簡単にやり取りできるようにします。当社の顧客は、40カ国のEコマース、銀行、旅行、ファッションなどで事業を展開しています。フランス、英国、ドイツ、スペイン、イタリアにオフィスを構える200人規模の国際企業です。2015年には1600万ドルを調達しました。

2016年7月、Prometheusは1.0リリースという大きなマイルストーンに到達しました。それ以来、新しいサービスディスカバリ統合や実験的なリモートAPIなど、多くの新機能が追加されました。また、インフラストラクチャ分野の新しい開発、特にKubernetesにより、監視対象環境が著しく動的になることを認識しました。当然のことながら、これはPrometheusに新たな課題をもたらし、ストレージ層にパフォーマンスのボトルネックを特定しました。

ここ数ヶ月、私たちはこれらのボトルネックに対処し、全体的なパフォーマンスを大幅に改善する新しいストレージコンセプトを設計し、実装してきました。また、ホットバックアップなどの機能を追加する道も開かれます。

変更は非常に根本的なものであるため、新しいメジャーリリースであるPrometheus 2.0が発行されます。ストレージ以外の重要な機能と変更は、安定版リリース前に計画されています。しかし、本日、新しいストレージの安定化プロセスを開始するために、Prometheus 2.0の初期アルファ版をリリースします。

Prometheusユーザーへのインタビューシリーズを続け、EuropaceのTobias Gesellchen氏が、Prometheusを発見した経緯について語ります。

Europaceが何をしているか教えていただけますか？

Europace AG は、ドイツ最大の住宅ローン、住宅金融商品、個人ローン向けのウェブベースの金融マーケットプレイスEUROPACEを開発および運営しています。完全に統合されたシステムは、約400のパートナー（銀行、保険会社、金融商品販売業者）を結び付けています。毎月数千人のユーザーが、EUROPACEで合計最大40億ユーロ相当の約35,000件の取引を実行しています。当社のエンジニアは、http://tech.europace.de/ と @EuropaceTech で定期的にブログを投稿しています。

Prometheusユーザーへのインタビューシリーズを続け、WeaveworksのTom Wilkie氏が、Prometheusを選択し、現在それを基盤として構築している経緯について語ります。

Weaveworksについて教えていただけますか？

Weaveworks は、オープンソースプロジェクトとサービスとしてのソフトウェアの組み合わせによってマイクロサービスを「運用可能にする」サービス、Weave Cloud を提供しています。

Weave Cloud は以下で構成されています。

• Weave Scope を使用した視覚化
• Weave Flux を使用した継続的デプロイメント
• コンテナSDNであるWeave Net によるネットワーク
• オープンソースの分散型Prometheus-as-a-ServiceであるWeave Cortex を使用した監視。

Weave Cloud は 60日間無料 で試すことができます。製品の最新情報については、当社のブログ、Twitter、またはSlack （招待）をご確認ください。

Prometheusユーザーへのインタビューシリーズを続け、CanonicalがPrometheusへの移行について語ります。

あなたとCanonicalが何をしているか教えていただけますか？

Canonical は、おそらくUbuntu Linuxを支援する企業として最もよく知られています。また、MAAS、Juju、OpenStackなど、他の多くのオープンソースプロジェクトを開発または貢献し、これらの製品の商用サポートを提供しています。Ubuntuは、OpenStackデプロイメントの大部分を支えており、本番環境のクラウドの55%、大規模なクラウドデプロイメントの58% を占めています。

私のグループであるBootStackは、当社の完全マネージドプライベートクラウドサービスです。私たちはCanonicalのお客様向けにOpenStackクラウドを構築および運用しています。

Prometheusユーザーへのインタビューシリーズを続け、JustWatchが監視を確立した経緯について語ります。

あなたとJustWatchが何をしているか教えていただけますか？

消費者向けに、JustWatch は、映画やテレビ番組をオンラインや劇場で合法的に視聴できる場所を見つけるのに役立つストリーミング検索エンジンです。17カ国で、Netflix、HBO、Amazon Video、iTunes、Google Playなど、すべての主要なストリーミングプロバイダーの映画コンテンツを検索できます。

映画スタジオやビデオオンデマンドプロバイダーなどのクライアント向けに、当社は国際的な映画マーケティング会社として、消費者向けアプリから世界中のファンの購入行動や映画の好みに関する匿名データを収集しています。スタジオが適切な視聴者にコンテンツを宣伝し、デジタルビデオ広告の無駄なカバレッジを最小限に抑えることで、デジタルビデオ広告を大幅に効率化できるよう支援しています。

Prometheusユーザーへのインタビューシリーズを続け、ComposeがGraphiteとInfluxDBからPrometheusへの監視の旅について語ります。

あなたとComposeが何をしているか教えていただけますか？

Compose は、世界中の開発者に本番環境対応のデータベースクラスターをサービスとして提供しています。アプリ開発者は、数回のクリックで、マルチホスト、高可用性、自動バックアップ、セキュアなデータベースを数分で準備できます。これらのデータベースデプロイメントは、需要の増加に応じて自動的にスケールアップするため、開発者はデータベースの実行ではなく、優れたアプリの構築に時間を費やすことができます。

当社は、AWS、Google Cloud Platform、SoftLayerのそれぞれにおいて、少なくとも2つのリージョンに数十のホストクラスターを持っています。各クラスターは、サポートされている場合はアベイラビリティゾーンにまたがり、独自のプライベートネットワークに約1000の高可用性データベースデプロイメントを格納しています。さらに多くのリージョンとプロバイダーが計画中です。

Prometheusユーザーへのインタビューシリーズの次回は、DigitalOceanがPrometheusをどのように使用しているかについて語ります。Carlos Amedee氏も、PromCon 2016でロールアウトの社会的側面について語っています。

あなたとDigitalOceanが何をしているか教えていただけますか？

私の名前はイアン・ハンセンで、プラットフォームメトリックチームで働いています。DigitalOcean はシンプルなクラウドコンピューティングを提供しています。これまでに13のリージョンで2000万のDroplet（SSDクラウドサーバー）を作成しました。最近、新しいブロックストレージ製品もリリースしました。

Prometheusユーザーへのインタビューシリーズを続け、ShuttleCloudがPrometheusの使用を開始した経緯について語ります。ShuttleCloudのIgnacio氏も、PromCon 2016でPrometheusが小規模なスタートアップにとって良い理由について説明しました。

ShuttleCloudは何をしていますか？

ShuttleCloudは、世界で最も拡張性の高いメールと連絡先のデータインポートシステムです。GoogleやComcastなどの主要なメールおよびアドレス帳プロバイダーが、データインポートを通じて切り替えエクスペリエンスを自動化することで、ユーザーの増加とエンゲージメントを向上させるのに役立っています。

当社のお客様は、当社のAPIを自社のサービスに統合することで、ユーザーがメールと連絡先を参加プロバイダー間で簡単に移行できるようにし、新しいプロバイダーに切り替える際にユーザーが直面する摩擦を軽減しています。サポートされている24時間365日のメールプロバイダーには、Comcast、Time Warner Cable、AT&T、Verizonなど、すべての主要な米国のインターネットサービスプロバイダーが含まれます。

エンドユーザーにメール移行のシンプルな経路を提供することで（インポートツールのUIを完全に制御できるようにしながら）、お客様はユーザーのアクティベーションとオンボーディングを劇的に改善しています。

何が起こったか

先週、世界中の80人のPrometheusユーザーと開発者がベルリンに集まり、Prometheus監視システムに関する史上初のカンファレンスであるPromCon 2016が2日間にわたって開催されました。このカンファレンスの目的は、Prometheusの使用によって得られた知識、ベストプラクティス、経験を共有することでした。また、コミュニティを成長させ、サービス監視に関する専門的なつながりを築く手助けをしたいと考えていました。以下に、初日の朝の様子をいくつかご紹介します。

特に根強い誤解について話しましょう。監視システムとPrometheusのプルベースのメトリック収集アプローチに関する議論があるたびに、誰かが「プルベースのアプローチは根本的にスケーリングしない」と必ず口を挟みます。与えられる理由はしばしば曖昧であるか、Prometheusとは根本的に異なるシステムにのみ当てはまります。実際、プルベースの監視を最大規模で扱ってきた経験からすると、この主張は私たちの運用経験に反しています。

「なぜPrometheusはプッシュではなくプルを選択するのか」というFAQエントリはすでにありますが、スケーリングの側面に特に焦点を当てていません。この主張に関する一般的な誤解を詳しく見て、それらがPrometheusに適用されるかどうか、どのように適用されるかを分析しましょう。

1月、私たちはPrometheusの公開後最初の1年に関するブログ記事を公開し、私たちにとって素晴らしい旅であり、皆さまにとっては革新的で有用な監視ソリューションとなることを願っている内容をまとめました。それ以来、PrometheusはCloud Native Computing Foundationにも参加し、Kubernetesに続く2番目のチャータープロジェクトとして、良い仲間と共に活動しています。

最近の私たちの取り組みは、Prometheusのバージョン1.0を境に、安定したAPIとユーザーインターフェースを提供することに集中してきました。この目標を達成し、Prometheus 1.0が本日利用可能になったことを発表できることを嬉しく思います。

1.0はあなたにとって何を意味しますか？

もしPrometheusをしばらく使っているなら、過去1年間で破壊的な変更の頻度と影響が大幅に減少したことに気づいているかもしれません。同様に、1.0への到達は、それ以降の1.xリリースがAPI安定性を維持することを意味します。アップグレードによってPrometheus API上に構築されたプログラムが壊れることはなく、更新によってストレージの再初期化やデプロイメントの変更が必要になることもありません。カスタムダッシュボードやアラートも1.xバージョンアップグレード後もそのまま維持されます。Prometheus 1.0は堅牢な監視ソリューションであると確信しています。Prometheusサーバーが安定したAPI状態に達した今、他のモジュールも徐々に独自の安定版バージョン1.0リリースに到達するでしょう。

Prometheusの構想以来、私たちはプロジェクトのために、いかなる単一企業にも依存しない持続可能なガバナンスモデルを模索してきました。最近、私たちは、Google、CoreOS、Docker、Weaveworks、Mesosphere、およびその他の主要なインフラ企業に支援されている、新設されたCloud Native Computing Foundation（CNCF）と協議を重ねてきました。

本日、CNCFの技術監督委員会が、Kubernetesに次ぐ2番目のホストプロジェクトとしてPrometheusを受け入れることを満場一致で決定したことを発表できることを嬉しく思います！これらの計画に関する詳細は、CNCFによる公式プレスリリースでご覧いただけます。

Prometheusサーバーに組み込まれた時系列データベース（TSDB）は、各時系列の生データサンプルを、1024バイトの固定サイズのチャンクで整理します。生データサンプルに加えて、チャンクにはいくつかのメタデータが含まれており、各チャンクに異なるエンコーディングを選択できます。最も基本的な区別はエンコーディングバージョンです。新しいチャンクのバージョンは、コマンドラインフラグ-storage.local.chunk-encoding-versionで選択します。これまでは、元のデルタエンコーディング用の0と、改良されたダブルデルタエンコーディング用の1の2つのバージョンのみがサポートされていました。リリース0.18.0から、バージョン2を追加しました。これは、チャンク内のサンプルごとに可変ビット幅を伴うため、可変ビットエンコーディングと呼びます。バージョン1はほぼすべての側面でバージョン0よりも優れていますが、バージョン1と2の間には真のトレードオフがあります。このブログ記事は、その決定を下すのに役立ちます。バージョン1はデフォルトのエンコーディングのままですので、この記事を読んでバージョン2を試したい場合は、コマンドラインフラグで明示的に選択する必要があります。切り替えを行っても害はありませんが、既存のチャンクは作成された後でエンコーディングバージョンを変更しないことに注意してください。ただし、これらのチャンクは設定された保持期間に従って徐々に廃止され、コマンドラインフラグで指定されたエンコーディングを持つチャンクに置き換えられます。

これはPrometheusユーザーへのインタビューシリーズの第2回で、Prometheusの評価と使用経験を共有するものです。

あなたとShowMaxが何をしているか教えていただけますか？

私はアントニン・クラルです。ShowMax の研究とアーキテクチャを統括しています。その前は、過去12年間、アーキテクチャおよびCTOの役職を務めていました。

ShowMaxは、2015年に南アフリカで開始されたサブスクリプションビデオオンデマンドサービスです。20,000エピソード以上のテレビ番組や映画を含む豊富なコンテンツカタログを保有しています。現在、当社のサービスは世界65カ国で利用可能です。競合他社がアメリカやヨーロッパで小競り合いをしている中、ShowMaxはより困難な問題に取り組んでいます。サハラ以南のアフリカのほとんどインターネットに接続されていない村で、どうやって一気に動画を見るのでしょうか？世界の動画の35%はすでにストリーミングされていますが、まだ革命に触れていない場所がたくさんあります。

私たちは約50のサービスを管理しており、そのほとんどはCoreOSを中心に構築されたプライベートクラスター上で動作しています。これらは主にクライアント（Android、iOS、AppleTV、JavaScript、Samsung TV、LG TVなど）からのAPIリクエストを処理しますが、一部は内部的に使用されます。最大の内部パイプラインの1つはビデオエンコーディングで、大量の取り込みバッチを処理する際に400台以上の物理サーバーを占有する場合があります。

当社のバックエンドサービスの大部分はRuby、Go、またはPythonで書かれています。Rubyでアプリケーションを記述する際にはEventMachineを使用しています（MRIではGoliath、JRubyではPuma）。Goは通常、大量のスループットを必要とし、ビジネスロジックがあまりないアプリケーションで使用されます。Pythonで書かれたサービスではFalconに非常に満足しています。データはPostgreSQLとElasticSearchクラスターに保存されています。リクエストルーティングのためにVarnishを設定するには、etcdとカスタムツールを使用しています。

これはPrometheusユーザーへのインタビューシリーズの第1回で、Prometheusの評価と使用経験を共有するものです。最初のインタビューは、Life360のDaniel氏です。

あなたとLife360が何をしているか教えていただけますか？

私はDaniel Ben Yosef、別名dbyです。Life360 のインフラストラクチャエンジニアで、その前は過去9年間システムエンジニアの役割を務めてきました。

Life360は、家族が繋がり続けるのを助けるテクノロジーを開発しており、家族向けのファミリーネットワークアプリです。これらの家族の対応に非常に忙しく、ピーク時には7000万の登録家族に対して毎分70万のリクエストを処理しています。

本番環境で約20のサービスを管理しており、主にモバイルクライアント（Android、iOS、Windows Phone）からの位置情報リクエストを処理し、ピーク時には150以上のインスタンスにまたがっています。冗長性と高可用性が私たちの目標であり、家族が利用できると私たちを信頼しているため、可能な限り100%の稼働時間を維持するよう努めています。

ユーザーデータは、MySQLマルチマスタクラスタと、常時約4TBのデータを保持する12ノードのCassandraリングの両方に保持しています。Go、Python、PHPで書かれたサービスがあり、スタックにJavaを導入する計画もあります。サービスディスカバリにはConsulを使用しており、もちろんPrometheusのセットアップもそれに統合されています。

AlertmanagerはPrometheusサーバーから送信されたアラートを処理し、それらのラベルに基づいてさまざまな受信者に通知を送信します。

受信者は、PagerDuty、Slack、メール、または汎用Webhookインターフェースを介したカスタム統合（例：JIRA）など、さまざまな統合のいずれかになります。

テンプレート

受信者に送信されるメッセージはテンプレートによって作成されます。Alertmanagerにはデフォルトのテンプレートが付属していますが、カスタムテンプレートを定義することもできます。

このブログ記事では、Slack通知の簡単なカスタマイズについて説明します。

すべての警告をSlackに送信する、このシンプルなAlertmanager設定を使用します。

global:
  slack_api_url: '<slack_webhook_url>'

route:
  receiver: 'slack-notifications'
  # All alerts in a notification have the same value for these labels.
  group_by: [alertname, datacenter, app]

receivers:
- name: 'slack-notifications'
  slack_configs:
  - channel: '#alerts'

デフォルトでは、Alertmanagerから送信されるSlackメッセージは次のようになります。

それは、1つの発火しているアラートがあり、それに続いてアラートグループ化のラベル値（alertname、datacenter、app）、そしてアラートが共通して持っているさらなるラベル値（critical）が続くことを示しています。

始まり

1年前の今日、私たちはPrometheusを世界に向けて正式に発表しました。これは、プロジェクトにそれ以来起こった素晴らしい出来事を振り返り、共有する絶好の機会です。しかし、まず最初に、始まりから始めましょう。

2012年にはすでにGitHubでPrometheusをオープンソースプロジェクトとして開始していましたが、当初はそれについて公表しませんでした。摩擦なく実験できる時間を与え、プロジェクトが成熟するのを待っていたのです。Prometheusは2013年にSoundCloudで本番監視に段階的に導入され、その後社内でますます利用されるようになり、2014年にはDockerやBoxeverの仲間にも早期に採用されました。長年にわたり、Prometheusはますます成熟し、人々の監視問題を解決していましたが、まだ一般には知られていませんでした。

前回の投稿で、Prometheusにおけるサービスディスカバリの新しい方法を多数紹介しました。それ以来、多くのことが起こりました。内部実装を改善し、コミュニティからKubernetesとMarathonでのサービスディスカバリをサポートする素晴らしい貢献を受けました。これらはバージョン0.16のリリースで利用可能になります。

また、カスタムサービスディスカバリについても触れました。

すべてのタイプのサービスディスカバリが、Prometheusに直接含めるのに十分なほど汎用的であるわけではありません。おそらく、あなたの組織には独自のシステムがあり、それをPrometheusで動作させる必要があります。これは、新しい監視ターゲットを自動的に検出する利点を享受できないという意味ではありません。

この投稿では、高度に一貫性のある分散型キーバリューストアであるetcdに基づいたカスタムサービスディスカバリのアプローチをPrometheusに接続する小さなユーティリティプログラムを実装します。

編集者注：この記事は、Prometheusユーザーによって書かれた寄稿記事です。

数万人の要求の厳しいゲーマーのためにネットワークを運用している場合、ネットワークの内部で何が起こっているかを真に知る必要があります。さらに、すべてをわずか5日間でゼロから構築する必要があります。

DreamHack について聞いたことがない方のために、以下がその説明です。2万人を集めて、そのほとんどに自分のコンピューターを持参させます。プロのゲーム（eスポーツ）、プログラミングコンテスト、ライブ音楽コンサートを混ぜ合わせます。その結果、デジタルに関するすべてに特化した世界最大のフェスティバルが誕生します。

このようなイベントを実現するには、多くのインフラストラクチャを整備する必要があります。この規模の通常のインフラストラクチャは、構築に数か月かかりますが、DreamHackのチームはわずか5日間ですべてをゼロから構築します。もちろん、これにはネットワークスイッチの設定などの作業も含まれますが、電力配線の構築、食品や飲料の店舗の設置、さらには実際のテーブルの構築も含まれます。

ネットワークに関連するすべてを構築および運用するチームは、公式にはネットワークチームと呼ばれていますが、私たちは通常、自分たちをtechまたはdhtechと呼んでいます。この投稿では、dhtechの仕事と、DreamHack Summer 2015でPrometheusをどのように使用して監視をさらに強化しようとしたかについて焦点を当てます。

ジョン・オールスパスは、彼の監視・メトリクス・アラート企業への公開書簡の中で、「異常を適切なタイミングで完璧に検出することは不可能である」と断言しています。

時系列データに基づいて問題を自動的に検出・診断するシステムを、才能あるエンジニアがいくつか構築しようとしているのを見てきました。デモンストレーションを機能させることは確かに可能ですが、データは常にノイズが多すぎて、最も単純な現実世界のシステム以外ではこのアプローチは機能しませんでした。

しかし、希望は失われていません。カスタム構築されたルールで検出および処理できる多くの一般的な異常があります。Prometheusのクエリ言語は、誤検知を回避しながらこれらの異常を発見するためのツールを提供します。

今週、Prometheus v0.14.0をリリースしました。これは、長らく待ち望まれていた多くの追加機能と改善が盛り込まれたバージョンです。

ユーザー側では、Prometheusは新しいサービスディスカバリメカニズムをサポートするようになりました。DNS-SRVレコードに加えて、箱から出してすぐにConsulをサポートし、ファイルベースのインターフェースにより、独自のディスカバリメカニズムを接続できるようになりました。将来的には、他の一般的なサービスディスカバリメカニズムをPrometheusに追加する予定です。

多くの小さな修正と改善に加えて、PrometheusプロセスにSIGHUPを送信することで、実行時に設定をリロードできるようになりました。変更の完全なリストについては、このリリースの変更ログを確認してください。

このブログ記事では、組み込みのサービスディスカバリメカニズムを詳しく見て、いくつかの実用的な例を提供します。追加資料として、Prometheusの設定ドキュメントをご覧ください。

Prometheusバージョン0.10.0を公開発表してから約3ヶ月が経過し、現在はバージョン0.13.1となっています。

SoundCloudの発表ブログ記事は、Prometheusの主要コンポーネントの最良の概要を提供していますが、Prometheusに関する他の多くのオンライン活動がありました。この投稿では、見逃した情報をすべて確認できます。

今後、このブログでは、Prometheusを最大限に活用するためのより多くの記事や発表を公開していきます。