앞선 글 “모니터링은 경보가 아니라 해석“에서, 기존 모니터링 환경의 한계 중 하나로 “기능 단위의 고립"과 “서비스 관점의 통찰 부재"를 들었다. 개별 구성요소에 대한 모니터링도 중요하지만, 거기서 멈추지 말고 그 요소들이 궁극적으로 이루게 되는 “서비스"와 사건들의 연관 관계, 인과 관계에 대한 분석이 사건을 해석하는데 매우 중요하다는 것을 강조하기 위함이었다. 이 글에서는, 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 이었다.
[더 읽기]
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)이다.
인터넷 기반 서비스, 특히 Cloud Computing 환경에서 개발되는 Application이라면 웹이든 모바일이든 꼭 사용하게 되고야 마는 OAuth2와 JWT, 그것을 바탕으로 하는 인증/인가 체계의 개념에 대하여 최대한 쉽게 정리한다. (사실, 쉽게 쓴다고 해도 쉬운 내용이 아니지만 일반적으로 접할 수 있는 Protocol 자체에 대한 관점보다는 사용하는 입장과 왜 이렇게 쓰는지를 이해하기에 조금이라도 수월한 글이 되었으면 좋겠다)
[더 읽기]
존재하지 않는 서버의 로그를 보려면 어떻게 해야 할까? 간단하다. 로그를 서버가 아닌 다른 곳에 저장해서 보면 된다. 더이상 서버가 존재하지 않는 클라우드컴퓨팅 환경에서 로그를 기록하고, 그 이상의 일을 하기 위해서, 다시 또다른 클라우드 서비스를 활용할 수 있는데, 그 중 하나가 Papertrail이다. (Part #2)
[더 읽기]존재하지 않는 서버의 로그를 보려면 어떻게 해야 할까? 간단하다. 로그를 서버가 아닌 다른 곳에 저장해서 보면 된다. 더이상 서버가 존재하지 않는 클라우드컴퓨팅 환경에서 로그를 기록하고, 그 이상의 일을 하기 위해서, 다시 또다른 클라우드 서비스를 활용할 수 있는데, 그 중 하나가 Papertrail이다. (Part #1)
[더 읽기]
이번 시리즈를 통해서 배운 것이 하나 있다면, 글을 쓰려거든 딱 그 주제 하나에만 집중해야 한다는 점이었다. 시작은 단지, SoftLayer Cloud와 Object Storage를 활용한 시험적인 Application을 소개하는 것이었는데, 시리즈에 담을 내용을 정하는 과정에서 욕심이 과했던 것 같다.
[더 읽기]