(Here’s the English version, easier to understand)
우리는 Docker 컨테이너를 Triton로 배포했고 다 잘 됐어요. 근데…갑자기 오늘 우리 앱가 먼제 있어요. 우리 앱은 느려요 아니면 작동하지 않아요. 그리고 컨테이너 안에 디버그 도구가 없어요. 그럼 우리는 뭐 할 거예요?
재부팅는 해결 아니에요
Triton의 컨테이너를 조금 탐에사하세요!
저는 다시 nginx 컨테이너를 트리톤에서 시작했어요.
이 컨테이너를 시작 했을 떼 컨테이너 안에 `docker exec`로 shell을 사작해고 파일 시스템를 조금 보세요. 뭘 발견했어요?
/native?
/native 뭐예요? 조금 더 보세요. 아마 유명한 Unix 프로그램을 잦아보세요? 아하! `awk`부터 `zcat`까지 다 있구나요! 그래서 /native가 다른 Unix예요? 맞아! /native는 Triton의 토박이 (native) 운영체제 이에요! 그리고 유용한 도구가 있어요!
탐사하세요.
/native에서 어랜 unix 도구가 사 살아요
/native를 사용하자!
이제는 /native기 있는걸 알아서 사용할 수 있어요. 먼저 나쁜 컨테이너 배포해요. 저는 ‘나쁜 컨테이너’ 예를 준비했어요. 소스 코드가 여기에 있어요. 이 ‘gamlerhart/waste-io’ 컨테이너를 시작하세요:
이 컨테이너 문제 있잖아요. 무슨 문제 있는 것 잦아보세요. 우리는 다시 `docker exec`로 컨테이너가 연락해요. 그럼 `iostat’ 사용 해보면 `iostat’ 없다고요. 근데 우리는 /native 사용할 수 있어요. /native의 PATH에 더하고 `iostat’ 사용 할 수 있어요:
.
아하!! 우리 컨테이너가 IO 많이 하고 있어요. 근데 우리는 더 알고 싶어요. 흠~~~….’tracing’ 하고 싶어요. ‘dtrace’ 하자요!. 맞아! dtrace가 /native에 있어요. 저는 dtrace프로 아니에요. 근데 인터넷 안내 많아요 (dtrace.org, guide, 예가).
우리는 ‘lx-sycall’-프로브 (LinuX-syscall) 사용할 거에요. `-ln lx-syscall:::`가 lx-syscall 프로브를 명단해요. -n `syscall::: { @num[execname,pid,probefunc] = count() }`는 프로브 시작하고 프로그램과 프로세스 아이디와 sycall 이름 그룹 해요. 프로브를 Cntl+C 그만하세요.
우리는 node-프로세스의 파일 시스템 write, read, open unlink하고 futex 많이 봐서 이 node 프로세스 나빠졌어요. 근데 이 프로세스가 뭐 하고 있어요? 무슨 파일 사용하고 있어요? 우리는 더 dtrace 프로브 하자! `x-syscall::open:entry` open-syscall만 보고 `execname==”node”`로 node-프로그램만 봐요. 고리고 `@num[copyinstr(arg0)] = count()`로 파일 그룹 해요:
아…임시의 파일을 많아요. 흠…node-프로그램 안에 어디에 이 임시의 파일 만들어요? Dtrace의 ‘jstack/ustack’ 우리는 스택 추적를 받을 수 있어요:
아…운이 없어요. open-syscall가 node의 이벤트 프로브에 나와요 (node를 dtrace로 알아보기 다른 주제이에요) . 근데 우리는 node를 프로그램가 `tmp/io-file-` 파일 마들기 알아고 이제 아마 프로그램 버그 문제를 풀 수 있어요.
셜록 ‘dtrace’ 홈즈
dtrace 잘 아세요?
dtrace 잘 알면 많는 프로브 못 잦아요? 그럼 Triton 컨테이너 안에 컨테이너만 볼 수 있어서 dtrace 프로보 덜 많아요. 그리고 우리는 Joyent의 클라우드 스비스 ‘global-zone’ 들어가면 못 해요. 개인 Triton가 있으면 할 수 있어요. 근데 이 글 끝냈어요. ^.^끝
