Monitoring

“모니터링은 경보가 아니라 해석“에서 들었던 기존 모니터링의 문제점 중 하나는 시계열 데이터를 효과적으로 다루지 못한다는 점이었다. 이 문제는, 데이터를 단순히 시간순으로 배열하는 것으로 그치는 문제와, 시간을 단순히 1차원으로만 본다는 점을 포함한다. 특히, 시간은 바라보는 기준이 될 뿐 우리가 관심을 갖는 것은 주기성과 리듬을 갖는 인간활동과 연관된 것이기 때문에 과거의 기록을 바탕으로 미래를 예측하기 위해서는 시간과 사건을 입체적으로 바라보는 것이 필요하다.

앞선 글 “모니터링은 경보가 아니라 해석“에서, 기존 모니터링 환경의 한계 중 하나로 “기능 단위의 고립"과 “서비스 관점의 통찰 부재"를 들었다. 개별 구성요소에 대한 모니터링도 중요하지만, 거기서 멈추지 말고 그 요소들이 궁극적으로 이루게 되는 “서비스"와 사건들의 연관 관계, 인과 관계에 대한 분석이 사건을 해석하는데 매우 중요하다는 것을 강조하기 위함이었다. 이 글에서는, Elastic Stack, 특히 Kibana에서 서로 다른 원천으로부터 수집된 데이터를 엮어서 표현하기 위한 기법 중 하나를 정리하여 기록하려 한다.

사실, 나를 아는 사람들은 믿지 않을 수도 있지만, 나는 조금 강하게 말해서 운영관점의 모니터링에 대하여 매우 회의적이다. 거의 무용론자에 가깝다. 그럼에도 불구하고, 모니터링을 매우 좋아하는데, 그것은 내가 바라보는 모니터링은 문제가 발생한 것을 확인하는 모니터링이 아니라 지속적으로 대상의 꼴을 파악하고 그것이 말하는 바를 읽어내기 위한 분석시스템으로 바라보기 때문이다.

“아, 이건 기록을 안 해뒀네…” 하면서 그냥 잊으려 했는데, 메모를 정리하다가 발견해버렸다. ㅠ.ㅠ Elastic Stack으로 NetFlow와 SNMP 모니터링을 구성했던 이야기. NMS라고 하면서 SNMP와 NetFlow를 빼면 좀 섭하지… 했다가, 귀찮지만 닫았던 묶음글을 다시 열어서 마지막으로 이번 이야기, NetFlow와 SNMP 모니터링 하기를 더 넣는다. 그 중 NetFlow 먼저.

“아, 이건 기록을 안 해뒀네…” 하면서 그냥 잊으려 했는데, 메모를 정리하다가 발견해버렸다. ㅠ.ㅠ Elastic Stack으로 NetFlow와 SNMP 모니터링을 구성했던 이야기. NMS라고 하면서 SNMP와 NetFlow를 빼면 좀 섭하지… 했다가, 귀찮지만 닫았던 묶음글을 다시 열어서 마지막으로 이번 이야기, NetFlow와 SNMP 모니터링 하기를 더 넣는다. 이번엔 SNMP로 정말 끝!

앞선 Elastic NMS Part 1: 엔진을 켜라!에서는 자료분석 플랫폼 Elastic Stack을 설치하고 기본적인 동작을 확인하는 과정에 대해서 정리했다. 이제 구체적으로 이 환경의 기능을 검토할 차례인데, 내가 Elastic Stack을 활용하는 목적이 NMS, 특히 로그중앙화(Log Aggregation) 환경을 만드는 것이므로 로그를 수집하고 기본적인 파싱을 하는 과정을 먼저 진행했다.

Elastic Stack은 사용자가 원하는 다양한 유형의 자료를 저장하고, 검색하고, 분석할 수 있는 범용의 분석 플랫폼이다. Elastic Stack은 기본적으로 다루는 자료의 형식을 제한하거나 가리지 않으며 흔히 말하는 “비정형 자료"를 “모두” 소화다고 말할 수 있지만, 의미있는 분석을 효과적으로 하기 위해서는 자료의 의미, 즉 자료형에 대한 고려가 필요하며, 개별 자료를 어떻게 다룰 것인지에 대한 정의가 필요하다. 이 글은, Elasticsearch가 자료를 다루는 방식과 자료형을 사용자가 정의하는 방법에 대하여 정리한다.

범용 자료분석 플랫폼인 Elastic Stack의 미모를 담당하는 구성요소가 바로 Kibana이다. Kibana는 Elasticsearch와 연동하여 사용자가 자유롭게 질의를 만들어 날리고, 그 결과를 시각적으로 표현할 수 있는 클라이언트인데, “자유로운 분석 플랫폼“으로써의 Elastic Stack이 아닌, “독자적인 응용프로그램을 위한 자료분석 백엔드“로써 Elastic Stack을 활용하는 경우에는 상대적인 비중이 낮은 구성요소이다. 그래서 이 글에서는, Kibana의 기능을 겉핥기로 스쳐 지나가려고 한다.

다중가입자 환경을 지원하는 쓸만한 로그중앙화 솔루션이 있을까… 한동안 찾던 중에, 적당한 것을 찾기가 쉽지 않았던 것도 있고 또 내가 원하는 세세한 부분을 반영하기에는 조금 저수준에서 접근할 필요가 있겠다는 생각이 들었다. 그래서 그 기반으로 사용할 후보로 검토했던 것이, 이미 많은 프로젝트에서 Backend로 사용되고 있는, 유명한 데이터 분석도구 Elastic Stack 이었다.

오픈소스 로그 관리/분석 시스템인 Graylog는 앞선 글에서 간단히 살펴본 것과 같이, 로그 관리에 대한 핵심 기능을 모두 갖추고 있으며 편리한 사용자 환경을 제공하고 있다. 이 글에서는, 앞서 살펴본 사용자 관점의 사용성 외에, 이러한 기능 제공을 위한 부수적인 설정과 관리 편의 기능을 정리한다.

Graylog는 짧은 시간 동안 시험을 했지만 꽤 만족스러웠던 시스템이었다. Tenant 지원이라든지 일부 기능이 나의 요구사항과 맞지 않아서 최종적으로 채택하지 않았지만, 전반적인 Concept이나 살짝씩 읽어지는 그 뒤에 깔린 철학적인 부분이 기억에 남아, 세 편의 설명글과 함께, 당시의 설정을 여기에 남긴다.

Graylog는 사용자의 모든 로그를 한 곳에 모아서 자동화된 기초분석을 해주며, 이를 시각적으로 표시해주거나 특이사항 발생을 감지했을 때 경보를 주는 기능을 제공한다. 또한 필요에 따라 사용자가 쉽게 세부사항을 찾거나 열람할 수 있도록 검색기능을 제공한다. 이 글에서는 이러한 기능요소에 대해 정리한다.

클라우드 컴퓨팅 환경에서 휘발성 인스턴스의 로그를 중앙화하여 (반)영구 보관하고, 다양한 소스로부터 발생하는 관련된 로그를 모아서 연관 분석을 진행할 수 있는 플랫폼을 찾던 중 발견한 공개 소프트웨어 중 하나가 오늘 소개하려 하는 Graylog이다. 이 글에서는, Graylog를 간단히 소개하고, 그 설치 방법을 정리한다.

Goul(거울; Mirror in English) is a tool for virtual network port mirroring over the Internet for network traffic analyze and/or security monitoring. May useful especially for cloud computing environment.

On legacy infrastructure, with many physical switches, we can use a port mirroring (SPAN; Switched Port Analyzer in Cisco’s term) on the switch for monitoring and analyzing of traffic, and connecting a security appliances. But in cloud computing environment, it is not easy as legacy and in some cases, it is completely impossible.

네트워크를 다루기가 상대적으로 어려운 클라우드컴퓨팅 환경을 겨냥한 네트워크 포트 미러링 솔루션을 찾다가, 도저히 기능이나 비용 면에서 마땅한 것이 없어서, 요즘 공부하고 있는 Golang을 사용해서 하나 만들었다.
이 글은, 일단 이 프로젝트를 소개하는 글(README)이다.

존재하지 않는 서버의 로그를 보려면 어떻게 해야 할까? 간단하다. 로그를 서버가 아닌 다른 곳에 저장해서 보면 된다. 더이상 서버가 존재하지 않는 클라우드컴퓨팅 환경에서 로그를 기록하고, 그 이상의 일을 하기 위해서, 다시 또다른 클라우드 서비스를 활용할 수 있는데, 그 중 하나가 Papertrail이다. (Part #2)

존재하지 않는 서버의 로그를 보려면 어떻게 해야 할까? 간단하다. 로그를 서버가 아닌 다른 곳에 저장해서 보면 된다. 더이상 서버가 존재하지 않는 클라우드컴퓨팅 환경에서 로그를 기록하고, 그 이상의 일을 하기 위해서, 다시 또다른 클라우드 서비스를 활용할 수 있는데, 그 중 하나가 Papertrail이다. (Part #1)

지난 10월에 진행하던 BMT 중에 네트워크 성능 측정, 또는 사용량 확인을 위해 진행했던 MRTG 설치과정을 기록한다.

이번 글은 좀 색다른 주제다. Apache+JSP 환경에서 동적인 ErrorDocument 작성하기. 웹 관련 개발은 놓은 지가 오래인 데다가… JSP라고는 눈꼽만큼도 해본 적이 없으면서, 그리고 근래에는 Cloud Computing, Android 얘기만 하다가 참 어색하기까지 하네…

휴~ 이러니 내가 캐노니칼/우분투를 좋아하지 않을 수 없단 말이지.

벌써 12월인데 오늘에야 처음으로 Ubuntu의 새 버전인 8.10 Intrepid의 서버 버전을 설치해보았다. 뭐, 그냥 새 배포본일 뿐이지 별다른 생각은 없었다. 설치하는 과정에서 보니까… 소프트웨어/보안패치 자동업데이트 부분이 눈에 띄기는 했었지. 그런데, 잠깐 logout 했다가 다시 접속했을 때, 뭔가 익숙하지 않은 뭔가가 있는 것이 아닌가?

sio4@jangseung:/box/vms$ ssh 192.168.122.182
sio4@192.168.122.182's password: 
Linux ubuntu 2.6.27-7-server #1 SMP Fri Oct 24 07:37:55 UTC 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/\*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/

  System information as of Wed Dec  3 00:40:01 KST 2008

  System load: 0.0              Memory usage: 5%   Processes:       51
  Usage of /:  8.7% of 7.87GB   Swap usage:   0%   Users logged in: 1

  Graph this data and manage this system at https://landscape.canonical.com/
Last login: Wed Dec  3 00:34:39 2008 from 192.168.122.1
sio4@ubuntu:~$ 

오~~ 시스템 정보 요약서비스! 좋지. 관리하던 서버가 있던 시절에는 이런 사소한 것에도 많은 관심을 가졌던 터라… 첫번째 느낌은 “향수"랄까? 그런데 자세히 보니… “저 쪽에 가서 이 자료를 그려보고 이 시스템을 관리해보시라"고? 아뿔싸! 아까 건성으로 보아 넘겼던 자동업데이트 부분에서 잠깐 스쳐봤던 그 단어! Landscape! 캐노니칼의 새로운 시스템 관리/모니터링 서비스이다!