タグ: #OpenTelemetry

← すべての記事

• gRPCのデバッグと観測：grpcurl、リフレクション、channelz、そしてメトリクスの罠

  gRPCはバイナリであるため、curlで中身を見ることはできません。その代わりに、サーバーが自らスキーマを通知するリフレクション（grpcurlがこれを使用）、標準のヘルスサービス、チャネル・サブチャネル・ソケットの統計情報を取得できるchannelz、そしてメトリクスが窓の役割を果たします。小さなクラスターの指標から2つの罠が見つかりました。kube-apiserver 1.34のetcdクライアント指標であるgrpcclientms

  2026-10-16 · 18 分で読めます #gRPC#grpcurl#서버 리플렉션#channelz#Prometheus

• 小さなクラスターで実際に動く gRPC: etcd、CRI、Hubble、OTLP

  8ノードの小さなクラスターで 4 つの gRPC 通信を読み取り専用で計測しました。kube-apiserver は同じノードの etcd に対して TCP 接続を 247 個も開いていましたが、これは Kubernetes がリソース（CRD を含む）ごとに etcd クライアントを個別に作成するためであり、ソースコードのコメントに既知の問題として記載されています。kubelet は containerd にランタイムとイメージの 2

  2026-10-16 · 19 分で読めます #gRPC#etcd#CRI#containerd#Hubble

• ストリーミング、deadline、リトライ、keepalive：呼び出しが長引く、または失敗したとき

  gRPCのメソッドは、リクエストとレスポンスがそれぞれ1つかストリームかによって4つに分類されます。ストリームはHTTP/2のフロー制御ウィンドウによって保護され、制限時間はdeadlineとして残り時間とともに次のサーバーに伝えられ、キャンセルはRSTSTREAMとして伝播します。ライブラリによるリトライは、サーバーがレスポンスヘッダーを送る前（Trailers-Only）にのみ、最大5回、0.8〜1.2倍のジッターを混ぜて行われます

  2026-10-16 · 20 分で読めます #gRPC#스트리밍#deadline#재시도#keepalive