logstash:grok 대신dissect로 성능을 향상시킵니다.

소개

나는 감시가 필요한 응용 프로그램, 서비스, 장치로부터 로그를 수집하고 저장하는 데 한동안 사용하지 않았다.Logstash는 이 로그를 수신, 해석, 발표하는 것을 책임지기 때문에 좋은 성능을 확보하는 것이 매우 중요하다.
내가 직면한 많은 성능 문제는 설정 오류, 실현 또는 일부 필터의 부정확한 사용으로 인한 것이다. 주로 grok 필터이다.grok 필터는 매우 유용하지만 정규 표현식을 바탕으로 하는 필터로 모든 표현식을 검증해야 한다. 이것은logstash가 초당 수신하는 이벤트 수에 달려 있다. 이런 검증은 CPU 부하를 증가시켜 전체 모니터링 과정에 영향을 줄 수 있다.

신축성 스택 더듬을까요, 해부할까요?

파이프의 성능을 향상시키는 간단한 방법은 다른 필터로 대체할 수 있는지 확인하는 것이다grok.내가 계속 grok 로 대체하고 있는 필터는 dissect 필터다.grok과dissect 사이의 주요 차이점은 dissect 정규 표현식을 사용하지 않고 메시지를 해석하는 데 있다. 필드는 위치로 정의되고 a%{와 a} 사이의 모든 내용은 필드로 간주되며 다른 모든 내용은 구분자로 간주되어 dissect보다grok 빠르고 가볍다.
다음 예제 메시지를 고려하십시오.

2020-08-20T21:45:50 127.0.0.1 [1] program.Logger INFO - sample message

우리는 이 메시지를 다음 필드로 해석할 수 있습니다.

timestamp , ipaddr , thread , logger , loglevel , msg

이 메시지는 grok 및 dissect 로 해석하기 위해 다음 설정을 사용합니다.

그로크

grok {
    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{IP:ipaddr} \[%{INT:thread}\] %{DATA:logger} %{WORD:loglevel} - %{GREEDYDATA:msg}"}
}

해부

dissect {
    mapping => {
        "message" => "%{timestamp} %{ipaddr} [%{thread}] %{logger} %{loglevel} - %{msg}"
    }
}

구조는 매우 비슷하지만 grok 필드의 경우 TIMESTAMP_ISO8601 또는 timestamp 필드의 경우 IP 검증에 사용할 정규 표현식을 지정해야 합니다. 이 표현식은 이 위치의 값을 필드의 값으로 사용하기 때문에 사용할 필요가 없습니다.이것은 우리가 둘 사이에서 선택을 하게 하는 원인 중의 하나다.
파이프에서 수집된 메시지가 항상 같은 구조를 가지고 있거나 미세한 변화가 있더라도 ipaddr 가 아니라 dissect 를 사용할 수 있다는 것이 장점이다. 해석 속도가 빠르고 처리 능력이 적기 때문이다.
하지만 얼마나 빠르고 작은 처리 능력이 필요합니까?

Grok 및 Dissect

이 두 필터의 성능을 비교하기 위해 나는 간단한 파이프를 사용했다. 그 중에서 dissect 필터는 grok 필터로, generator 필터는 input 필터로, 나는 이전에 다른 운행에서 보여준 stdout 필터를 사용했다.

input {
    generator {
        lines => ["2020-08-20T21:45:50 127.0.0.1 [1] program.Logger INFO - sample message"]
        count => 10000000
    }
}

filter {
    #
    # grok or dissect filter
    #
    if [sequence] != 0 and [sequence] != 9999999 {
         drop { }
     }
}
output {
    stdout { }
}

이 파이프는 기본적으로 1000만 개의 메시지를 생성하고 지정한 필터를 적용하여 output 또는 grok, 그리고 dissect 을 사용하여 첫 번째 메시지와 마지막 메시지를 제외한 모든 메시지를 삭제합니다. 이 메시지는 처리의 시작과 끝을 검증하기 위한 것입니다.
이 파이프는 다음과 같이 출력됩니다.

{
          "host" => "elk",
            "ipaddr" => "127.0.0.1",
       "message" => "2020-08-20T21:45:50 127.0.0.1 [1] program.Logger INFO - sample message",
      "sequence" => 0,
      "loglevel" => "INFO",
        "logger" => "program.Logger",
      "@version" => "1",
     "timestamp" => "2020-08-20T21:45:50",
           "msg" => "sample message",
        "thread" => "1",
    "@timestamp" => 2020-08-26T02:00:38.127Z
}
{
          "host" => "elk",
            "ipaddr" => "127.0.0.1",
       "message" => "2020-08-20T21:45:50 127.0.0.1 [1] program.Logger INFO - sample message",
      "sequence" => 9999999,
      "loglevel" => "INFO",
        "logger" => "program.Logger",
      "@version" => "1",
     "timestamp" => "2020-08-20T21:45:50",
           "msg" => "sample message",
        "thread" => "1",
    "@timestamp" => 2020-08-26T02:02:34.018Z
}

필터가 실행되는 동안 기계의 CPU 사용률을 비교하는 데 흥미를 느꼈기 때문에 grok 백그라운드에서 운행하고 5분 동안 1초에 한 번씩 지표를 수집하여 300개의 도량치를 얻었는데 이것은 이런 상황에 있어서 이미 충분하다.
파이프를 실행하기 위해 나는 4개의 vCPU와 4GB의 RAM을 가지고 있으며, CentOS 7.8을 실행하고, 7.9 버전에서 Logstash를 실행한다.
nmon의 모든 도량 값은 다음과 같은 형식을 가지고 있다.

ZZZZ,T0010,00:16:49,21-AUG-2020
CPU001,T0010,50.5,2.0,0.0,46.5,1.0
CPU002,T0010,99.0,0.0,0.0,1.0,0.0
CPU003,T0010,97.0,1.0,0.0,1.0,1.0
CPU004,T0010,96.0,1.0,0.0,3.0,0.0
CPU_ALL,T0010,86.4,0.8,0.0,12.8,0.0,,4
MEM,T0010,3789.0,-0.0,-0.0,1024.0,2903.2,-0.0,-0.0,1024.0,-0.0,281.9,577.3,-1.0,2.0,0.0,181.5
VM,T0010,30,0,0,2384,12760,-1,0,0,0,0,27,0,0,2541,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
PROC,T0010,5,0,2524.7,-1.0,-1.0,-1.0,1.0,-1.0,-1.0,-1.0
NET,T0010,2.6,0.1,2.8,0.1
NETPACKET,T0010,10.9,2.0,12.9,2.0
JFSFILE,T0010,59.0,0.0,0.5,59.0,24.3,4.5,4.5,4.5
DISKBUSY,T0010,0.0,0.0,0.0,0.0
DISKREAD,T0010,0.0,0.0,0.0,0.0
DISKWRITE,T0010,0.0,0.0,0.0,0.0
DISKXFER,T0010,0.0,0.0,0.0,0.0
DISKBSIZE,T0010,0.0,0.0,0.0,0.0

이 모든 줄 중에서 CPU_를 포함하는 줄만 매우 중요합니다. 더 구체적으로 말하면 세 번째 열은 채집 시 모든 CPU의 평균 사용률 비율을 가지고 있습니다.dissect 및 drop 파이핑을 실행하는 동안 수집된 데이터에 대해 일부 데이터 조작을 한 후에 우리는 CPU 사용률과 실행 시간을 가시화하고 비교할 수 있다.

우리가 그림에서 본 초기 사용의 최고치는 Logstash 초기화로 인해 발생한 것으로 다음 플랫폼은 메시지 처리 과정에서의 사용에 대응한다.
그림에서 알 수 있듯이 이 특정 용례에서 테스트된 두 필터가 1000만 개의 메시지를 처리하는 시간은 기본적으로 같지만, 우리는 cpu 사용률에 큰 차이가 있다.nmon 필터를 사용할 경우 평균 CPU 사용률은 40%이고 grok 필터를 사용할 경우 평균 CPU 사용률은 60%를 초과합니다.

결론 및 링크

각 파이프의 파이프 수와 초당 이벤트 수에 따라 dissect 를 dissect 로 교체할 수 있는지 연구하는 데 시간이 걸리면 데이터 수신과 분석에 큰 개선이 있을 수 있습니다.인프라 시설이 구름 위에 있을 때, 이것도 원가를 낮출 수 있다. 왜냐하면 그것은 더욱 작은 실례를 사용할 수 있고, 어떤 상황에서도 cpu의 소모를 줄일 수 있기 때문이다.
로그 구조가 웹 서버 로그, 응용 프로그램 로그, 방화벽, 공유기와 항상 같은 경우, 또는 로그가 사용할 형식을 제어할 수 있을 때, 로그stash를 사용하여 이 로그를 수집하고 해석할 때 grok 필터가 가장 좋습니다.

링크

grok :

dissect : official documentation

이 글은 이전에 나의 블로그official documentation에 발표되었다