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

黎明期

私がYACEを始めた当初、これがこのような規模に成長するとは全く予想していませんでした。当時、私はワークフォース管理ソフトウェアに特化した会社である Invision AG（デザインアプリとは異なります）で働いていました。彼らはこのツールをオープンソース化することを全面的に支援してくれ、チームメイトの Kai Forsthövelの助けもあって、YACEは誕生しました。

最初のコミットは2018年で、CloudWatchメトリクスを簡単にスケーリングし、測定すべきものを自動検出できるようにしつつ、ユーザーエクスペリエンスをシンプルで直感的に保つことを主な目標の1つとしていました。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が双方向で互いをサポートするようにしてきました。これにより、両システム間の変換に関する公式仕様の作成、およびPrometheusメトリクスをOpenTelemetry Collectorに、またはその逆にインポートできる実装が実現しました。

それ以来、私たちは OpenTelemetryユーザーがメトリクスをPrometheusに保存する際の課題 を理解するために多大な時間を費やし、それに基づいて それらをどのように解決できるかを検討してきました。提案された変更の一部は、プッシュとプル両方のサポートなど、どちらかの側の動作保証を壊さないように注意深い検討が必要です。PromCon Berlin 2023では、トークの1つでアイデアをまとめることを試みました。

ベルリンでのデブサミットでは、これらの変更とOpenTelemetryに対する一般的なスタンスについて詳細に議論し、大方の合意は「OpenTelemetryメトリクスのデフォルトストアになりたい」というものでした！

このイニシアチブを主導するコア開発者グループを結成し、OTelサポートを主要機能の一つとして2024年に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がリリースされ、エキサイティングな機能と改善がもたらされました。中でも重要な改善の一つは、新しいデータ構造でラベルを使用する `stringlabels` リリースです。このブログ記事では、2.43リリースと `stringlabels` 最適化に関するよくある質問に答えます。

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

`stringlabels` リリースは、新しいデータ構造でラベルを使用するPrometheus 2.43のバージョンです。すべてのラベル/値を単一の文字列として保存するため、ヒープサイズが小さくなり、ほとんどの場合で速度が向上します。これらの最適化はデフォルトのバイナリには含まれておらず、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サーバー統計、さらにはガーデニングにおける植物の健康状態まで。
• 今日、ほとんどの人はクラウドネイティブソフトウェアにHTTP/HTTPSの `/metrics` エンドポイントがあり、Prometheusがスクレイピングできることを期待しています。これはGoogle内で秘密裏に開発され、Prometheusプロジェクトによって世界的に普及した概念です。
• オブザーバビリティのパラダイムが変化しました。SREや開発者が最初からメトリクスに大きく依存しており、ソフトウェアの回復力、デバッグ可能性、データ駆動型の意思決定を向上させていることがわかります！

結局、Prometheusが動作していないKubernetesクラスターを見ることはほとんどありません。

本日、Prometheus監視スペースにおけるさまざまなプロジェクトとベンダー間の相互運用性を確保することを目的とした Prometheus Conformance Program を開始します。法的な書類はまだ最終化されていませんが、テストを実行した結果、これを第1回結果とみなしています。このローンチの一環として、Julius VolzがPromQLテスト結果を更新しました。

簡単なリマインダーとして、このプログラムはPrometheus **Conformance**と呼ばれ、ソフトウェアは特定のテストに**準拠**でき、それが**互換性**評価につながります。この名称は複雑に思えるかもしれませんが、これにより多くの言葉を使わずにこのトピックについて話すことができます。

オスカー・ワイルドによれば、模倣は称賛の最も誠実な形です。

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

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

CNCFによる発表および私たち自身による発表で、Prometheus準拠プログラムを開始します。

公式テストを実行する前に、エコシステムがどのような状況にあるかの概要を皆さんに提供するために、テストスイートの新しい仲間を紹介したいと思います：Prometheus Remote Write 準拠テストスイートは、Sender part of the Remote Write protocol を私たちの仕様に対してテストします。

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

Prometheusは、クラウドネイティブ分野およびそれ以降のメトリクス監視の標準です。相互運用性を確保し、ユーザーを予期せぬ事態から保護し、より多くの並列イノベーションを可能にするために、Prometheusプロジェクトは Prometheus Conformance Program をCNCFの協力のもと、コンポーネントの準拠と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`フラグで隠された機能を持つ`disabled features`という新しいセクションを導入しました。将来のリリースでは、このセクションにますます多くの機能が追加されると予想されます。

このリストにある機能は実験的なものと見なされており、`--enable-feature` の間は以下の考慮事項が伴います。

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

新しいPrometheusバージョン2.13.0が利用可能になり、いつものように多くの修正と改善が含まれています。変更点についてはこちらでお読みいただけます。しかし、一部のプロジェクトやユーザーが待っていた機能が1つあります：chunked, streamed version of remote read API。

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

リモートAPI

バージョン1.x以降、PrometheusはリモートAPIを使用してストレージと直接やり取りする機能を持っています。

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

• Write - Prometheusからプッシュされたサンプルを受信する
• Read - Prometheusからサンプルをプルする

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

Prometheusユーザーへのインタビューシリーズを継続し、ForgeRockのLudovic Poitouが彼らの監視ジャーニーについて語ります。

ご自身とForgeRockが何をしているか教えていただけますか？

私は、フランス、グルノーブル近郊に拠点を置くForgeRockのプロダクトマネジメントディレクター、Ludovic Poitouです。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年以来、Hostingerプロジェクト（無料ウェブホスティングプロバイダー）を含む約3000万人のクライアントがいます。

Prometheus導入前のモニタリング経験について教えてください。

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

自動化ツールは存在しませんでした。Bash + Perlで仕事をしていました。チームと自分自身をスケールアップしたいなら、自動化は決して無視すべきではありません。自動化なし - より多くの手作業が発生します。

当時、物理サーバーは約150台ありました。比較すると、現在までにVMと物理マシンを合わせて約2000台のサーバーがあります。

ネットワーク機器については、SNMPは依然として広く使用されています。「ホワイトボックス」スイッチの台頭により、SNMPはそれほど必要ではなくなり、通常のツールをインストールできるようになりました。

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

私たちはCumulusOSを使用しており、私たちの場合は主にx86なので、あらゆる種類のLinuxを実行することに全く問題はありません。

はじめに

タイトルが示すように、サブクエリはクエリの一部であり、以前は不可能だったクエリ内での範囲クエリを可能にします。これは長年の機能リクエストでした：prometheus/prometheus/1227。

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

動機

場合によっては、低い解像度/範囲（例：`5m`）で`rate`を使用して問題を検出したいが、より高い範囲（例：`1h`の`max_over_time`）でこのデータを集計したいことがあります。

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

数日または数週間にわたるデータで迅速な結果を得たい場合、記録ルールに十分なデータが蓄積されるまでかなりの時間がかかることがあります。記録ルールの追加を忘れると、フラストレーションが溜まります。そして、クエリの各ステップに対して記録ルールを作成するのは面倒です。

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

Prometheusユーザーへのインタビューシリーズを継続し、PresslabsのMile Rosuが彼らの監視ジャーニーについて語ります。

ご自身とPresslabsが何をしているか教えていただけますか？

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

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

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

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

本日、PrometheusがCNCF内で卒業したことをお知らせできることを嬉しく思います。

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

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

• サービスの高チャーンをサポートするためにストレージバックエンドを完全に書き直しました
• 特に2.3.2では、安定性に向けて大規模な取り組みを行いました
• Prometheusの導入とコミュニティへの参加を容易にすることに特に焦点を当てたドキュメントプッシュを開始しました

Prometheusには、Consul、Kubernetes、Azureなどのパブリッククラウドプロバイダーなど、多くのサービスディスカバリ（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のローカル開発用、Ambassador、KubernetesネイティブAPIゲートウェイでEnvoy Proxy上に構築されており、Forge、ビルド/デプロイシステムが含まれます。

私たちは、オープンソースの取り組みをサポートするために、AWSのKubernetesで多数のミッションクリティカルなクラウドサービスを実行しています。これらのサービスは、1日に数十の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です。素晴らしいトークとイベントのラインナップをご用意しています。Kubernetesの監視方法に関する実践的なアドバイスを得るためにPrometheus Salonへ行き、さまざまな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が何をしているか教えていただけますか？

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

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

Prometheusユーザーへのインタビューシリーズを継続し、iAdvizeのLaurent COMMARIEUが、彼らのレガシーなNagiosとCentreon監視をPrometheusに置き換えた方法について語ります。

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

私はiAdvizeのシステムエンジニア、Laurent COMMARIEUです。60人のR&D部門の5人のシステムエンジニアチームに所属しています。私たちの仕事は主に、アプリケーション、サービス、および基盤となるシステムが稼働していることを確認することです。私たちは開発者と協力して、彼らのコードが本番環境に到達するまでで最も簡単なパスを確保し、あらゆる段階で必要なフィードバックを提供します。そこで監視が重要になります。

iAdvizeは、フルスタックの会話型コマースプラットフォームです。私たちは、ブランドが顧客、従業員、デバイス、モノとのすべてのオンラインインタラクションを保護するソリューションを提供しています。顧客は、eコマース、銀行、旅行、ファッションなど、40カ国で活動しています。私たちは、フランス、英国、ドイツ、スペイン、イタリアにオフィスを持つ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 は、ドイツ最大の住宅ローン、住宅金融商品、個人ローンプラットフォームである Web ベースの EUROPACE 金融マーケットプレイスを開発・運営しています。完全に統合されたシステムにより、約 400 のパートナー（銀行、保険会社、金融商品販売業者）が連携しています。数千人ものユーザーが EUROPACE で毎月、最大 40 億ユーロ相当の約 35,000 件の取引を実行しています。当社のエンジニアは、http://tech.europace.de/ および @EuropaceTech で定期的にブログを公開しています。

Prometheus のユーザーへのインタビューシリーズを継続して、Weaveworks 社の Tom Wilkie が、Prometheus をどのように選択し、現在どのようにそれを構築しているかについて語ります。

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

Weaveworks は、オープンソースプロジェクトと SaaS を組み合わせてマイクロサービスを「運用」するサービスである Weave Cloud を提供しています。

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

• 可視化：Weave Scope
• 継続的デプロイメント：Weave Flux
• ネットワーク：Weave Net、コンテナ SDN
• モニタリング：Weave Cortex、当社のオープンソース分散 Prometheus-as-a-Service。

Weave Cloud は 60 日間無料 でお試しいただけます。製品に関する最新情報は、当社の ブログ、Twitter、または Slack（招待）でご確認ください。

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

ご自身と Canonical 社の事業内容について教えていただけますか？

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

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

Prometheus のユーザーへのインタビューシリーズを継続して、JustWatch 社がどのようにモニタリングを確立したかについて語ります。

ご自身と JustWatch 社の事業内容について教えていただけますか？

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

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

Prometheus のユーザーへのインタビューシリーズを継続して、Compose 社が Graphite と InfluxDB から Prometheus へのモニタリングの旅について語ります。

ご自身と Compose 社の事業内容について教えていただけますか？

Compose は、本番稼働可能なデータベースクラスタを開発者向けにサービスとして提供しています。アプリ開発者は当社に来て、数回のクリックで、高可用性、自動バックアップ、セキュリティを備えたマルチホストデータベースを数分で利用できます。これらのデータベースデプロイメントは、需要が増加するにつれて自動的にスケールアップするため、開発者はデータベースの実行ではなく、素晴らしいアプリの構築に時間を費やすことができます。

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

Prometheus のユーザーへのインタビューシリーズの次として、DigitalOcean 社が Prometheus の使用方法について語ります。Carlos Amedee は、PromCon 2016 での ロールアウトの社会的側面 についても語りました。

ご自身と DigitalOcean 社の事業内容について教えていただけますか？

私の名前は Ian Hansen で、プラットフォームメトリクスチームに所属しています。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 が安定することを意味します。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 を追加しました。これは、チャンク内のサンプルごとに可変ビット幅を伴うため、varbit エンコーディングと呼んでいます。バージョン 1 はほとんどの点でバージョン 0 よりも優れていますが、バージョン 1 と 2 の間には実際のトレードオフがあります。このブログ記事は、その決定を支援します。バージョン 1 はデフォルトのエンコーディングのままですので、この記事を読んだ後にバージョン 2 を試したい場合は、コマンドラインフラグで明示的に選択する必要があります。どちらかに切り替えても問題はありませんが、既存のチャンクは作成後にエンコーディングバージョンを変更しないことに注意してください。ただし、これらのチャンクは設定された保持時間に従って徐々に削除され、コマンドラインフラグで指定されたエンコーディングを持つチャンクに置き換えられます。

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

ご自身と ShowMax 社の事業内容について教えていただけますか？

私は Antonin Kral で、ShowMax のリサーチおよびアーキテクチャを率いています。それ以前は、過去 12 年間、アーキテクチャおよび CTO の役割を担ってきました。

ShowMax は、2015 年に南アフリカでローンチされたサブスクリプションビデオオンデマンドサービスです。20,000 エピソード以上のテレビ番組と映画の広範なコンテンツカタログがあります。現在、当社のサービスは世界 65 カ国で利用可能です。より有名な競合他社がアメリカとヨーロッパで skirmish している間、ShowMax はより困難な問題と戦っています。それは、接続がほとんどないサハラ以南アフリカの村で、どのようにして binge-watch するのかということです。すでに世界のビデオの 35% はストリーミングされていますが、革命がまだ影響を与えていない場所はたくさんあります。

主にプライベートクラスタ上で CoreOS を中心に構築された約 50 のサービスを管理しています。これらは主にクライアント（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 クラスタに格納されます。etcd とカスタムツールを使用して、リクエストルーティングのための Varnish を設定しています。

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

ご自身と Life360 社の事業内容について教えていただけますか？

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

Life360 は、家族がつながるのを助けるテクノロジーを作成しています。私たちは家族のためのファミリーネットワークアプリです。これらの家族を管理するのに非常に忙しく、ピーク時には 7000 万人の登録済み家族のために 1 分あたり 70 万件のリクエストを処理しています。

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

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

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 メッセージは次のようになります。

firing しているアラートが 1 つあること、その後にアラートグループのラベル値（alertname, datacenter, app）、さらに共通のアラートラベル値（critical）が表示されていることがわかります。

始まり

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

Prometheus は 2012 年に GitHub でオープンソースプロジェクトとして開始されましたが、当初は騒ぎませんでした。プロジェクトが成熟し、摩擦なしで実験できる時間を確保したかったのです。Prometheus は 2013 年に SoundCloud 社で本番モニタリングに徐々に導入され、その後、同社内での利用がますます増え、2014 年には Docker 社や Boxever 社の友人たちにも早期に採用されました。長年にわたり、Prometheus はますます成熟していましたが、人々のモニタリングの問題を解決していたにもかかわらず、一般にはまだ知られていませんでした。

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

また、カスタムサービスディスカバリ のトピックにも触れました。

すべてのサービスディスカバリタイプが十分に汎用的であるわけではないため、直接 Prometheus に含めることはできません。組織には独自のシステムが導入されており、Prometheus で動作させる必要があるだけかもしれません。これは、新しいモニタリングターゲットの自動検出のメリットを享受できないという意味ではありません。

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

編集者注：この記事は Prometheus ユーザーが執筆したゲスト投稿です。

何万人もの要求の厳しいゲーマーのネットワークを運用している場合、ネットワーク内で何が起こっているのかを本当に知る必要があります。そして、すべてを 5 日でゼロから構築する必要があります。

もし DreamHack を聞いたことがないなら、ピッチはこうです：20,000 人の人々を集め、その大半に自分のコンピュータを持参させます。eSports、プログラミングコンテスト、ライブコンサートを組み合わせます。結果は、デジタルなものすべてに特化した世界最大のフェスティバルです。

このようなイベントを可能にするためには、多くのインフラストラクチャが必要です。この規模の通常のインフラストラクチャは構築に数ヶ月かかりますが、DreamHack のクルーは 5 日でゼロからすべてを構築します。これには、ネットワークスイッチの設定だけでなく、電力供給の構築、食料品店と飲料店の設置、実際のテーブルの構築なども含まれます。

ネットワークに関連するすべてを構築・運用するチームは、正式にはネットワークチームと呼ばれますが、通常は自分たちを *tech* または *dhtech* と呼んでいます。この記事では、dhtech の仕事と、DreamHack Summer 2015 で Prometheus を使用してモニタリングをさらに向上させようとした方法に焦点を当てます。

John Allspaw は、彼の *モニタリング/メトリクス/アラート企業への公開書簡* で、「異常を完璧に、適切なタイミングで検出することは不可能」と主張しています。

しかし、すべての希望が失われたわけではありません。カスタムルールで検出および処理できる一般的な異常はたくさんあります。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 を最大限に活用するための記事や発表をさらに公開します。