스스로 복구하는 소프트웨어를 위한 데이터 레이어.
탐지 · sigiro
$ sigiro anomalies
SERVICE SIGNAL BASELINE NOW SHIFT INCIDENT
checkout error_rate 0.4% 19.2% +0.96 checkout@18:35
checkout latency_p95 180ms 30.0s +0.99 checkout@18:35
2 shifts · 1 incident · since 18:35
진단 · sigiro
$ sigiro diagnose checkout
suspect deploy 9f2c1ab, landed 18:33
failing POST /api/orders
failure mode timeout 246 · server_error 6
errors_total 1284
drill_down_sql SELECT trace_id, duration, status_message
FROM sigiro_spans WHERE service_name = 'checkout' …
수정 · 사용자의 에이전트
$ claude "checkout times out since 9f2c1ab"
read src/orders/upstream.ts
edit src/orders/upstream.ts +4 −1
test 42 passed
push fix: bound the orders upstream call at 5s
검증 · 사용자의 파이프라인, sigiro의 증거로
$ sigiro anomalies --service checkout
SERVICE SIGNAL BASELINE NOW SHIFT INCIDENT
no shifts · checkout · last 7d
학습 · 사용자의 메모리
$ cat playbooks/checkout-upstream-timeout.md
## checkout · upstream timeout
detected error_rate +0.96, latency_p95 +0.99
cause unbounded upstream call, shipped in 9f2c1ab
fix 5s deadline on the orders client
watch the same shape on any service calling orders
사용 방법
네 단계. 연결하고, 질문하고, 상관관계를 보고, 확인합니다.
OpenTelemetry를 sigiro로 보냅니다. 질문 하나를 던집니다. 아래의 각 단계는 셸 세션 하나입니다.
sigiro는 표준 포트에서 표준 OTLP를 사용합니다.
$ curl -fsSL https://sigiro.com/install | sh
installed ~/.local/bin/sigiro
$ sigiro serve &
[1] 41802
listening on 4317, 4318, 9999
$ export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
$ export OTEL_SERVICE_NAME=checkout
$ npm start &
[1] 41823
checkout listening on :3000
$ sigiro status
ready · OTLP 4317 and 4318 · service checkout · 18,402 spans in 5 min
$ curl -sX POST localhost:9999/v1/diagnose -d '{"service":"checkout"}'
{
"summary": "two signals moved together on checkout at 18:35",
"suspect": "deploy 9f2c1ab, landed 18:33",
"failing": "POST /api/orders",
"how": { "timeout": 246, "server_error": 6 },
"errors_total": 1284,
"query": "SELECT * FROM spans WHERE service = 'checkout' AND ..."
}
$ cat models.sql
SELECT model, count(*) AS calls, max(duration) AS slowest
FROM spans JOIN logs USING (trace_id)
WHERE service = 'checkout' AND status = 'error'
GROUP BY model ORDER BY slowest DESC
$ sigiro query --sql-file models.sql
MODEL CALLS SLOWEST
gpt-5.2-mini 246 30.0s
claude-haiku-4.6 31 2.1s
$ curl -s localhost:9999/v1/diagnose -d '{"service":"checkout"}' > answer.json
$ jq .operation_summaries[0] answer.json
{
"operation": "POST /api/orders",
"errors": 246,
"error_rate": 0.19,
"drill_down_sql": "SELECT trace_id, duration, status_message FROM …"
}
$ jq -r .operation_summaries[0].drill_down_sql answer.json > drill.sql
$ sigiro query --sql-file drill.sql
TRACE_ID DURATION STATUS_MESSAGE
9f2c1ab4e77d 30012 context deadline exceeded
3b81fe0a2c56 30004 context deadline exceeded
c40d9e73aa18 29997 context deadline exceeded탐색. 에이전트가 도움 없이 API 설명을 읽습니다.
공개 문서 하나가 모든 엔드포인트를 설명합니다.
[
"/v1/anomalies",
"/v1/diagnose",
"/v1/query",
"/v1/services",
"/v1/traces/{trace_id}"
]얻는 것
마이그레이션 불필요. sigiro는 이미 사용 중인 도구에 연결됩니다.
텔레메트리를 보내는 곳
실행하는 곳
결과를 읽는 곳
- 직접 확인하십시오
- 모든 결과에는 그 결과를 만든 쿼리가 들어 있습니다.
- 유지 관리할 것이 없습니다
- 임계값도 규칙도 설정하지 않습니다. sigiro는 각 서비스의 이력을 사용합니다.
- 5분이면 설치가 끝납니다
- 명령어 하나와 환경 변수 두 개면 됩니다. 코드는 바꾸지 않습니다.
- 직접 설치하면 무료입니다
- 호스트 수, 사용자 수, 데이터 양에 따른 요금이 없습니다. 저희가 대신 운영하기를 원하시면 문의해 주십시오.
- 데이터는 사용자 환경에 남습니다
- sigiro는 사용자의 서버에 설치합니다. sigiro는 저희에게 어떤 데이터도 보내지 않습니다.
- sigiro가 sigiro를 모니터링합니다
- sigiro는 자체 텔레메트리를 sigiro로 보냅니다. 저희는 이렇게 저희 장애를 찾습니다.