監視 やばい

yabaibuki.dev #5の登壇資料です

https://livesense.connpass.com/event/349898/

Transcript

1. ©MIXI 監視　やばい 株式会社MIXI 井上 翔太
2. ©MIXI 自己紹介 名前：しょっさん
 X（旧: Twitter）/ mixi2：@syossan27
 所属：MIXI
 活動：
 • SRE Kaigi • SRE Magazine • ゆるSRE勉強会
3. ©MIXI やばい
4. ©MIXI 監視が
5. ©MIXI ２０２４年 未だに地道な監視しかできていない ことに焦っていた・・・
6. ©MIXI 地道にやっている例 承知！ なんか最近サービスが遅いな〜って感じるので、どの辺 が原因なのか調査してくれない？
7. ©MIXI 地道にやっている例 フロントエンドとバックエンド、それぞれの ログで遅くなっているところがないかチェッ クして、見つかったらそのアクセスでリクエ ストされたログを全てチェックして・・・
8. ©MIXI 地道にやっている例 フロントエンドとバックエンド、それぞれのログで遅く なっているところがないかチェックして、見つかったら そのアクセスでリクエストされたログを全てチェックし て・・・ やばい！
9. ©MIXI んじゃ楽するために行動しま しょ
10. ©MIXI OTel × Cloud Traceを導入するぞ！！！！！ • フロントエンド/バックエンドの一貫したTraceを収集することで、 １リクエストに対する全体の処理時間やボトルネックの特定を容易にする • リクエスト全体の総処理時間ごとの可視化 • SpanとLogがつながっていることで、Spanごとの詳細な動きがすぐに追える • Traceに属性を追加することによる拡張性 メリット
11. ©MIXI OTel × Cloud Traceを導入するぞ！！！！！ • フロントエンド/バックエンドの一貫したTraceを収集することで、 １リクエストに対する全体の処理時間やボトルネックの特定を容易にする • リクエスト全体の総処理時間ごとの可視化 • SpanとLogがつながっていることで、Spanごとの詳細な動きがすぐに追える • Traceに属性を追加することによる拡張性 メリット • めんどい デメリット
12. ©MIXI 実装するぞ！！！！！
13. ©MIXI 実装: フロントエンド Next.jsで組まれたフロントエンド に手動計装 Point Default Spanを無効化 • 不要なSpanがあったりなので、無効化した • Samplerを用いて、 next.span_type を含むSpan を除外 class CustomSampler implements Sampler { shouldSample( _context: Context, _traceId: string, _spanName: string, _spanKind: SpanKind, attributes: Attributes ): SamplingResult { // next.span_typeが存在する場合は、 NextJSのDefault Spanなのでサンプリングしない if ("next.span_type" in attributes) { return { decision: SamplingDecision.NOT_RECORD, }; } return { decision: SamplingDecision.RECORD_AND_SAMPLED, }; } }
14. ©MIXI 実装: フロントエンド Next.jsで組まれたフロントエンド に手動計装 Point Default Spanを無効化 • 不要なSpanがあったりなので、無効化した • Samplerを用いて、 next.span_type を含むSpan を除外 Point CloudPropagatorでCloud Traceへ伝搬 • フロントエンドとバックエンドでTraceを繋げ る必要があるため、 opentelemetry-cloud-trace-propagator の CloudPropagatorで用いてTrace IDを送る // Cloud Traceで利用するために、 CloudPropagatorを使って X-Cloud-Trace-Contextの形式でTraceを伝搬させる const propagator = new CompositePropagator({ propagators: [new CloudPropagator()], }); propagation.setGlobalPropagator(propagator);
15. ©MIXI 実装: バックエンド Railsで組まれたバックエンドに 自動計装 Point GraphQLに対応 • graphql-rubyを利用しているので、 ActiveSupport::Notifications を用いてGraphQL でのtraceも取得する # graphql-rubyで発生するActiveSupport::Notificationsを利用する # ref: https://graphql-ruby.org/queries/tracing#activesupportnotifications trace_with(GraphQL::Tracing::ActiveSupportNotificationsTrace) notifications = [ 'lex.graphql', 'parse.graphql', 'validate.graphql', 'analyze_multiplex.graphql', 'analyze_query.graphql', 'execute_query.graphql', 'execute_query_lazy.graphql', 'execute_field_lazy.graphql', 'authorized_lazy.graphql', 'resolve_type.graphql', ] # デフォルトのNotificationsと上記のNotificationsをマージし て設定 config.google_cloud.trace.notifications = Google::Cloud::Trace::Railtie::DEFAULT_NOTIFICATIONS + notifications
16. ©MIXI 実装: バックエンド Railsで組まれたバックエンドに 自動計装 Point GraphQLに対応 • graphql-rubyを利用しているので、 ActiveSupport::Notifications を用いてGraphQL でのtraceも取得する # ログとTraceを紐付けるためのフィールド 'logging.googleapis.com/trace': "projects/[project-name]/traces/#{trace_id || ''}" , Point 構造化ログにtraceに関するフィールドを 追加 • 構造化ログに logging.googleapis.com/trace を付 け足すことで、Cloud Traceに該当するTrace ID にSpanを追加すると同時にログとの紐づけを行 う
17. ©MIXI 実装: その他 Point opentelemetry-collectorの構築 • フロントエンドからCloud Traceへtraceを送出す るためにSidecarとして構築
18. ©MIXI 実装: その他 Point バックエンド側のNGINXでヘッダー 編集 • X-Cloud-Trace-Contextからtrace_idを抽出し、 X-Request-Idヘッダーへ設定することで、 バックエンド側でtrace_idを扱えるようにする # X-Cloud-Trace-Contextからtrace_idを抽出 map $http_x_cloud_trace_context $trace_id { ~^([0-9a-f]+)\/ $1; default $request_id; } log_format json escape=json '{' '"request_id":"$trace_id"' '}' Point opentelemetry-collectorの構築 • フロントエンドからCloud Traceへtraceを送出す るためにSidecarとして構築
19. ©MIXI できたぞ！！！！
20. ©MIXI ▪ Cloud Trace
21. ©MIXI ▪ Cloud Trace - Span
22. ©MIXI ▪ Cloud Trace - Span attributes
23. ©MIXI まだまだ荒削りだが、一旦はOK
24. ©MIXI 今後も"やばい"を撲滅していくぞ！
25. ©MIXI ご清聴ありがとうございました