First published: Last updated:
Conclusion
Originally published in Japanese at https://zenn.dev/ymotongpoo/books/tinygo-otel-esp32/viewer/55-conclusion.
The OpenTelemetry Go SDK does not run on a microcontroller that runs TinyGo. The SDK and the exporters assume that a host OS exists. On the other hand, this book’s implementation confirmed that you can implement the OTLP protocol with only the standard library and a small amount of your own code. The metrics, logs, and traces that the M5Stack CoreS3 sent went through the Collector and appeared together in Grafana. They also survived a 30-minute soak run and a restart of the Collector. Once the data reaches the Collector, everything after that point is the same pipeline that OpenTelemetry uses on a server.
These results lead to one decision for OpenTelemetry on a microcontroller: implement the parts that the device needs yourself, instead of putting the SDK on the device as is. On the device, you must write the OTLP encoding, the HTTP export, clock synchronization, and a bounded buffer. You can leave the rest to the Collector: adding attributes, TLS, authentication, and retries to the backend. If you want to add something to the device, first check whether that information is available only on the device. If the information is decided outside the device, you can add it in the Collector configuration.
I measured the numbers in this book with TinyGo 0.42.0, espradio v0.3.0, and one M5Stack CoreS3. If TinyGo’s reflect or the espradio API changes, the amount of code that you must write yourself also changes. For now, the most reliable basis for your decisions is the OTLP specification and the values that you measure on your own device.