Honeycombメモ
koheiyamayamaデータの保管場所について。
環境、データセットという概念がある。
Webアプリで言えば、前者はDev,Staging,Productionみたいな分け方。
この説明の中で気になったのは「開発者ごとのローカル環境を作る人も多い」みたいに書いてある。
Datadogやnewrelicだとこういうの、やりづらい印象がある。
DatadogだとEnvタグのカーディナリティが増えるが、それを可とする組織、あるのかしら？
でもよくよく考えるとありなのかもしれない。
データセットは環境に複数存在する。
これは2つに分類できる。
ひとつはservice dataset、もうひとつはgeneral datasetという。
service datasetはSpanにセットされるservice.nameフィールドによって識別される。
単一のTraceは一つの環境内で複数のデータセットに存在するSpanから構成される。
画像内ではTraceDがDataset A,Bに存在するSpan E,Fから構成されている。
general datasetはトレースデータに含まれないあらゆるデータを指します。 これにはデプロイメントデータ、ログソースデータ、メトリクスなどが含まれる。
Honeycombでは複数データセットを横断したクエリを実行可能ですが、トレースデータ以外のデータについては、複数の汎用データセットに分割して管理する方法が推奨されます。非トレースデータの設定に関する推奨アプローチは以下の通りです：
データに対して行いたい具体的な質問をいくつか考えてみてください
どのようなデータを収集すれば、その質問に答えられるかを考えてください
質問に答えるためにデータに対して実行する必要があるクエリについて考え、特に、フィルタリングを行って必要なデータのみを抽出できるようにする方法を検討してください。
ということらしい。
つまり、Environment DevにApplication Log dataset, Metrics dataset, Profiler dataset、、、みたいに作っていくのがいいのかしら。
オブザーバビリティエンジニアリングを読み進めたほうが良さそう。
トレースデータと非トレースデータの横断的なクエリ処理
トレースデータと非トレースデータをシームレスに連携させてクエリを実行するため（例：ロードメトリクスとAPIコールのトレース情報を相関させる場合）、これらのデータ間の一貫性を維持することが非常に重要です。 例えば、OpenTelemetryを使用してデータを収集している場合、サービス名、ホスト名、その他使用する可能性のあるフィールドには、推奨されるOpenTelemetryスキーマを使用してください。
つまり、SpanとMetrics、Log等をうまいことつなげるための設計が大事ってこと。
どうやるのか、ライブラリのドキュメントを読めば概ねわかりそう。
koheiyamayamaAPIキーは権限不変、目的別に別れている、環境ごとに作成するといった感じ。
koheiyamayamaログの送り方。
Opentelemetry Collectorを使うのが良さそう。
Google Cloudにもドキュメントがある。
koheiyamayamaconnect-goを利用している場合、これを使えばいい感じになる。
koheiyamayamaotelconfigを入れていると、system cpuやgo runtime metricsが勝手に計測されるっぽい。
honeycombを見ているとやたらとmetricsが登録されている。