可観測性に入門しよう 株式会社ユニクエスト 長谷川広樹 github.com/hiroki-it @Hiroki__IT

自己紹介 ▼ お仕事 最近：クラウドインフラ、IaC、CICD、... 以前：DDD ▼ 関心のある技術領域 ・クラウドインフラ ・IaC ・DDD github.com/hiroki-it @Hiroki__IT 長谷川 広樹 (はせがわ ひろき) 株式会社ユニクエスト

目次 ■ 可観測性 ■ 監視やテストとの違い ■ なぜ，我々は可観測性を高める必要があるのか ■ 可観測性を高める方法 ■ テレメトリーとは ■ メトリクスとは ■ メトリクス ～ データポイントとは ～ ■ ログとその種類 ■ SaaSツールでログを楽しく構造化できちゃう ■ 分散トレースとは ■ 分散トレース ～ スパンとは ～ ■ 分散トレース ～ 図の読み方の例 ～ ■ テレメトリー間の関連付け ■ 関連付け ～ 構造化ログとスパン ～ ■ 関連付け ～ その他 ～

可観測性とは 収集されたデータから システムの 想定内 と 想定外 の両方の不具合を どれだけ正確に推測できるかの程度

テストや監視との違い テストや監視は 想定内 の不具合のみを検知するアクション 引用：https://www.humio.com/free-ebook-distributed-systems-observability/ 想定外も 想定内のみ

なぜ，我々は可観測性を高める必要があるのか 想定外 の不具合は テストや監視では検知できない 高い可観測性によって 想定外の不具合を表面化できる

なぜ，我々は可観測性を高める必要があるのか 複数のコンポーネント(要素)からなるシステムで 不具合が発生した場合 不具合発生 引用：https://github.com/GoogleCloudPlatform/microservices-demo

なぜ，我々は可観測性を高める必要があるのか 不具合の発生したコンポーネントの特定に時間がかかる 高い可観測性によって 原因のコンポーネントを素早く特定できる 特定

可観測性を高める方法 可観測性を高めるためには どうすれば... 十分量の『テレメトリー』を収集し テレメトリー間を関連付け 可視化する！(持論)

可観測性を高めるために収集する必要のあるデータ要素 テレメトリーとは メトリクス ログ 分散 トレース 引用：https://knowledge.sakura.ad.jp/26395/

テレメトリー ～ SaaSツール ～ SaaSツールを利用すると テレメトリーの収集・関連付け・可視化を行いやすい 引用： ・https://newrelic.com/ ・https://www.datadoghq.com/ ・https://www.splunk.com/

メトリクスとは とある分析にて 一定期間に発生した複数の データポイントの集計値 引用：https://www.slideshare.net/AmazonWebServicesJapan/20190326-aws-black-belt-online-seminar-amazon-cloudwatch ※ AWS CloudWatchのメトリクスの概念を拝借 分析ごとに 集計

メトリクス ～データポイントとは～ 引用： ・https://whatis.techtarget.com/definition/data-point ・https://aws.amazon.com/jp/about-aws/whats-new/2017/12/amazon-cloudwatch-alarms-now-alerts-you-when-any-m-out-of-n-metric-datapoints-in-an-interval-are-above-your-threshold/ とある分析にて 対象から得られる 最小単位の数値データ 分析Ａにおいて 毎分 得られる数値 = 分析Ａにおけるデータポイント 分析Ｂにおいて 毎時 得られる数値 = 分析Ｂにおけるデータポイント 分析Ｃにおいて 毎日 得られる数値 = 分析Ｃにおけるデータポイント ※ 分析ごとにデータポイントが存在

特定の瞬間に発生した イベント記録のデータ ログとその種類 { "client_ip": "192.168.0.1", "timestamp": "2021-01-01 12:00:00", "method": "GET", "url": "/users", "status_code": 200 } ～ 構造化ログ (JSONなど) ～ イベントの 項目名と値 192.168.0.1 [2021-01-01 12:00:00] GET /users 200 ～ 非構造化ログ (文字列) ～ イベントの 値のみ 引用：https://newrelic.com/jp/blog/how-to-relic/metrics-events-logs-and-traces

SaaSツールでログを楽しく構造化できちゃう 192.168.0.1 [2021-01-01 12:00:00] GET /users 200 楽し過ぎて 一日中やってしまう... （個人の感想です） %{ipv4:client.ip}\s+\[%{date("yyyy-MM-dd HH:mm:ss"):date}\]\s+%{word:http.method}\s+%{notSpace:http.path}\s+%{integer:http.status_code} { "client": { "ip": "192.168.0.1" }, "http": { "method": "GET", "path": "/users", "status_code": 200 } } DatadogのGrokパーサーで構造のルールを表現 値に基づいて，ログを 検索 できるようになる

分散トレースとは マイクロサービスアーキテクチャにおいて 複数のサービスから得られる スパンのセット 引用：https://www.dynatrace.com/news/blog/open-observability-part-1-distributed-tracing-and-observability/ 分散トレース スパン

分散トレース ～スパンとは～ 特定のサービスに関する データのセット (JSONなど) 引用：https://docs.datadoghq.com/tracing/guide/send_traces_to_agent_by_api/ { "duration": 123, # 処理の所要時間 "error": 0, # エラーの有無 "meta": { "env": "prd" # タグのリスト }, "metrics": { "baz-sum": 123 # サービスのメトリクス }, "name": "laravel.request", # スパン名 "parent_id": 123, # 親スパンID "resource": "/foos", # アクセスされたリソース "service": "foo-service", # サービス名 "span_id": 123456789, # スパンID "start": 0, # 処理開始時間 "trace_id": 123456789, # トレースID "type": "web" # サービスのタイプ } スパンはトレースIDをもち 異なるスパン間で紐づけ可能 異なるサービスを横断する処理を 一繋ぎ に可視化 ※ Datadogのスパンの構造例（SaaSツールごとに異なる）

分散トレース ～図の読み方の例～ 引用：https://cloud.google.com/architecture/using-distributed-tracing-to-observe-microservice-latency-with-opencensus-and-stackdriver-trace ■ 上から下へ読む 上流サービス(上位スパン)が 下流サービス(下位スパン)の 処理をコールしている ■ 下から上に読む 下流サービス(下位スパン)から 上流サービス(上位スパン)に 結果を返却している

テレメトリー間の関連付け メトリクス ログ 分散 トレース テレメトリーを関連付けて 可観測性を高める

関連付け ～ 構造化ログとスパン ～ 構造化ログに トレースID，スパンID を持たせる 引用：https://docs.datadoghq.com/tracing/visualization/trace/?tab=spantags ① ② そのログが どのサービス で どのタイミング で 発生したかのかを可視化 ※ Datadogの関連付けの例（SaaSツールごとに異なる）

関連付け ～ その他 ～ また今度... 󰢛

改めて，可観測性とテレメトリーを見る 可観測性を高めたくなってきたぞぉ～！ メトリクス ログ 分散 トレース 想定外 想定内

最後に テーマと関係ないけど Gopherくん超かわいい!!! by Takuya Ueda (https://twitter.com/tenntenn) The Gopher character is based on the Go mascot designed by Renée French.