노스웨일즈 김씨 시조의 블로그

팀을 옮기면서 익히기 시작했던 Chronos. 핵심은 Mesos에서 실행되는 App에 불과하지만 분명 좋은 Tool인 것은 부인할 수 없다. 근데 문제는 Mesos, Chronos 모두 패키징을 제공하지 않아서 사용자가 스스로 BUILD해서 사용해야 한다는 점이다. 그런 부분이 좋은 BIZ Model이 되었는지 MESOSPHERE라는 회사에서 MESOS, CHRONOS를 묶어 PACKAGING을 제공하고 있다.

회사는 CENTOS6 이어서 그에 맞추어 RPM을 설치 했고, GOOGLING을 통해서 /sbin/start , /sbin/stop, /sbin/restart command로 각 Daemon을 start/stop할 수 있게 되었다.

근데 최근에 start option을 일부 수정할 이슈가 생겼는데, 어디를 수정해야 하는지 모르겠다는 점이다.

/sbin/start{stop,restart}를 체크해 보니 결국 /sbin/initctl의 link들이고 아래 article을 보니 /etc/init에 각 daemon 관련 config를 읽어 온다는 정보를 알게 되었다.

http://serverfault.com/questions/489525/linux-how-to-pass-parameters-to-service-foo-start-at-command-line

결국 CHRONOS 실행 Script를 찾았는데... 이 Script에 재밌는 부분이 보인다.

function load_options_and_log {

  set -x

  # Load Chronos options from Mesos and Chronos conf files that are present.

  # Launch main program with Syslog enabled.

  local cmd=( run_jar )

  if [[ -s /etc/mesos/zk ]]

  then

    cmd+=( --zk_hosts "$(cut -d / -f 3 /etc/mesos/zk)"

           --master "$(cat /etc/mesos/zk)" )

  fi

  if [[ -d $conf_dir ]]

  then

    while read -u 9 -r -d '' path

    do

      local name="${path#./}"

      if ! element_in "--${name#'?'}" "$@"

      then

        case "$name" in

          '?'*) cmd+=( "--${name#'?'}" ) ;;

          *)    cmd+=( "--$name" "$(< "$conf_dir/$name")" ) ;;

        esac

      fi

    done 9< <(cd "$conf_dir" && find . -type f -not -name '.*' -print0)

  fi

  logged chronos "${cmd[@]}" "$@"

}

/etc/mesos/zk파일을 읽어 와서 HOST설정하는 건 알고 있었는데, CONF_DIR에 파일들에 대해서 --<파일NAME>=<파일CONTENT>형태의 OPTION을 설정해 주는 부분이 정말 흥미로웠다.

일단 CONF_DIR에 내가 필요한 옵션 이름으로 파일을 만들어서 CHRONOS를 RESTART해 보니 과연 해당 파일 내용을 읽어와서 대몬을 START시켜준다.

항상 느끼는 거지만 SHELL을 잘 사용하면 사용할 수록 개발자들의 편의성이 없어 지는 듯 싶다.

몇 년동안 일하면서 항상 하고 싶었지만 해보지 못했던 일중에 하나가 RPM 파일을 만드는 거였다.

일단 시간도 없었고.. ( 게으르다고 해야 할 까 .. ) 그리고 개발쪽 관련 공부에 집중하다 보니..

근데 이번에 원준씨가 이직하면서 본의아니게 Cron시스템을 인수인계 받아 진행하다 보니 RPM을 만드는 일이 생겼다.

일단 PUPPET관련해서 작업 끝내고, SYSOPS가 시스템까지 구축해준 상태에서 최종 확인을 하다 보니 새로운 RPM을 설치하는 게 진행이 되지 않는 것이었다. 시스템 문제인가 생각했는데, 잠시 시간 날때 확인해 보니 내 PUPPET에 문제가 있었다.

그래서 PUPPET을 고치고 새로운 RPM을 설치해 보니 RPM은 설치 되었다고 나오는데 설치되어 있어야 할 파일들이 없다. PUPPET을 이리저리 바꿔보고 했는데도 되지 않고... 시간 만 보내고 있는데 불연듯 RPM이 잘못 된건 아닐까 생각이 든다.

그래서 spec파일을 검토해 보고 googling을 해보니 아래 article이..

내용은 RPM에서 spec파일에 선언되어 있는 명령문들은 아래 순서 대로 실행된단다.

 1. %Pre of new package
 2. %Post of new package
 3. %Preun of old package
 4. %Postun of old package
http://stackoverflow.com/questions/7398834/rpm-upgrade-uninstalls-the-rpm

마침 나는 api spec파일을 copy하면서 Postun섹션을 넣었는데... 이게 실행이 되면서 설치 폴더들이 다 지워 지는 것이었다.api는 multi version을 위해서 rpm설치할 때 해당 version을 폴더 경로에 넣어서 uninstall도 하지 않지만 하더라도 해당 버젼 폴더만 지우니 문제가 없는 것이었다. 

나도 지금이라도 버젼을 넣어서 처리 할 까 생각하다가 어차피 자바로 포팅하기 까지만 지금 구조로 갈꺼니깐 없어 진 파일 패키지에 남아 있다고 해서 큰문제는 생기지 않을 듯 싶다.

흐미... SPEC파일에 대해서 조금만 봤어도 하지 않았을 실수 때문에 거의 하루를 날려버리게 되다니..

COPY를 하더라도 정확히 이해하고 해야지.. 그리고 다음에는  RPM만들떄 꼭 버젼을 고려해야 겠다.

결국 %Postun을 없애고 나니 RPM삭제이후에도 파일들은 시스템에 남아 있게 되는거 아닌가...

Shell 코드를 작성하다보면 Java Property를 읽는 경우가 종종 있는데 보통은

. <FILE_PATH>

를 사용하면 FILE에 있는 각 변수 들이 환경 변수로 등록이 되어 사용된다.

보통은 문제가 없는데 만일 변수에 .이 있을 경우는 이를 command로 인식해 버려서 command를 실행하는 형태로 처리 되어 변수를 읽을 수 없게 된다. 역시 편한거에는 한계가 있다는 그래서 검색을 하다 보니 관련 해서 좋은 TIP을 발견

sed '/^\#/d' myprops.properties | grep 'someproperty'  | tail -n 1 | cut -d "=" -f2-

sed로 #로 시작되는 Line을 제외한 후  grep로 원하는 property가 나오는 마지막 라인을 가져온 후 = 이후의 값을 읽어 온다.

추가적으로 trim을 처리 하는 부분을 추가하면 아래 처럼 쓸 수 있다.

JAVA_HOME=`sed '/^\#/d' build.properties | grep 'jdk.home'  | tail -n 1 | cut -d "=" -f2- | sed 's/^[[:space:]]*//;s/[[:space:]]*$//'`

->build.properites에서 jdk.home property를 읽어서 JAVA_HOME변수에 넣는다.

출처 : http://shrubbery.homeip.net/c/display/W/Reading+Java-style+Properties+Files+with+Shell

흠... 드뎌 LOG Processing관련한 내용까지도 Tech Ops가 처리 해 줘서 이제는 12시에 다시 읽어 나서 작업 돌리고 자는 일은 끝..

이제는 LOG ANALYZE 도 인수 인계 해 버리면 정말 OAS API와는 작별을 고하게 될 듯 싶다.

Travis가 API 오류 분석을 요청해서 확인해 본 결과 Temp folder를 작업 이후에 clean up 하지 않아서 32K limit로 인하여 오류가 발생한 case 였다.

다행히 TEST ( ? )  environment여서 다행이었지만, Production에 Temp folder가 몇 개나 있는지는 알수가 없었다.

이걸 shell을 어찌짜야 하나 internet을 뒤졌더니 다행히 아래와 같은 shell command로 가능했다.

shell> for D in *; do echo $D; find $D -type d| wc -l; done

다행히도 Production에 temp folder가 1000개 이상 넘는 case는 없어서 다행이었다.

근데 이상한건.. 어떻게 1000개가 넘는 case가 하나도 없을 수 있지?

U.I에서 clean up 해 준다고 해도, API만 사용하는 case도 많을 텐데..

이번에 Project를 진행하면서 특정 기간동안의 특정 도메인 TRAFFIC 정보를 GATHERING 한 후
TRAFFIC CUT-OVER 이후에 CUT-OVER 이전의 TRAFFIC에서 찾을 수 없는 CASE를 추출하는 SHELL을 작성해야 하는 상황이 발생하였다.

결국 특정 기간의 TRAFFIC 정보를 분석해서 MASTER 파일을 작성한 후 CUT-OVER 이후의 로그 파일과 이를 비교해야 하는 SHELL 이었다.

우선 진행해야 하는 건 로그 파일을 뒤져서 URL이 특정 도메인으로 시작하는 데이터를 가져오는 일이 었다.

일단 로그파일에서 특정 도메인 정보를 가져오는 건 비교적 쉬웠다.

egrep --file=<PATTERN_FILE>-i <LOG 파일들> | cut -d^ -f2,5,6

'^'를 구분자로 가지는 <LOG 파일들>에서 <PATTERN_FILE>에 지정된 문자열을 가지는 데이터를 가져와서 2,5,6 필드들을 가져오는 구문이었다. 이때 egrep의 -i 옵션을 사용하여 case insensitive 하게 처리 하도록 했다.

다른 필드 값들에 있는 케이스를 무시했었는데, 데이터를 보다보니 PATTERN에 있는 도메인 정보가 다른 필드에서도 사용되는 case도 있고, 도메인이 TEST 같은 간단한 경우는 URL 내의 다른 정보에서도 나오는 것이 아닌가.

결국 아래와 같이 egrep을 한 데이터를 다시 egrep 하도록 하였다.

egrep --file=<PATTERN_FILE>-i <LOG 파일들> | cut -d^ -f2,5,6 | egrep --file=<PATTERN_FILE> -i

이렇게 하니 로그 데이터를 모을 수 있었는데, 2번째 필드의 경우는 다시 ','로 세부 필드가 또 구분되게 되어 있다.

결국 tr로 모든 ','를 '^'로 변환하여 2번째 필드 안의 세부 필드들도 다음 프로세스에서 사용할 수 있게 하였다.

결국 아래와 같이 LOG 데이터를 1차 가공 파일로 저장하도록 SHELL을 작성하였다.

egrep --file=<PATTERN_FILE>-i <LOG 파일들> | cut -d^ -f2,5,6 | egrep --file=<PATTERN_FILE> -i | tr -s ',' '^' >> ${LOG_DATE}_site_log.txt

이 site_log파일에 있는 내용을 가지고 실제 TRAFFIC URL을 가져오는 코드를 작성해야 하는데, sort 와 uniq를 사용하니 간단히 해결 됐다.

awk '{FS="^"} {print $2"@"$5}' ${LOG_DATE}_site_log.txt | sort | uniq -c > ${LOG_DATE}_traffic.txt

먼제 awk로 2번째와 5번째 필드 문자열을 @를 연결자로 합치고, ( 즉 <2번째 필드>@<5번째 필드> ) 이 값을 가지고 sort와 uniq를 진행하니 ,

발생횟수 <2번째 필드>@<5번쨰 필드> 형태의 데이터를 가지는 TRAFFIC 정보 파일이 작성 되었다.

흠.. 그런데 생각해보니 EMPTY case 정보도 필요 할 듯 하여 3번째 필드가 0인 case의 EMPTY LOG를 EMTPY TRAFFIC 정보 파일에 저장하는 아래 SHELL도 작성하게 되었다.
awk -F'^' 'BEGIN {OFS="^"} {if ($3 == "0" ) print $2"@"$5}' ${LOG_DATE}_site_log.txt | sort | uniq -c > ${LOG_DATE}_empty_traffic.txt

처음에는 위 파일들을 MASTER 파일로 사용하려 했는데, 좀더 진행해 보니 날짜 별로 조금씩 트랙픽이 틀려져서 위 파일을 마스터 파일을 쓸 수가 없었다. 결국 날짜별 site_log 파일을 가지고 MASTER 파일을 만들어 내어야 하는데 나중에 처리할 떄 대/소문자 이슈를 없애기 위해서 전체 날짜별 TRAFFIC 파일들 CONCATE 시킨 후 모든 데이터를 소문자로 바꾸어 위와 동일한 Process를 통해 master 파일을 작성할 수 있었다.

for f in *_site_log.txt
do
        awk '{FS="^"} {print $2"@"$5}' ${f} | sort | uniq >> ${TMP}
        echo "$f file"
done

cat ${TMP} | tr '[:upper:]' '[:lower:]' | sort | uniq > ${마스터파일}

tr '[:upper:]' '[:lower:]' 이부분이 대문자를 소문자로 변환해 주는 파일이다.

이제 마지막으로 다른 로그 파일을 가져와서 마스터 파일에 있지 않은 TRAFFIC 정보를 추출해야 한다.
즉 마스터 파일과 join을 한 후 join 되지 않는 데이터를 가져와야 하는데 이 걸 라인단위로 읽어서 마스터 파일과 비교하는 SHELL을 짜려니 만만하지가 않다.

구글링을 해 보니 딱 나에게 필요한 기능의 SHELL COMMAND가 있다.

comm -23 <로그파일> <마스터파일> > <최종파일>

comm는 두개의 sort된 파일을 가지고 JOIN을 해서 결과를 추출해 주는데

이때 -1, -2, -3 과 같이 옵션을 주면

-1 은 왼쪽 ( <로그파일>) 결과만 있는 부분을 제거 - Right outer join과 유사 )
-2 는 오른쪽 ( <마스터파일> ) 결과만 있는 부분을 제거 - Left outer join과 유사 )
-3 는 양쪽에 모두 결과가 있는 부분을 제거 하게 되어 있다.
따라서 -23을 하게 되면 마스터파일에 결과만 있는 경우와, 양쪽 모두에 있는 부분을 제거 하게 되니, 마스터 파일에 등록되지 않은 Traffic 정보를 가지는 로그 데이터 만을 출력하게 되는 것이다.

처음에는 이런 걸 어떻게 개발하나 했는데, 기존에 다른 사람이 개발한 거랑, 구글링의 힘들 빌렸더니 결국 거의 원하는 결과를 추출해주는 SHELL을 작성할 수 있었다.

이렇게 개발해 놓고 나니, 지금 내가 개발해 놓은 로그 분석툴의 CONCURRENT CHECK 부분을 DB 에서 할필요가 없지 않았나 하는 생각이 든다.

이젠 너무 DB만 쓰지 말고 이렇게 SHELL 로 할 수 있는 부분은 SHELL로 많이 처리 해야 할 듯 싶다.

Log 파일들을 분석할 일이 있어서 여러 서버에서 Log 파일을 가져오는 Shell을 작성하고 있었다.

다른 Shell Script를 참조로 아래와 같이 작성하였고
while read host
do
  ....
done < host.txt

while loop이 잘 도는 지 체크해 보려고 echo로 확인해 보면 잘 실행되었다.

그래서 원하는 script를 추가 하였을 경우에는 loop이 실행되지 못하고 한 번 실행 한 후 바로 멈추는 것이었다.

너무 이상한데 마침 SSH 인증 관련 문제가 있어서 그 문제떄문이려니 해보니 그것도 아니다..

그래서 인터넷을 찾아 보니 아래 페이지가 TIP을 주었다.

http://stackoverflow.com/questions/5626374/while-read-line-do-and-grep-problems

마침 내가 작업하려는게 host 파일들에 접속해서 파일을 받아 오는 것이었는데..
파일 받아 올때 파일 에 있는 CRLF 가 while loop을 exist 하는 것이었다.

결국 shell 내에서 array를 선언한 후 아래와 같이 수정하여 실행을 하니 정상적으로 수행되었다.

HOST_LIST=( HOST1 HOST2 .. )

for host in "${HOST_LIST[@]}"

...

done

Shell이 빨라서 좋은 데 이렇게 전혀 생각도 못했던 부분에서 문제가 생기면 시간을 너무 잡아 먹어서 .. 좀..
뭐 어쨋든.. rsync 할 떄 CPU가 올라 가는 부분을 제외하면 거의 대 부분의 이슈는 해결 된 듯..

rsync 이슈도 googling 해보니 -c 옵션을 사용할 경우 파일 Checksum을 실행 하여 파일 COPY를 한 다고 하니,
이 부분을 제거하면 문제가 없을 듯 하다.
어차피 내가 지금 짜고 있는 건 파일 전체를 다운 받아야 하는 Code 이니깐.

작년말에 API LOG 분석툴을 개발하여 사용중이 었다.
PRODUCT에서 API를 매일 가져온 후 DB에 넣어서 사용량 추이를 볼 수 있게 한 것 인데,
매일 새벽에 경유서버에서 전체 PRODUCT의 LOG 파일을 가져온 후 분석 서버에서 경유서버의 파일을 가져와서 DB에 넣는 구조로 되어 있다.

헌데 경유서버에 보안 관련 설정을 해 놓아서 인지 대칭 보안키를 설정했는데도 SCP나 RSYNC를 사용할 때 암호를 계속 물어 보는 것이었다.
흠 이 문제를 어떻게 풀어 볼까 하고 찾아보았더니 sshpass 라는 utility가 있다.
password를 입력하기 어려운 shell script에서 password를 입력해 주는 훌륭한(?) Tool인 것이다.
일단은 shell을 실행해서 테스트 해 보니 잘 돌아서, cron에도 등록을 했는데..
cron에서는 계속 문제가 생기는 것이다.
환경 변수 이슈인듯 해서 shell도 바꾸어 보고, 혹시나 파일 다운로드 되기 전에 다음 step이 실행되나 싶어서 sleep도 주고 했는데, 현상은 바뀌지 않는 것이다.

결국 수동으로 계속 실행하고 있었는데..
율이 때문에 출산 휴가 간 사이에 정팀장님이 그 부분을 확인하시고 환경 변수 이슈인것 같다고 하신다. 그러면서 -x를 option으로 주면 debugging 정보를 확인할 수 있을 꺼라는 Hint까지..

일단 script내에 -x를 주고 테스트를 진행해 보니 일단 debug 정보가 나오기에,
cron 실행되는 걸 기다려서 cron log를 봤는데... log에는 정보가 없다.
근데.. shell에서 계속 mail이 왔다는 메시지가 떠서 mail 함을 열어 봤더니.. 거기에 debug 메시지가 포함된 실행 정보가 보이는 것이다.

결국 그 정보를 통해서 원인을 알아내어 이제는 자동으로 메일 작업이 잘 돌게 되었다.
근데.. 원인은... ?
sshpass가 /usr/local/bin 에 설치되어 있는데 해당 경로가 PASS에 안 잡혀서 발생한 것이었다.
sshpass 같은 utility면 당연히 shell에서 사용될 텐데.. 어찌 그게 cron 에서 자동으로 잡히는 경로에 설치가 안 됐는지...

좀더 자세한 정보는 아래 페이지에서 찾을 수 있다.
http://www.cyberciti.biz/tips/debugging-shell-script.html

API로는 처리가 안되는 Client issue로
별도 Job을 작성해서 FTP로 정보를 제공해 주는 서비스가 있는데..
얼마전에 해당 Client의 FTP 서버 이슈로 파일이 전송되지 않는 문제가 발생했다.

그쪽에서 문제 해결 한 다음에 FTP 서버에 수동으로 파일을 넘겨 주어 해당 이슈는 해결이 되었는데..

그 쪽 VP가 FTP Uploading 중 문제가 발생할 경우에 1시간 주기로 여러번 Try 할 수 있도록 Script를 수정해 달라는 요청을 해왔다.

마침 몇 일간 다른 이슈가 있어서 조만간 봐주겠다고 메일만 보내놓고 있었는데..
어제 VP가 수정 요청 어떻게 됐냐고 물어 온다.
흑.... 어물쩡 넘어 갈 까 했었는데...

오늘 마침 시간이 나서.. 자료를 찾아 보다가
Matt한테 이슈를 얘기 해 보니 간단한 solution을 준다.

Shell에서 command를 실행 한 후 exit code를 체크해 보면 될꺼라고 한다.
internet에서 예제까지 찾아서..

http://linuxers.org/howto/how-find-exit-code-last-executed-command-bash-using-environment-variable
$? 값을 체크하면 이전에 실행된 command의 return 값을 확인할 수 있다고 ..

흠.... 이런 좋은 TIP을 하고 생각하며 script를 작성하려니...
다른 article에 ftp는 에러가 발생해도 정상(0) 를 return한다는 내용을 찾아서 바로 알려 준다.

http://stackoverflow.com/questions/4899316/getting-exit-status-code-from-ftp-command-in-linux-shell

결국 아래와 같이 FTP 메시지를 Capture 하여 SUCCESS MESSAGE가 있는 지 수동으로 체크해야 한단다.

FTPLOG=/temp/ftplogfile
ftp -inv <<! > $FTPLOG
open server
user ftp pwd
put filename
close
quit
!

FTP_SUCCESS_MSG="226 Transfer complete"
if fgrep "$FTP_SUCCESS_MSG" $FTPLOG ;then
   echo "ftp OK"
else
   echo "ftp Error: "$OUT
fi
exit 0

결국은 위 내용을 응용하여 에러 발생하면 SLEEP 했다가 다시 FTP 파일 올리는 방법으로 해당 SHELL 수정을 완료 했다.

혼자 끙끙 거리면서 해결할라고 했으면 한 참 뒤져도 해결 못했을 텐데
Matt의 TIP 덕분에 1~2시간 만에 해결하였다.

모르는 문제는 너무 혼자서 해결하려 하기 보다는 함께 공유하면 쉽게 해결 될 수 있다는>>..
그리고 Matt이 정말 좋은 동료라는 걸 새삼스럽게 각인하는 하루 였다.

Thanks , Matt.