Sentry 로그 수집 시스템 복구

Sentry 가 출시 된 지 거의 두 달 만 에 무 너 졌 습 니 다. 무 너 진 원인 은 두 가지 가 있 습 니 다.
1. postgresql 용 기 를 실행 하 는 기계 디스크 공간 이 소 진 되 어 데이터 베이스 가 서 비 스 를 중단 합 니 다.
2. Nginx 와 sentry 웹 을 실행 하 는 docker 를 다시 시작 할 수 없습니다.
sentry 를 복구 하 는 과정 은 두 단계 로 나 뉜 다.
1. postgresql 에서 30 일 전의 데 이 터 를 정리 하고 디스크 공간 을 복원 합 니 다.
2. sentry 웹 과 nginx 를 실행 하 는 기계 에 docker 를 재 설치 합 니 다. nginx 와 sentry 웹 server 가 상 태 를 저장 하지 않 기 때문에 웹 server 를 재 구축 하면 데이터 가 손실 되 지 않 습 니 다.

postgresql 디스크 공간 청소:

여기에 대응 하 는 작업 은 database rotation 이 라 고 불 려 야 합 니 다. sentry 자체 가 cleanup 라 는 도구 로 cleanup 를 이용 하여 만 료 된 데 이 터 를 삭제 할 수 있 습 니 다.
단, cleanup 는 데이터베이스 에 서 비 스 를 요구 합 니 다.sentry 를 구축 할 때 postgresql 을 위주 로 구축 하고 메 인 라 이브 러 리 에 있 는 기계 디스크 가 다 소모 되 어 데이터베이스 서 비 스 를 시작 할 수 없습니다.다행히 라 이브 러 리 에 20G 정도 의 남 은 공간 이 있어 서 라 이브 러 리 의 디스크 공간 을 정리 한 다음 에 라 이브 러 리 를 주 라 이브 러 리 로 올 린 다음 에 원래 의 라 이브 러 리 디스크 를 비우 고 새 라 이브 러 리 의 데 이 터 를 동기 화 할 수 있 습 니 다.이렇게 하면 일부 데 이 터 를 손실 시 킬 수 있 는데, 다행히 sentry 가 기록 한 데 이 터 는 특별히 중요 하지 않다.

cleanup:

sentry 의 cleanup 도구 동작 도움말

root@9acfe6561812:/# sentry cleanup --help
Usage: sentry cleanup [OPTIONS]

  Delete a portion of trailing data based on creation date.

  All data that is older than `--days` will be deleted.  The default for this is 30 days.  In
  the default setting all projects will be truncated but if you have a specific project you want
  to limit this to this can be done with the `--project` flag which accepts a project ID or a
  string with the form `org/project` where both are slugs.

Options:
  --days INTEGER         Numbers of days to truncate on.  [default: 30]
  --project TEXT         Limit truncation to only entries from project.
  --concurrency INTEGER  The number of concurrent workers to run.  [default: 1]
  -q, --silent           Run quietly. No output on success.
  -m, --model TEXT
  --help                 Show this message and exit.

sentry 웹 이 있 는 서버 에서 진행 되 며, postgresql 에 대해 원 격 cleanup 을 진행 합 니 다.

docker run -d --name sentry_cleanup

...        

 sentry --config /sentry_conf.py cleanup --days 30

이렇게 하면 현재 일 기간 30 일 전의 데 이 터 를 삭제 할 수 있다.

vacuum：

cleanup 을 실행 한 후에 df - h 명령 을 사용 하면 데이터베이스 가 차지 하 는 디스크 공간 이 줄 어 들 지 않 고 남 은 공간 이 20 여 G 밖 에 없 는 것 을 발견 할 수 있 습 니 다. 이것 은 cleanup 의 delete 명령 으로 postgresql 데 이 터 를 삭 제 했 기 때 문 입 니 다. 그러나 postgrdsql 은 delete, update 등에 대해 해당 하 는 줄 표 지 를 DEAD 로 표시 할 뿐 디스크 공간 을 진정 으로 방출 하지 않 았 습 니 다.(참고:http://www.cnblogs.com/littlehb/archive/2013/04/28/3048892.html）
이 를 DEAD 행 기록 으로 표시 하 는 데 사용 되 는 공간 을 철저하게 방출 하기 위해 서 는 vacuum 작업 이 필요 합 니 다.
vacuum 작업 은 postgresql 자체 의 vacuumdb 도 구 를 사용 할 수 있 습 니 다. vacuumdb 작업 도움말 은:

root@s1226:/# vacuumdb --help
vacuumdb cleans and analyzes a PostgreSQL database.

Usage:
  vacuumdb [OPTION]... [DBNAME]

Options:
  -a, --all                       vacuum all databases
  -d, --dbname=DBNAME             database to vacuum
  -e, --echo                      show the commands being sent to the server
  -f, --full                      do full vacuuming
  -F, --freeze                    freeze row transaction information
  -q, --quiet                     don't write any messages
  -t, --table='TABLE[(COLUMNS)]'  vacuum specific table(s) only
  -v, --verbose                   write a lot of output
  -V, --version                   output version information, then exit
  -z, --analyze                   update optimizer statistics
  -Z, --analyze-only              only update optimizer statistics
  -?, --help                      show this help, then exit

Connection options:
  -h, --host=HOSTNAME       database server host or socket directory
  -p, --port=PORT           database server port
  -U, --username=USERNAME   user name to connect as
  -w, --no-password         never prompt for password
  -W, --password            force password prompt
  --maintenance-db=DBNAME   alternate maintenance database

Read the description of the SQL command VACUUM for details.

Report bugs to .

vacuumdb 는 postgres 사용자 로 실행 되 어야 합 니 다. sudo - u 작업 에 맞 출 수 있 습 니 다. 예 를 들 어 sentry공간 정 리 를 위 한 명령 은:

root@s1226:/# sudo -u postgres vacuumdb -U postgres -d sentry -t nodestore_node -v -f --analyze     
sudo: unable to resolve host s1226.bx.sys.d
INFO:  vacuuming "public.nodestore_node"
INFO:  "nodestore_node": found 75819 removable, 705972 nonremovable row versions in 461966 pages
DETAIL:  0 dead row versions cannot be removed yet.
CPU 12.00s/52.63u sec elapsed 126.17 sec.
INFO:  analyzing "public.nodestore_node"
INFO:  "nodestore_node": scanned 30000 of 59846 pages, containing 353649 live rows and 0 dead rows; 30000 rows in sample, 705727 estimated total rows

인쇄 된 정 보 는 잘 모 르 겠 습 니 다. row 가 dead 이 고 removable 인 것 을 발견 한 다음 에 공간 을 풀 어 저장 구멍 을 정리 한 것 으로 추 정 됩 니 다.
잘 모 르 겠 지만 모든 데이터 시트 를 정리 한 결과 디스크 에 많은 공간 이 방출 되 었 습 니 다.

root@s1226:/# df -h
Filesystem                                                                                          Size  Used Avail Use% Mounted on
/dev/mapper/docker-253:17-1048577-21e6cfea1af36f66bd554fbb5b5eec529d63692288a2d9115a9ee91d3457cb98   10G  501M  9.6G   5% /
tmpfs                                                                                               3.9G     0  3.9G   0% /dev
tmpfs                                                                                               3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/vdb1                                                                                            99G   36G   58G  39% /cluster/database
shm                                                                                                  64M     0   64M   0% /dev/shm
/dev/vda1                                                                                            12G  1.7G   11G  14% /etc/keepalived/keepalive.conf

/ cluster / database 가 마 운 트 한 나머지 공간 은 기 존 20 여 G 에서 58G 로 늘 었 습 니 다.
이로써 메 인 라 이브 러 리 의 공간 을 정리 한 다음 에 예비 라 이브 러 리 를 시작 하고 keepalived 를 실행 합 니 다. 데이터 베 이 스 를 복원 하 는 것 이 완료 되 었 습 니 다 (일부 데 이 터 를 잃 어 버 렸 습 니 다)

sentry 웹 서버 의 복구:

sentry 시스템 에서 저 는 nginx, sentry 웹, celery cron 과 celery worker 를 같은 host 에 배치 합 니 다. 밝 혀 지지 않 은 이유 로 두 달 동안 실행 한 후에 docker 가 끊 었 습 니 다. docker 를 다시 시작 하면 용 기 를 다시 시작 하 는 시간 이 초과 되 고 용기 가 있 는 디 렉 터 리 디스크 는 100% 를 차지 하 며 실행 로그 로 채 워 질 수 있 습 니 다.
sentry 웹 server 자체 에 데 이 터 를 저장 하지 않 고 복구 가 간단 하 며 직접 재 구축 하면 됩 니 다.그러나 구축 이 끝 난 후 브 라 우 저 를 통 해 sentry 의 관리 인터페이스 에 로그 인 하면 500 Internal Error 의 오류 가 발생 할 수 있 습 니 다. 온라인 요청 이 끊 이지 않 아 오류 로그 가 잠 겨 해결 방법 을 찾 지 못 했 습 니 다.
이런 상황 에서 돌파 구 는 오류 재현 + 오류 포 지 셔 닝 입 니 다. 생각 을 정리 한 후에 다음 과 같이 조작 합 니 다.
1. 그 중의 한 server 에 대해 대외 적 인 nginx 용 기 를 닫 고 외부 요청 을 잠시 거절 하 며 테스트 용 nginx 용 기 를 시작 합 니 다. 도 메 인 이름 s1226 인 server 를 설정 합 니 다.
2. docker logs - f -- tail sentry 명령 을 사용 하여 sentry 웹 서버 의 로 그 를 감시 합 니 다 (sentry 로 그 는 모두 stdout 에 직접 출력 되 었 으 며 서버 내부 에 파일 을 기록 하지 않 았 습 니 다)
3. 브 라 우 저 로그 인 관리 인터페이스 에서 전단 에 오류 가 발생 했 습 니 다. 이때 배경 에서 이상 을 발 견 했 습 니 다. 이 유 는 조작 이 존재 하지 않 는 데이터 시트 sentry 때 문 입 니 다.organizationavator
그 다음 에 stacktrace 에 따 르 면 소스 코드 를 추적 한 결과 존재 하 는 파일 이 실 행 된 것 을 발견 했다. 그 제야 환경 을 구축 할 때 docker pull sentry 는 지정 한 버 전이 없고 끌 어 내 린 미 러 는 sentry 8.13 이 며 데이터 베 이 스 는 sentry 8.11 에 대응 하여 sentry 버 전 을 바 꾼 후에 문 제 를 해결 했다.