プロメテウスの未来とプロジェクトエコシステム（2020）

約 transl。：これは、Prometheus開発チームの著名なメンバーであり、Grafana Labsのコミュニティディレクターであり、OpenMetricsプロジェクトの創設者であり、CNCFのSIGObservabilityグループの議長であるRichardHartmannによる最近の講演に基づく記事の翻訳です。著者は、オープンソースプロジェクト（およびコミュニティ）プロメテウスの人生の昨年を要約し、主な困難と最も近い見通しについて話します。







中にPromConオンライン2020、私は「プロメテウスとその生態系の未来」と題した講演を行いました。そして、その要点を皆さんと共有したいと思います。

概要

前回の会議PromCon-2019以来、Prometheusには多くの変更がありました。

2.14

バージョン2.14では、Reactに新しいインターフェイスが導入されています。機能面ではまだ古いものに遅れをとっていますが、現在取り組んでおり、改善を続けています。

2.15

バージョン2.15は、MetadataAPIのバナーの下にありました。プロメテウスの露出フォーマットは長い特殊な表現サポートしてきましたHELP、TYPEしかし、プロメテウス自体は単純に、このデータを破棄するために使用される、など。それらが残っているので、APIを介してそれらへの外部アクセスを開くことができます。たとえば、Grafanaはすでにこの機会を利用しており、ユーザーが作業する時系列に関する追加情報をユーザーに提供しています。

2.16

バージョン2.16は、さまざまな改善と安定性に重点を置いています。たとえば、2016年以降、ユーザーはUIで現地時間を選択する機能や、クエリログの実装について質問してきました。これらの問題を解決できてよかったです。

2.17

長引く機能要求と言えば、バージョン2.17はついに、データベースのACIDに待望の「I」をもたらしました：isolation。

2.18

では2.18、トレースと露光形式インスタンスのサポートが改善されました。インスタンスは、PrometheusにOpenMetricsを実装することによる最初のユーザーが気付く影響です。それらをGrafanaと組み合わせることにより、次の場所から次の場所に移動できる便利な粒度を実現できます







。

2.19

では2.19、我々は50％程度でメモリ消費量を削減しました！プロメテウスはすでに非常に効果的ですが、インスピレーションと気が遠くなるような最適化の大きな可能性があります。



このグラフは、これをよく表しています。

2.20

バージョン2.20は、v2.6（！）以降で最長の変更ログを誇っています。主なものは、おそらくDockerSwarmとDigitalOceanのネイティブサービス検出サポートです。



しかし、2つの独立したサービス検出メカニズムの実装を超えた、より重要な変更があります。Prometheusを分解し、古いソリューションと確立されたアプローチの多くを新たに検討します。世界は変化しました（おそらく私たちもこれに関与していました）-これはプロジェクト自体と他の人の両方で考慮に入れる必要があります。

node_exporter

要約すると、node_exporterがバージョン1.0に到達し、EXPERIMENTALTLSサポートが含まれるようになったことを指摘しておきます。Cloud Native Computing Foundationは、Cure53によるnode_exporterの監査を後援しました（これは、一般的なエクスポーターと、特にTLS実装の両方を対象としていました）。そして、それは二重の価値がありました。TLSを他のエクスポーターにコピーする前にチェックしただけでなく、node_exporterを他のパターンのコピー元のギニアピッグとして使用しました。

未来

プロジェクトとして、私たちが栄光に支えられていると感じることがあります。少し前に、「プロメテウスには機能がありません」というモットーの下でグラファナ内でブレーンストーミングセッションを実行し、レッドハットに同じことをするように勧めました。その過程で、Prometheusチーム全体が利用できるすべてについてのドキュメントを作成しました。これは、特定のトピックに対処するためのフレームワークとして機能し、開発サミット中に議論するためのポイントに分割されます（これらのポイントの準備ができ次第）。

開発者サミット

昨年は2つの開発サミットがありました。1つはKubeConEUの後、もう1つはPromConの後です。 2020年にも同じことをする予定でしたが、COVIDはそれを阻止しました。今年はサミットはありませんでしたが、より短く、より頻繁で、仮想の会議という方法を見つけたと思います。一度に1〜2日間収集するのではなく、4時間のブロックを費やします。このような最初の開発サミットは7月10日に開催され、次のサミットはおそらく8月7日に開催されます。蓄積されたすべての質問を分析するまで、それらを実行し続けます（ただし、上記のドキュメントから新しいアイテムが追加されるにつれて、その数は絶えず増加しています）。



今、私は2つのことをしたいと思っています。

1. , . , , . , . — , , .
2. , , . , , .

メタデータはプロメテウスに真の価値をもたらし始めています（上記2.15を参照）。メタデータを操作するためのオプションをさらに実装する必要があります（たとえば、リモートの読み取り/書き込みを介してメタデータを配布します）。以下のコンセンサスは、「メタデータが変更/消失した場合はどうなりますか？」などの興味深い質問には対応していません。または「攻撃ベクトルになった場合はどうなりますか？」

コンセンサス：メタデータをより適切に維持したいと考えています。作業は特別な文書で行われます。



コンセンサス：PR 6815は、実験的な回避策として使用されます。ほとんどの場合、バージョン3.xでは異なります。

ワークフローの変更とs / master / main /

作業プロセスで蓄積されたゴミを掻き集めるというトピックは特別な説明を必要としませんが、言葉遣い（用語の統一）を排除することについていくつかの言葉を言う必要があります。私たちは用語の整理に真剣に取り組んでいます。これは最も重要なことではありませんが、今できることです。 GitHubからの対応するツールキットを待っている間。登場次第、コミュニティブリッジを通じて有償のインターンをこの作品に引き付けようとしています。



私はLinuxFoundationおよびCNCFと話し合って、これをすべてのプロジェクトに実装する可能性があります。このトピックに興味のある人にとっては絶好の機会です。多くのプロジェクトを探索し、さまざまなツールを使用して、多くの人々に会う機会です。 Twitter（@TwitchiH）またはメール（richih）で私に連絡してください grafana.comで）興味があれば。

コンセンサス：すべてのプロメテウス/リポジトリで「マージ前にステータスチェックを要求する」を設定します...メインブランチでの直接プッシュを許可しませんか？メインブランチでの強制プッシュを許可しませんか？



コンセンサス：すべてのメインブランチへの強制プッシュを無効にします。



コンセンサス：デフォルトの動作ではメインブランチをプッシュできますが、プロメテウス/プロメテウスなどの「重要な」リポジトリでは無効にする必要があります（メンテナの裁量による）。

データの入力（埋め戻し）

これは最も古い機能要求の1つであり、コンセンサスにアプローチする方法の良い例です。この問題についてプロメテウスチームにはさまざまな意見が出回っており、共通の分母にたどり着くのは困難です。したがって、私は三つの基準と限られており、非常に具体的な合意案を書いた：「我々は、埋め戻しをサポートしたいネットワーク上に少なくともブロックヘッドブロックと重複しません。」



長い議論と合意に達するための試みの結果、これを行うのは容易ではないことが明らかになりました。次のようにそのため、私は提案を再定式化：「我々は埋め戻しをサポートしたいネットワーク上で、少なくともストリームヘッドブロックと交差していません"。



この問題について全員に自分の意見を表明させることによってのみ、最終バージョンに到達することができました。「適切に実装されていれば、ヘッドブロックと交差しないブロックでネットワークを介した 埋め戻しをサポートしたいと思います。」ここでの各単語は、コンセンサスの正確な範囲と境界を反映するように選択されています。

: Prometheus OpenMetrics, CSV- .



: backfilling , .



: backfilling , .



: backfilling , .

物事を整理することに関連する別のタスク。ここで私は囲碁を批判したいと思います：それは単一のmonorepが標準である世界で開発されました。 Googleは、共通コードのすべて（またはほとんど）を単一のリポジトリに保存します。このアプローチには多くの利点がありますが、実際の状況にうまく変換されません。 Goはゆっくりと、しかし確実にこの遺産から遠ざかっています。



おもしろい事実：私は議論のほぼ最初にコンセンサス提案を書きました。少なくとも試してみるのは明らかでした。ベン・コチエがこれを志願することは明らかでした。そして、node_exporterが「犠牲者」になることは明らかでした。原則として、私たちはワークフローの改善に努めています。ベンは常にボランティアであり、node_exporterはテストベンチであり、そこから結果を他のエクスポーターにコピーします。そして、はい、議論がしばらく続き、人々が事実に直面するのではなく、自分でこれに到達することが重要でした。

コンセンサス：node_exporterで削除し、満足のいく結果が得られるかどうかを確認します。

メーリングリストとIRC

Googleは中国でブロックされていますが、メーリングリストはそれに取り組んでいます。メールでの購読を可能にすることにしました。私がチェックした：prometheus-users+subscribe@googlegroups.comは動作します。必要に応じて、アーカイブ（https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.html）を読むこともできます。



さらに、一部のxkcd 1782は非常に関連性があるため、誰もがMatrixを介してIRCを使用できるようにしました。

:



, Google ; - .



docs/community , Google.



IRC, Matrix; , .

サミットで私が言ったことを繰り返します。「2015年にプロメテウスについて最初に気に入らなかったのはドキュメントでした。 2020年、私は彼女が嫌いです。使用するのは難しく、ほとんど役に立たず、自分が何をしているのかをすでに知っている人、または少なくとも概念についての良いアイデアを持っている人にのみ適しています。」要するに、私たちはこの方向に取り組みます：

:



:



* (user manual) .

* (reference) , PromQL /.

* (guides), .



Diana Payton , .. .



.

興味のある方は、現在、Grafana Cloudで、Prometheusの公式アップストリームドキュメントに取り組むテクニカルライターを探しています。結局のところ、私たちはコミュニティへのコミットメントを真剣に受け止めています。



いつものように、dev-summitからのメモが公開されます。2020-1サミットと過去数年間のサミットの結果も読むことができます。

翻訳者からのPS

私たちのブログも読んでください：

• 「監視とKubernetes」（レビューとビデオレポート）;
• " KubernetesのPrometheusオペレーターのデバイスとメカニズム";
• " Kubernetesで欠落している画像を検出するためのk8s-image-availability-exporterの紹介»。