척와(Chukwa)는 분산되어 있는 서버에서 로그 데이터를 수집하고, 수집된 데이터를 저장하며 분석하기 위해 만들어졌다.
또한 하둡 클러스터의 로그나 서버의 상태 정보 등을 관리할 수 잇는 기능도 포함되어 있다.
척와 시스템은 아래와 같이 구성된다.
| !chukwa architecture.png! |
척와 에이전트가 데이터를 직접 수집하지는 않고, 어댑터(adaptor)에서 수집한다.
어댑터는 에이전트 프로세스 안에서 실행되며, 데이터를 실제로 수집하는 역할을 한다.
에이전트에 어댑터를 등록하는 방법에는 두 가지가 있다.
컬렉터 Fail Over(Chaining)
에이전트는 시작할 때 환경 설정 파일{color:red}(conf/collectors){color}을 읽어들인 후, 이 중에서 하나의 컬렉터를 랜덤하게 선택해서 데이터를 전송한다.
선택한 컬렉터 서버에 장애가 생기면, 설정 파일에 등록된 다른 컬렉터 서버에 데이터를 전송한다.
에이전트 쪽 로그 유실 방지
모든 컬렉터 서버에 장애가 있다면, 마지막으로 전송된 파일의 오프셋 정보(checkpoint)를 로컬 파일 시스템에 기록해 둔다.
이후에 컬렉터에 정상적으로 데이터를 전송할 수 있을 때가 되면, 해당 오프셋 이후의 데이터를 전송한다.
이러한 방식을 통해 로그 유실을 방지한다.
에이전트로부터 전송된 데이터를 주기적으로 하둡 파일 시스템에 저장한다.
이때 한 컬렉터는 여러 대의 에이전트 서버로부터 데이터를 전송받지만, 이를 하나의 파일에 저장한다.
이처럼 컬렉트가 저장하는 파일을 싱크(sink) 파일이라고 부르며, 하둡 파일 시스템의 SequenceFile 포맷으로 저장한다.
컬렉터 쪽 로그 유실 방지
하둡 파일 시스템은 파일을 저장할 때 특정 크기(64MB) 이상이 되지 않으면 close() 명령을 이용해서 파일을 닫지 않는 한 파일 내용이 보이지 않는다.
따라서 파일을 저장하는 클라이언트(이 경우 컬렉터)가 비정상 종료된 경우, 해당 데이터가 유실될 수 있다.
척와에서는 데이터가 유실되는 일을 방지하기 위해 주기적으로 새로운 파일을 생성하며,
이후에 에이전트에서 전송받은 데이터는 새로운 파일에 저장한 후 close()한다.
Fan Out
컬렉터는 로그 파일을 하둡 파일 시스템에 정의한다. 하지만 사용자가 정의한 Writer를 지정할 수도 있다.
예를 들어 척와에서 제공하는 PipelineStageWriter를 사용하면, 하나의 로그에 대해 여러 개의 Writer를 사용할 수 있다.
이를 통해 특정 로그를 수집해서 저장하는 동시에, 실시간으로 분석할 수도 있다.
실제로 척와에서는 디폴트로 PipelineSgateWriter를 사용한다.
// chukwa-collector-conf.xml 중에서
....
<property>
<name>chukwaCollector.writerClass</name>
<value>org.apache.hadoop.chukwa.datacollection.writer.PipelineStageWriter</value>
</property>
<property>
<name>chukwaCollector.pipeline</name
<value>org.apache.hadoop.chukwa.datacollection.writer.SocketTeeWriter,
org.apache.hadoop.chukwa.datacollection.writer.SeqFileWriter</value>
</property>
...
척와에서 로그 데이터를 처리하는 작업에는 아카이빙(archiving)과 디먹스(demux), 2가지 작업이 있다.
뿐만 아니라 맵리듀스를 직접 만들어서, 아키이빙과 디먹스 작업이 완료된 데이터에 대해 맞춤형 분석 작업을 할 수도 있다.
척와 내부적으로도 PostProcessing이라는 작업을 수행한다.
PostProcessing은 디먹스가 완료된 데이터 중에서 하둡 클러스터의 시스템 메트릭 정보 등을 HICC에서 사용하는 데이터로 변환한 후, MySQL에 저장한다. PosteProcessing 코드를 참조하면, 로그 파일을 요구에 맞게 분석하는 시스템을 구축할 수 있을 것으로 보인다.
척와 어댑터는 데이터를 청크(chunk) 단위로 전송한다.
청크란 일련의 바이트로 구성되며, 메타데이터가 일부 포함된다.
이러한 메타데이터는 다음과 같으며, 이 중에서 Cluster와 Datatype은 사용자가 직접 설정해야 한다.
| 필드 | 의미 | 설정 |
|---|---|---|
| Source | 청크가 생성되는 호스트명 | 자동으로 설정된다 |
| Cluster | 호스트가 연결된 클러스터 | conf/chukwa-env.sh에 사용자가 설정한다. |
| Datatype | 출력 포맷 | 어댑터를 구동할 때 사용자가 지정한다. |
| Sequence ID | 스트림에서 청크의 오프셋 | 자동으로 설정된다.초기 오프셋은 어댑터가 실행될 때 설정된다. |
| Name | 데이터 소스 이름 | 자동으로 설정되며, 어댑터가 선택한다. |
장애가 발생했을 때 로그를 재전송하는 경우 로그 데이터의 중복을 방지하기 위해서 이러한 메타데이터가 추가된다.
또는 데이터를 분석할 ? 로그의 데이터 타입 정보를 활용할 수도 있다.
일반적으로 척와의 파일 시스템은 아래와 같이 구성된다.
/chukwa/
— archivesProcessing/
— dataSinkArchives/
— demuxProcessing/
— finalArchives/
— logs/
— postProcess/
— repos/
— rolling/
— temp/
척와 에이전트에서 전송한 데이터는 아래의 단계를 따르 처리된다.
이제 척와에 대한 개략적인 설명은 이 정도로 해 두고, 실제로 척와를 설치해 보자. 척와 설치와 관련해서는 척와 설치하기 (Installing Chukwa)에서 살펴보겠다.
척와를 설치하려면 아래와 같은 항목이 먼저 준비되어야 한다.
척와는 아래와 같은 요소로 구성된다. 따라서 척와를 설치하려면 척와 클러스터, 척와 에이전트, 척와 컬렉터를 설치해야 한다.
| !chukwa architecture.png! |
여기에서는 아래와 같은 구성으로 척와를 구성하고자 한다.
| !chukwa test platform.png! |
두 대의 우분투 머신에서 하나는 척와 에이전트로, 나머지 하나는 척와 컬렉터를 설치하고자 한다.
척와 컬렉터를 설치한 머신에는 하둡을 의사 분산 모드로 설치해서, 로그 데이터를 저장하는 역할까지 하도록 한다.
아래의 사항은 에이전트와 컬렉트를 설치할 머신에서 공통적으로 설정해야 하는 작업이다.
척와 공통 정보를 conf/chukwa-env.sh에 설정한다. (에이전트와 컬렉터가 설치된 머신 모두에 설정해야 한다).
척와 에이전트를 설치 과정은 "1. 척와 에이전트 옵션 설정하기", "2. 에이전트 등록하기", "3. 컬렉터 등록하기", "4. 어댑터 등록하기" 총 4개의 작업으로 구성된다.
척와 에이전트는 conf/chuwa-agent-conf.xml에서 설정한다.
디폴트 그대로 사용해도 실행하는데 문제가 없으며, 필요에 따라 아래의 옵션을 설정한다.
에이전트로 실행할 전체 에이전트 목록을 conf/agents에 설정한다.
여기에서는 에이전트가 로컬서버 한대이므로 localhost만 등록한다.
conf/agents
localhost
데이터를 전송할 컬렉터를 conf/collectors에 등록한다.
척와는 이 파일에서 컬렉터를 임의로 골라서 해당 컬렉터로 데이터를 전송한다.
해당 컬렉터에 장애가 발생하면, 컬렉터 목록에서 다른 컬렉터를 선택하는 방식으로 로그 유실을 방지한다.
여기에서는 221번 서버가 컬렉터이므로, 이 컬렉터에 대한 정보를 등록한다.
실제로 실행할 전체 컬렉터 목록은 컬렉터가 설치된 머신의 conf/collectors에서 설정한다.
conf/collectors
데이터를 수집할 어댑터를 conf/initial_adpators에 등록한다.
이처럼 어댑터를 설정파일에 등록할 수도 있지만, 실행 중인 에이전트에 어댑터를 직접 추가할 수도 있다.
여기에서는 conf/initial_adaptors.template 파일을 참조해서 만든다.
템플릿 파일에 등록된 어댑터 중에서 Df, Top에 해당하는 어댑터 2개만 conf/initial_adpators에 등록한다.
conf/initial_adpators
add org.apache.hadoop.chukwa.datacollection.adaptor.ExecAdaptor Df 60 /bin/df -l 0
add org.apache.hadoop.chukwa.datacollection.adaptor.ExecAdaptor Top 60 /usr/bin/top -b -n 1 -c 0
척와 에이전트는 아래의 명령어를 실행해서 데몬으로 실행할 수 있다.
bin/start-agents.sh
명령어를 실행하면 conf/agents에 나열단 각 머신에 ssh로 접속해서 에이전트를 실행한다.
이 경우 에이전트가 로컬호스트 하나 뿐이므로, 로컬호스트의 에이전트가 실행된다.
반대로 척와 에이전트는 아래의 명령어를 실행해서 중지한다.
bin/stop-agents.sh
에이전트가 제도로 동작중인지는 에이전트 포트(디폴트로 9093을 사용한다)에 텔넬 접해서 확인할 수 있다.
에이전트가 정상적으로 동작중이라면, 에이전트와 관련된 상태 메시지가 나온다.
컬렉터에서 수집한 데이터를 저장해야 하므로, 하둡과 관련된 설정을 추가해야 한다.
conf/chukwa-env.sh
에 HADOOP_HOME과 HADOOP_CONF_DIR을 아래와 같이 설정한다.
conf/chukwa-env.sh
export HADOOP_HOME="하둡이 설치된 위치"
export HADOOP_CONF_DIR="${HADOOP_HOME}/conf"
척와 컬렉터는 conf/chukwa-collector-conf.xml에서 옵션을 설정할 수 있다.
반드시 설정해야 하는 부분은 writer.hdfs.filesystem다. 여기에서는 의사 분산 모드로 설치한 하둡 파일 시스템을 설정한다.
conf/chukwa-collector-conf.xml}
<property>
<name>writer.hdfs.filesystem</name>
<value>hdfs://localhost:9000</value>
<description>HDFS to dump to</description>
</property>
이 외에도 컬렉터에서는 아래와 같은 속성을 설정할 수 있다.
실행할 컬렉터는 모두 conf/collectors에 등록한다. 여기에서는 221번 서버가 컬렉터이므로, 이 컬렉터에 대한 정보를 등록한다.
conf/collectors
척와 컬렉터는 아래의 명령어를 실행해서 데몬으로 실행할 수 있다.
bin/start-collectors.sh
그러면 conf/collectors에 나열단 각 머신에 ssh로 접속해서 컬렉터를 모두 실행한다.
반대로 척와 컬렉터는 아래의 명령어를 실행해서 중지한다.
bin/stop-collectors.sh
컬렉터가 제대로 동작중인지 확인하려면 브라우저에서
http://collectorhost:collectorport/chukwa?ping=true
와 같이 접속해본다.
여기에서는
http://localhost:8080/chukwa?ping=true
로 접속해 보면 아래와 같이
Date:1322449269195
Now:1322449296866
numberHTTPConnection in time window:0
numberchunks in time window:0
lifetimechunks:0
컬렉터와 관련된 상태 정보를 확인할 수 있다.
데이터 처리 프로세스를 실행한다.
start-data-processors.sh
그러면 아카이빙, 디먹스, HICC용 데이터 프로세싱 작업이 실행되고 이를 통해 주기적으로 데이터를 처리하게 된다.
실제로 start-data-processors.sh를 열어서 보면 아래와 같이, archive, demux, dp를 차례대로 실행함을 알 수 있다.
start-data-processors.sh
이렇게 설치가 끝났다면, 실제로 척와 관련 데몬을 실행해서 제대로 실행되는지 확인해 보자.
이렇게 설정을 다했다면 아래와 같은 구성으로 관련 데몬을 실행한다.
| !chukwa test daemon.png! |
척와 에이전트가 설치된 머신에서 /tmp/chukwa/logs로 이동한다.
해당 디렉토리에는 agent.log가 있으며 열어보면
start-data-processors.sh
HTTP post thread ChukwaHttpSender - collected 14 chunks for post_53
HTTP post thread ChukwaHttpSender - >>>>>> HTTP post_53 to http://33.33.211.211:8080/ length=18715
HTTP post thread ChukwaHttpSender - >>>>>> HTTP Got success back from http://33.33.211.211:8080/chukwa; response length 826
HTTP post thread ChukwaHttpSender - post_53 send 0 chunks, got back 14 acks
와 같이 전송 정보를 확인할 수 있다.
척와 컬렉터가 설치된 머신에서 /tmp/chukwa/logs로 이동한다.
해당 디렉토리에는 collector.log가 있고, 컬렉터와 관련된 로그를 확인할 수 있다.
척와 컬렉터의 데이터 프로세스를 실행했다면, http://localhost:50070/로 접속해서 아래와 같이 척와 스토리지를 확인할 수 있다.
| !chukwa test hdfs.png! |
척와 에이전트의 경우, 로그를 수집할 대상 서버에 설치된다.
따라서 에이전트로 인해 해당 서버의 본래의 기능에 영향을 미쳐서는 안된다.
이를 위해 실제 척와 에이전트가 설치되었을 때 로그 수집 대상 서버에 미치는 영향도를 분석하고자 한다.
테스트 목적으로 로그를 생성하는 데몬 서버를 다운 받는다.
(첨부파일에 ^demo_loggers.jar를 참조)
해당 서버를 실행하면, /tmp/ws_demo_log 디렉토리에 demo라는 이름의 로그를 생성한다.
데몬 서버가 생성한 로그를 테일링할 어댑터를 (conf/initial_adaptors) 파일에 등록한다.
initial_adaptors
add filetailer.FileTailingAdaptor DaemonData /tmp/ws_demo_log/demo 0
성능 측정 스크립트인 usage_ps.sh 스크립트를 아래와 같이 작성한다
usage_ps.sh
pid=`cat /tmp/chukwa/pidDir/Agent.pid`
out_file="output_$1.txt"
rm -rf $out_file
echo "%CPU $MEM VSZ RSS" >> $out_file
while (true)
do
sleep 3
ps aux | grep $pid | grep -v grep | awk '{print $3, $4, $5, %6 }' >> $out_file
done
영향도 분석을 위한 시나리오는 다음과 같다.
아래와 절차에 따라 작업을 수행했다.
시나리오 1번 과정, 3번 과정을 먼저 처리 한후, STUDY:number of Visitor에 3을 설정한 후 그 결과를 수집했다.
이에 따른 데몬 서버의 처리 결과는 다음과 같다.
===========================================
SUMMARY
===========================================
= Started At: 2011-11-29 20:14:30
= Ended At: 2011-11-29 20:15:20
= Size(bytes): " + fileSize); 84162
= Log Size/Time(Bytes/Sec): 1
===========================================
로그 데몬 서버를 중지한 후, STUDY:number of Visitor에 100을 설정해서 서버를 재실행해서 그 결과를 수집했다.
이에 따른 데몬 서버의 처리 결과는 다음과 같다.
===========================================
SUMMARY
===========================================
= Started At: 2011-11-29 20:15:24
= Ended At: 2011-11-29 20:16:13
= Size(bytes): " + fileSize); 2754700
= Log Size/Time(Bytes/Sec): 55
===========================================
로그 데몬 서버를 중지한 후, STUDY:number of Visitor에 1000을 설정해서 서버를 재실행해서 그 결과를 수집했다.
이에 따른 데몬 서버의 처리 결과는 다음과 같다.
===========================================
SUMMARY
===========================================
= Started At: 2011-11-29 20:16:29
= Ended At: 2011-11-29 20:17:10
= Size(bytes): " + fileSize); 21950227
= Log Size/Time(Bytes/Sec): 538
===========================================
서버 처리 결과에서 보는 바와 같이 로그 생성 속도는 선형적으로(1 -> 55 -> 538)로 증가함을 알 수 있다.
영향도를 측정한 결과 파일은 다음과 같다 (중간 부분은 일부 생략했다).
%CPU %MEM VSZ RSS
1.4 1.5 419024 27224
1.3 1.5 419024 27224
1.3 1.5 419024 27224
1.1 1.5 419024 27224
1.1 1.5 418928 27292
0.9 1.5 418928 27324
확인 결과 오히려 CPU와 메모리 사용률이 증가하지 않고, 적어지는 결과가 나왔다.
눈으로 보이는 결과만 봐서는 두 가지 결론을 내릴 수 있다.
분석작업을 수행하면서 이와 동시에 척와 에이전트 로그를 테일링해서 실제로 에이전트가 어떻게 로그를 처리하고 있는지 함께 확인했다.
물론 과학적인 분석은 아니며, 육안으로 확인할 결과다.
---