Logstash 필터 kv

같은 구조임에도 배열이 조금씩 다른 로그가  있다.

sip = 1.1.1.1 dip = 2.2.2.2 sport = 100 dport = 200 action = permit
sip = 1.1.1.1 dip = 2.2.2.2 sport = 100 dport = 200 attack = 10.10.10.10
sip = 1.1.1.1 dip = 2.2.2.2 attack = 10.10.10.10

이런 로그를 처리하려면 필터 설정이 복잡해지게 마련.

filter {
  if "action" in [message] {
    dissect { mapping => { "message" => "sip = %{sip} dip = %{dip} sport = %{sport} dport = %{dport} action = %{action}" } }
  } else if "port" in [message] and "attack" in [message] {
      dissect { mapping => { "message" => "sip = %{sip} dip = %{dip} sport = %{sport} dport = %{dport} attack = %{atack}" } }
  } else {
      dissect { mapping => { "message" => "sip = %{sip} dip = %{dip} attack = %{attack}" } }
  }
}

Logstash 연동 에러(Limit of total fields)

로드스태시 연동 과정에서 발생한 에러. 엘라스틱서치에서 하나의 인덱스가 가질 수 있는 필드 개수에 제한이 있나 보다. 기본적으로 허용된 필드 개수는 1,000개. 필드 분류를 어떻게 했길래 개수가 1,000개를 넘어가지?

mysql-connector-java 8 버그

Elasticsearch 활용(Snort 데이터베이스 연동) 편에서 Mysql 데이터베이스 연동을 위해 mysql-connector-java 5 버전을 사용했었는데 어느새 8 버전이 나왔다.

Elasticsearch 6.4의 변화

엘라스틱서치가 최근 6.4 버전을 공개했다. 심심해서 버전 릴리즈 추이를 그려봄. 다음은 릴리즈 현황. 2010년에 처음 나왔구나.

정규표현식이 최선일까?

로그스태시 필터링 과정에서 grok 필터를, 그러니까 정규표현식을 사용하는 게 최선이냐는 질문을 받았다. 답은 그때 그때 달라요(..)

눈 씻고 봐도 구조 파악이 어려운 비정형 데이터를 정형 데이터로, 일관된 규칙을 갖는 테이블 구조로 바꿀 때는 정규표현식이 최선이다. 그런데 다행히도 컴퓨터에서 발생하는 대부분의 로그는 눈곱만큼이라도 나름의 구조를 가지고 있는 반정형 데이터이다.

grok 필터 작성 사례에 등장했던 로그를 다시 한번 살펴보자. 얼핏 어수선해 보이지만 해당 로그는 뚜렷한 "필드":"값" 구조를 가지고 있다.

Logstash 필터 grok 사례

로그스태시를 이용해서 로그를 전송하면 기본적으로 원본 로그는 message 필드에 저장된다.

이 상태에서는 분석할만한 게 없다. 인구 조사를 떠올려보자. 단순히 머릿수만 세면 대한민국 인구 5천만, 이러고 끝이다. 하지만 성별을 분리하면 성비 분석이 가능해지고, 나이를 추가하면 연령대별 인구 통계를 알 수 있다. 집계 대상을 다양화하면 다양한 분석이 가능해진다는 얘기.

스위치

칩 히스와 동생 댄 히스 형제의 두번째 저서. 근데 전반적으로 전작 스틱을 많이 재활용한 듯(..) 형제가 사이는 참 좋아 보인다.

두 형제는 이제 마음을 사로잡는 스토리텔링에서 한걸음 더 나아가 인간과 조직의 적극적 행동 변화를 이야기한다.

행동을 극적으로 변화시킬 수 있는 방법은 무엇일까? 간단하다. 기수에게는 방향을, 코끼리에게는 동기를 부여하면 된다고.

기수? 코끼리?

인간의 두뇌에는 2개의 시스템이 있다고 한다. 이성(기수)과 감성(코끼리). 바로 생각에 관한 생각의 대니얼 카너먼이 얘기한 '의식적이고 추론 노력이 필요해서 느린 이성'과 '무의식/본능적이고 자동이라 빠른 감성'.