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

서비스를 운영하고 있고, 장애가 발생했다. 그리고 순식간에 그것을 감지한 모니터링 시스템으로부터 경보를 받았다. 그래서, 뭐가 달라졌는가? 장애가 사라졌나? 장애조치를 마치고 그 시점의 각종 로그와 성능자료를 살펴봤다. 그래서, 뭐가 달라졌는가? 원인을 밝혔으니 장애가 없던 일이 되나?

모니터링을 했고 그로부터 발전적인 결과를 얻으려면, 궁극적으로 그 결과는 장애를 없애는 것이 되어야 한다. 장애를 없애지 못한다면 그 모니터링은 반쪽짜리 모니터링일 뿐이다. 그렇다면 모니터링 시스템은 단순히 장애를 빠르게 인지하고 알려주는 것이 아닌 장애 원인을 해석해내고 더 나아가 징후를 감지할 수 있어야 의미가 있을 것이다.

이 묶음글은 아래와 같이 3+1 개의 글로 이루어져 있으니, 관련된 부분을 함께 참고하면 좋을 것 같다.

기억속의 모니터링

그러나… 각종 이벤트가 말하는 바를 읽어내는 것은 커녕, 대상의 꼴을 제대로 파악하는 것부터가 그렇게 쉬운 일은 아니다. 쉽지 않은 게 아니라 어렵다. 몇몇 모니터링 시스템에 의존하여 시스템 운영업무를 해봤고, 또 꽤 많은 수의 모니터링 솔루션에 대한 검토를 했었으며, 직접 모니터링 시스템을 설계하고 구현해보기도 했다. 괜찮은 것을 찾는 것도, 그럭저럭 쓸만한 것을 만드는 것도, 매우 어렵다.

왜 어려운가? 내가 생각해본 범위에서는 다음과 같은 이유가 가장 크다.

  • 세밀하다. 그러나 고립되어 있다.
    • 많은 경우, 시스템 모니터링, Application 모니터링, 네트워크 모니터링 등으로 특정 분야에 전문적이지만 그 분야에 한정된, 고립된 모니터링을 한다.
    • 그 결과, 복합적인 문제나 원인지점과 문제지점이 떨어져 있는 경우에 쉽게 그것을 찾아내거나 감지할 수가 없다.
  • 애당초, 관점에 문제가 있다.
    • 통찰보다는 성능 수집과 장애 파악에 지나치게 집중하고 있다.
    • 서비스 자체가 아닌 그것을 이루는 제품, 구성요소 단위에 치중한다.
  • 시계열 데이터를 제대로 다루지 못한다.
    • 단순하게 순간을 연속적으로 배열한 것은 시계열 데이터가 아니다.
    • 넓고 깊게, 그리고 3차원, 4차원 적인 분석이 불가능하다.

말하자면, 종합검진을 통해 숨어있는 질병이나 질별을 유발할 수 있는 증상을 파악하지 못하고 덫난 피부에 연고만 그때 그때 발라주고 있는 샘이다.

새로운 꿈, 이벤트 해석기

긴 시간동안 고민을 해왔지만 여전히 어렵다. (물론, 어려워야 재미가 있지?)

아무튼, 내게 얼마간의 시간이 주어질지 모르겠지만 이번에는 조금 다른 시도를 해볼까 한다. (끝까지 할 수 있을지, 그것도 걱정이긴 하다.) 아무튼, 새롭게 해보려는 것은 다음과 같은 내용을 키로 설정하였다.

  • 구성요소 단위가 아닌 서비스 중심의 모니터링을 해보고 싶다.
  • 개별 증상보다 연계된 조짐을 파악할 수 있었으면 좋겠다.
  • 시계열 분석 및 2차원, 3차원 시계열 분석을 해보고 싶다.

그리고,

  • 틀을 제공하고, 자동화 연계 등을 위한 문을 열어주고 싶다.
  • 마지막으로, 제품을 만들기 보다는 방향을 잡고 싶다.

첫 걸음

사실, 시중에 나와있는 것 보다 더 좋은 것을 개인 프로젝트로 만드는 것을 상상하는 것은 좀 욕심이지 않을까? 그래서…

위의 이야기는 그냥 허공에 두고, 먼저…

Elastic Stack으로
여러 시스템 이벤트를 종합하여 살펴볼 수 있는 플랫폼을 하나 만들어 보려고 한다.

지난 몇일 동안 꾸며본 프로토타입은 아래 모양과 같다.

함께 읽기

이 프로젝트의 첫번째 묶음글은 아래와 같이 진행될 예정이다.

그리고 그 환경의 준비는

에 정리해 두었다.