FlumeNG를 Windows Eclipse를 통해 빌드하는 방법을 정리했습니다.

Eclipse에 필요한 소프트웨어가 두가지 있습니다.
Subclipse : SVN을 받기 위한 소프트웨어
m2eclipse : Maven 빌드를 위한 소프트웨어
 

그럼 시작해보겠습니다.

필요한 소프트웨어 Help -> Install New Software 에서 진행합니다.

검색하시면 더 자세한 정보가 있겠지만,

Subclipse 설치 (http://subclipse.tigris.org/update_1.8.x)

m2eclipse 설치 (http://download.eclipse.org/technology/m2e/releases)
를 사용해서 설치 하면 됩니다.

Subclipse를 설치하신 뒤 SVN Perspective로 가셔서 Repository(https://svn.apache.org/repos/asf/incubator/flume)을 등록하고 branches에 있는 728 버전을 Check Out 합니다.


Check Out을 하게 되면 Parent Project 만이 Eclipse Workspace에 등록되어있는 것을 볼 수 있습니다. 해당 프로젝트를 Maven 형태로 바꾸기 위해서 Flume-728 프로젝트 위에서 마우스 우 클릭 후 configure -> Convert to Maven Project를 실행합니다.



Module을 Eclipse Project에 등록하기 위해서 각각을 import합니다.
Import -> Maven -> Existing Maven Projects



import 하는 과정에서 Error가 나오는 경우도 있는데 무시하셔도 지장은 없습니다.
보통 flume-ng-core, flume-ng-legacy-source에서 발생합니다. 모두 Resolve All  Later를 누르고 진행합니다.



pom.xml에도 몇가지 문제가 발생하는데 모두 Ignore 해버립니다.



flume-avro-source, flume-ng-core의 경우는 Build Path에 generated-sources를 추가한다.



이런 에러가 남아있다면 프로젝트에서 마우스 우 클릭하고 Maven -> Update Maven Dependencies를 실행하고 앞부분의 Generated Sources 추가를 다시 진행합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

원본 글 :  http://nosql.mypopescu.com/post/14541964621/big-data-vs-right-data 

(발번역자 왈 : Big Data, Log에 관련되서 계속 공부를 하다가 재미있는 글을 발견했다. 인터넷 초기 정보의 바다에서 의미있는 정보 찾기에 대한 이야기 혹은 신문에서 의미있는 뉴스 찾기 등과 같이 수 많은 정보중에 의미있는 정보를 찾아야한다는 많이 듣던 이야기를 반복하는 것이긴 하지만... 항상 까먹는 나같은 범인들에게는 중요한 이야기라 생각된다. 그리고 발번역은 계속된다.)

Dana Garner[1] : 우리는 단지 데이터에서 증가를 다루는 것이 아니라 다른 데이터 소스를 다룬다. 우리는 여전히 메인프레임과 함께하고 있다. (당췌 무슨 소린지 ... )

이 내용은 우리가 Big Data를 다루는 것은 불가능하다. Right Data를 다루어야만 한다. Big Data와 Right Data의 차이는 무엇인가?

Noel Yuhanna[2] : 이것은 GIGO(Garbage In Garbage Out) (발번역자 : FIFO를 바꿔서 쓰는것 같음)와 같다. 오랜 시간동안 Data를 다루는 조직들은 자신들이 어떤 Data를 다루어야하는지 조차 파악하지 못하고 있었다. 뿐만 아니라 그 Data의 가치 조차 파악되지 않았따. 새로운 도전은 바로 이런 Data의 가치를 파악하는 것이다.

그리고 매우 중요한 포인트는 바로 이런 Data를 통해 비지니스 감각을 만드는 것이다. 그래서 Right Data가 중요하다. [...]

다시 생각해보면 Big Data를 다루는 조직들에게는 엄청난 기회이다. 무엇보다 Big Data의 의미에 대해서 생각해보고 이해해야 하며 그것을 활용할 것인지 끊임없이 질문해봐야 한다. Data에 대해서 정확하게 인지하지 못한다면 Big Data Framework에 Data를 넣는 것은 의미도 목적도 없는 행위일 뿐이다.

Todd Brinegar[3]:  Noel 의 말이 100% 맞다. 이 내용은 대부분의 Data에 대한 것이 아니라 Right Data에 대한 것이다. 내 고객들 중에는 다량의 데이터베이스를 가지고 있는 사람들이 있는데 그들의 데이터베이스에는 관심도 없고 사용하지도 않는 데이터들이 쌓여있다.

[...]


그렇기 때문에 Right Data가 들어오고 추가되고 가져가지는 것과 그런 Data를 만드는 것이 요즘 매우 중요해지고 있다. 이런 것들을 낮은 가격으로 만드는 기술을 가지고 있는 것이 매우 중요하다. 

이런 대담을 보고 다르게 생각해보면:

Right Data에 바로 접근하는 방법은 없다.

(발번역자 왈 : 번역했더니 무슨 소린지 더 모르겠다. 일단했으니 올립니다. 죄송합니다.)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

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

About

이번 포스트는 Fluentd 에 대한 소개이다. Fluentd는 Treasure Data 사에서 만든 오픈소스 로그 수집기 이다.

The Problems

로그에 있어서 근본적인 문제점은 로그들이 스트림 형태로 표현될 지라도 파일로 저장되는 것에 있다. 전통적으로 로그들은 text 형태의 파일로 덤프되게 되고 rsync를 상요해서 시간 혹은 하루 주기로 수집된다. 오늘날의 web/mobile 어플리케이션에서는 이런 방식은 두가지 문제를 야기한다. 

PROBLEM 1: NEED AD-HOC PARSING

Text 형태의 로그는 자신만의 포맷을 가지고 있어서 분석 엔지니어들은 각각의 포맷에 맞는 파서를 만들어야 한다. 분석 엔지니어는 Data Scientist이지 파서 제너레이터가 아니다!!!!

PROBLEM 2: LACKS FRESHNESS

로그의 지연현상이 발생한다. 사용자 행태에 대한 실시간 분석이 훨씬 빠른 기능 반복을 만든다. nimber A/B 테스팅을 통해 서비스 차별화에 도움이 된다.

이런 이유 때문에 Fluentd를 만들게 되었다. 우리는 Fluentd가 파일의 제거와 로그를 반구조화 데이터 스트림으로 변경을 통해 스케어러블 로그 수집의 모든 이슈를 해결할 것이라고 믿는다.

What’s Fluentd?

Fluentd를 설명하기 가장 쉬운 방법은 'syslogd that understands JSON'이다. 특징은 다음과 같다. :

• 쉬운 설치 : rpm/deb/gem 사용
• 작은 footprint : 300라인의 루비소스
• 반구조화 데이터(Semi-Structured data) : 로깅
• 쉬운 시작 : 적은 설정
• 완벽한 프러그인 스타일 : 구조화, Ruby gems를 사용한 프러그인 배포

유사한 다른 로그 수집 시스템은 페이스북의 Scribe, Cloudera의 Flume이 있다. 아래 테이블을 통해 Scribe, Flume, Fluentd의 차이점을 요약해보도록 하겠다. (주의: 저자는 FlumeNG branch에 대해서 정확하게 이해하고 있지는 못하지만 Flume에 큰 변화의 움직임이 있는것 같다.)

물론 여기에도 장점과 단점은 있다. Fluentd 최대 확장과 유연성은 Ruby의 에코 시스템을 통한다. 반면 Scribe는 강력한 성능(물론 Fluentd또한 꽤나 빠르다. 하나의 코어에서 1800msg/s를 처리할 수 있다.)을 가지고 있다. Flume은 Java로 만들어졌기 때문에 다양한 엔터프라이즈 시스템에 적용이 가능하다.

아래 내용은 Fluentd의 기본 컨셉에 대해 자세히 다루도록 하겠다.

LogEntry = time + tag + record

전통적인 raw-text 로그와 다르게 Fluentd의 로그 엔트리는 세가지 속성을 가지고 있다. (time, tag, record)

• time 은 UNIX 타임 스탬프로 로그가 포스트되는 시점을 나타낸다.
• tag 는 로그포워딩에 사용되는 경로 메세지를 나타내고 자세한 내용은 다음에 설명하겠다.
• record 는 JSON 형태로 표현되고 raw text형태가 아니다.

레코드는 의도적으로 JSON형태로 표현된다. Fluentd는 비구조화 데이터(unstructured data)가 아닌 반구조화 데이터(semi-structured data)를 수집한다. 이것은 다음 분석에 파싱이 필요없다는 것을 뜻한다. 이 방식은 다루기 쉽고 임의의 regexp 보다 빠르다. 그렇지만 어플리케이션이 Fluentd를 위해서 로깅 라이브러리를 필요로 한다.

Internal Architecture: Input -> Buffer -> Output

Fluentd는 3가지 기본 컨포넌트로 구성된다. : Input, Buffer, Ouput 기본 행동은 1) Feeding logs from Input, 2) Buffers them, 3) Forward to Output.

Input

Input은 로그가 들어오는 장소를 말한다. 사용자는 다양한 소스로 부터 이벤트를 받아드리도록 확장 할 수 있다. 예를 들어서 Input은 공식적으로 HTTP+JSON, file을 tail하기(Apache log parser 지원), syslog를 지원한다. 물론 Ruby plugin 작성을 통해 다양한 Input plugin작성이 가능하다.

Buffer

Buffer는 신뢰성을 위해 존재한다. Output이 실패했을 경우 이벤트는 버퍼에 남아있고 자동적으로 재시도 된다. 메모리나 파일 버퍼가 지원된다.

Output

Buffer는 log의 청크를 만들고 Output으로 전달한다. Output은 저장하거나 청크를 전달한다. Buffer는 몇초에서 1분동안 청크가 생성되는 것을 기다린다. 이런 것은 배치 스타일의 임포팅을 지원하는 스토리지에서 매우 효과적인 쓰기 방법이다.

다양한 Input/Output plugin들이 커뮤니티를 통해서 만들어지고 있다. : MongoDB, Redis, CouchDB,Amazon S3, Amazon SQS, Scribe, 0MQ, AMQP, Delayed, Growl, 등이 있다.

Log Forwarding

Fluentd는 하나의 노드에서도 동작을 잘할 뿐만 아니라 여러 노드의 설정 또한 가능하다.

어플리케이션 서버는 하나의 Fluentd를 로컬에 가지고 있고, 로컬의 로그들을 모든 로그를 하나로 수집하는 다른 Fluentd로 넘기게 된다. tag는 목적지가 되는 Fluentd를 가르키게 된다(정해진 설정 파일을 사용).

Conclusion

Fluentd를 사용하면 실시간 로그 수집을 매우 간단하게 할 수 있다. 또한 다른 로그 수집 솔루션중에서 가장 쉽게 설치, 설정, 추가, 수행이 가능하다고 생각한다.
물론 Scribe 와 Flume에 비해서 얼마 되지 않은 제품이지만 벌써 하루에 수천만 건의 로그를 수집하는 사용자들이 Fluentd를 사용하고 있다. 커미터의 숫자와 플러그인들 또한 매일같이 늘어나고 있다.

 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.