コンテンツにスキップ
sigiro
Esc
↑↓移動↵開く⌘Jプレビュー
このページの内容

クイックスタート

1 つのコマンドで sigiro を起動し、OpenTelemetry を向けて、最近の失敗を SQL で照会します。所要時間は 5 分で、コレクターも設定ファイルも不要です。

このチュートリアルでは、sigiro サーバーを起動し、自分のサービスからテレメトリを 送信し、2 つの質問を尋ねます。最後には診断結果を読み、その裏側にある SQL を実行 します。所要時間は 5 分です。

sigiro は 1 つのプロセスです。コレクターをデプロイする必要はなく、設定ファイルを 書く必要もありません。

ホスト版を使う場合は sigiro signup --name "Your Name" --email you@example.com を実行してください。 ホスト版ガイドでは、作成された CLI セッションを使います。

1. 実行する

curl -fsSL https://sigiro.com/install | sh
sigiro serve

このスクリプトはお使いのオペレーティングシステムとプロセッサを読み取ります。次に、 ダウンロードした内容の SHA-256 を公開されているチェックサムと照合します。バイナリ は ~/.local/bin に書き込まれます。別のディレクトリを使用する場合は SIGIRO_INSTALL_DIR を設定してください。

ビルドは arm64 向けの Linux および macOS と、x86-64 向けの Linux に存在します。 それ以外のプラットフォームでは、コンテナをご利用ください。

新しいデータディレクトリでバイナリを初めて起動すると、準備が整う前にクエリ拡張機能を ダウンロードする場合があります。固定の待ち時間ではなく、起動ログを確認してください。

docker run -d --name sigiro --restart unless-stopped \
  -p 127.0.0.1:4317:4317 -p 127.0.0.1:4318:4318 -p 127.0.0.1:9999:9999 \
  -v sigiro-data:/var/lib/sigiro ghcr.io/sigiroai/sigiro

名前付きボリュームにより、コンテナを再起動してもデータが残ります。再起動ポリシーに より、ホストの再起動後もサーバーが起動します。Docker が公開するポートにはこのホスト からのみアクセスできます。Jaeger などが 4317 と 4318 を使用中の場合は、実行前に 最初の 2 つの -p フラグを -p 127.0.0.1:14317:4317 -p 127.0.0.1:14318:4318 に置き換えてください。OTLP HTTP の送信先は http://localhost:14318（gRPC は localhost:14317）に変更します。ホスト側の 9999 も空いている必要があります。 変更した場合は、以降の API リクエストでも変更後のホスト側ポートを使用してください。

Jaeger v2 の既存の受信先を維持してトレースを複製する場合は、Jaeger と並行して sigiro を試すを参照してください。アプリの送信先は変更しません。

3 つのポートにはそれぞれ 1 つの役割があります。

ポート プロトコル
4317 gRPC 経由の OTLP
4318 HTTP 経由の OTLP
9999 クエリおよび診断 API

テレメトリを送信する前に、サーバーが準備できていることを確認してください。

curl --fail http://localhost:9999/health

Docker では docker inspect --format '{{.State.Health.Status}}' sigiro が準備完了時に healthy を返します。そうならない場合は docker logs sigiro を確認してください。 データディレクトリはバイナリの場合は ~/.local/share/sigiro、イメージの場合は /var/lib/sigiro です。

サーバーがキーを要求しないことに注意してください。セルフホストのサーバーはリクエスト を認証しません。上記の Docker コマンドはアクセスをこのホストに制限します。信頼 できないネットワークにポートを公開しないでください。ネットワークがセキュリティ境界です。

2. テレメトリを送信する

スタック内のあらゆる OpenTelemetry SDK やコレクターが、変更なしで動作します。標準の 環境変数を sigiro に向けてください。

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 \
OTEL_SERVICE_NAME=checkout \
  <your-app-start-command>

コードにまだ計測が入っていない場合は、手作業で追加しないでください。まず エージェントでコードを計測するに従い、その後ここに 戻ってきてください。

次に、実際のトラフィックをサービスに流し、テレメトリが到達したことを確認します。

curl http://localhost:9999/v1/services

レスポンスは services 配列を含む JSON オブジェクトです。最初のリクエストから数秒 以内に、お使いのサービスがその配列に現れます。配列が空の場合は、HTTP 経由の OTLP ではポートが 4318、gRPC 経由の OTLP では 4317 になっていることを確認してください。

3. 最近のエラーを問い合わせる

最初のクエリは指定した期間の操作数と失敗数を示します。原因を断定するものではありません。

curl -sS -X POST http://localhost:9999/v1/query \
  --data-binary "SELECT span_name, count(*) AS calls,
                   sum(CASE WHEN status_code = 2 THEN 1 ELSE 0 END) AS errors
                 FROM sigiro_spans
                 WHERE service_name = 'checkout'
                   AND timestamp > CURRENT_TIMESTAMP - INTERVAL '30 minutes'
                 GROUP BY span_name ORDER BY errors DESC LIMIT 10"

4. 元のスパンを調べる

次のクエリは生のスパンを返します。修正を決める前に関連するトレースやデプロイを確認してください。保存済み異常テーブルや診断エンドポイントは使いません。

curl -sS -X POST http://localhost:9999/v1/query \
  --data-binary "SELECT trace_id, duration, status_message
                 FROM sigiro_spans
                 WHERE service_name = 'checkout' AND status_code = 2
                   AND timestamp > CURRENT_TIMESTAMP - INTERVAL '30 minutes'
                 ORDER BY timestamp DESC LIMIT 20"

ここまでにやったこと

サーバーを起動し、OpenTelemetry を送信し、期間を限定して生のテレメトリを問い合わせました。結果は証拠であり、自動的な原因判定ではありません。

次のステップ

このページは役に立ちましたか？