Contact

• 이미지 생성
  • qemu-img create -f qcow2 win2.qcow2 2G
• 이미지 할당
  • dd if=/dev/zero of=/var/lib/libvirt/images/win2.qcow2 bs=1M count=2048
• 이미지 붙이기
  • virsh attach-disk windows10 /var/lib/libvirt/images/win2.qcow2 vdb –cache none

function gen_uuid() {
    return sprintf( '%04x%04x-%04x-%04x-%04x-%04x%04x%04x',
        // 32 bits for "time_low"
        mt_rand( 0, 0xffff ), mt_rand( 0, 0xffff ),

        // 16 bits for "time_mid"
        mt_rand( 0, 0xffff ),

        // 16 bits for "time_hi_and_version",
        // four most significant bits holds version number 4
        mt_rand( 0, 0x0fff ) | 0x4000,

        // 16 bits, 8 bits for "clk_seq_hi_res",
        // 8 bits for "clk_seq_low",
        // two most significant bits holds zero and one for variant DCE1.1
        mt_rand( 0, 0x3fff ) | 0x8000,

        // 48 bits for "node"
        mt_rand( 0, 0xffff ), mt_rand( 0, 0xffff ), mt_rand( 0, 0xffff )
    );
}

이 설정 파일을 수정하여 사용자 정의하기 전에 몇가지 문법을 확인해 보자.

설정 파일에서 쓰이는 지시자(Directives) 목록은 다음과 같다.

– source : 입력 형태 결정.

– match : 출력 목적지 결정

– filter : 이벤트 처리 파이프라인 결정

– system : 시스템 광역 설정

– label : 내부 라우팅을 위한 출력 및 필터를 그룹화

– @include : 다른 설정 파일 삽입

1. source

input 플러그인을 매개변수로 하는 지시자로 어떤 방식으로 이벤트를 입력받을 것인지 설정한다.

Fluentd 의 표준 input 플러그인에는 http 와 forward 가 있다.

http 플러그인은 fluentd 를 HTTP 엔드포인트로 바꿔 HTTP 메시지를 전달 받는다.

forward 플러그인은 fluentd 를 TCP 엔드포인트로 바꿔 TCP 패킷을 전달 받는다.

원하는 만큼 source 지시자를 추가하여 동시에 여러개의 이벤트를 받아들일 수 있다.

각 source 지시자에 사용할 input 플러그인을 tyep 파라미터(@type) 에 설정한다.

사이트에서 더 많은 input plugin 리스트를 확인할 수 있다. (http://docs.fluentd.org/v0.12/articles/input-plugin-overview)

source 는 Fluentd 의 라우팅 엔진에 이벤트를 전송한다. 이벤트는 tag, time, record 의 세 엔티티로 구성된다.

– tag 는 마침표 ‘.’ (예: myapp.access) 로 구분된 문자열이며 Fluentd 내부 라우팅 엔진의 지침으로 사용된다.

– time 필드는 input 플러그인으로 부터 지정되며 Unix 시간 형식이어야 한다.

– record 는 JSON 객체이다.

tag 는 모든 문자를 허용하지만, output 플러그인에서 다른 컨텍스트로 전달되어 사용(예: table / database / key name 등) 되기 때문에 되도록 소문자, 숫자, 밑줄 정도만 사용하는 것이 좋다. (정규식: ^[a-z0-9_]+$)

위의 예에서 HTTP input 플러그인으로 이벤트를 전송하는 예제이다.

2. match

match 지시자은 source 지시자로부터 전달받은 이벤트 중 일치하는 tag 가 있는 이벤트만을 찾아 처리한다.

주로 다른 시스템에 이벤트를 출력하는 등의 동작을 하여 output 플러그인이라고 한다.

Fluentd 의 표준 output 플러그인은 file 과 forward 가 있다.

file 은 다른 파일에 출력을 기록할 때, forward 는 다른 서버로 출력을 보낼 때 사용한다.

각 match 지시자은 tag 와 매칭할 패턴 및 사용할 output 플러그인을 지정하는 type 파라미터(@type) 를 포함해야 한다.

패턴과 일치하는 tag 의 이벤트만 output 목적지로 전송된다. (위의 예에서는 “myapp.access” 태그가 있는 이벤트만 일치).

match 패턴

– * 는 tag 의 마침표(.)로 구분된 한 파트와 매칭 : a.* 는 a.b 와 일치, a 나 a.b.c 와 불일치)

– ** 는 tag 의 마침표(.)로 구분된 모든 파트와 매칭 : a.** 는 a, a.b, a.b.c 와 일치

– {X,Y,Z} 는 X tag, Y tag, Z tag 등이 매칭. 여러 tag 리스트를 콤마로 구분해 지정할 수 있으며 *,** 도 사용 가능하다. : a.{b,c.**} 는 a.b 나 a.c.** 와 일치

– 하나의 match 지시자안에 여러개의 패턴을 공백으로 구분할 수도 있다.

match 순서

match 지시자도 여러 개를 사용할 수 있으며 상단에 쓰여진 순서대로 일치 여부를 판단한다.

아래처럼 match 지시자가 있을 때 두번째 match 지시자(myapp.access 패턴) 는 불려질 수 없다.

마찬가지로 사이트에서 더 많은 output plugin 리스트를 확인할 수 있다. (http://docs.fluentd.org/v0.12/articles/output-plugin-overview)

3. filter

filter 지시자는 match 와 동일하지만, 또 다른 filter 로 전달이 가능하다. (chained pipeline)

Input -> Output 플로우가 filter 를 거치면 Input -> filter 1 -> … -> filter N -> Output 가 된다.

아래는 표준 filter 인 record_transformer 를 사용한 예이다.

먼저 {“event”:”data”} 이벤트는 record_transformer 플러그인을 사용하여, 이벤트에 “host_param” 이라는 필드를 추가하고, 추가된 필드 {“event”:”data”,”host_param”:”webserver1″} 를 match 지시자의 file output 으로 보낸다.

<filter> 순서 역시 <match> 과 동일하게 쓰여진 순서대로 처리되므로 <match> 전에 <filter> 가 들어가야 한다.

4. system

system 지시자로 지정되는 다음 설정들은 fluentd 콘솔 명령의 옵션들과 동일하다.

log_level – 로그 표시 수준

suppress_repeated_stacktrace – true 로 설정되면 로그에 stacktrace 를 숨김 (기본값)

emit_error_log_interval – 오류 로그를 내보내는 시간 간격(초)

suppress_config_dump – 설정 파일의 내용이 로그에 표시되지 않음.

without_source – input 플러그인 없이 시작 (오래된 버퍼를 비울때 유용)

process_name – 프로세스 이름 변경

5. label

label 지시자는 내부 라우팅을 위한 ouput 및 filter 를 그룹화하여, tag 처리의 복잡성을 줄여준다.

tag 접두사 없이 이벤트를 구분할 때 특히 유용하다.

label 은 내장 플러그인 파라미터이므로 매칭시킬 때는 아래 예제처럼 @ 접두사를 붙여 준다.

위 설정에서 forward 이벤트는 elasticsearch output 으로 라우트되고, in_tail 이벤트는 @SYSTEM label 의 grep filter 와 s3 ouput 으로 라우트 된다.

이처럼 label 은 <filter>, <match> 지시자등을 그룹화 할 수 있다.

@ERROR label

@ERROR label 은 플러그인의 emit_error_event API 에 의해 생성된 오류 레코드에 사용되는 내장 label 이다.

<label @ERROR> 를 설정하면 관련된 오류가 발생했을 때 이벤트가 이 label 로 라우팅 된다. (예: 버퍼가 가득 찼거나 유효하지 않은 레코드일 때)

6. @include

@include 지시자를 사용하여 별도의 설정 파일에 있는 지시자를 가져올 수 있다.

@include 지시자는 정규 파일, glob 패턴 및 http URL 규칙 등으로 경로를 지정할 수 있다.

glob 패턴에서 파일은 알파벳순으로 불려지므로, a.conf 와 b.conf 가 있으면 fluentd 는 a.conf 를 먼저 분석한다.

중요한 설정 파일은 안전하게 @include 로 따로 구분하라.

Introducing BigData Log Aggregator, Fluentd

curl -L https://toolbelt.treasuredata.com/sh/install-debian-jessie-td-agent2.sh | sh

$ sudo /etc/init.d/td-agent restart
[ ok ] Restarting td-agent (via systemctl): td-agent.service.
$ sudo /etc/init.d/td-agent status
● td-agent.service - LSB: data collector for Treasure Data
   Loaded: loaded (/etc/init.d/td-agent; generated; vendor preset: enabled)
   Active: active (running) since Fri 2016-10-21 08:42:49 UTC; 10s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 4780 ExecStop=/etc/init.d/td-agent stop (code=exited, status=0/SUCCESS)
  Process: 4846 ExecStart=/etc/init.d/td-agent start (code=exited, status=0/SUCCESS)
    Tasks: 9 (limit: 4915)
   Memory: 63.4M
      CPU: 447ms
   CGroup: /system.slice/td-agent.service
           ├─4879 /opt/td-agent/embedded/bin/ruby /usr/sbin/td-agent --log /var/log/td-agent/td-agent.log --daemon /var/run/td-agent/td-agent.pid
           └─4882 /opt/td-agent/embedded/bin/ruby /usr/sbin/td-agent --log /var/log/td-agent/td-agent.log --daemon /var/run/td-agent/td-agent.pid
Oct 21 08:42:49 gather-twitter-data systemd[1]: Starting LSB: data collector for Treasure Data...
Oct 21 08:42:49 gather-twitter-data td-agent[4846]: Starting td-agent:  * td-agent
Oct 21 08:42:49 gather-twitter-data systemd[1]: Started LSB: data collector for Treasure Data.

$ sudo /etc/init.d/td-agent stop

$ sudo /etc/init.d/td-agent restart
$ curl -X POST -d 'json={"json":"message"}' http://localhost:8888/debug.test

$ sudo td-agent-gem install fluent-plugin-gcloud-pubsub

우선 log aggregator가 무엇인지 한 문장으로 설명하면, 여러 머신에서 쌓인 로그들을 한 번에 분석할 수 있도록 수집하여 주는 시스템을 말한다.
요새는 특히나 클라우드 시스템이 유행하면서 같은 일을 하는 시스템임에도 다른 머신에서 돌아가는 일이 많아지면서 필요성이 크게 증가하였다.
이번 조사로 알게 된 것들을 적어보도록 하겠다.

Scribe

우선 scribe는 Facebook에서 제작하고 사용하던 log aggregator system이다.

scribe: http://www.cnblogs.com/brucewoo/archive/2011/12/13/2285482.html

후에 다른 로그 수집 시스템들을 보면 알겠지만, Scribe는 다른 시스템보다 간단한 구조로 되어 있다.

Scribe는 일종의 message queue와 message queue에 쌓인 message를 DB에 저장해 주거나, DB가 실패하였으면 local에 저장하였다가 DB가 복구되었을 때 다시 DB에 저장해 주는 것만을 책임진다. 다시 말하면, message queue에 실제로 메시지를 보내는 부분은 사용자가 직접 작성하여야 한다는 것이다.

흔히들 말하는 scribe의 장점은 c++로 만든 만큼 다른 시스템들의 3~5배 정도의 성능을 보여준다는 것이다. 하지만 실제 scribe 사용자들은 무엇보다도 Facebook이 실제로 사용하였던 솔루션인 만큼 성능과 안정성에서 신뢰도가 있다는 것을 장점으로 뽑는다.

아래는 단점.
일단 가장 큰 문제는 더이상 Facebook이 Scribe를 사용하지 않는다는 것이다. Facebook은 이미 Java로 작성한 Calligraphus를 사용하기 시작했다. scribe는 open source이고 개발이 완전히 멈춘 것은 아니다. 하지만 Facebook이 중심적으로 만들던 시절에 비하면 거의 발전이 없는 상태라고 해도 될 정도이다.
앞에서 말했듯이 Scribe는 message를 보내는 부분을 완전히 새롭게 작성해야 한다. 또한, 바이너리 배포를 안하기 때문에 사용하려면 Scribe 자체도 빌드하여야 하는데 Scribe 자체가 여러 라이브러리에 의존성이 걸려있기 때문에 빌드하는 것도 쉽지 않다.

남은 장점은 성능밖에 없는 관계로 일단 다른 솔루션을 사용해보고, 그것으로 감당이 되지 않을 정도로 많은 부하가 걸리는 게 아니라면 굳이 Scribe를 사용할 이유는 없어 보인다.

Flume

 다음으로 소개할 Flume은 과거 Cloudera에서 제작하여 지금은 apache의 top level project가 되었다.
Flume의 가작 큰 특징(?)은 중간에 설계가 크게 바뀌었다는 것이다.

Flume OG: http://archive.cloudera.com/cdh/3/flume/UserGuide/

Flume NG: http://flume.apache.org/

 Fluentd는 ruby와 c로 짜여진 log aggregator 시스템이다.

fluentd: http://blog.treasure-data.com/post/13047440992/fluentd-the-missing-log-collector-software