[tag-observability/whitepaper.md at main · cncf/tag-observability · GitHub](https://github.com/cncf/tag-observability/blob/main/whitepaper.md) (Accessed on: 01/06/2022) [[CNCF]]による[[Observability]]のWhitepaper。 DeepLによる日本語訳 ## エグゼクティブ・サマリー システムの複雑性と毎秒処理するデータの継続的な増加に伴い、ワークロードの状態を理解するために、より優れた観測性が必要になっている。可観測性ツールに加え、サービスとしてのソフトウェアの実行を担当するすべてのエンジニアが、アプリケーションの監視と観測の方法を理解することを期待するのが一般的になっています。顧客の期待が高まり、サービス・レベル目標が厳しくなるにつれ、エンジニアはこれまで以上に迅速にデバッグし、問題の根本原因を見つけなければならない。 本稿では、クラウド・ネイティブな観測可能性をすぐに始められるようにすることを目的とする。クラウド上でワークロードを実行する際に必要となる、様々な種類の観測可能性の概要とパターンについて説明します。 ## はじめに クラウド・コンピューティング、マイクロサービス、分散システムの普及に伴い、新しいアプリケーションはクラウド上で動作するように設計・構築されることが多い。これは、より弾力性があり、よりパフォーマンスが高く、よりセキュアなアプリケーションを構築するための新たな戦略を提供するが、これらのワークロードをサポートするインフラストラクチャの制御を失うという潜在的なコストを伴う。シスアド、開発者、ソフトウェア・オペレーターは、本番稼動中のアプリケーションの状態と、そのアプリケーションが稼動している基盤インフラの健全性を把握していなければならない。さらに、例えばソースに新たなインスツルメンテーションを追加したり、実行中のプロダクション・コードにブレークポイントを設定したりすることなく、これらのシグナルを外部から観測できなければならない。 アプリケーションは、何らかのエンティティ（例えば、そのエンティティが他のアプリケーションであろうと、データセンターにアクセスできない人間であろうと）によって観測可能にするメカニズムを含み、促進するように設計され、構築されなければならない。この努力は、設計の初期段階から行う必要があり、多くの場合、余分なコードやインフラストラクチャーの自動化や計測が必要になる。このような文化的、プロセス的な変化は、多くの組織にとってしばしば課題であり、障害でもある。その上、市場に出回っている多くの手法やツールは、合理的なレベルの観測可能性に到達するための異なるアプローチを提案している。 ひとたび満足のいく観測可能なレベルに達すれば、その利点に疑いの余地はない！文化の変化、異なるツール、異なる目的、異なる方法。考慮しなければならない多くの詳細が、この旅を混乱させ、辛いものにする。本稿は、より多くのソフトウェア・チームやオペレーション・チームが、システムにおいて観測可能性のメリットを得られるように、明確性を提供することを目的としている。 ## ターゲット・オーディエンス 本稿の対象読者は以下の通りである： サイト信頼性エンジニア DevOpsエンジニア シスアド ソフトウェア・エンジニア インフラエンジニア ソフトウェア開発者 この論文は、信頼性、セキュリティ、透明性の実証可能なレベルに到達しながら、顧客の既存の観測可能なシステムと統合する観測可能なソフトウェアを提供することを望む組織の上記の役割のいずれかに関連しています。観測可能性は学際的なトピックであるため、このようなソフトウェアの設計と実装を担当するプロジェクトマネージャ、プロダクトマネージャ、プログラムマネージャ、アーキテクトなどの組織の利害関係者も、この論文に興味を持つかもしれません。また、コンピュータ・サイエンス、情報システム、エンジニアリング（またはそれに関連する）の学生や、オブザーバビリティの領域に興味を持つ人々も、この論文に役立つ情報を見つけることができるかもしれません。 ## 目標 クラウド・コンピューティングの採用は、小規模から大規模なハイテク企業まで、コストやスケールを最適化し、より効率的な製品を設計するのに役立っているが、それには複雑さが伴う。インフラが遠隔地にあり、一時的で、グローバルに分散しているため、データセンターに対するシスアドのコントロールは今や失われている。かつては管理者と開発者が相反する目標を持つ文化であった企業は、信頼性の高いソフトウェアを構築することを目的とする単一のチームとして協力しなければならない新しい文化に変わらなければならない。クラウド・ネイティブ・システムの状況を観察し、この新しい現実の中でシステムの信頼性を維持するために、そのような企業を支援するいくつかの新しい戦略やツールが登場している。 観測可能なシステムの設計と開発中に、サードパーティ（通常はツールのセット）にテレメトリーデータを送信または公開するように計装されなければならない。別の方法として、Javaランタイム、pprof、eBPFなどを使った自動計測がある。その遠隔測定データは、トレース、構造化イベント、プロファイル、クラッシュダンプと同様に、ソフトウェアエンジニアリングチームで長い間使用されてきたメトリクスやログの形で頻繁にやってくる。それぞれのシグナルには目的とベストプラクティスがあり、それらの誤用は、"アラート疲労 "や "高コスト "のような、ソフトウェアをスケールで実行する際の新たな問題につながる可能性がある。 企業文化の変革、キャパシティ・プランニング、法的問題など、いくつかの新たな課題があるにせよ、その多くは、この新時代にいち早く参入した革新的な企業がすでに取り組み、解決してきたものだ。初心者は彼らの発見や失敗から学び、彼らのベストプラクティスに従って同じ問題に取り組むことができる。本稿では、観測可能性シグナルとその扱い方の違い、一般的な問題に取り組む際に成功した企業が用いたいくつかの異なる手法のリスト、観測可能性の範囲に含まれるいくつかのツールと観測可能性スタックのどこに位置づけられるべきかの提示、さらに、まだ未解決である、あるいはある手法がまだあまり市場に浸透していない、一般的に知られているギャップを示す。 非ゴール このドキュメントは、特定のobservabilityプロジェクトのための低レベルのインストールガイドや設定の詳細を提供するものではありません。また、W3Cのコンテキストプロパゲーションや、Prometheus Exposition format (OpenMetrics)、OpenTelemetry protocol (OTLP)のような様々な標準を深く掘り下げるものでもありません。 その代わり、一般的な概要と、プロジェクト・ドキュメンテーションのような貴重な資料への参照を提供する。 観測可能性とは何か？ 観測可能性がシステムの望ましい特性であることは間違いない。誰もがそう言っていますよね？すでに観測可能性の旅を始めている人もいれば、今まさにこのホワイトペーパーを読んでいる人もいるでしょう。実際、"Observability "はバズワードになっており、他のバズワードと同じように、誰もがそれを提唱しながら自分の足跡を残したいと思っています。観測可能性についてレベルアップを図るのであれば、その本来の目的をはっきりさせるようにしよう。 制御理論では、「可観測性とは、あるシステムの内部状態が、その外部出力の知識からどの程度推測できるかを示す尺度である」。7.理論的には、観測可能性とは、人間や機械がシステムの状態を観察し、理解し、行動することができるシステムの機能である。そう、観測可能性とは、定義からすると単純に見えるが、目的なしに実装された場合、システムがどのような出力を持つべきかを決めるのは複雑になる。物事が横道にそれ始めるのはその時である。 仕事を始めるとき、他人の仕事をコピーするのは簡単だ。これはオープンソースの恩恵の1つであり、同時に呪いの1つでもある。ヘルムチャート、Ansibleのプレイブック、Terraformのモジュールなど、多くの例がオンライン上にある。これらのスクリプトを1つ実行するだけで、ほんの数分で観測可能なスタックを立ち上げ、稼働させることができる。簡単だし、他の人たちにとってもうまくいっている。だから私にも使えるはずだ。これらのスクリプトを使わないことを勧めるつもりはないが、観測可能性とは単にきれいでピカピカのツールを使うことではないことを忘れてはならない。システムからどのような出力が出るかを意識しなければならないし、何よりも重要なのは、目的を持つことだ！そして何よりも重要なのは、目的意識を持つことだ！「ああ、この特定のデータを収集したい、将来必要になるかもしれないから」と考え、別のデータ、また別のデータ、また別のデータ......とこの思考を繰り返しているうちに、気がついたらデータレイクを構築していた、ということになりかねない。 Observabilityは、システムの開発ライフサイクルの文字通りすべてのフェーズで使用できます。新機能のテスト、生産時の耐障害性のモニタリング、顧客が製品をどのように使用しているかについての洞察、製品ロードマップについてのデータ駆動型の意思決定などで使用することができる。これらの目標のいずれかを念頭に置いたら、アウトプット、つまり私たちがシグナルと呼ぶものについて考え始めるだろう。 観測可能シグナル 前述したように、シグナルとは、人間や機械が知識を推測できるシステムの出力である。これらのシグナルは、システムによって異なり、達成したい目的によって異なります。温度やRAM使用量のように、ある時点で測定したいものであったり、分散システムの多くのコンポーネントを通過するイベントを追跡したいものであったりする。例えば、CPU、メモリ、ディスクなどのリソースに対して、ある時点で最も負荷がかかっているシステムの機能を知りたいとか、システムがどのようなタイミングで壊れたかを知りたいなどです。いくつかのシグナルは、知識を推測するために重なるかもしれませんが、他のシグナルは、特定のシステム側面に特化しています。これらのシグナルはすべて一緒に使うことで、同じテクノロジーを観察するさまざまな方法を提供することができます。また、私たちが最初の一歩としてお勧めするように、1つまたは数個から始めて、他のシグナルを使いこなすこともできます。 メトリックス、ログ、トレースという「3つの観測可能性の柱」について聞いたことがある人は多いだろう。これらは一般的によく言われることであり、おそらく皆さんもこれから始めようとしていることでしょう。私たちは、2つの理由から、これらを「3本柱」ではなく「主要なシグナル」と考えたい： 柱には、基礎となるものという暗黙の意味がある。これらは安全なスタート地点であるが、同時に必ず必要というわけではない。実際、1つか2つのシグナルをベースに他のシグナルを少し混ぜることは、コスト効率を向上させるために有効なトレードオフになり得る（例えば、アドホックトレースによるメトリクスとログ）。 最近、アプリケーションプロファイル（継続的なプロファイリング）やクラッシュダンプのような、より多くのシグナルがオープンソースコミュニティで普及しつつある。近い将来、新しいセマンティクスを持つ新しいシグナルが登場するかもしれません。 Figure 1 図1は、ワークロードから観察できるデータを分類するのに役立つ3つの主要なシグナルを示している。すべてのメトリクスが意味的に集計可能であるわけではないが、一般的に、より簡単な方法で集計可能である（または、それ自体でイベントのグループを表す）ことに注意。ボリューム・スケールが小さいとは、典型的なボリュームのことである。メトリックスで多すぎるデータを生成することはできるが、ログやトレースよりも少し難しい。 すべての信号は、収集または計測される方法が異なる。入手、保存、分析にかかるリソースコストも異なるが、同じシステムを観察する方法も異なる。これらの中から、あるいはこれらすべてを選択することは、エンジニアリングにおける他のすべての作業と同様、トレードオフのゲームです。次のセクションでは、それぞれのシグナルをより深く掘り下げることで、この決断を下す手助けをします。まず、人々が好んで使うメトリクス、ログ、トレース、そして、新しく登場した2つのシグナル、アプリケーション・プロファイルとクラッシュ・ダンプです。 指標 メトリクスとは、データを数値化したものである。主に2つのカテゴリーに分けられる：すでに数値化されたデータと、数値に分解（集約）されたデータである。前者の例としては気温が、後者の例としてはウェブサーバー上で観測されたHTTPリクエストのカウンターが挙げられる。 数値はデータを保存する最も効率的な方法であり、すべての確立された産業は、時間の経過とともに測定基準を優先する傾向にある。例えば、あなたの家賃、水道代、冷暖房費、電気代は測定基準のみであり、あなたがそれらを支払う銀行口座も測定基準のみである。 ホスト（仮想マシンなど）のヒープ・メモリ使用量を測定するゲージです。これを「heap-memory-bytes」と呼ぶことにします。メトリックは、名前、ラベルのセット（属性またはタグと呼ばれることもある）、および各時点の数値（たとえば、1秒ごとに1つの値）で構成される。特定の名前とラベルを持つ各メトリックのインスタンスは、しばしば「タイムシリーズ」または「ストリーム」と呼ばれる。 heap-memory-bytes」によって、各ホストのヒープメモリ使用量を時系列で見ることができる。また、データ・センターごとの平均ヒープ・メモリ使用量など、追加の集計を行うこともできる。 メトリック名 ラベルキー ラベルの値 ラベルキー ラベルの値 時刻t0における値 t1 ヒープ・メモリ・バイト ホスト ホスト123 データセンター c1 11231 11200 ヒープ・メモリ・バイト ホスト ホスト234 データセンター c1 300203 412103 表1は、あるメトリックの例に対する2つの時系列を示している。これらのメトリック名、ラベル、および特定のタイムスタンプの値は、列を持つ表形式のビューで表されている。 蒸留されたデータは、いくつかの詳細を失う。つまり、「ヒープメモリバイト」の例では、観測された間隔（t0とt1の間）のヒープ値はわからない。また、どのプロセスIDが使用され、どれだけのヒープバイトが使用されているかなど、ホストよりも詳細なことは答えられない。これは、より詳細な個々のイベント（例えば「プロセスAがホストB上で20バイトを割り当てた」）のレコードや情報に焦点を当てるログやトレースとは異なります。 意図したとおりに使えば（カーディナリティの問題を参照）、このトレードオフにより、メトリクスは「既知の未知数」に対する最も効率的なシグナルのひとつとなる： メトリックは、予測可能な処理コスト（保持、発信、送信、保存のため）という点で、効率的である。例えば、割り当てやプロセスがいくつ実行されていても、ホストごとに常に1つの "heap-memory-bytes "メトリクスが存在する）。 明確な次元を持つ少量のデータは、人間のオペレーターが状況の概要を素早く把握できるため、精神的な過負荷を軽減することもできる（例えば、いつメモリが飽和状態になったか）。 業界はまた、さまざまな観測に有用な、さまざまなタイプの測定基準を考え出した。様々なデータモデルが複数のタイプを記述していますが、一般的にサポートされている3つのコアタイプを概説することができます： ゲージ：任意に上下できる単一の数値を表す指標。ゲージは通常、温度や現在のメモリ使用量のような測定値に使われるが、同時リクエスト数のように上下できる「カウント」にも使われる。 カウンター：単調に増加する一つのカウンターを表す累積的な指標。その値は、再起動のときのみ増加するかゼロにリセットされる。例えば、カウンターは処理されたリクエスト数、完了したタスク数、 エラー数を表すことができる。 ヒストグラムヒストグラムは観測値(リクエスト時間や応答サイズのような)をサンプリングし、設定可能なバケットや指数バケットでカウントします。また、すべての観測値の合計も提供します。パーセンタイルやヒートマップのような分布したオブザベーションの高度な分析を可能にします。 メトリクスは通常、構造化または半構造化されており、一般的に2つの方法で使用される： リアルタイムのモニタリングとアラート- メトリクスの最も一般的なユースケースは、ビジュアル・ダッシュボードの概要とドリルダウンです。また、監視対象システムがしきい値を超えた、または異常な動作をしているというアラートまたは通知を、人間または自動システムにトリガーするためにも使用されます。 傾向分析と分析- メトリクスは、長期的な傾向分析と長期的な計画の目的にも使用される。また、インシデントが発生した後に、根本的な問題を修正し、再発を防止するために監視するための洞察を得ることもできる。 メトリクスが提供する情報は、システムの全体的な挙動や健全性に関する洞察を形成するために使用されます。メトリクスは多くの場合、「何が」起きているのか、時には「なぜ」起きているのかに大きな役割を果たします。例えば、メトリクスは1秒あたりのHTTPリクエスト数を教えてくれますが、リクエストの急増や急減の理由を教えてくれるとは限りません。しかし、ロードバランサが過負荷になっている理由（例えば、リクエストが多すぎてCPUがスパイクしている）はわかります。 言い換えれば、メトリクスは必ずしも根本原因を明らかにするものではありませんが、高レベルの概要を提供し、問題の根本原因を見つけるための出発点となります。調査の次のステップでは、関連する情報、例えば、他の関連するメトリクス（例えば、より高いレイテンシの根本原因を探すために、サーバーの温度をチェックすることができます）、トレース、ログを調べます。 CNCFエコシステムでは、2つの一般的なメトリック・データ・モデルが見られる：Prometheusと OpenTelemetry（メトリクス）だ。 メトリックのカーディナリティ ワークロードについて収集するメトリクスの重要な特性は、そのカーディナリティです。一般に、メトリクスのカーディナリティとは、ある期間に収集された一意のメトリクス系列の数を意味します。表 1 は、t0-t1 期間のカーディナリティが 2 であることを表しています。しかし、もし100のデータセンターがあり、それぞれ10,000のホストがあったとすると、同じ期間中に100万のメトリクス系列（カーディナリティは1,000,000）を生成することになります。 100万という数字は1つの指標名としては大きく見えるが、1つのノード・データベースには簡単に収まる。例えば、Prometheusは数千万のアクティブなシリーズにスケールすることができる。また、すべてのメモリ割り当てを表すログやトレースイベントの数よりも、処理コストが大幅に安くなります。 つまり、真のコストはカーディナリティとともに増大します。メトリクスの一般的な間隔が1秒から1分の間であることを考えると、サンプル数はある期間のカーディナリティを表すこともできます。ベンダーやシステムによっては、サンプルごとに課金している場合があるのはこのためです。また、多くのシステムでは、特定の時間におけるカーディナリティの大きさに一定の制限があります。 どのくらいのカーディナリティが多すぎるのか？それは、あなたのニーズと、あなたがメトリックに費やすことをいとわない金額に依存します。また、高価なディメンジョン（多くの一意な値を持つディメンジョン）は、価格に見合った十分な価値を提供しません。 例えば、"heap-memory-bytes "を拡張して、アプリケーションごとのメモリーを追跡したいとします。最初のアイデアは、プロセスIDを表す "PID "ラベルをメトリックに追加することだ。 メトリック名 ラベルキー ラベルの値 ラベルキー ラベルの値 ラベルキー ラベルの値 時刻t0における値 t1 ヒープ・メモリ・バイト ホスト ホスト123 ピッド 22 データセンター c1 3445 3445 ヒープ・メモリ・バイト ホスト ホスト123 ピッド 24 データセンター c1 231 190 ヒープ・メモリ・バイト ホスト ホスト123 ピッド 44 データセンター c1 51331 22340 ... ヒープ・メモリ・バイト ホスト ホスト234 ピッド 34 データセンター c1 300203 412103 ... 表2は、潜在的に危険な余分なPIDラベルを持つ指標の一例について、複数の時系列を示している。 このようなメトリックのカーディナリティは実質的に無制限になり得るため、このメトリックの 実装はグレーゾーンに入る(64ビットシステムでは約400万個のPIDが可能であり、アプリケーションを 再起動するたびに新しい一意のPIDが生成される可能性がある)。各ゾーンに平均3つのレプリカを持つ100のアプリケーションを1日ホストするとする。この場合、PID ラベルは、その単一メトリックのカーディナリティを数十億にする可能性がある。 この例では、特定のアプリケーションのレプリカが使用するメモリに興味があるので、特定のアプリケーションを識別できる限り、PIDは必要ない。もし、何らかのID（例えばKubernetesのポッド名のようなもの）でレプリカを識別できるようにし、"PIDラベル "の代わりに "レプリカID "を追加すれば、"heap-memory-bytes "のカーディナリティを最大3億シリーズ（通常はそれ以下）まで減らすことができる。さらにホストラベルを削除すれば（アプリケーションのレプリカがどのホストでどれだけのメモリを使うかを気にするか）、300（全レプリカ数）×100（データセンター数）で、カーディナリティ（ひいてはコスト）をわずか3万に減らすことができる！ PID "ラベルを追加すると、カーディナリティが無制限になる可能性があるが、すべてはインフラの特性次第である。それは価値のある決断かもしれないが、偶発的なメトリックのカーディナリティの爆発（スケーラビリティの問題やコストの急上昇を引き起こす驚くほど多くの系列）になるかもしれない。 メトリクスのカーディナリティは、しばしばメトリクスのアキレス腱と呼ばれます。これは誤解を招きやすいのですが、観測可能なデータはすべてコストがかかるからです。メトリクスの効率性は、安定した次元と、時間の経過に伴うその値から生まれます。 高いカーディナリティの問題は、ユーザーが安価で効率的なメトリクス・ストレージとパイプラインを、非メトリクスの特徴を持つ観測可能性データに過剰に使用しようとするために、しばしば発生します。メトリクスが短命な系列（数サンプル）を持つ原因となっている、非常にユニークなラベル（高いカーディナリティ）に行き着いたとします。その場合、メトリクス・サンプルの代わりにイベント（ログ、トレース、プロファイル）を出力することを検討する必要があります。 過去ログ ログは、オペレーティング・システム、アプリケーション、サーバー、または他のデバイス内の使用パターン、アクティビティ、および操作を記述する1つまたは複数のテキスト・エントリです。 ログは次のようなさまざまなカテゴリーに分類することができる： アプリケーションログ- アプリケーションログは、アプリケーション内でイベントが発生したときに作成されます。これらのログは、開発者が開発中やリリース後にアプリケーションがどのように動作するかを理解し、測定するのに役立ちます。 セキュリティ・ログ- セキュリティ・ログは、システム内のセキュリティ・イベントに応じて作成される。これには、ログインの失敗、パスワードの変更、認証要求の失敗、リソースへのアクセス、ファイル、デバイス、ユーザーを含むリソースの変更、その他の管理上の変更など、さまざまなイベントが含まれます。システム管理者は、多くの場合、どのイベントをセキュリティログに含めるかを設定できます。 システムログ- システムログは、物理デバイスや論理デバイスを扱うカーネルレベルのメッセージ、ブートシーケンス、ユーザーやアプリケーションの認証、障害やステータスメッセージを含むその他のアクティビティなど、オペレーティングシステム内のイベントを記録します。 監査ログは監査証跡とも呼ばれ、基本的にイベントと変更の記録である。通常、誰がどのような操作を行い、システムがどのように対応したかを記録することで、イベントを捕捉する。多くの場合、システム管理者は、ビジネス要件に基づいて監査ログに何を収集するかを決定する。 インフラログ- インフラ管理の重要な部分であり、組織のIT基盤に影響を与える物理的および論理的な機器の管理を含む。これは、オンプレミスでもクラウドでも可能であり、API、Syslog、またはホストベースのエージェントを使用して収集されたその他のものを介して取得される。 ログは、メトリクスやトレースを導き出すため、セキュリティ監査のため、あるいはデバッグのためなど、さまざまなシナリオで役立ちます。アプリケーションとシステムに関連するすべてのイベントの記録を保持することで、特定の状況に至るステップ・バイ・ステップのアクションを理解し、再現することさえ可能になります。これらの記録は、障害が発生した瞬間のアプリケーションやシステムの状態を理解するための情報を提供する根本原因分析を実行する際に、特に価値があります。 ログに保存されている情報は自由形式のテキストであるため、意味を導き出すのが難しい。過去30年間、ログにスキーマを適用する試みが数多くなされてきたが、特に成功した例はない。スキーマを使う理由は、関連する情報をよりアクセスしやすくするためである。一般的にこれは、ログファイル内のテキストを解析し、分割し、分析することによって行われる。ログ・データは、メトリクスやトレースなど、他の観測可能なシグナルに変換することもできます。いったんデータがメトリクスになれば、経時変化を理解するために使用できる。ログデータは、ログ分析技術によって可視化・分析することもできます。 ログレベルは、各ログ文の重要度を表すことができる。このようなログレベルの1セットは、ERROR、 WARNING、INFO、DEBUGである。ERRORが最も詳細のないレベルで、DEBUGが最も詳細なレベルです。 ERRORは、障害が発生した理由と詳細を伝える。 WARNINGは、故障ではないが注意を要する高レベルのメッセージである。 INFOメッセージは、システムがどのように機能するかを理解するのに役立つ。 DEBUGは、各アクションの詳細情報が保存されるレベルである。通常、トラブルシューティング時や、ストレージやパフォーマンスへの影響から短期間のみ使用されます。 複数の冗長性レベルを使用して、トラブルシューティングや根本原因の分析を支援する詳細な情報を生成します。 複数の方法でログを転送することが可能である。最初の提案は、ログを中央の場所に直接送るように標準ストリームを設定することである。次に、ログをメッセージ・キューに書き込み、最終的な宛先に到達する前にフィルタリングまたはエンリッチする。最後の方法は、オープンソースのデータ・コレクター・アプリケーションを使用して、ログを中央のリポジトリに送信する。ログを他の観測可能なシグナルと組み合わせて、システムの完全なビューを持つ。 セキュリティは、ロギング・ソリューションを計画する際に念頭に置かなければならないものです。ログ関連のファイルや情報を、保存時および中央リポジトリに送信する際の転送時に暗号化する。個人を特定できる情報（PII）をいかなるログにも保存しないこと。最後に、本当に重要なデータは、ログだけに保存すべきではない。ログ文は有用であるにもかかわらず、その配信は保証されていない。 痕跡 分散トレースとは、エンドユーザーによって開始されたリクエストのような分散トランザクション中に何が起こったか、そしてその結果としてタッチされたすべてのダウンストリームのマイクロサービスやデータストアにまたがるその影響を理解する技術です。 トレースは通常、"トレース・データ・ポイント "のツリー、あるいはスパンと呼ばれるもので、次の例のようにガント・チャートとして可視化される： Image 1 画像1はJaegerプロジェクトのUIで、指定されたトレースのスパンを視覚化している。 トレースは通常、1つの具体的なトランザクション・インスタンス、つまりコンピュータが特定のプログラムを通じてたどった経路を表す。スパンは高度に文脈化されている。特に、スパンはそれを開始した「親」スパンに関する情報を記録する。これにより、サービス、キュー、データベースなど、分散システムの異なるアクター間の因果関係を確立することが可能になる。 異なるアクター間の関係を持続させる重要なメカニズムは、コンテキスト伝播である。多くの監視システムが独自の方法でトレースコンテキストのプロパゲーションを実装している一方で、業界はトレースコンテキストのプロパゲーションを標準化すべきであることに合意した。これは、W3C Distributed Tracing Working Groupの設立と、それに続くW3C Trace Context Specificationのリリースにつながりました。W3C Trace Context は、分散トレースシナリオを可能にするコンテキスト情報を伝播するための標準 HTTP ヘッダと値のフォーマットを定義しています。この仕様は、コンテキスト情報がサービス間でどのように送信され、変更されるかを標準化するものです。コンテキスト情報は分散システムにおいて個々のリクエストを一意に識別し、プロバイダ固有のコンテキスト情報を追加・伝播する手段を定義しています。 今日、OpenTelemetry のようなプロジェクトや .NET のようなプラットフォームは、標準的な伝播フォーマットとして W3C Trace Context を使用しています。また、ログと Prometheus メトリクスに付けられたトレースとスパンの ID である Exemplars も同じフォーマットに従っている。より多くのクラウド・ネイティブ・プロジェクトがこの道を歩んでおり、他の設計目標がない場合は、W3C標準の使用が推奨される。クラウド・インフラストラクチャ・プロバイダーがこれをサポートすれば、サービス・ゲートウェイのようなマネージド・サービスを経由しても、コンテキストが壊れることはない。 インスツルメンテーションは全ての観測可能性シグナルにとって重要であるが、複雑さを考えると、分散トレーシングにおいて不可欠な役割を果たす。Instrumentationはデータポイントを作成し、サービス間のコンテキストを伝播します。コンテキストの伝播なしでは、入ってくるHTTPリクエストとそのダウンストリームのHTTPリクエスト、あるいはメッセージプロデューサーとそのコンシューマーを結びつけることはできません。 インスツルメンテーションには、分散トレースのための2つの主な目的がある：コンテキスト伝搬とスパンマッピングである。ほとんどの場合、コンテキスト伝搬はHTTPクライアントやサーバーと統合可能なライブラリを使用して透過的に行われます。このパートでは、OpenTelemetry API/SDKのようなプロジェクト、ツール、技術が使用できます。 Figure 2 図2は、ネットワーク・コールのスパン関係を示している。 プロフィール 企業がクラウド・ネイティブ・アプリケーションの最適化を進めるにつれ、パフォーマンス指標を可能な限り詳細なレベルで把握することがますます重要になっています。プロファイルを継続的に収集することで、特定のシステムになぜそのような問題が発生しているのかを掘り下げて確認することができます。 他のユースケースやリソースに使えるプロファイラーもいくつかある： CPUプロファイラ ヒーププロファイラ GPUプロファイラ ミューテックス・プロファイラ IOプロファイラ 言語固有のプロファイラー（Go pprof、JVM Profiler、現在Javaに追加されているpprofサポートなど） プロファイリングには多くのサブタイプがあるが、リソースのシステム内での割り当てを理解するという目的は同じである。 従来、プロファイリングは、システムの可視化に伴うオーバーヘッドが大きいため、本番環境での実行には適さないと考えられてきた。しかし、サンプリング・プロファイラの人気のため、クラウド環境ではますます人気が高まっている。オーバーヘッドが数パーセントしか追加されないため、本番環境でのプロファイリングは実行可能なオプションとなっている。 プロファイリングデータに「時間」軸を追加することで、静的なプロファイルから得られるきめ細かさと洞察が得られ、きめ細かな視点と鳥瞰図からデータを理解し、検査することができる。リソースを総合的に理解することは、クラウド・ネイティブ・アプリケーションの最適化／デバッグや、リソースの割り当て方法を計画する上でますます重要になる。 トレースによって、アプリケーションのどの部分にレイテンシの問題があるのかを理解する選択肢が広がるのと同様に、プロファイリングによって、さらに深く掘り下げ、レイテンシの問題がなぜ存在するのかを理解することができます。さらに、コードのどの部分が最もサーバリソースを使用しているかを理解するのに役立ちます。 ランタイムが生成するプロファイリング・データには、通常、行番号までの統計が含まれているため、コードの「何を」から「なぜ」に直接たどり着くには最適なデータである。 Image 2 画像2は、Goで書かれたアプリケーションのCPUプロファイルのつららグラフの例である。これには、Syscallコールで実行されるカーネル操作が含まれています。このプロファイルは、CPU時間の35%がハッシュの計算に使用されていることを強調し、最適化の可能性を示しています。ソースはこちら。 ダンプ ソフトウェア開発では、コア・ダンプ・ファイルはプログラム、すなわちクラッシュしたプロセスのトラブルシューティングに使用される。古典的には、オペレーティングシステムは、場所、名前の規則、ファイルサイズなどの何らかの設定の助けを借りて、分析のためにクラッシュ時のプロセスのメモリのイメージを書き込む。しかし、クラウドネイティブでは、大規模クラスタのコアダンプファイルの収集は、クラスタのストレージがクラスタノードにどのように接続されているかによって、ストレージやネットワークのボトルネックになりやすい。たとえば、処理負荷の高いアプリケーションでは、2桁ギガバイトのコアダンプファイルが生成される可能性があります。 Linuxベースのシステムでは、コアダンプファイルはグローバル設定（/proc/sys/kernel/core_pattern）によってどこにでも書き込むことができます。カーネル2.6以降では、いわゆるコアダンプハンドラーを使った、コアダンプを扱う新しい方法がある。これは言い換えれば、ファイルの収集をオペレーティングシステムに委ねる代わりに、クラッシュしたプロセスの出力をアプリケーションの標準入力にプッシュし、そのアプリケーションはファイルの書き込みを担当するということです。例えば、Debianベースのディストリビューションでは、systemdとabortの両方をサポートしている。RedHatベースのディストリビューションは、いわゆるABRTを使用している。 今日現在、クラウドネイティブコミュニティは、コアダンプの収集についてまだ助けを必要としている。少なくとも2つの主な理由を強調したい：アプリケーション開発者が、名前の規約やサイズ、あるいはファイルの収集場所さえも設定するためのすべてのノブにアクセスできたシステムと比べると、クラウドネイティブでは、アプリケーションやインフラの所有者の役割が明確でないため、グローバルなシステム設定への（特権的な）アクセス権が少なくなっている。さらに、データの永続性はクラウドネイティブ環境に固有のものだ：クラッシュしたアプリケーション（例えばポッド）は、再起動する前にコアダンプファイルを永続ボリュームに書き込むための収集支援が必要です。約6年前のRFC（https://lore.kernel.org/patchwork/patch/643798/）では、グローバルなシステム設定としてコアパターンを持つ代わりに、名前空間化されたコアパターンのサポートをLinuxカーネルコミュニティに要求していました。また、Dockerコミュニティでは、Dockerでcore_patternをサポートすることを求める同じ年代の人たち（moby/moby#19289）がissueをオープンしている。 観測信号の相関 間違いなく、観測可能な空間は複雑である。前のセクションで学んだように、私たちが実行するソフトウェアの状態と動作についてより詳しく知るために、私たちは様々な角度から、様々な間隔とパイプラインで、様々なデータタイプを収集する：メトリクス、ログ、トレース、プロファイル、コアダンプ。 最初に思い浮かぶ疑問は、なぜこれほど多くのタイプを作らなければならないのか、ということだ。ただ1つの "キャッチーでオールマイティ "なものではだめなのだろうか？問題は、それができないことだ。同じように、アスファルトの道路とオフロードの両方で効率的に機能する自転車を1つにすることはできない。信号の種類はそれぞれ、その目的に高度に特化している。メトリクスは、信頼性が高く安価なモニタリングとスケールでの分析（信頼できるシステムの基盤）を中心に据えている。我々は、より多くのコンテキストのために、実行中のシステムに関するより小さな詳細についての洞察を与えてくれるログラインを収集する。ある時点で、その詳細はリクエストツリーを形成するので、分散トレーシングはそのスパンとクロスプロセスのコンテキスト伝搬で登場する。どのコードが非効率的で、予想外の量のリソースを使用しているかをチェックするために、より深く、パフォーマンス・アプリケーション・プロファイルに飛び込まなければならないこともある。コアダンプをキャプチャすることで、アプリケーションクラッシュに関する貴重な洞察を得ることができる。 たった1つのシグナルを持つだけで、完全で便利な観測可能性ストーリーを実現できることはほとんどありません。例えば、メトリクスの詳細（カーディナリティ）を増やしすぎるのはコストがかかりすぎるし、アラートに必要なほぼリアルタイムのレイテンシで、ありとあらゆる操作を確実にトレースするにはコストがかかりすぎる。そのため、多くの組織は、観測可能性のストーリーのために複数のシグナルを導入し、活用することを目指している。 マルチシグナル・オブザーバビリティ・ストーリーを構築する場合、克服すべき課題がいくつかある。大規模なベンダーと契約しない限り、各観測信号用に別々のシステムが必要になる可能性が高い。これは、各シグナルのパフォーマンス特性や使用パターンが異なるためで、異なるストレージ・システムやその他の設置方法が必要になる可能性が高い。 さらに、4つ以上の観測可能なシグナルがあることを考えると、観測可能なシステムのユーザーは、4つ以上の異なるUIと各シグナルを取得するAPIを理解するために、かなり大きな学習曲線が必要になるかもしれません。例えば、メトリックスやロギングにしか精通していない場合、トレーシングやプロファイリングをほとんど使用しないなど、近道をしようとするユーザを見ることは珍しいことではありません。 各観測可能性シグナルをサイロに保管する代わりに、異なるシグナル間のシームレスな移行を可能にする方法があります。このセクションでは、シグナルの相関関係と、それがどのように観測可能性の使用体験に役立つかについて説明する。 推薦の言葉これらすべてを受け入れるのは大変なことだ。今日、何から始めるべきか決める必要があるなら、既にあるものから始めよう。クラウドネイティブやネットワーク環境では、メトリクスから、より伝統的なセットアップではログから始めることができるだろう。メトリクスをうまく使えるようにしてから、他のシグナル・タイプに手を広げよう。そうすることで、価値を見出すまでの時間が最も短くなり、コスト効率も最も良くなります。 信号相関 データを相関させる基本的な方法は2つある：自分で相関関係を構築する方法と、すでにあるデータを活用する方法だ。 できる限り、すべてのオブザーバビリティ・シグナルに同じメタデータ構造を使うべきだ。例えば、KubernetesやPrometheusを使っている場合、すでにメトリクスにラベルを使っているはずだ。できる限り、ログにも同じラベルを使いましょう。 もし自分で作らなければならないなら、すべてのシグナルに共通するデータを見てみよう： Figure 3 図3は、4つの観測信号間の共通リンクを示している。 すべての観測可能なシグナルを継続的に収集するおかげで、すべてのデータはあるタイムスタンプにスコープされる。これによって、ある時間ウィンドウ（時にはミリ秒まで）内のシグナルに対してデータをフィルタリングすることができる。別の次元では、上の図に示された状況のおかげで、観測可能性シグナルのそれぞれは、通常、特定の "ターゲット "にバインドされている。ターゲットを特定するためには、ターゲットのメタデータが存在する必要があり、理論的には、ターゲットからのメトリクス、プロファイル、トレース、ログラインを見ることができます。さらに絞り込むと、観測可能性データが収集されたコードコンポーネント、例えば "ファクトリー "に関する余分なメタデータを全てのシグナルに追加することは、珍しいことではありません。 Figure 4 図4は、一貫したターゲット・メタデータを使用して、異なる観測可能性シグナル間をジャンプする方法を示している。 図4に示したフローだけでも、特定のプロセスやコードコンポーネントと時間に関連する各シグナルから項目を選択することで、各シグナルから素早くナビゲートできるため、かなり強力だ。この点を考慮すると、Grafanaのようないくつかのフロントエンドでは、すでにこのようなリンクやサイドビューを作成することができる。 しかし、これで終わりではない。我々は時々、トレースやロギングに付随する更なる詳細を持つことがある。分散トレースは、単一のトレースIDの下ですべてのスパンを束縛することからその力を得る。この情報は、関数から関数へ、プロセスからプロセスへ、同じユーザーリクエストに対する操作をリンクするために注意深く伝搬されます。リクエストIDやオペレーション ID と呼ばれる、 リクエストに関連する同じ情報をログラインで共有することは珍しいことではありません。ロギングとトレース間のこれらのIDが同じであることを保証する簡単なトリックで、我々はそのような低レベルのスコープでお互いを強くリンクします。これにより、ログライン間を簡単に行き来でき、個々のリクエストに結びついたスパンやタグをトレースできるようになります。 Figure 5 図5は、リクエストIDまたは操作IDを使ってログとトレース間をジャンプする方法を示している。 このようなレベルの相関関係は、いくつかのユースケースには十分かもしれないが、重要なものを見逃しているかもしれない：大規模！このような大規模システムのプロセスは、少数のリクエストを処理するのではない。膨大に異なる目的と効果のために、何兆ものオペレーションを実行するのだ。たとえ一瞬でも、一つのプロセスから全てのログラインやトレースを取得できたとしても、その時処理されている何千もの同時リクエストから、あなたの目的に関連するリクエスト、操作、トレースIDをどうやって見つけるのでしょうか？強力なロギング言語（LogQLなど）を使えば、ログレベル、エラーステータス、メッセージ、コードファイルなどの詳細についてログをgrepすることができます。しかし、これには、利用可能なフィールド、そのフォーマット、およびそれがどのように状況にマッピングされるかを理解する必要があります。 特定のエラーの数が多いとか、エンドポイントの待ち時間が長いというアラートで、 影響を受けたリクエストIDをすべて知ることができたら、もっといいと思いませんか?そのようなアラートはおそらくメトリクスに基づいていて、そのようなメトリクスは、おそらくログラインやトレースも生成し、そのリクエスト、操作、またはトレースIDが割り当てられている、いくつかのリクエストフローの間にインクリメントされましたよね？ しかし、ご存知のように、このような集計されたデータは、メトリックスや複数のリクエストの結果を組み合わせたログラインのように、設計上、集計されます（驚！）。私たちは、コストと集中の理由から、すべての（時には何千もの）リクエストのIDを集計の一部として渡すことはできない。しかし、これらのリクエストについて、活用できる便利な事実があります。関連するすべてのリクエストは、このような集計された指標やログラインのコンテキストでは、ある程度等しいのです！ですから、すべてのIDを保持する必要はないかもしれません。例のケースを表すものを一つ添付すればいいのです。これが模範例と呼ばれるものです。 Exemplar: 何かの典型的な、あるいは良い例。 Figure 6 図6は、ターゲットメタデータ、リクエストID、操作ID、または模範例 を使用した、すべての可能なリンクを示す。 私たちは、完全な観測可能システムにおいて、すべてのリンクをミックスして使用することができ、複数の信号や視点からシステムを検査する際にスムーズな柔軟性を与えてくれる。 理論的には、プロファイルに模範解答を添付することもできます。しかし、プロファイルの特殊性とユースケース(インプロセスのパフォーマンスデバッグ)を考慮すると、1つのプロファイルを1つのリクエストや操作にリンクする必要があることは稀で、ログのトレースを得ることができます。 実用的なアプリケーション 信号の間をナビゲートする方法について説明したが、それは役に立つのだろうか？つの基本的な例を簡単に見てみよう： Figure 7 図7は、アラートから始まり、スムーズな観測可能性相関を利用したトラブルシューティングの例を示している。 SLOを超える予想外の高いエラー率に関するアラートが届いた。アラートはエラーのカウンタに基づいており、501のエラーになるリクエストの急増が見られます。人間にとってわかりやすい正確なエラーメッセージを知るために、exemplarで例のログラインに移動します。エラーは多くのホップの背後にある内部マイクロサービスから来ているようなので、トレースIDに一致するリクエストIDの存在のおかげでトレースにナビゲートします。そのおかげで、どのサービス/プロセスが問題の原因かを正確に知ることができ、さらに深く掘り下げることができます。 Figure 8 図8は、トレースから開始し、ターゲット・メタデータの相関を利用するトラブルシューティングのストーリーの異なる例を示している。 遅いリクエストをデバッグする。トレースサンプリングでリクエストを手動でトリガーし、トレースIDを取得した。トレースビューのおかげで、リクエストの途中にあるいくつかのプロセスの中で、基本的な操作のために驚くほど遅いABC-1リクエストがあることがわかる。ターゲットメタデータと時間のおかげで、関連するCPU使用率メトリクスを選択する。マシンの限界に近い高いCPU使用率が見られ、CPUが飽和していることを示している。CPUの使用率が高い理由（特にコンテナ内の唯一のプロセスである場合）を知るために、同じターゲットメタデータと 時間の選択を使ってCPUプロファイルに移動します。 実践的な実装 豊かな相関性を持つマルチシグナル観測可能性は、まだ発展途上である。あなたやあなたの使っているプロジェクトが、その一面しか実装していなくても心配しないでください。このセクションでは、典型的なシステムでシグナルをリンクさせることができるいくつかの意味的な規約について説明します。図3と図6で述べたリンクを確保するために実装しなければならない項目を反復して説明しよう： すべての信号に一貫したターゲット・メタデータが付加される。 同じターゲット（例えば同じアプリケーション）からの観測可能性シグナルを切り替えるために、一貫したメタデータが必要だ。これは、PrometheusやOpenTelemetry Prometheusレシーバー（メトリクス）、ログテーリングコレクター（OpenTelemetry、Fluentd、Fluentbitなど）のようなプルベースのシステムを活用し、一貫性のあるターゲットラベルや属性、例えば "cluster"、"environment"、"pod"、"container_name "がコレクターやエージェントによってアタッチされていることを確認することを意味するかもしれません。OTLP（メトリクス、ログ、トレース）のようなプッシュベースのコレクションを扱う場合、インスツルメンテッドアプリケーションは通常ターゲット情報をアタッチし、一貫性を確保します。 オペレーションID、リクエストID、またはトレースIDを同じユニークなIDにし、ロギングシステム（トレースだけではありません！）に添付することを検討してください。 トレースとロギングクライアントインスツルメンテーションを組み合わせて、トレースライブラリがトレースIDを生成するようにしてください。同じトレースIDは、リクエストに関連するイベントをログに記録する際に、ログラインに添付することができます。 楽器の模範。 模範解答を有効にするには、通常クライアントのインスツルメンテーションを変更しなければならない。これは、Trace ID（有効な場合）を関連するメトリクス（例えばリクエストレイテンシのヒストグラムなど）に注入しなければならないからです。多くのPrometheusクライアント（Goなど）とOpenTelemetry SDKはexemplarsをサポートしているので、対応するインスツルメンテーションコードを変更するだけです。将来的には、模範解答を自動的に注入するライブラリや自動計測ソリューションが増えるかもしれません。 使用例 観測可能性とそのシグナルについて、より高度な使い方と分類を見ていこう。 ボックス・ベースのモニタリング・カテゴリー モニタリングは、既知の未知数を検出できるシステムと呼ばれることもある。未知の未知数についても発見し推論できることを重視する観測可能性とは対照的だ。 モニタリングは、従来はシステム管理者またはオペレーター（運用担当者）の関心事だった。ソフトウェアはモニタリングを念頭に置いて開発されておらず、運用担当者は外部シグナルからシステムの状態を推測しなければならなかった（時にはシグナルを「誘発」する、別名プロービング、例えばブラックボックス・エクスポーターを使用する）。これがクローズ・ボックス・モニタリングと呼ばれるものだ。 つまり、コードのインスツルメンテーションは開発プロセスの一部となり、もちろん、モニタリングは開発プロセス（デバッグ、最適化）にも利益をもたらす。これは、ソフトウェアの箱を開けなければならないことを意味し（オープン・ボックスという名前の由来）、インスツルメンテーションは観測可能性を高めるための重要なステップとなる。 オープン・ボックス・モニタリングは、より複雑な計測器を必要としますが、アプリケーションからより正確で効率的な信号を得ることができます。クローズ・ボックス・モニタリングは、モニタリングの必要に応じてアプリケーションを変更できない場合や、ユーザー・エクスペリエンスを正確に測定したい場合にも有効なオプションです。 SLI、SLO、SLAの実施 SLI、SLO、SLAメトリクスの導入により、サービス品質と顧客の満足度を客観的に測定できます。さらに、組織内のビジネス、製品、エンジニアリングのような異なる機能間で、共通の用語セットを提供します。エンジニアリングの時間はどの組織においても希少なリソースであるが、誰もが自分の問題を切実な問題として感じている。SLO は、SLO に違反した場合のビジネス上の結果を誰もが理解することで、そのような会話をよりデータドリブンにする。一方、内部の対立を解決することは、意味のある実行可能なアラートを可能にする意味のある抽象化を提供することで、より顧客志向にする。 実装の詳細に深く飛び込む前に、定義を明確にしておく必要がある。 サービス・レベル指標（SLI）：SLIとは、提供されるサービス・レベルのある側面（例えば、現時点でのテール遅延やエラー率）について、注意深く定義された定量的尺度（通常はメトリック）である。 サービス・レベル目標（SLO）：SLOとは、どれくらいの頻度で障害が発生するかを示す目標。SLIが測定するサービスレベルの目標値または値の範囲。SLOは多くの場合、当初はかなり制限的に設定され、後で調整される。後でSLAを確定するだけでなく、開発目標を設定することも役に立つ。 サービスレベル合意（SLA）：SLAとは、SLOまたはSLOの少し緩和されたバージョンに違反した場合の結果を含むビジネス契約である。 エラーバジェット：SLOによって決定される期間における故障イベントの許容範囲。これは100%からSLOを引いた値である。 詳しくはGoogle SRE Bookをご覧ください。 提案されたSLOが有用で効果的であるためには、すべての利害関係者がそれに同意しなければならない。プロダクトマネジャーは、この閾値がユーザーにとって十分なものであることに同意しなければならない。この値を下回る性能は許容できないほど低く、エンジニアリング時間を費やして修正する価値がある。製品開発者は、エラー予算が使い果たされた場合、サービスが予算内に戻るまで、ユーザへのリスクを減らすために何らかの手段を講じることに合意する必要がある。このSLOを守ることを任務とする本番環境の責任者チームは、チームの長期的な健全性とサービスに損害を与えるような多大な努力、過度の労力、燃え尽き症候群を伴わずに、このSLOを守ることが可能であることに合意している。 Figure 9 図9は、SLI、SLO、およびSLAを定義するために必要な手順を示している。 オブザーバビリティ・データに対する警告 Observabilityデータに対するアラートは、監視対象システムの問題を検出する能力をユーザに提供します。メトリクス・コレクションが広く採用される以前は、ほとんどのソフトウェア・システムは、問題のトラブルシューティングとトリアージ、およびシステムの可視性を得るために、ログのみに依存していました。ログの検索とダッシュボードに加えて、ログとプローブは、多くのチームとツールの主要なアラート・ソースとして機能しました。この方法は、今日でも多くの最新の観測可能性システムに存在しますが、一般的には時系列メトリクスでのアラートを優先して避けるべきです。より具体的には、定義されたSLOとエラーバジェットを使用して、実行可能なアラートを実行することについて見ていきます。 時系列データにはアラート可能なシグナルが多数あり、その多くはアプリケーション固有のものである可能性が高い。推奨されるベストプラクティスは、チームの SLO を使用してアラートを実行することです。上述したように、SLOはサービスレベル目標であり、サービスレベル指標によって測定されるサービスレベルの目標値または値の範囲です。例えば、REST API の SLO は、「リクエストの 95% を 500 ミリ秒未満で処理すること」とすることができます。チームに効果的なアラートを出すために、エラーバジェットも定義する必要があります。SLOとエラーバジェットを組み合わせて、実用的なアラートを出す方法を見ていきます。 注意喚起の実際 アラートの構築は非常に複雑であり、誤検知に圧倒されアラート疲れを起こしやすい。アラートは実用的であるべきで、誰かが対処すべき問題を示すものでなければならない。 例えば、「ページング」アラートと「チケッティング」アラートには違いがある。ここでの用語は実にさまざまだ。ある人は "アラート "と言いますが、具体的には "ページング"、つまり誰かが目を覚ますほど緊急に必要な人的介入を意味します。 発券」アラートの有用性は過小評価されがちである。つまり、いずれは注意が必要だが緊急ではないアラートである（大規模システムでは常に何かが壊れるものであり、そのような壊れにはある程度耐えられるように設計されている）ため、例えば壊れた重要でないディスクを交換するなど、業務時間中の通常業務の一部として使用することができる。 シンプルなアプローチ、燃焼率に基づくアプローチ、そしてMLモデルに基づくアプローチだ。 目標エラー率 目標エラー率で警告するのは、一般的なアプローチである。小さな時間枠、例えば10分を選び、その時間枠のエラー率がSLOを超えたらアラートを出す。 たとえば、SLO が 99.9% の場合、過去 10 分間のエラー率が >= 0.1% であれば警告します。Prometheus では、これは次のようになります（HTTP リクエストエラーの合計を過去 10 分間の全リクエストの合計で割ったもの）： (sum(rate(http_requests_total{code=~"5.*"}[10m])) / sum(rate(http_requests_total[10m]))) > 0.001 これには、アラートロジックで何が起こっているかを簡単に確認でき、エラー発生時に迅速にアラートを配信できるという利点がある。しかし、このアラートは、定義したSLOに違反していない多くのイベントで発せられる可能性が高い。 燃焼率 燃焼率に関するアラートは、より洗練された方法であり、より実用的なアラートが得られる可能性が高い。まず、バーンレートとエラーバジェットをより詳細に定義しよう。 すべてのSLO定義に内在するのは、エラーバジェットの概念である。SLOを99.9%とすることは、0.1%のエラー率（すなわちエラーバジェット）を、事前に定義された時間（SLOウィンドウ）は許容できる、と言っていることになる。「バーンレートとは、SLOに対してサービスがエラーバジェットを消費する速さのことです。SLOが99.9％で、30日間という時間枠の場合、一定の0.1％のエラー率でエラー予算がすべて消費されます。8 Figure 10 図10は、燃焼速度に対する誤差を示している。 燃焼率 99.9%SLOのエラー率 疲労困憊 1 0.1% 30日 2 0.2% 15日 10 1% 3日 1000 100% 43分 表3は、燃焼率と予算消化完了までの時間を示している。 バーンレートは、ウィンドウのサイズを小さくし、検出時間が長く精度の高いアラートを作成することを可能にします。この例では、アラートウィンドウを1時間に固定し、5％のエラー予算が誰かに通知するのに十分重要であると判断すると仮定します。 燃焼率に基づく警報の場合、警報が発せられるまでの時間は以下の通りである： (1 - SLO / error ratio) * alerting windows size * burn rate そして、警告が発せられるまでに消費されるエラー予算は以下の通りである： (burn rate * alerting window size) / time period つまり、30日分のエラー予算の5％を1時間以上費やすとすると、燃焼率は36となる。警告のルールはこうなる： (sum(rate(http_requests_total{code=~"5.*"}[1h])) / sum(rate(http_requests_total[1h]))) > 36 * .001 異常検知 このセクションは警告の言葉から始めよう：十分に大規模なデータセットであれば、相関関係を見つけることができる。例えば、海賊の数と地球温暖化は、近年温暖化が急激に進むまで、ほぼ200年間は反比例していた。 しきい値ベースのアラートは、既知の値に基づいてアラートを構成するメカニズムをユーザーに提供する一方で、季節性や進行中のロールアウト、その他のシナリオによって引き起こされるデータの変動に適応することができず、硬直的になる可能性がある。 機械学習技術と統計モデルを使用することで、数ヶ月分の行動パターンを理解し、現在観測されているサンプルが異常かどうかを判断するのに使用することができる。観察されているシステムの問題を検出するメカニズムとして、異常検知を採用した学術的な研究やオープンソースの実装がいくつか存在する。この件に関するeBayのユーザーストーリーを参照。 MLベースの動的しきい値には複雑さが伴う。このようなアラートが、人間や自動的な修復を促すのに十分な信頼性があるかどうかについては議論がある。しかし、トラブルシューティングの提案やヒントとして非常に価値があることは間違いない。 根本原因分析 観測システムが問題を検出したら、その問題をトリアージする必要がある。根本原因の分析は通常、手動または自動化された技術によって行われ、ログ、メトリクス、トレースを通じて利用可能なさまざまなシグナルを調べ、問題の最も有力な原因を特定します。複数のマイクロサービスからのデータを処理し、根本原因に対する推奨を開発するイベントグラフベースのアプローチに依存する洗練された技術は、大規模分散システムのトリアージにかかる時間を大幅に短縮します。 観測可能性に関する現在のギャップ このセクションでは、CNCFエコシステムにおいて、より多くの作業を必要とする観測可能性に関連する領域を探ります。このセクションは、素晴らしいプロジェクト、標準、ブログ記事、あるいはビジネスのための部屋だと考えてください！ もしかしたら、そのうちのいくつかに対する答えを持っていて、このホワイトペーパーに貢献できるかもしれない。そうすることは大歓迎である（貢献のページを参照）。 時間が経てば、CNCFのオープンソース・スペースにおけるこれらのギャップを埋められるだろう。いくつか紹介しよう： OSSにおける自動的かつ非侵入的な計装化 アプリケーションのオーナーは、観測可能性のシグナルを収集するために、しばしばソースコードを修正し、異なるエージェントを参照しなければならない。そして、さらに多くのシグナルが来ることがわかります。オープンボックスシグナルを自動的に推論し、収集パイプラインと統合するソリューションが増える余地がある。 標準化されたクエリーレイヤー 観測可能性データシステムには様々なドメイン固有言語（DSL）が存在するが、それらの間の一貫性や相互運用性はほとんどない。観測可能性は開発経験の基礎的な側面であり、豊富な遠隔測定インジェスト、ストレージ、処理システムが利用可能である。データやクエリを移行するために、ユーザーはしばしば特注のツールを書かなければならないため、他のベンダーやツールに乗り換えることは依然として困難である。そのために、ユーザーは、以前のシステムとの明白な違いがない、異なる観測システムの複雑さを学ぶのに時間を費やさなければならない。OpenTelemetry (OTel)イニシアチブは、クライアントの互換性と取り込みの観点から、オープンソースプロジェクト/ベンダー間の相互運用を可能にする。OTel をヒントに、データがどのように照会されるかを標準化し、データを表現するために使用されるスキーマ／用語を標準化する作業がまだ必要である。 OSSにおけるより多くの観測可能性データベース 私たちは、すべての観測可能性シグナルがOSSや非AGPLソフトウェア、特にCNCFの下だけを使って簡単に実装できるわけではないことを認めます。成熟したメトリクス・データベース（Prometheus、Thanos、Cortex）がある一方で、CNCF傘下のロギング、トレース、プロファイリング・データベースはありません。しかし、CNCFの外には多くの素晴らしいソリューションがあり、ライセンスが少ないものや寛容なものもある。 ストリーミングAPIのモニタリング 今日、非常によく知られたモニタリング手法がいくつかある。例えば、Brendan Greggがコンピュートリソースを監視するために説明したUSEメソッドや、Tom Wilkieがリクエストベースのサービスを監視するために考案したREDメソッドなどである。 残念ながら、どちらの方法論もストリーミングAPIに実装するのは難しい。gRPCのようなストリーミング・リモート・プロシージャ・コール（RPC）の普及に伴い、私たちはそれらを監視するための新しい、あるいは更新された方法論とツールを開発しなければならない。