본문으로 건너뛰기
sigiro
Esc
↑↓이동↵열기⌘J미리보기
이 페이지에서

빠른 시작

명령 하나로 sigiro를 실행하고 OpenTelemetry를 가리킨 다음, 최근 실패를 SQL로 조회하십시오. 5분이면 되고 컬렉터도 설정 파일도 필요 없습니다.

이 튜토리얼에서는 sigiro 서버를 시작하고, 사용자 서비스의 텔레메트리를 전송하며, 두 가지 질문을 던집니다. 마지막에는 진단 결과를 읽고 그 근거가 되는 SQL을 실행합니다. 5분이 걸립니다.

sigiro는 하나의 프로세스입니다. 컬렉터를 배포하지 않으며 설정 파일도 작성하지 않습니다.

호스팅 버전을 사용하려면 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을 사용 중이라면 명령을 실행하기 전에 처음 두 -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 시험 실행을 참고하십시오. 애플리케이션의 전송 대상은 변경하지 않습니다.

세 개의 포트는 각각 하나의 기능을 담당합니다:

포트 프로토콜
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를 보낸 다음 기간이 제한된 원본 텔레메트리를 조회했습니다. 결과는 증거이지 자동 원인 판정이 아닙니다.

다음 단계

이 페이지가 도움이 되었나요?