Observability
オブザーバビリティ_、可観測性, o11y
システムの内部状態を外部から把握できる能力を指す
理想的には、システムがどの様な状態になったとしても、データを用いて、理解し説明できる
Telemetry + 分析
Observabilityの3本柱
参考
Observabilityをはじめよう!(前編) 〜Observabilityの背景と構成要素〜 | さくらのナレッジ
/mrsekut-book-4814400128/027 (1章 オブザーバビリティとは?)
#wip
/mrsekut-book-4814400128/027 (1章 オブザーバビリティとは?)を読んだ
obeservabilityの具体はいまいちわからんが、モチベーションはわかった気がするmrsekut.icon
k8sや様々なインフラの組み合わせで構成された現代の分散システムは、複雑になりすぎている
従来のモニタリングやメトリクスを用いた異常の検知は、予測できるものにしか対応できない
予測してなかった異常が起きた時に、
コードを見たり、新たに修正を入れたりすることなく、原因を突き止めたい
observabilityは、そういう状態にしておくことを目指している
この辺の考え方って、SLOとかと衝突している気がするが、どういう扱いになっているんだろう?
cardinality
/mrsekut-book-4814400128/038
cardinalityが高いほうが、1つのものを特定しやすい
せやなmrsekut.icon
dimention
/mrsekut-book-4814400128/039
データ内のキーの数
JSの1つのobjectのpropertyの数みたいなイメージかなmrsekut.icon
参考値として、成熟した計装では、生成される構造化イベントには300~400ぐらいのdimentionを含むらしい
探索可能性
/mrsekut-book-4814400128/041
https://speakerdeck.com/newrelic2023/20230523-findy-newrelic-o11y1
https://findy-tools.io/articles/monitoring-o11y-1/3
事例集
https://speakerdeck.com/biwashi/o11y-handson
https://blog.x.com/engineering/en_us/a/2013/observability-at-twitter
分散システムがあることが、前提にあるっぽい
複数のシステムが分散しているので、障害が起きた時に原因の特定が難しい
サーバが1つだと、わざわざObservabilityと言ってなにか特別なことをするまでもなく、そらそこが原因やろ、となるのでmrsekut.icon
Twitterの分散システムを可視化したもの
https://gyazo.com/78c789aacd8a321324f28e5a8fbc0d1c https://blog.x.com/engineering/en_us/a/2013/observability-at-twitter
関連が多すぎて、何もしてないとどこで障害が起きたのかの特定が大変