TinyGoでオブザーバビリティ？OpenTelemetryはTinyGoで使えるのか / Is OpenTelemetry available in TinyGo environment?

TinyGo Conference 2026における登壇資料です。
https://conf.tinygo-keeb.org/2026/

検証をした結果の調査資料はこちらにあります。
https://zenn.dev/ymotongpoo/books/tinygo-otel-esp32

PoCはこちらです。
https://github.com/ymotongpoo/tinygo-otel-esp32

Transcript

1. TinyGoで オブザーバビリティ？ OpenTelemetryは​TinyGoで​使えるのか TinyGo Conference 2026 · 2026-10-10 Yoshi Yamaguchi
2. 山口 能迪​（やまぐちよしふみ） Staff Developer Advocate Grafana Labs 専門領域 オブザーバビリティ OpenTelemetry Go @ymotongpoo
3. 最終結果 M5Stackから​Grafanaに​3シグナルが​届く シグナルは​テレメトリーの​種類で、​メトリクス、​ログ、​トレースの​3つ 公式の​OpenTelemetry Go SDKは​使っていない
4. 構成 デバイスは​同じ​LANの​Collectorへ​送る OTLPは​OpenTelemetryの​通信プロトコル Collectorは​テレメトリーを​受け取り、​加工して​保存先へ​転送する​サーバー
5. 最 初 に ​訂 正 プロポーザルの​理由の​一部を​誤認していた 方針は​変わらない 公式の​Go SDKは​そのままでは​使えない デバイスは​LAN内の​Collectorに​送る 前提 M5Stack CoreS3の​実機で​測った​値 TinyGo 0.42.0と​espradio v0.3.0で​確認
6. "In general, the OTel spec is not designed for the limited resources present in embedded systems."​ （一般に、​OTelの​仕様は​組み込みシステムに​ある​限られ た​リソースに​合わせて​設計されていません） Ted Young​（OpenTelemetry共同創設者）、​open-telemetry/community#2160、​2024年6月
7. 公式の​Go SDKは なぜ​使えないのか
8. ビルドしてみる SDKと​エクスポーターは​ビルドで​止まる APIは​記録の​呼び出し口、​SDKは​APIの​実装で​値の​集計と​属性の​付与を​担う。 エクスポーターは​SDKが集 ​ めた値 ​ を​OTLPで送 ​ る部 ​ 品。 構成​（OpenTelemetry Go v1.46.0）​ 結果​ 止まった​箇所 otel/metric と metric/noop （APIだけ）​ 成功​（6,400バイト）​ なし otel/sdk/metric を​追加 失敗 sdk/resource から x/sys/unix otlpmetrichttp を​追加 失敗 envconfig の tls.X509KeyPair APIにだけ依存する​ライブラリなら、​TinyGoの​プログラムに​組み込んでも​ビルドは​通る
9. 原因 止まる​理由は​メモリではなかった # sdk/metric を追加したビルド system calls are not supported: target emulates a linux/arm system on xtensa # otlpmetrichttp を追加したビルド .../otlpmetrichttp@v1.46.0/internal/envconfig/envconfig.go:143:19: undefined: tls.X509KeyPair 部品 前提に​している​こと​ SDK（ sdk/resource ）​ OSに​問い合わせて​ホストの​情報を​集められる​ エクスポーター​（ envconfig ）​ 証明書を​扱える​完全な crypto/tls が​ある​
10. PROTOBUF ビルドが​通っても​実機で​panicする 生成型を proto.Marshal に​渡すと​最初の​送信 で​落ちる wifi connected, address: 192.168.0.102 panic: unimplemented: (reflect.Type).MethodByName() abort called 公式の​対応表では reflect は​importableも​ passes testsも​yes importできる​ことと、​個別の​メソッドが​実装 されているこ ​ とは別 ​
11. PROTOBUF dynamicpbは​動くが​1回で​29KBを​確保する dynamicpbで​組み立てる 29,277バイト 手​書きの​エンコーダで​組み立てる 0バイト 8タイムシリーズと​リソース属性3件を​1回組み立てるたびに、​ヒープへ​新しく​確保する​量 メトリクスを​10秒ごとに送 ​ る今 ​ 回の設 ​ 定では​dynamicpb は使 ​ えない
12. OTLPを​自前実装する
13. エンコ ー ド OTLP/JSONは​構造体の​タグで​書ける type span struct { TraceID string `json:"traceId"` SpanID string `json:"spanId"` ParentSpanID string `json:"parentSpanId,omitempty"` Name string `json:"name"` Kind int `json:"kind"` } OTLPの​仕様が​定める​正式な​エンコーディング で、​Collectorは​protobufと​同じく​受け付ける IDは​16進の​文字列、​64ビット整数は​10進の​文字 列、列 ​ 挙値は整 ​ 数 10タイムシリーズで​3,016バイト​（protobufは​ 1,379バイト）
14. HTTPクライアント 脱 net/http で​フラッシュ使用量が​30%減る Wi-Fi接続、​時刻同期、​3シグナルの​送信を​含むファームウェア全体で​比較 項目​（バイト）​ net/http 手​書き 差 フラッシュ​（​プログラムの​格納先）​ 1,067,175 748,691 318,484 静的RAM 147,636 114,796 32,840 差は crypto/tls と、​そこから​付いてくる crypto/x509 や math/big の​分 平文しか​話さない​デバイスでは​一度も​実行されない
15. 置 き 換 え た ​も の 公式の​部品で​使えたのは​スキーマだけ 上段が​公式の​部品、​下段が​今回の​実装
16. マイコンの​上で 詰まった​ところ
17. 時刻 NTPの​実装は​あるが​呼べる​APIが​無い 時刻が​1970年の​ままだと、​データは​Grafanaの​表示範囲に​入らない # espradioの公開APIで接続しただけ warning: clock never synchronised; timestamps will be wrong clock ready: 1970-01-01 00:00:33.0411515 +0000 UTC # SNTPを自分で書いたあと sntp: resolved pool.ntp.org to 167.179.119.205 sntp: clock set to 2026-09-15 06:33:52.876544886 +0000 UTC lneto は​NTPを​実装しているが、​espradio v0.3.0の​接続手順からは​呼べない UDPで​48バイトを​送る​SNTPを​自分で​書いた
18. スタック スタック不足の​エラーが​出ない​こともある 結果​ -stack-size 8KB​（デフォルト）​ EXCCAUSE = 28 (LoadProhibited) で​落ちる​ 12KB EXCCAUSE = 28 (LoadProhibited) で​落ちる​ 14KB fatal error: goroutine stack overflow で​落ちる​ 15KB 動く​ 16KB 動く。​30分の​連続稼働を​通過 encoding/json は​入れ子の​OTLPを​再帰で​たどる。​12KB以下では、​スタック不足の​報告より​先 に​メモリが​破損する
19. メ モ リ の ​量 ヒープは​3シグナルでも​DRAMの​半分以下 GC後の​ヒープは​約204,000バイトで、​TinyGoが​使える​DRAM​（425,984バイト）の​48% グラフの上 ​ 端はヒ ​ ープの上 ​ 限に貼 ​ り付 ​ き、保 ​ 持している量 ​ は下 ​ 端に表 ​ れる
20. メモリの​使 い方 詰まったのは​量ではなく​送信ごとの​確保 送信の​たびに​確保して​捨てる​メモリ。​GCで​回収されるが、​多い​ほど​GCの​間隔が​短くなる 実装 1回の​送信で​増える​ヒープ​（バイト）​ 送信ごとに​接続を​張り、 json.Marshal を​使う​ 8,272 接続を​使い回す 4,816 さらに​出力バッファを​使い回す 688 ログと​トレースを​足した​現行版 2,992
21. デバイスに​どの​処理を​残すか
22. 3つの​シ グナル デバイスの​外から​測れない​ことだけを​送る メトリクスは​10秒ごと。​ログと​トレースは​メトリクスの​送信が​成功した​直後に​送る メトリクス ログ トレース Goの​ヒープ Wi-Fiドライバの​メモリ 電波強度（ ​ RSSI）と送 ​ 信の​結果 起動、​送信の​失敗、​回復、 周期全体の​スパンの​下に 16件を​超えたら​古い順に​上書き その件 ​ 数はメ ​ トリクスで送 ​ る POSTの​子スパン 12本の​タイムシリーズ 4種類の​出来事 部分的な​拒否 送信1周期 値の​読み取り、​エンコード、
23. ト レ ース 送信1周期の​8割強は​HTTPの​POST 実機で​記録した​1周期の​例。​エンコードは​2割に​届かない
24. 連続稼働試験 30分の​連続稼働で​送信の​失敗は​0回 送信間隔10秒、​スタック16KB。​15分の​時点で​Collectorを​再起動 メトリクスのみ​ 3シグナル 送信 180回 180回 失敗 0回 0回 800バイト 2,992バイト 1回 7回 178,704バイト 203,776〜206,128バイト 6.1秒 9.1秒 項目 1回の​送信で​増える​ヒープ GC GC後の​ヒープ 再​起動からの​回復 GC後の​ヒープは​増え続けず、​Collectorの​再起動後も​次の​周期で​送信が​再開する
25. 役 割 の ​分 担 TLSと​属性の​付与は​Collectorに​任せる デバイス その​場でしか​測れない​値を​測る 時刻を​合わせる バッファに​上限を​置き、​溢れた​件数を​送る 一時的な​失敗​（429、​502、​503、​504）も​ 送り直さず、​次の​周期に​新しい​値を​送る Collector 環境の​属性を​足す deployment.environment.name など TLSと​認証情報を​持つ データをま ​ とめ、バ ​ ックエンドへ​再送する
26. 結論 まとめ OTel Go SDKが​使えない​原因は、​メモリ制限ではなく​ホストOSへの​依存と reflect の​未実装 OTLPの​スキーマは​使える。 encoding/json 、​手書きの​HTTPクライアント、​SNTPで​話せる マイコンで詰 ​ まるのはメ ​ モリの量 ​ より、送 ​ 信ごとのメ ​ モリ確保と​goroutineのス ​ タック デバイスはそ ​ こでしか分 ​ からないこ ​ とだけを送 ​ り、​TLSと属 ​ 性の付 ​ 与は​Collectorに任 ​ せる Collectorから先 ​ は、サ ​ ーバーで使 ​ う​OpenTelemetryと同 ​ じパ ​ イプライン PoCは​これです https://github.com/ymotongpoo/tinygo-otel-esp32
27. 報告した​I SSUE 調査で​見つけた​問題を​tinygo-orgへ​報告した issue 内容 espradio#75 接続手順から​時刻を​合わせる​手段が​無い​ espradio#76 接続中の​アクセスポイントの​RSSIを​返す関数の​提案 tinygo#5839 ESP32-S3で​スタックの​あふれが​報告されない​ tinygo#5204へ​追記 tls.X509KeyPair が​無く otlpmetrichttp を​ビルドできない​ tinygo#3862へ​追記 MethodByName が​未実装で proto.Marshal が​panicする​ 2026年10月7日に​報告。​上の​3件は​新規の​issue、​下の​2件は​既存の​issueへの​コメント