확장 로그 스 태시 (redis / elasticsearch)

12 centos 5.8 서버가 넘는 클러스터에서 기본 logstash shipper를 사용하여 logstash를 배포하여 /var/log/*/*.log중앙 logstash 서버 로 다시 보냅니다 .

rsyslogd를 배송 업체로 사용해 보았지만 rsyslogd의 ImFile 모듈의 버그로 인해 원격 엔드가 응답하지 않으면 로그가 메모리에 쌓입니다.

현재 Redis를 전송 메커니즘으로 사용하고 있으므로 logstash01이 로컬로 실행 중이며 이러한 로그의 VLAN IP에 바인딩되어 있습니다.

따라서 logstash-shipper는 logstash01의 redis로 보냅니다. logstash01은 별도의 프로세스에서 실행중인 Elasticsearch로 보냅니다.

우리가보고있는 것은 다음과 같습니다. Elasticsearch에는 141 개의 차단 된 스레드가 있습니다. elasticsearch 상위를 추적하면 다음이 표시됩니다.

futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL

다음은 elasticsearch의 jstack입니다.

다음은 logstash의 jstack입니다.

그래서 .. 지난 밤, 일부 웹 서버 (로그가 로그에 꼬리를 붙인 것)는 평균 500 개 이상의로드로 견뎌냈습니다.

logstash01에는 이것이 있습니다

Dec 19 00:44:45 logstash01 kernel: [736965.925863] Killed process 23429 (redis-server) total-vm:5493112kB, anon-rss:4248840kB, file-rss:108kB

OOM 킬러는 의미 로그가 .. 물건을 운송 어느 한 서버의 메모리에 쌓여 레디 스 서버, 사망 그래서 어떻게 든 아파치는 트위스트의 팬티를 얻을 수 있음을 의미합니다. (솔직히, 나는 그것이 어떻게 로그를 마무리한다고 가정하는지 모르겠다.)

이것은 사건이 어떻게 전개되었는지에 대한 나의 이론이다.

1. 교통 체증이 발생했습니다.
2. 엄청난 양의 로그가 생성되었습니다.
3. logstash / elasticsearch는 초당 300-400 개의 새로운 이벤트 만 처리 할 수있는 것처럼 Redis에 쌓여 있습니다.
4. 레디 스는 OOM-killer가 무의식적으로 학살 한 지점까지 완전히 채웠습니다.
5. Redis는 새 항목 수락을 중단합니다.
6. 이제 원격 호스트쪽에 항목이 쌓이기 시작합니다.
7. 모든 것이 견딜 수 있습니다. Apache가 요청 수락을 중지합니다. (왜?).

질문은 다음과 같습니다.

8. 통나무에 꼬리가 달린 것이 왜 아파치가 까다로운가? 아파치가 글을 쓰지 못하게 막는 것이 있습니까?

9. 탄력적 검색을 더 빠르고 더 나은 / 탄력하게 만드는 확실한 방법이 있습니까?

10. Redis를 탄력적으로 만들고 OOM으로 인해 죽지 않는 건전한 방법이 있습니까?

11. 내가 설정 한 방식에 근본적인 결함이 있습니까, 아니면 모든 사람에게이 문제가 있습니까?

-- 편집하다 --

@lusis에 대한 일부 사양.

admin@log01:/etc/init$ free -m
             total       used       free     shared    buffers     cached
Mem:          7986       6041       1944          0        743       1157
-/+ buffers/cache:       4140       3845
Swap:         3813       3628        185

Filesystem             Size  Used Avail Use% Mounted on
/dev/sda2               19G  5.3G   13G  31% /
udev                   3.9G  4.0K  3.9G   1% /dev
tmpfs                  1.6G  240K  1.6G   1% /run
none                   5.0M     0  5.0M   0% /run/lock
none                   3.9G     0  3.9G   0% /run/shm
/dev/sda1               90M   72M   14M  85% /boot
/dev/mapper/data-disk  471G  1.2G  469G   1% /data

/dev/sda2 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda1 on /boot type ext2 (rw)
/dev/mapper/data-disk on /data type ext3 (rw)
/data/elasticsearch on /var/lib/elasticsearch type none (rw,bind)

log01:/etc/init$ top 
top - 14:12:20 up 18 days, 21:59,  2 users,  load average: 0.20, 0.35, 0.40
Tasks: 103 total,   1 running, 102 sleeping,   0 stopped,   0 zombie
Cpu0  :  3.0%us,  1.0%sy,  0.0%ni, 95.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu1  : 12.0%us,  1.0%sy,  0.0%ni, 86.6%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu2  :  4.7%us,  0.3%sy,  0.0%ni, 94.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  5.6%us,  1.3%sy,  0.0%ni, 93.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  5.3%us,  1.3%sy,  0.0%ni, 93.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  6.4%us,  1.0%sy,  0.0%ni, 92.3%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   8178120k total,  6159036k used,  2019084k free,   761780k buffers

귀하의 게시물은 사양 방식 (LS 인덱서, 로그 볼륨 또는 기타 많은 것)에 대해 많이 설명하지 않지만 먼저 최선을 다해 귀하의 질문에 대답하려고 노력합니다. 면책 조항 : 나는 logstash 개발자 중 하나입니다-

1. 아파치로가는 너트는 logstash 프로세스의 부작용으로 인한 것일 수 있습니다. 지금은 그 자리를 따로 두었습니다.

2. ES f / b / s를 만드는 방법은 ES 노드를 더 추가하는 것입니다. 정말 쉬운 일입니다. 네트워크 토폴로지에 따라 서로 자동 검색하기도합니다. 이 업계에서 17 년이 지난 후에는 ElasticSearch만큼 쉽게 수평으로 확장되는 것을 본 적이 없습니다.

3. Redis를 f / b / s하려면 redis 클러스터링을 사용하지 마십시오. 최신 버전의 Logstash는 내부적으로 Redis로드 밸런싱을 수행 할 수 있습니다. Redis 출력은 플러그인 설정에서 Redis 호스트 목록을 지원하며 입력 측에 지원을 추가 할 예정입니다. 그 동안 인덱서 / 소비자 측에서 여러 Redis 입력 정의를 사용할 수 있습니다.

4. 나는 당신이 하나의 (아마도 저전력 호스트)로 많은 것을하려고하는 것처럼 들린다는 것 이상으로 대답 할 수는 없습니다.

적절한 확장 프로세스는 배치 된 구성 요소를 별도의 시스템으로 나누는 것으로 시작합니다. 나는 당신의 구성이 어디에도 없다고 생각하지만 logstash '병목 현상'이 필터에있는 곳. 수행하는 변환 수에 따라 Logstash 프로세스의 메모리 사용량에 영향을 줄 수 있습니다.

Logstash는 레고와 비슷하게 작동합니다. 2x4 브릭을 사용하거나 2 개의 2x2 브릭을 사용하여 동일한 작업을 수행 할 수 있습니다. logstash의 경우를 제외하고는 하나의 큰 벽돌보다 작은 벽돌을 사용하는 것이 실제로 더 튼튼합니다.

우리가 일반적으로 제공하는 일반적인 조언은 다음과 같습니다.

• 가장자리에서 가능한 빨리 로그를 발송하십시오. 디스크에 쓰는 대신 순수한 네트워크 전송을 사용할 수 있다면 좋지만 필수는 아닙니다. Logstash는 JVM 기반이며 좋은 결과와 나쁜 의미가 있습니다. 대체 배송 업체를 사용하십시오. 나는 파이썬 기반의 하나 ( https://github.com/lusis/logstash-shipper )를 썼지 만 사람들은 대신 Beaver를 사용하는 것이 좋습니다 ( https://github.com/josegonzalez/beaver ).

• 가능한 한 적은 필터링이 필요한 형식 (json 또는 최적의 json-event 형식)으로 로그를 생성하십시오. 이것이 항상 가능한 것은 아닙니다. 나는이 작업을 수행하기 위해의 log4j 어 펜더를 썼다 ( https://github.com/lusis/zmq-appender ) 결국 (자신의 repo에 패턴 레이아웃을 발발 https://github.com/lusis/log4j-jsonevent-layout ). 이는 해당 로그에 대해 logstash에서 필터링을 수행 할 필요가 없음을 의미합니다. 입력의 유형을 'json-event'로 설정했습니다.

아파치의 경우 다음 방법을 시도해 볼 수 있습니다. http://cookbook.logstash.net/recipes/apache-json-logs/

• 여러 구성 요소로 나누기 logstash에 대해 한 모든 대화에서 스테로이드의 유닉스 파이프라고 설명합니다. 파이프 라인을 원하는만큼 길거나 짧게 만들 수 있습니다. 책임을 수평으로 이동하여 로그 스 태시를 확장합니다. 이는 파이프 라인을 더 길게 만드는 것을 의미 할 수 있지만 지연 시간 오버 헤드와 관련하여 통계적으로 관련이있는 것은 아닙니다. 네트워크를보다 강력하게 제어 할 수있는 경우 (예 : EC2에서는 아님) 표준 트래픽 격리로 놀라운 일을 할 수 있습니다.

또한 logstash 메일 링리스트는 매우 활성화되어 있으므로 항상 시작해야합니다. 시작하기 가장 좋은 곳으로 구성을 정리하고 강조하십시오.

Sonia와 같은 ElasticSearch를 페타 바이트 수준으로 확장하는 회사와 Mailstamp 및 Dreamhost와 같은 회사는 Logstash를 미친 수준으로 확장합니다. 할 수 있습니다.