“모니터링은 경보가 아니라 해석“에서 들었던 기존 모니터링의 문제점 중 하나는 시계열 데이터를 효과적으로 다루지 못한다는 점이었다. 이 문제는, 데이터를 단순히 시간순으로 배열하는 것으로 그치는 문제와, 시간을 단순히 1차원으로만 본다는 점을 포함한다. 특히, 시간은 바라보는 기준이 될 뿐 우리가 관심을 갖는 것은 주기성과 리듬을 갖는 인간활동과 연관된 것이기 때문에 과거의 기록을 바탕으로 미래를 예측하기 위해서는 시간과 사건을 입체적으로 바라보는 것이 필요하다.
[더 읽기]
앞선 글 “모니터링은 경보가 아니라 해석“에서, 기존 모니터링 환경의 한계 중 하나로 “기능 단위의 고립"과 “서비스 관점의 통찰 부재"를 들었다. 개별 구성요소에 대한 모니터링도 중요하지만, 거기서 멈추지 말고 그 요소들이 궁극적으로 이루게 되는 “서비스"와 사건들의 연관 관계, 인과 관계에 대한 분석이 사건을 해석하는데 매우 중요하다는 것을 강조하기 위함이었다. 이 글에서는, Elastic Stack, 특히 Kibana에서 서로 다른 원천으로부터 수집된 데이터를 엮어서 표현하기 위한 기법 중 하나를 정리하여 기록하려 한다.
[더 읽기]
사실, 나를 아는 사람들은 믿지 않을 수도 있지만, 나는 조금 강하게 말해서 운영관점의 모니터링에 대하여 매우 회의적이다. 거의 무용론자에 가깝다. 그럼에도 불구하고, 모니터링을 매우 좋아하는데, 그것은 내가 바라보는 모니터링은 문제가 발생한 것을 확인하는 모니터링이 아니라 지속적으로 대상의 꼴을 파악하고 그것이 말하는 바를 읽어내기 위한 분석시스템으로 바라보기 때문이다.
[더 읽기]
서로 독립적인 버전체계를 사용하면서 개별 제품의 연합군 같은 느낌이 더 강했던 ELK Stack, 즉 Elasticsearch, Logstash, Kibana는 이제 버전체계를 통일하고 Elastic Stack이라는 공식적인 명칭으로 사용하면서 더 활발하게 시장 공략을 하고 있는 것 같다. 이 글은, 지난번 소개했던 “Elastic NMS Part 1: 엔진을 켜라!“의 업데이트 성격의 글로, Elastic Stack의 현재 버전인 6.0 버전에 대한 설치과정을 정리한 것이다.
[더 읽기]
“아, 이건 기록을 안 해뒀네…” 하면서 그냥 잊으려 했는데, 메모를 정리하다가 발견해버렸다. ㅠ.ㅠ 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 이었다.
[더 읽기]