로그 내보내기 (Export logs)
Fly Log Shipper 앱을 사용하면 앱의 로그를 여러분이 선택한 서비스로 모아 보낼 수 있어요. 이 문서에서는 Log Shipper를 배포하고 구성해서 Datadog이나 AWS S3 같은 외부 서비스로 로그를 보내는 방법을 알려드려요.
Fly Log Shipper 앱을 사용하면 앱의 로그를 여러분이 선택한 서비스로 집계할 수 있어요.
앱이 stdout으로 출력하는 것이 Fly.io에서 로그가 돼요. 라이브 로그 테일과 로그 검색은 대부분의 경우 충분해요. 하지만 Datadog이나 AWS S3 같은 외부 서비스로 로그를 내보내야 한다면 Log Shipper를 사용할 수 있어요.
출처: 문서
본문
Fly Log Shipper
로그를 여러분이 선택한 위치로 보내는 가장 쉬운 방법이에요.
Fly Log Shipper 앱은 Fly.io의 내부 로그 스트림에 연결돼요. 다른 앱처럼 Fly.io 조직에서 이것을 실행할 수 있어요.
Fly Log Shipper는 Vector를 실행하며, Vector가 로그를 잡아 여러분이 선택한 위치로(Vector sink를 통해) 보내요.
지원되는 Providers (sinks) 목록에서 하나 이상을 선택하고 Fly Log Shipper가 그 sink들을 실행하도록 구성할 수 있어요.
각 provider는 동작하는 데 몇 가지 환경 변수(또는 시크릿)만 설정하면 돼요.
Fly Log Shipper 사용하기
예시를 들어볼게요. Logtail로 로그를 보내려면 다음과 같이 하면 돼요:
# Make a directory for your log shipper app
mkdir logshippper
cd logshippper
# Create the app but don't deploy just yet
fly launch --no-deploy --image ghcr.io/superfly/fly-log-shipper:latest
# Set some secrets. The secret / env var you set
# determines which "sinks" are configured
ORG=personal
fly secrets set ORG=$ORG
fly secrets set ACCESS_TOKEN=$(fly tokens create readonly $ORG)
fly secrets set LOGTAIL_TOKEN=<token provided by logtail source>
원하는 만큼 많은 provider를 시크릿을 추가해 구성할 수 있어요. 필요한 시크릿은 사용하려는 provider에 따라 결정돼요.
Log Shipper는 Fly.io의 내부 로그 스트림에서 로그를 가져오며 인바운드 연결을 받아들일 필요가 없으므로, 공개 서비스나 IP 주소가 없어야 해요. 배포 전에 생성된 fly.toml 파일을 편집해 [http_service](또는 [[services]]) 섹션 전체를 삭제하세요.
그런 다음 공개 IP 주소를 할당하지 않고 배포하세요:
fly deploy --no-public-ips
이미 공개 IP 주소가 있는 Log Shipper를 배포했다면, fly ips list로 주소를 나열하고 fly ips release <address>로 제거하세요.
헬스 체크 추가하기
Log Shipper는 가끔 종료하지 않고 로그 전송을 멈출 수 있으므로 헬스 체크를 추가하는 것이 좋아요. Vector는 포트 8686에서 /health 엔드포인트를 제공해요. 앱에 서비스가 없으므로 fly.toml의 최상위 [checks] 섹션을 사용하세요. 이는 공개 서비스나 IP 주소가 필요하지 않아요:
[checks]
[checks.vector]
port = 8686
type = "http"
method = "get"
path = "/health"
grace_period = "10s"
interval = "30s"
timeout = "5s"
fly checks list로 헬스 상태를 확인하세요.
특정 로그 보내기
기본적으로 로그 시퍼는 조직 내에서 실행되는 모든 앱의 로그를 가져와요(조직은 ORG 시크릿/환경 변수로 설정돼요).
그 범위를 좁히려면 Fly Log Shipper 인스턴스에 SUBJECT 환경 변수를 설정할 수 있어요. 이는 시크릿으로 설정하거나 fly.toml 파일의 환경 변수로 설정할 수 있어요.
Subject 형식은 logs.<app_name>.<region>.<instance_id>예요. Log Shipper를 특정 인스턴스, 특정 리전, 그리고/또는 특정 애플리케이션으로 좁힐 수 있어요.
사용할 수 있는 와일드카드 2개가 있어요:
*와일드카드는 문자열 사이에 들어가며 여러 번 사용할 수 있어요>와일드카드는 문자열 끝에 가며 한 번만 사용할 수 있어요
예를 들어, sandwich라는 이름의 애플리케이션의 로그만 보내려면 SUBJECT 환경 변수를 다음과 같이 설정하면 돼요(Log Shipper fly.toml 파일에서):
[env]
SUBJECT = "logs.sandwich.>"
이것은 > 와일드카드를 사용해 sandwich 애플리케이션의 모든 로그를, 어느 리전이나 인스턴스에서 나왔든 잡으라고 말해요.
다른 예시:
[env]
SUBJECT = "logs.*.dfw.>"
이 SUBJECT는 dfw 리전에 호스팅된 모든 애플리케이션의 모든 인스턴스에서 로그를 잡으라고 말해요.
Vector 구성하기
provider(또는 선호도)에 따라 Vector 구성을 커스터마이즈해야 할 수도 있어요. 이는 vector.toml 구성 파일로 하며, Machine files 덕분에 source vector.toml을 로컬 디렉터리로 복사하고, 요구사항에 맞게 수정한 다음, 저장하고 재배포하는 것만큼 간단해요:
fly deploy --file-local="/etc/vector/vector.toml=/path/to/local/vector.toml"
그게 다예요! 내장된 구성 파일이 덮어써지고 Vector가 수정된 구성을 사용해요.
내부 구조
Fly.io는 NATS 스트림을 통해 로그를 보내요. 이것은 nats://[fdaa::3]:4223의 모든 앱에 사용 가능하며, Log Shipper가 로그를 잡는 곳이 바로 여기예요.
Log Shipper 내에서 그 로그를 잡는 Vector 구성은 vector.toml 파일에 있어요.
이 저장소에 기여해(또는, 아시다시피 fork해서) 여러분 자신만의 provider(sink)를 추가할 수 있어요!
고가용성 앱에서 중복 로그 메시지 피하기
고가용성을 위해 두 대 이상의 Machine을 실행하고 싶다면, NATS 엔드포인트가 구독 큐(subscription queues)를 지원해서 이름이 지정된 큐의 한 구독자에게만 메시지가 보내지도록 보장해요. HA를 위해 여러 로그 프로세스를 실행하고 중복 메시지가 전송되는 것을 피하고 싶다면, Log Shipper fly.toml 파일에서 QUEUE 시크릿을 설정해 임의의 큐 이름을 구성할 수 있어요. 예를 들어:
[env]
QUEUE = "org-logs"