brunch

매거진 Linux OpenSource

라이킷 19 댓글 3

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 강진우 Nov 26. 2016

Packetbeat를 이용한 네트워크 모니터링

Linux Opensource

오늘은 Packetbeat와 ElasticSearch, 그리고 Kibana를 사용해서 네트워크 모니터링을 하는 방법에 대해 이야기해 보려고 합니다. ElasticSearch를 비롯한 그 일련의 오픈소스들이 ElasticStack이라는 것으로 묶이면서 관심을 가지고 봤던 오픈소스인데요, 기대 이상의 품질을 보여주었습니다. 그럼 천천히 시작해 보겠습니다.

Packetbeat 란?

Packetbeat는 ElasticStack의 가장 하단에 있는 제품입니다. 로그 파일을 읽어서 파싱 하거나 정보를 수집해서 ElasticSearch 혹은 Logstash 등으로 보내주는 역할을 합니다. 그중에서도 Packetbeat는 네트워크 패킷을 pcap 라이브러리를 이용해서 분석한 후 ElasticSearch로 보내주게 됩니다.

이런 느낌..

자세한 정보는 https://www.elastic.co/products/beats/packetbeat 이곳에서 볼 수 있으며 RPM 파일을 다운로드하여서 설치만 해주면 됩니다. 설치는 매우 간단하기 때문에 따로 다루지 않겠습니다.

Packetbeat 설정

Packetbeat를 설치한 시스템은 아래와 같은 Data Flow를 가지고 있는 시스템입니다. nginx를 통해서 사용자의 요청을 받은 후 백엔드에 java로 요청을 전달하고, Mysql, Memcache와 통신해서 데이터를 가져오고, 내부 다른 시스템의 API를 이용하기도 하는 전형적인 웹 기반의 애플리케이션입니다.

시스템 Data Flow

/etc/packetbeat/packetbeat.yml 파일을 열어서 우선 불필요한 포트에 대한 모니터링은 제외합니다. 그래서 dns, http, memcache, mysql 이렇게 4개의 포트에 대해서만 수집하도록 설정합니다.

nginx로 SSL을 설정해서 443 포트로 서비스하는 서버의 경우 당연히 443 포트로 수집하는 정보는 아무것도 볼 수 없습니다. 그럴 때는 nginx가 java로 보내는 백엔드 포트를 수집하도록 설정해야 실제 사용자로부터의 요청에 대해 살펴볼 수 있습니다.

최종적으로 파일은 아래와 같은 내용이 됩니다.

packetbeat.interfaces.device: any

packetbeat.flows:
  timeout: 15s
  period: 10s

packetbeat.protocols.dns:
  ports: [53]

  include_authorities: true
  include_additionals: true

packetbeat.protocols.http:
  ports: [80, 8080] # 8080 포트가 nginx에서 java로 보내는 포트입니다.

packetbeat.protocols.memcache:
  ports: [11211]

packetbeat.protocols.mysql:
  ports: [3306]

output.elasticsearch:
  hosts: ["es.domain.com:9200"]
  index: "service-packetbeat-%{+yyyy.MM.dd}" #이 설정을 하지 않으면 기본 packetbeat-* 형태의 인덱스로 생성됩니다. 이미 제공되는 샘플 대시보드를 사용하고자 하면 기본 인덱스를 사용해야 합니다.

패킷 수집 방식을 기본 pcap에서 af_packet으로 바꿀 수도 있습니다. 리눅스 환경에서만 가능하며 CPU Usage를 좀 줄일 수 있다고는 하지만 트래픽이 많은 서버의 경우 크게 효과를 보지 못하는 것 같습니다.

그리고 packetbeat를 실행해 줍니다. kibana를 통해서 접속해 보면 아래와 같이 Discover 탭에서 패킷 정보가 수집되는 것을 확인할 수 있습니다.

실 서버라서 _source는 블러 처리를..

구슬이 서 말이라도 꿰어야 보배라는 말처럼 패킷 정보를 수집해도 그걸 제대로 보여줄 수 없다면 아무 의미가 없을 겁니다.

기본으로 제공해 주는 Packetbeat용 대시보드가 있으니 그걸 import 해서 살펴보는 것도 많은 도움이 되실 겁니다.

그래서 이번 글에서는 두 가지 정보를 그려볼까 합니다.

1. HTTP의 응답 속도의 분포 현황

2. Mysql query method의 분포 현황

이 두 가지를 잘 응용하면 거의 대부분의 필요한 그래프를 그릴 수 있을 겁니다. 그럼 먼저 HTTP의 응답 속도부터 그려 보겠습니다.

HTTP 응답 속도의 분포 현황 그리기

응답 속도를 표현하는 것에는 다양한 방법이 있겠지만 시간대별 도수 분포도 의미가 있을 것이라고 생각합니다. [Visualize] - [Vertical bar chart]를 클릭한 후 수집하고 있는 인덱스 명을 클릭해 줍니다.

맨 처음 보게 되는 화면

위와 같은 화면에서 상단 *로 표시된 부분을 type:"http"로 명시해 줍니다. 그리고 buckets에서 [X-Axis]를 클릭한 후 아래와 같이 맞춰 줍니다.

Aggregarion : Date Histogram
Field : @timestamp
Interval : Auto

그리고 상단에 플레이 버튼을 클릭하면 아래와 같이 그래프가 조금 더 이쁘게 변하는 것을 볼 수 있습니다.

적용 후 그래프 모습

하지만 아직 우리가 원하는 데이터를 그리진 못하고 있습니다. [Add sub-buckets]를 클릭한 후 [Split bars]를 클릭해서 아래와 같이 값을 맞춰 줍니다.

Split Bars 설정

그리고 상단의 플레이 버튼을 클릭하면 아래와 같이 아름다운 그래프를 볼 수 있습니다.

HTTP Responsetime 도수 분포 그래프

위 그래프는 어떤 의미일까요? 응답 속도가 0인 요청이 가장 많은 것을 볼 수 있으며, 그 위로 50을 기준으로 1~50 사이의 요청, 51~100 사이의 요청들이 분포되어 있음을 볼 수 있습니다. 이 그래프를 통하면 가장 많이 걸리는 요청이 어떤 것인지를 확인할 수 있으며, 그때 시간이 어느 정도 걸리는지도 분포를 통해서 확인할 수 있습니다.

Mysql query method의 분포 현황

다음으로 Mysql query method의 분포 현황을 그려 보겠습니다. mysql 서버로 날아가는 요청 중에 어떤 method가 많은지를 확인 함으로써 서비스의 성격과 이상 동작 여부를 알 수 있습니다. 이번에도 Vertical bar chart를 선택합니다. 그리고 이번엔 type:"mysql"로 선택하고 나머지 설정은 위 예제와 같이 맞춰 줍니다. Split Bars만 아래와 같이 설정해 줍니다.