[入門 OpenTelemetry - O'Reilly Japan](https://www.oreilly.co.jp/books/9784814401024/) ## 目次 1章　最新のオブザーバビリティの現状 1.1　『時代は変わる』 1.2　オブザーバビリティ: 主要な用語 1.3　テレメトリーの歴史 1.4　オブザーバビリティの3つのブラウザタブ 1.5　新たな複雑性 1.6　3本柱は偶然だった 1.7　一束のデータ 1.8　まとめ 2章　なぜOpenTelemetryを使うのか 2.1　本番環境の監視: 現状 2.2　本番環境のデバッグの課題 2.3　テレメトリーの重要性 2.3.1　ハードおよびソフトコンテキスト 2.3.2　テレメトリーの階層化 2.3.3　セマンティックテレメトリー 2.4　人々は何を必要としているのか 2.4.1　開発者と運用担当者 2.4.2　チームと組織 2.5　なぜOpenTelemetryを使うのか 2.5.1　ユニバーサルスタンダード 2.5.2　相関されたデータ 2.6　まとめ 3章　OpenTelemetry概要 3.1　主要なオブザーバビリティシグナル 3.1.1　トレース 3.1.2　メトリクス 3.1.3　ログ 3.2　オブザーバビリティコンテキスト 3.2.1　コンテキストレイヤー 3.2.2　属性とリソース 3.2.3　セマンティック規約 3.3　OpenTelemetryプロトコル 3.4　互換性と将来性 3.5　まとめ 4章　OpenTelemetryのアーキテクチャ 4.1　アプリケーションテレメトリー 4.1.1　ライブラリ計装 4.1.2　OpenTelemetry API 4.1.3　OpenTelemetry SDK 4.2　インフラストラクチャテレメトリー 4.3　テレメトリーパイプライン 4.4　OpenTelemetryに含まれないもの 4.5　OpenTelemetry Demoを使ったハンズオン 4.5.1　デモを実行する 4.5.2　アーキテクチャと設計 4.5.3　OpenTelemetryでアプリケーションパフォーマンスを管理する 4.5.4　干し草の山から針を探す 4.5.5　デモにおけるオブザーバビリティパイプライン 4.6　新しいオブザーバビリティモデル 4.7　まとめ 5章　アプリケーションの計装 5.1　エージェントと自動セットアップ 5.1.1　SDKのインストール 5.1.2　プロバイダーの登録 5.2　プロバイダー 5.2.1　トレーサープロバイダー 5.2.2　メータープロバイダー 5.2.3　ロガープロバイダー 5.2.4　プロバイダーの停止 5.2.5　カスタムプロバイダー 5.3　設定ベストプラクティス 5.3.1　リモート設定 5.4　リソースの添付 5.4.1　リソースディテクター 5.4.2　サービスリソース 5.5　計装の実装 5.5.1　アプリケーションコードの計装 5.5.2　どの程度が多すぎるか 5.5.3　スパンとメトリクスを重ねる 5.5.4　ブラウザとモバイルクライアント 5.6　セットアップチェックリスト 5.7　すべてをパッケージングする 5.8　まとめ 6章　ライブラリの計装 6.1　ライブラリの重要性 6.1.1　ネイティブ計装を提供する理由 6.1.2　ネイティブ計装ではオブザーバビリティがデフォルトで動作する 6.1.3　ネイティブ計装でユーザーとコミュニケーション 6.1.4　ネイティブ計装が示すパフォーマンスへのこだわり 6.2　なぜライブラリがまだ計装されていないのか 6.3　OpenTelemetryはどのようにライブラリをサポートするように設計されているか 6.3.1　OpenTelemetryは計装APIと実装を分離する 6.3.2　OpenTelemetryは後方互換性を維持する 6.3.3　OpenTelemetryはデフォルトで計装をオフ 6.4　共有ライブラリチェックリスト 6.5　共有サービスチェックリスト 6.6　まとめ 7章　インフラストラクチャの観測 7.1　インフラストラクチャのオブザーバビリティとは何か 7.2　クラウドプロバイダーを観測する 7.2.1　クラウドのメトリクスとログの収集 7.2.2　メタ監視 7.2.3　コンテナ内のコレクター 7.3　プラットフォームの観測 7.3.1　Kubernetesプラットフォーム 7.3.2　サーバーレスプラットフォーム 7.3.3　キュー、サービスバス、その他非同期ワークフロー 7.4　まとめ 8章　テレメトリーパイプラインの設計 8.1　よくあるトポロジー 8.1.1　コレクター不在 8.1.2　ローカルコレクター 8.1.3　コレクタープール 8.2　パイプライン操作 8.2.1　フィルタリングとサンプリング 8.2.2　フィルタリングは容易、サンプリングは危険 8.3　変換、スクラブ、バージョン管理 8.3.1　テレメトリーをOTTLで変換する 8.3.2　プライバシーと地域規制 8.3.3　バッファリングとバックプレッシャー 8.3.4　プロトコルを変える 8.4　コレクターのセキュリティ 8.5　Kubernetes 8.6　テレメトリーコストの管理 8.7　まとめ 9章　オブザーバビリティの展開 9.1　オブザーバビリティの3軸 9.1.1　深さ対広さ 9.1.2　コード対収集 9.1.3　中央集権型対分散型 9.2　イノベーションから差別化へ 9.2.1　テストとしてのオブザーバビリティ 9.2.2　グリーンオブザーバビリティ 9.2.3　AIオブザーバビリティ 9.3　OpenTelemetry展開のチェックリスト 9.4　まとめ ## メモ > [[OpenTelemetry]]は、複雑なクラウドネイティブアプリケーションを含むさまざまな情報システムにおいて、包括的なテレメトリー収集により迅速な問題解決を実現し、ソフトウェアシステムの開発と運用を改善するためのフレームワークです。 本書は、このOpenTelemetryの概要からさまざまなソフトウェアの計装について、またインフラストラクチャの観測やテレメトリーパイプラインの設計、実運用するシステムへの展開まで、OpenTelemetryを導入する際に知っておきたい知識をコンパクトにまとめた書籍です。 システムの可視性を高め、信頼性を向上させたいと考えているすべてのソフトウェアエンジニア、SRE、DevOpsエンジニア、アーキテクト、そして管理職にとって、貴重な情報源となるでしょう。 > 私たちのゴールは、OpenTelemetryそのものを学ぶための包括的なガイドを提示することでした。私たちは、さまざまなパーツが何であるかだけでなく、それらがどのように組み合わさっているのか、そして、なぜなのかを理解して欲しいと考えています。本書は、OpenTelemetryを本番システムに実装するだけでなく、OpenTelemetryプロジェクトへの貢献者として、あるいは組織でのオブザーバビリティ戦略ツールの一環として、OpenTelemetry自体を拡張するために必要な基礎知識をあなたに提供します。 - ユーザーテレメトリー - パフォーマンステレメトリー シグナル - プログラム自身の中にある計装（インストゥルメンテーション、テレメトリーデータを発するコード） - 実際の観測が行われる解析ツールにネットワーク経由でデータを送るための伝送システム ソフトウェアシステムは、時間をかけて構築された意思決定の組み合わせであり、それらを運用する作業の多くには、データを収集し、正規化し、解釈し、さまざまな目的のためにさまざまな利害関係者に出し分ける > 2022年のVOIDレポートには、インシデントの重大性と持続時間の間に関係がないことに関する多くの興味深い洞察が含まれていて、テレメトリーにとって重要なことは、平均応答時間（MTTR）を短縮する利便性ではないという結論に至っています [[The VOID Report 2022]] コンテキスト - ハードコンテキスト：、分散アプリケーションのサービスが、同じリクエストの一部である他のサービスに伝搬（プロパゲーション）できる、リクエストごとの一意な識別子。 - ソフトコンテキスト： 各テレメトリー計装が、同じリクエストを処理するさまざまなサービスやインフラストラクチャからの測定値に付加するメタデータのさまざまな部分。顧客識別子、リクエストを処理したロードバランサーのホスト名、テレメトリーデータのタイムスタンプなど。