Next.js / VercelでOpenTelemetryを使ってみたい
こっちはあとでよむ
o-telの用語はここにまとまってるらしい
Next.js supports OpenTelemetry instrumentation out of the box, which means that we already instrumented Next.js itself. When you enable OpenTelemetry we will automatically wrap all your code like getStaticProps in spans with helpful attributes.
すげえなそれは
Good to know: We currently support OpenTelemetry bindings only in serverless functions. We don't provide any for edge or client side code.
「edgeはまだよ」と
Getting Startedの前に用語読んでこようかな
読んできた(下のブロック)
OpenTelemetry is extensible but setting it up properly can be quite verbose. That's why we prepared a package @vercel/otel that helps you get started quickly. It's not extensible and you should configure OpenTelemetry manually if you need to customize your setup.
初心者にはありがたいっす
npm install @vercel/otel
してinstrumentation.ts
書くだけか、さすがVercelさん
Manual軽装も書いてあるけど今はいいや
ローカルで確認するときはこれ使えって
If everything works well you should be able to see the root server span labeled as GET /requested/pathname. All other spans from that particular trace will be nested under it.
うまくいけばこうなるらしい
We made sure that OpenTelemetry works out of the box on Vercel.
というわけでVercel側のドキュメントもあとでよむ
追跡したい処理をwrapしてカスタムspanを作ることができる
import { trace } from '@opentelemetry/api'
export async function fetchGithubStars() {
return await trace
.getTracer('nextjs-example')
.startActiveSpan('fetchGithubStars', async (span) => {
try {
return await getValue()
} finally {
span.end()
}
})
}
Next.js automatically instruments several spans for you to provide useful insights into your application's performance.
Next.js特化のspanはあらかじめ仕込まれてるらしい
うーん、fetchじゃなくてprismaでデータ通信しているのはどうしたもんかな。
用語が知りたい
Observability lets us understand a system from the outside, by letting us ask questions about that system without knowing its inner workings.
「内部実装について知らなくていい」はテストのポイントと同じだね
Telemetry: システムが吐き出すデータのこと。traces, metrics, logs に分類される。
Reliability: サービスがユーザーの期待通りに動いている度合い
Metrics: システムエラー率やCPU使用率、リクエスト率といった数値を一定期間にわたって集計したもの
SLI, or Service Level Indicator: サービスの動作の測定値。ページの読み込み速度とか。
SLO, or Service Level Objective: SLIをビジネス価値に紐づけたもの(?)
Logs
- ログは、サービスや他のコンポーネントが発するタイムスタンプ付きメッセージ
- トレースとは異なり、ログは必ずしも特定のユーザーリクエストやトランザクションに関連付けられているわけではない
- ログ単体だとそこまで役に立たないが、スパンの一部として含まれる場合・トレースやスパンと相関がある場合に威力を発揮する
Spans
- ひとつの操作に対応
- その操作が実行された期間に何が起こったかを追跡
- 名前、時間データ、構造化ログ、attributesが含まれる
attributesは例が載ってるけど通信に関する情報
Distributed Traces
- サービスをまたいで経路記録できる
- 1つ以上のスパンで構成される
イメージ画像がわかりやすかった
最初のドキュメントの部分集合に近いけど、Vercel Integrationについてだけ気になった
You must be using an OTEL Integration:
- New Relic: Available in Beta to teams on Pro and Enterprise plans by following the steps below
- DataDog: Available in Private Beta to teams on the Enterprise plan. To get access contact your CSM and follow the steps below
Pro以上でNew Relic使えると、ほぼなにもしなくていいよ〜て感じか
これのとおりにやったら、nr dev
でこれ出た
✓ Compiled /instrumentation in 188ms (23 modules)
ローカルでの見方が全然わからん
docker再起動したらちゃんと自分で設定したサービス見えた
ローカルでぱらぱら動かしただけやと「画像の読み込みに時間かかってるんやなー」くらいしか感じないかも。読み取り方がまだよくわかってない。
飽きるまで読むか
History
OpenTelemetry is the result of a merger between two prior projects, OpenTracing and OpenCensus. Both of these projects were created to solve the same problem: the lack of a standard for how to instrument code and send telemetry data to an Observability backend. However, neither project was fully able to solve the problem on its own, and so the two projects merged to form OpenTelemetry so that they could combine their strengths and truly offer a single standard.
歴史面白いね
What OpenTelemetry is not
OpenTelemetry is not an observability back-end like Jaeger, Prometheus, or commercial vendors. OpenTelemetry is focused on the generation, collection, management, and export of telemetry data. The storage and visualization of that data is intentionally left to other tools.
ここ大事ね
なんかその他のドキュメントは実装方法とか拡張方法について書かれていて、今は必要なさそう。