tag-observability/whitepaper.md at main · cncf/tag-observability
※引用はDeepL
エグゼクティブサマリー
SaaSに携わるエンジニアは、もはや全員、アプリの監視と観測の方法を理解できなきゃいけない
世の中そうなってんだよ、クラウドネイティブなんだよ
イントロ
動いてるサービスに手を加えることなく観測したいね
そのためには観測可能なメカニズムを組み込む必要があるんですよ
で、これは設計初期やらやらないとあかんのですわ
それにコードの自動化や計測も要るのでハードルも高い
文化的ハードルもありがちなんだってさ🐰
だから俺たちが「結局どうすればええねん?」の道標を明快に教えてやるよ
対象読者
まあ現役のエンジニアですわ
マネージャーとかも読んでもええよ
コンピュータサイエンスの学生でも読めるかもしれん
ゴール
先駆者の先行事例を教えてやるよ。お前ら初心者にはありがたいぜ?二の鉄ふまずに済むぜ?
未解決問題や解決方法が市場にあまり浸透してないネタもついでに教えてやるよ
o11yって何?
まずオブザーバビリティって言葉が独り歩きしてるんで、ここで扱う「ちゃんとした意味」を見てくれな
本質は制御理論のこれ
可観測性とは、システムの外部出力の知識から、システムの内部状態をどれだけうまく推測できるかを示す尺度である
便利なossの対等ですぐ使えるようになったけど、どんな出力があるかわからん
あれもこれも必要と迂闊に追加した結果、「え?データレイクでもつくるん?w」となる
o11yってさ、目標ちゃんと決めるところからなんだよね
観測可能性は、文字通りシステムの開発ライフサイクルのあらゆる局面で活用することができます。新機能のテスト、本番環境の回復力のモニタリング、顧客の製品使用に関する洞察、製品ロードマップに関するデータ駆動型の意思決定など、あらゆる場面で利用できます。
何でもできるからこそ、何がしたいかをちゃんと決めるってことなのかな?🐰
とりあえず出力から見ていこうぜ。シグナルっちゅーねん
シグナル
シグナルとはシステムが出す出力のこと
3本柱――メトリクス、ログ、トレースは聞いたことある人も多いよね
業界標準といわれている
が、実はこれ不完全
他にもプロファイルとかダンプとか色々ある
まだ確立されてねえのよ
すべてを全部記録・表示・分析しきることはできない
結局はトレードオフなのよ
メトリクスは統計的(aggregatableと表現されている🐰)
ログはundistributed events
トレースはrequest-scoped distributed events
で、トレースとログはディスクを食いがち
メトリクス
データを数値化したもの
温度みたいにすでに数値化されたものと、プロセスカウンタみたいに数値化するものがある
状態を時系列に淡々と記録したものである
用途は2つ
リアルタイムに見えるようにしたりアラート出したり
分析したり洞察出したり
主に何が起こっているかを教えてくれる
割とトラシューの出発点になるようですねぇ🐰
ログ
テキストのストリーム
OS、アプリ、サーバーその他デバイス上で記録される
使用パターン、活動や操作を記録する
主に以下がある
アプリケーションログ。アプリイベント。
セキュリティログ。セキュリティイベント。
監査ログ。イベントの変更と記録。アクティビティ。
システムログ。カーネルなどOSレベル。
インフラログ。
インフラストラクチャー管理の重要な部分であり、組織のIT基盤に影響を与える物理的・論理的機器の管理を含む。これは、オンプレミスまたはクラウドにあり、API、Syslog、またはホストベースのエージェントを使用して収集した他のいずれかを介して取得されます。
ちょっと何言ってるかわからない🐰
ログメッセージの解読は一般的には難しい
コンテキストがないから
原文ではtextとなってるのでたぶん誤字?contextだろ?🐰
ログのスキーマ化は無理やね
この30年で成功例がないとまで言っている
ログレベルがある
知ってるので割愛🐰
転送戦略はいくつかある
1 中央集権的な場所に直接送る(標準ストリームを設定)
2 キューに書き込み、最終目的地に送る前にフィルタリングする
3 ossなどで実現できるデータコレクターに送る
暗号化はした方が良いと思うよ
個人情報は書くな
配信は保証されてるわけではないのでロストは少しは?覚悟せいや
トレース
分散トレースという言い方をしている🐰
開発者ツールのnetworkタブの、あのガントチャートみたいなの、あれもトレースみたいやね🐰
トレースコンテキスト(何をどのように送るか)は長年議論の的だったが、標準化の波が来てる
W3Cも動いてるよ
OpenTelemetryもあるよ
インストルメント化が重要
1 データポイントをつくること
2 サービスからサービスへコンテキストを伝搬させること
既存ツール?はコンテキスト伝搬の方がメインっぽいね🐰
多くの場合、コンテキストの伝播は、HTTPクライアントやサーバに統合可能なライブラリを使って透過的に行われる。このパートでは、OpenTelemetry API/SDKs、OpenTracing、OpenCensusなどのプロジェクト、ツール、技術を利用することができます。
プロファイル
パフォーマンスを知るために割当状況を把握すること🐰
どいつがどれだけ使っているのか
もっというと「ボトルネックは誰や?」
cpu, heap, gpu, mutex, i/o, jvmなど言語別
元々「プロファイルのための処理」自体がオーバーヘッドでかすぎて実現無理ゲーだったが、サンプリング方式の台頭によって今は可能になっている
トレースで「どこで遅れとるんや?」を知り、プロファイルで「なんで遅れとるんや?」を知る
時間軸を追加することで、より俯瞰的な視点で見ることもできるみたい🐰
ダンプ
プログラマにはおなじみデバッグに役立つコアダンプさん
クラッシュ時のメモリ内容が書かれている
が、まだクラウドネイティブとして扱えるには至れていないそうだ🐰
理由は以下がムズいから
1 コアダンプ自体がosに深く依存した技術で、吐くのも読むのもos依存でしかも特権的だったわけだが、今のクラウドネイティブの役割体系ではこれをうまく扱えない。とりあえずroot権限許すかーってわけにはいかんやろ?
2 再起動される前にコアダンプファイルをサルベージする必要がある(ここではk8sのPodの例)
次: Correlating Observability Signals
---
Links From <- Observability_o11y_可観測性_is_何
Links To ->