Sysdig : 정의 및 사용법

Sysdig는 컨테이너를 지원하는 범용 시스템 가시성 도구입니다. Sysdig를 특별하게 만드는 것은 시스템의 커널에 연결되어 컨테이너별로 정보를 분리한다는 것입니다. 이 자습서에서는 Sysdig의 오픈 소스 버전에 중점을 둘 것입니다.

다음 섹션에서는 다음을 수행합니다.

  • Sysdig 설치
  • docker-compose를 사용하여 Wordpress 설치 스핀 업
  • Sysdig를 사용하여 이벤트를 수집하고 나중에 분석하십시오
  • Sysdig를 사용하여 실시간으로 데이터 분석

전제 조건

  • Docker가 시스템에 설치되어 있습니다. Docker 설치에 대한 자세한 내용은 Docker 설치 페이지를 참조하십시오.
  • Docker Compose가 시스템에 설치되어 있습니다. Docker Compose 설치 방법에 대한 지시 사항은 Docker Compose 설치 페이지를 참조하십시오.
  • 커널 헤더는 호스트 시스템에 설치됩니다.

Sysdig 설치

Docker 컨테이너 내에 Sysdig를 설치하려면 다음 단계를 따르십시오.

  1. 터미널 창에서 다음 명령을 실행하여 Sysdig Docker 이미지를 가져옵니다.
도커 풀 sysdig / sysdig
기본 태그 사용 : 최신 최신 : sysdig / sysdig에서 당기기 2967486b0658 : 당기기 완료 78101b780c72 : 당기기 완료 7e78b657334d : 당기기 완료 650327159ca8 : 당기기 완료 47ebf73ab754 : 당기기 완료 bf51ac76a6d9 : 당기기 완료 0cd11104dbf6 : 당기기 완료 e6dcf17d00d8d : 완료 완료 e6dcf17d00d8d : 완료 완료 풀 완료 6de86c8ed6e9 : 풀 완료 8d1825f8be4b : 풀 완료 다이제스트 : sha256 : bbfe6953fd2b3221a8974eb13024dd33c7e78aebef8fee3d7a0d9ecdeed84ce0 상태 : sysdig / sysdig : latest에 대한 최신 이미지 다운로드

2. 다음을 입력하여 컨테이너에서 Sysdig를 실행하십시오.

docker run -i -t --name sysdig --privileged -v /var/run/docker.sock:/host/var/run/docker.sock -v / dev : / host / dev -v / proc : / host / proc : ro -v / boot : / host / boot : ro -v / lib / modules : / host / lib / modules : ro -v / usr : / host / usr : ro sysdig / sysdig
* 호스트에서 / usr / src 링크 설정 * 존재하는 경우 sysdig-probe 언로드 * sysdig에 대해 dkms 설치 실행 중 오류! echo 커널 3.10.0-957.12.2.el7.x86_64의 커널 헤더는 /lib/modules/3.10.0-957.12.2.el7.x86_64/build 또는 /lib/modules/3.10.0-957.12에서 찾을 수 없습니다. .2.el7.x86_64 / source. * dkms 빌드 실행에 실패했으며 /var/lib/dkms/sysdig/0.26.4/build/make.log를 찾을 수 없음 * 시스템 sysdig-probe가있는 경우로드하려고 시도 * 3.10에 대해 사전 컴파일 된 sysdig-probe를 찾으려고 시도 .0-957.12.2.el7.x86_64 /host/boot/config-3.10.0-957.12.2.el7.x86_64에서 커널 구성을 찾았습니다. https://s3.amazonaws.com/download에서 사전 컴파일 된 모듈을 다운로드하려고합니다. .draios.com / stable / sysdig-probe-binaries / sysdig-probe-0.26.4-x86_64-3.10.0-957.12.2.el7.x86_64-82e2ae1fb159132636f7b50a762f20ef.ko 다운로드 성공, 모듈 root @ 7b14a23f22eb로드 중 : / #

위 명령에 대해 몇 가지 참고할 사항 :

  • -i 플래그는 STDIN을 열린 상태로 유지합니다.
  • --privileged 매개 변수는 호스트의 모든 장치에 대한 액세스를 제공합니다. 또한 컨테이너 내부에서 실행중인 프로세스가 호스트에서 실행되는 프로세스와 동일한 호스트 액세스를 허용하도록 SELinux를 설정합니다.
  • -v 플래그는 Sysdig가 액세스 할 수있는 파일 목록 (호스트에서)을 지정합니다.

Wordpress 설치 스핀 업

이 섹션에서는 docker-compose 명령을 사용하여 Wordpress를 설치합니다.

  1. 새 터미널 창에서 프로젝트 디렉토리로 이동하여 다음 명령을 입력하십시오.
mkdir 워드 프레스 -sysdig && cd 워드 프레스 -sysdig

2. 다음 내용으로 docker-compose라는 파일을 만듭니다.

버전 : '3.3'서비스 : db : 이미지 : mysql : 5.7 볼륨 :-db_data : / var / lib / mysql 재시작 : 항상 환경 : MYSQL_ROOT_PASSWORD : somewordpress MYSQL_DATABASE : wordpress MYSQL_USER : wordpress MYSQL_PASSWORD : wordpress wordpress : depend_on :-db 이미지 : 워드 프레스 : 최신 포트 :- "8000 : 80"재시작 : 항상 환경 : WORDPRESS_DB_HOST : db : 3306 WORDPRESS_DB_USER : 워드 프레스 WORDPRESS_DB_PASSWORD : 워드 프레스 WORDPRESS_DB_NAME : 워드 프레스 볼륨 : db_data : {}

3. 다음을 사용하여 docker-compose up 명령을 분리 모드로 실행하십시오.

docker-compose up -d
기본 드라이버로 네트워크 "wordpress-sysdig_default"생성 기본 드라이버로 볼륨 "wordpress-sysdig_db_data"생성 워드 프레스 풀기 (wordpress : latest) ... 최신 : 라이브러리 / 워드 프레스에서 당기기 8ec398bc0356 : 풀 완료 85cf4fc86478 : 풀 완료 970dadf4ccb6 : 풀 완료 8c04561117a4 : 당기기 완료 d6b7434b63a2 : 당기기 완료 83d8859e9744 : 당기기 완료 9c3d824d0ad5 : 당기기 완료 9e316fd5b3b3 : 당기기 완료 578b40496c37 : 당기기 완료 814ae7711d3c : 당기기 완료 4896fed78b6b : 당기기 완료 e74c5409086 완전 Ecda5b7aad12 당기기 : 완전 완료 84256a6b6b44 : 당기기 완료 35d4f385efb7 : 당기기 완료 bf697c2ae701 : 당기기 완료 d054b015f084 : 당기기 완료 다이제스트 : sha256 : 73e8d8adf491c7a358ff94c74c8ebepresspresspress 워드 워드를 생성합니다. press_1 ... 완료

4. 다음을 통해 컨테이너 상태를 확인할 수 있습니다.

도커 PS

모든 것이 잘 진행되면 다음과 유사한 결과가 나타납니다.

컨테이너 ID 이미지 명령 생성 상태 포트 이름 f390eec29f52 wordpress : latest "docker-entrypoint.s…"1 분 전 Up Up 약 1 분 정도 0.0.0.0:8000->80/tcp wordpress-sysdig_wordpress_1 a844840626d8 mysql : 5.7 "docker-entrypoint. s… "약 1 분 전 Up 약 1 분 3306 / tcp, 33060 / tcp wordpress-sysdig_db_1 7b14a23f22eb sysdig / sysdig"/docker-entrypoint.… "13 분 전 Up 13 분 sysdig

5. 이제 Wordpress가 시작되었습니다. 설치 마법사를 시작하려면 브라우저를 http : // localhost : 8000으로 지정하십시오.

6. 설치 마법사가 완료되면 샘플 포스트를 작성해 보겠습니다.

파일로 데이터 수집

이 섹션에서는 Sysdig를 사용하여 이벤트를 수집하고 나중에 분석하는 방법을 보여줍니다.

  1. 캡처 된 모든 이벤트를 파일로 덤프하려면 Sysdig 컨테이너로 이동하고 다음 명령을 입력하십시오.
sysdig -w 모니터링 -wordpress.scap

2. 새 터미널 창에서 ab를 사용하여 최대 100 개의 요청을 동시에 실행하면서 10000 개의 요청을합니다.

ab -n 1000 -c 100 http : // localhost : 8000 /? p = 7
이것은 ApacheBench, 버전 2.3 <$ Revision : 1430300 $>입니다. Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Apache Software Foundation 라이센스, http://www.apache.org/ Benchmarking localhost (환자) 완료 100 건 완료 200 건 완료 300 건 완료 400 건 완료 400 건 완료 500 건 완료 600 건 완료 700 건 완료 800 건 완료 900 건 완료 1000 건 완료 1000 건 완료

위의 출력은 간결성을 위해 잘 렸습니다.

3. 둘러보기 Sysdig 컨테이너로 돌아가서 "CTRL + C"를 입력하여 데이터 캡처를 중지하십시오.

데이터 분석

이제 monitoring-wordpress.scap 파일의 크기를 보면 Sysdig가 80M 이상의 데이터를 캡처했음을 알 수 있습니다.

ls -lh 모니터링 -wordpress.scap
-rw-r--r--. 1 루트 루트 80M 1 월 7 일 16:28 모니터링 -wordpress.scap

이 산을 통해 길을 찾으려면 끌이라는 것을 사용합니다.

부정 행위는 기본적으로 이벤트 스트림을 분석하고 유용한 조치를 수행하는 Lua 스크립트입니다.

다음 명령을 실행하여 끌 목록을 표시 할 수 있습니다.

sysdig -cl
범주 : 응용 프로그램 --------------------- httplog HTTP 요청 로그 httptop 최상위 HTTP 요청 memcachelog memcached 요청 로그 범주 : CPU 사용 ---------- --------- 스펙트로 그램 OS 대기 시간을 실시간으로 시각화합니다. subsecoffset 1 초 미만의 오프셋 실행 시간을 시각화합니다. topcontainers_cpu CPU 사용량 별 상위 컨테이너 topprocs_cpu CPU 사용량 별 상위 프로세스 범주 : 오류 ---------------- topcontainers_error 오류 수별 상위 컨테이너 topfiles_errors 오류 수별 상위 파일 topprocs_errors 숫자 별 상위 프로세스 오류

위의 출력은 간결성을 위해 잘 렸습니다.

치즐에 대한 자세한 정보를 검색하려면 다음 예제와 같이 sysdig 명령과 -i 플래그 및 치즐의 이름을 차례로 실행하십시오.

sysdig -i httptop
카테고리 : 애플리케이션 --------------------- httptop 상위 HTTP 요청 상위 HTTP 요청을 다음 기준으로 표시 : ncall, 시간 또는 바이트 Args : [string] by-상위 HTTP 트랜잭션 표시 by : ncalls, 시간 또는 tes로, 기본값은 ncalls입니다.

예제를 계속해서 httptop 끌을 사용하여 최상위 HTTP 요청을 표시하는 방법은 다음과 같습니다.

sysdig -r 모니터링 -wordpress.scap -c httptop
ncalls 메소드 URL ----------------------------------------------- ---------------------------------- 2001 GET localhost : 8000 /? p = 7 14 옵션 * 2 GET localhost : 8000 / favicon.ico 1 GET /wp-content/themes/twentytwenty/assets/fonts/inter/Inter-upright-var.woff2 1 GET localhost / v1.24 / containers / 6bd8418eb03f / json 1 GET localhost / v1.24 / 컨테이너 / 06def7875617 / json 1 GET /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600 1 GET /v1.24/images/db39680b63ac47a1d989da7b742f7b382af34d85a68214f8977

-pcontainer 플래그를 사용하여 컨테이너 친화적 인 형식으로 동일한 정보를 볼 수 있습니다.

sysdig -r 모니터링 -wordpress.scap -c httptop -pcontainer
ncalls 컨테이너 메소드 URL ---------------------------------------------- ---------------------------------- 1000 wordpress-sysdig_wo GET localhost : 8000 /? p = 7 1000 호스트 GET localhost : 8000 /? p = 7 43 wordpress-sysdig_wo 옵션 * 1 sysdig GET /v1.24/images/1b1624b63467ec61fab209b6be6e79707ae786df86607b9474b246acd31600 1 sysdig GET localhost / v1.24 / containers / 06def7875617 / jsonhost sysdig GET cd06093b141b / json 1 sysdig GET /v1.24/images/00e230fe24da9067f9b6e65cfbe9935a5affac1ae8e44edb6a5b0ccc26374d 1 sysdig GET /v1.24/images/db39680b63ac47a1d989da7b34f901b77a38d79da14c59f901

더 깊이 파기

Sysdig는 컨텐츠가 풍부한 정보를 캡처하여 컨테이너의 내부 작동에 대한 자세한 통찰력을 얻습니다. 몇 개의 컨테이너를 실행 중이고 어떤 프로세스가 가장 많은 CPU를 소비하는지 알고 싶다고 가정 해 봅시다.

  1. 이벤트를 캡처 한 기간 동안 활성화 된 컨테이너를 나열하십시오.
sysdig -r 모니터링 -wordpress.scap -c lscontainers

2. 가장 많은 CPU를 소비 한 컨테이너를 다음과 같이 식별 할 수 있습니다.

sysdig -r 모니터링 -wordpress.scap -c topcontainers_cpu
CPU % container.name --------------------------------------------- ----------------------------------- 5.37 % wordpress-sysdig_wordpress_1 1.35 % wordpress-sysdig_db_1 0.84 % 호스트 0.51 % sysdig

3. topprocs_cpu chisel을 사용하면 더 많은 CPU를 사용하는 프로세스를 더 깊이 파고 식별 할 수 있습니다.

sysdig -r monitoring-wordpress.scap -c topprocs_cpu container.name에 wordpress_1이 포함되어 있습니다
CPU % 프로세스 PID ---------------------------------------------- ---------------------------------- 0.12 % 아파치 2 8383 0.11 % 아파치 2 9413 0.11 % 아파치 2 9300 0.11 % 아파치 2 9242 0.11 % 아파치 2 8897 0.11 % 아파치 2 8422 0.10 % 아파치 2 9372 0.10 % 아파치 2 9241 0.10 % 아파치 2 8424 0.09 % 아파치 2 9429

더 자세한 내용을 보려면 ps chisel이 더 자세한 대안을 제공합니다.

sysdig -r monitoring-wordpress.scap -c ps container.name = wordpress-sysdig_wordpress_1
TID PID 사용자 VIRT RES FDLIMIT CMD 5896 5896 루트 232.82M 22.32M 429496729 apache2 8383 8383 www-data 307.44M 25.46M 429496729 apache2 8422 8422 www-data 235.44M 22.90M 429496729 apache2 8424 8424 www.data46307974444 8897974444 8897974444 8897 www-data 235.44M 22.89M 429496729 apache2 9154 9154 www-data 235.44M 22.91M 429496729 apache2 9241 9241 www-data 307.44M 25.66M 429496729 apache2 9242 9242 www-data 307.44M 25.67M 429496729 apache2 9300 9490 22.89M 429496729 apache2 9372 9372 www-data 235.44M 22.89M 429496729 apache2 9413 9413 www-data 233.44M 20.77M 429496729 apache2

유용한 팁

위의 예 (sysdig -w monitoring-wordpress.scap)에서와 같이 Sysdig를 실행하여 이벤트를 캡처하면 사용 가능한 모든 공간을 사용할 때까지 이벤트 파일이 계속 커집니다. 이를 방지하는 데 도움이되는 몇 가지 방법이 있습니다.

  • Sysdig가 -n 플래그를 전달하여 캡처해야하는 이벤트 수를 지정하십시오. Sysdig가 지정된 수의 이벤트를 캡처하면 자동으로 종료됩니다.
sysdig -n 5000 -w 모니터링 -wordpress.scap
  • 캡처를 지정된 크기의 작은 파일로 나누도록 Sysdig를 구성하려면 -C 플래그를 사용하십시오. 다음 예제는 이벤트를 10MB 미만의 파일에 지속적으로 저장합니다.
sysdig -C 10 -w 모니터링 -wordpress.scap

10MB 이하의 파일이 생성됩니다.

ls -lh 모니터링-워드 프레스 *
-rw-r--r--. 1 루트 루트 9.6M 1 월 7 일 17:13 monitoring-wordpress.scap0 -rw-r--r--. 1 루트 루트 9.6M 1 월 7 일 17:14 monitoring-wordpress.scap1 -rw-r--r--. 1 루트 루트 9.6M 1 월 7 일 17:14 monitoring-wordpress.scap2 -rw-r--r--. 1 루트 루트 9.6M 1 월 7 일 17:14 monitoring-wordpress.scap3 -rw-r--r--. 1 루트 루트 9.6M 1 월 7 일 17:14 monitoring-wordpress.scap4 -rw-r--r--. 1 루트 루트 9.6M 1 월 7 일 17:14 monitoring-wordpress.scap5 -rw-r--r--. 1 루트 루트 9.6M 1 월 7 일 17:14 monitoring-wordpress.scap6 -rw-r--r--. 1 루트 루트 9.6M 1 월 7 일 17:14 monitoring-wordpress.scap7 -rw-r--r--. 1 루트 루트 6.4M 1 월 7 일 17:14 monitoring-wordpress.scap8
  • Sysdig가 -W 플래그와 함께 보관해야하는 최대 파일 수를 지정하십시오. 예를 들어, -C 및 -W 플래그를 다음과 같이 결합 할 수 있습니다.
sysdig -C 10 -W 4 -w 모니터링 -wordpress.scap

위의 명령은 마지막 네 개의 캡처 파일 만 유지합니다.

ls -lh 모니터링-워드 프레스 *
-rw-r--r--. 1 루트 루트 7.2M 1 월 7 일 17:21 monitoring-wordpress.scap0 -rw-r--r--. 1 루트 루트 9.6M 1 월 7 일 17:21 monitoring-wordpress.scap1 -rw-r--r--. 1 루트 루트 9.6M 1 월 7 일 17:21 monitoring-wordpress.scap2 -rw-r--r--. 1 루트 루트 9.6M 1 월 7 일 17:21 monitoring-wordpress.scap3 root @ cd06093b141b : / # sysdig -C 10 -W 4 -w monitoring-wordpress.scap

실시간 모니터링

Sysdig를 사용하면 실시간으로 데이터를 분석 할 수도 있습니다. 언뜻보기에 이것은 기본적으로 모든 이벤트가 콘솔에 지속적으로 출력되기 때문에 어려운 작업처럼 보일 수 있습니다. 다행히도 끌이 여기에 있습니다.

예를 들어 봅시다.

컨테이너 단위로 프로세스 분석

  1. 컨테이너를 나열하려면 다음 명령을 실행하십시오.
도커 PS
컨테이너 ID 이미지 명령 생성 상태 포트 이름 5b253e74e8e7 sysdig / sysdig "/docker-entrypoint.…"9 분 전 Up 9 분 sysdig 06def7875617 wordpress : latest "docker-entrypoint.s…"3 시간 전 최대 3 시간 0.0.0.0:8000 -> 80 / tcp wordpress-sysdig_wordpress_1 6bd8418eb03f mysql : 5.7 "docker-entrypoint.s…"3 시간 전 Up 3 시간 3306 / tcp, 33060 / tcp wordpress-sysdig_db_1

2. 다음을 사용하여 WordPress 컨테이너에서 실행중인 프로세스를 분석 할 수 있습니다.

sysdig -pc -c topprocs_cpu container.name = wordpress-sysdig_wordpress_1

3. 마찬가지로 MySQL 컨테이너에서 실행중인 프로세스를 분석 할 수 있습니다.

sysdig -pc -c topprocs_cpu container.name = wordpress-sysdig_db_1

이 예제와 크게 다르지 않은 Sysdig는 네트워크 트래픽, 디스크 사용량 등을 모니터링 할 수 있습니다.

이 자습서에서는 Sysdig를 사용하여 컨테이너에서 생성 된 활동을 명확하게 이해하는 기본 사항을 살펴 보았습니다. 이 블로그 게시물의 예제는 시작하는 데 도움이되었으며 이후 자습서에서는 Csysdig 및 Sysdig Inspect 사용 방법을 보여줍니다.