Monitoring in the time of Cloud Native — Part 8

クラウドネイティブにおけるモニタリングーPart 8

今回からクラウドネイティブにおけるモニタリングに関しての記事をご紹介していきたいと思います。

とても長い文章になるので、いくつかに分けて投稿していきたいと思います。

今回はPrometheus、メトリック、トレースについてです。

A new hope for the future

ロギングにおいて未解決のままの問題のがあるという事実から、輝かしい例である OpenTracing 、つまりコミュニティ主導の開発の力の証であるOpenLogging仕様に期待が寄せられています。クラウドネイティブ時代に合わせて設計された仕様で、万博博覧会と伝播形式を導入しています。 ログに記録する仕様は、構造化されたイベントである必要があり、大量かつファイデリティが低いイベントのダイナミックなサンプリングに関する規則を体系化します。 すべての主要言語のライブラリとして実装でき、すべての主要なアプリケーションフレームワークとミドルウェアでサポートできる仕様です。 ストリーム処理の進歩を最大限に活用できる仕様であり、 すべてのCNCFプロジェクト、特にKubernetesの共通語ロギング形式となる仕様です。

Metrics

「Prometheusは単なるサーバーではありません。 標準のセットとプロジェクトであり、サーバーは全体の一部にすぎません。 」

Prometheus は、指標の説明形式を体系化するという偉業を成し遂げ、これが標準になることを私は期待しています。 Prometheusは長期ストレージを提供していませんが、約1年前にPrometheusに追加されたリモート書き込み機能により、PrometheusメトリックをOpenTSDBやGraphiteなどのカスタムリモートストレージエンジンに書き込むことができ、Prometheusをライトスルーキャッシュに効果的に変換できます。一般的な書き込みバックエンドを最近導入したことによって、時系列をPrometheusからHTTPおよびProtobufを介してKafkaやCassandraなどのストレージシステムに転送できます。

ただし、リモート読み取りはわずかに新しいものであり、ここ数か月で努力が実り、何か意味のあるものになっているのを見てきました。 InfluxDBは、Prometheusのリモート読み取りと書き込みの両方をネイティブにサポートするようになりました。 リモート読み取りにより、Prometheusはクエリ実行時にリモートバックエンドからrawの（生の）サンプルを読み取り、Prometheusサーバーで結果を計算できます。

さらに、今後の2.0リリースでのPrometheusストレージエンジンを改善することにより、Prometheusは、時系列の名前が大量に変動するクラウドネイティブのワークロードをさらに助長します。 Prometheusの強力なクエリ言語は、同じクエリ言語を使用してアラートを定義し、テンプレートアノテーションでアラートを充実させる機能と相まって、「モニタリング目的」の全てのものに最適なものになります。

ただし、メトリックでは、ラベルスペースを explode させないように注意することが重要です。 ラベルは、ある程度均一に維持できる属性の小さなセットに限定されるように選択する必要があります。 すべてに注意を喚起する誘惑に抵抗することも重要になります。アラートを効果的にするためには、システムのハード障害モードの小さなセットを特定することが重要になります。 「モニタリング」される信号の理想的な数は3〜5くらいであり、7〜10であると考える人もいます。 私の友人との会話でよく話題あがるのは、「モニタリング」がいかに「うるさい」かということです。ノイズの多いモニタリングは、一度も見たことのないメトリックデータ（つまり、メトリックサーバーのストレージスペースの無駄）や、さらに悪いことに、アラートファティーグの深刻なケースになる誤ったアラートにつながります。

Traces

今までトレーシングを実装することは困難でしたが、サービスメッシュの台頭により、トレース機能の統合はとても楽になりました。 Lyftは、サービスメッシュパターンを採用することで、1行のコードを変更することなく、すべてのアプリケーションのトレースサポートを得という話は有名です。サービスメッシュは、メッシュレベルでトレースおよび統計コレクションを実装することにより、可観測性の DRY を支援します。これにより、個々のサービスをブラックボックスとして扱うことができますが、それでも全体として「メッシュ」に対する驚くべき可観測性が得られます。 メッシュを形成するアプリケーションがヘッダーをメッシュ内のネクストホップに転送できる必要があるという警告があったとしても、このパターンは、最小限のコード変更で既存のインフラストラクチャーにトレースを後付けするのに非常に役立ちます。

When it makes sense to augment the three aforementioned tools with additional tools

例外であるトラッカー（私はこれらをlog ++と考えています）はここ数年で大きく進歩し、例外を検査するプレーンテキストファイルやJSONの塊よりもはるかに優れたUIを提供しています。 例外のトラッカーは、完全なトレースバック、ローカル変数、すべてのサブルーチンまたはメソッド呼び出しでの入力、エラー/例外の発生頻度、およびデバッグにとって重要になってくる他のメタデータも提供します。例外トラッカーは、例外とアプリケーションのクラッシュを追跡するという1つのことを目指しており、これを非常にうまく行う傾向があります。 ログが必要ではないというわけではありませんが、例外トラッカーはログを増強します（もしあなたが冗談を許してくれれば）-ただしこれは、例外的なものです。

一部の新しいツールは、ネットワークパケットを真実のソースとして扱い、パケットキャプチャーを使用して全体的なサービストポロジーを構築することで、可視性を実現しやすくなります。 これによってスタック全体のすべてのアプリケーションコードをイントルメントするよりも確実にオーバーヘッドが少なくなりますが、主に異なるコンポーネント間のネットワークインタラクションの分析に役立ちます。マルチスレッドサービスの非同期動作またはシングルスレッドサービスでの予期しないイベントループの停止に関する問題のデバッグには役立ちませんが、単一のサービス内で何が起こっているかをより把握するためにメトリックまたはログを追加することで、全体のアーキテクチャーを十分に可視化することができます。

Conclusion

可観測性はモニタリングとまったく同じではありません。 可観測性とは、より全体的なものを意味し、「モニタリング」、アプリケーションコードのイントルメンテーション、ジャストインタイムデバッグのための積極的なイントルメント、およびシステムのさまざまなコンポーネントのより完全な理解を含んだものです。

可観測性とは、システムが実稼働環境でフランケンシステムに変わる可能性があることを認識して、システムを構築できる能力、そして自信を持つことを意味します。 私たちが構築しているソフトウェアは、最善の努力にもかかわらず、さまざまな程度で破損する可能性がある（ほとんどの場合は破損する可能性があることを）ということ理解することが大切です。ラップトップまたはCIでコードを動作させることと、実稼働環境でコードを実行することとは、屋内プールで泳ぐこととピラニアがうじゃうじゃい危険な川で泳ぐこととの違いです。 外国の環境で実行している自分のサービスをデバッグできるように修正できないという感覚は、許容されません。

この投稿を、クラウドネイティブの時代にソフトウェアの開発と運用がどのように行われるべきかについてお話した上で締めくくりたいと思います。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。