はじめに
基本的にメモそのまま。
APMの世界から見るOpenTelemetryのTraceの世界
Opentelemetryとは？
ログ、メトリックス、トレースを集めてエクスポートする、言語に依存しない標準規格です。
Viewerは「Backend Service」
Telemetryから見たら、Viewerは「バックエンド」という扱い。
Viewerは規格外なので、インターフェースを満たせば何を使っても良い（mackerel、Grafana etc）
開発中でも使うと良さそう
あんまりインフラを触るのは得意ではないけれど、デバッグ用にAOPであれこれしていたところをやらなくても、メトリックスとして取得できるのであれば、それで解決するのはアリなのかもしれない（ので、ちょっと頑張ってみようかな）。
spanをつかってピンポイントに確認できる
デバッグで調査をするところを、あえて、OTLPを使っていくみたいなことをして、ちょっとずつツールに慣れるというのもやってみても良いかもしれない？
バッチに有効そう
バッチに自分でログを入れていたところを簡略化できそう。
テストのないシステムのバージョンアップに非常に協力
何がどこで動いているのか？というのを実装を変えることなく、そとから覗き込むことができるというのはたしかに有効そう
自動計装と手動計装をMIXするときに気をつけること
命名でどちらの計装かわかるようにしておいたほうが良いかも、とのこと。
サンプリングをするときのポイントは？
ログでクリティカルが出ているけど、メトリックスで出ていないみたいなことはありえる。
いずれにしても「？」なことがあったら、ログを元に注視する対象（サーバ、アプリ（Span））を絞ってサンプリングの対象を決める感じかなぁ。
Spring Boot 4.0で実装と監視を分離する
これまでの歴史のおさらいがあるのは嬉しい
DynaTraceは、少しだけみたことあるので、ちょっと懐かしい（2019年頃？）。
形としてまとまり始めたのは2018年くらいみたいなので、アーリー的な時期だったのか……（そりゃ僕には荷が重い）。
アプリケーションが監視環境を知っていなければならないのか？
NOというのが適切な構造なのでは？というのは納得するところ。
サイドカーパターンにして、アプリケーションはしならくて良いっていうのが良いとなぁと思う。
ただ、開発環境で簡易的にやろうと思うと、サイドカーを準備する環境構築することとか考えると躊躇はするんだけれど……
Spring CloudとSpring Bootは違うチーム
という理解であっているかな？
とにかく、そんな感じの関係性らしい。
Spring Boot 4でOTLPの依存をいれるだけでOK？
方向性としてはYESなんだけど、ログについてはlogback-appenderがアルファ版なので、正式にはまだ未対応。
そんなときには、マキさんのブログへGO（https://ik.am/entries/892）
環境構築のパターン
ローカルから本番までの基本構成を提示してくれているのは嬉しい。
大規模の場合のKafkaのパターンも嬉しい。
ポイントは、アプリケーションはOTLPへの依存をpomで設定するだけで完結しているところ。
Grafana
AIをつかって環境構築をされたそうですが、こちらを参考にすればよいとのこと。
Docker OpenTelemetry LGTM | OpenTelemetry documentation
さいごに
いままで、腰が引けてしまう「監視」が、こんなに敷居が低くなっているとは思わなかった。
やってみようと思えるくらい低くなったと思う。
前日に引き続き、懇親会に参加。
EE勉強会にも参加していらっしゃった方と お話させていただいた。
お互いに「現在進行形ではEEを使ってはいないけど、情報収集や動向把握の一環として」というのは同じでした。
あとは、流れで EE／MicroProfile のOTLP周りはどうなんでしょうね、とかとか。
標準仕様を決める合意形成が終わっているのであれば、一気に開発を進めてくれるんじゃないかと思ったり思わなかったり……
