トレーシングで重要なのがSamplingです。
単純に全データを計測するとコストが増えたりパフォーマンスに影響が出たりします。
OpenTelemetryではSamplingに対する仕様が決まっているので、それに基づいて具体的な実装を紹介します。
OpenTelemetry Specification - Sampling
サンプリングには大きく2つのタイプがあります。
Head basedとTail basedです。
ref: https://newrelic.com/jp/blog/best-practices/distributed-tracing-and-sampling
続きを読むOpenTelemetryはOpenCensusやOpenTracingをまとめた形で生まれたので、既にOpenCensusやOpenTracingの形で実装されたライブラリは移行するのが大変です。
例えばGCPの各SDKは基本的にOpenCensusで実装されています。
そのようなライブラリを使用する際に
といったBridgeを使うことで簡単にOpenTelemetry用のSpanとして取り込むことができます。
OpenTelemetryはObservabilityの三本柱であるLogs、Metrics、Tracesをベンダーに依存せず実装するための仕様＆実装です。
今回はそのうちのTracesをGoで試してみます。
OpenTelemetryでは以下の要素があります。
| 登場人物 | 役割 |
|---|---|
| Tracer Provider | Tracerを提供する。またトレース情報のExport先を管理したり、トレースに共通で付けたい属性データを管理する |
| Tracer | Spanを生成する |
| Span | 各操作におけるトレース情報 |
| Trace Exporter | トレース情報の出力先。標準出力だったり、Jaegerのような分散トレース可視化ツールなど |
| Trace Context | Spanの関連付け（Child of, Follows from）をする上で伝播させる必要のあるデータ |
普段プログラミングでは特定の言語を使っていますが、シェルスクリプトはビルドスクリプトをいじる時くらいしか使わず都度検索して調べ直す事が多いです。
また使い方が間違っていてもテストする文化が浸透していないため、期待しない挙動になっていても気が付かないケースも多々あります。
（ShellSpecやBatsといったテストフレームワークはあるものの、そこまで複雑なことをさせないためテストはいいかとなりがち）
そういった課題を解決できるツールとしてShellCheckがあります。
ShellCheckはシェルスクリプトのLinter（静的解析ツール）です。
Playgroundが用意されており、↓で手軽にチェックできます。
ShellCheck – shell script analysis tool
続きを読む前回はyttに基本的な使い方を説明しました。
今回は少し実践的に、変数を外部ファイルとして扱ってサービス毎だったりdev/prdといった環境毎にYAMLを生成できるようにします。
前回はテンプレートにベタ書きしていた値を変数に入れていましたが、今回は外部ファイルから注入します。
フローとしては以下で、一番最初に処理されます。
ref: https://carvel.dev/ytt/docs/v0.44.0/how-it-works/
※今回Overlaysは扱わないです
続きを読むといったようなケースでは、似たようなYAMLをパラメータだけ変更して自動生成したくなります。
そのような時はyttというツールが課題を解決できます。
Bazelでも使用されているStarlark言語をベースとしたYAMLのテンプレート&パッチツールです。
yttの良い点としては
といったところでしょうか。
続きを読む