NMS 개념 - 장애관리 아홉번째

일반적인 장애 관리에서 사용하는 기법(폴링)는 장애가 난 후 그것을 빨리 알려줄 수는 있지만

장애가 왜 발생했는지는 알기는 어렵기 때문에 사실 네트워크의 장애 발생 시

제일 명확한 원인을 제공해 줄 수 있는 것은 어디엔가 남아 있는 LOG가 맞다.

그러나 LOG 관리 시스템은 구축하기에 비용이 많이 든다는 점과

비용대비 결과물이 그리 만족스럽지 못하다는 것(돈으로 환산되지 않는다는 점...),

그리고 시스템을 구축하고 유지 관리할 만한 전문가가 별로 없다는 것이다.

그렇더라도... 관리를 하지 않을 수는 없으니... 그것도 문제다.

 

어쨌거나.. 비용과 효율성에 대한 것은 일단 제쳐 두고

실제로 LOG 관리 시스템을 구축하는 절차에 대해 생각해 보자.

 

항상 그렇듯이 제일 처음 할 것은 관리 대상과 정책을 정하는 것이다.

 

1) 어떤 장비들의 로그를 관리할 것인가?

2) 장비들의 logging 레벨(혹은 trap level)을 어느 정도로 정할 것인가?

그리고 이 두 가지를 고려해 1일 평균 log 량을 산정한다.

이것은 도입할 시스템과 구비해야 할 DISK의 용량을 정하는데 백데이터가 된다.

 

하지만 이것들 보다 먼저 해야 하는 일이 있다.

그것은 무엇을 보고자 하는지 정하는 것이다.

보고자 하는 LOG가 무엇인지, 어떤 형태로 보기를 원하는지 결정하고 시작해야 한다.

 

이 부분은 아주 중요하지만 간과하고 진행하다가 최종 단계에서야

되니 안되니 하며 개발자와 발주자 사이에 큰 문제로 불거지게 되는 경우가 허다하다.

 

특히 장비가 로그를 어떤 형태로 남기는지 확인하는 것도 중요한 이슈 중에 하나인데

이에 따라 개발방법과 개발해야 하는 범위가 전혀 달라질 수 있기 때문이다.

 

시스템 도입 전에 관리하고자 하는 장비들이 로그를 전송하는 방식을 확인해야 한다.

대부분이 syslog 또는 trap을 지원하지만... 그렇지 않은 장비들도 많이 있기 때문이다.

 

다행히 별도의 포트를 통해 udp 또는 tcp 방식으로 로그를 전송해 준다면,

이를 받아 주는 프로그램을 개발해야 한다.

장비들의 EMS를 통해서 자체 프로토콜로 logging을 하는 장비라면

EMS로 부터 log를 가져오는 방법을 연구해 이를 프로그램 해 주어야 한다.

이런 식으로 각각의 장비 별로 log를 통합할 수 있는 방법을 찾는다.

아예 통합이 불가능한 장비라면, 다음 장비 교체 시기에 이에 대한 업그레이드나

교체도 고려해야 할 것이다.

 

이러한 절차들이 끝나야 어떤 시스템을 도입할 것인지 결정할 수 있게 된다.

 

그럼 log 관리 프로그램을 상용으로 할 것인지, 아니면 개발을 할 것인지 결정해 보자.

 

상용 로그 분석 시스템은 네트워크 관리 용도 보다는 web log 분석이나, 방화벽 로그 분석 등의

용도로 많이 쓰이기 때문에 네트워크 용으로 사용하려고 하다 보면 여러 가지로 수정해야 하는

경우가 많다. 따라서 처음부터 개발을 하는 것이 더 나을 수도 있다.

 

다음은 DB를 사용할 것인지 그냥 파일을 사용할 것인지를 고려한다.

DB를 사용하면 비용이 발생하기는 하나 안정적이며 로그 검색이나 통계에 훨씬 용이하다.

LOG를 사용하면 구축 비용이 적게 든다. 단, 검색이 매우 어렵다.

최근에는 디스크의 가격이 많이 하락했기 때문에 디스크 가격이 그리 중요하지는 않다.

저장하는 것이 문제가 아니라... 쌓여 있는 데이터를 어떻게 활용하느냐가 관건이기 때문이다.

일단적으로 시스템이라는 관점에서 볼 때, LOG 보다는 DB 사용을 권장하고 싶다.

 

다음은 어떤 DB를 사용할 것인가 이다.

상용 DB라면 오라클이나 MS SQL서버를 가장 많이 사용할 것이고,

비용이 문제라면 mysql을 선택하면 된다.

(무료였으나, 최근 들어 기업용으로 쓸 때는 약간의 가격을 지불하는 것으로 알고 있다.)

 

대부분의 장비들이 syslog를 사용한다면 unix 시스템을 사용하는 것이 편할 것이고,

이 때 가장 저렴하게 구축하는 방법은 PC 서버에 linux+mysql+syslod daemon 조합이다.

여기에 아파치 톰캣등의 웹서버를 이용하여 검색 및 통계 기능을 만들 수 있다.

개발비만 추가하면 된다.(제대로 된 개발자를 찾기 어렵다.)

 

조금 더 제대로 된 시스템을 만들자면...

PC 서버에 windows+mssql+개발프로그램(.net)에 iis 또는 .net 기반의 view를 제공해 주는

시스템을 구축하는 방법도 있을 것이다.

아마도 위의 시스템보다는 더 쉽게 개발자를 구할 있을 것이고

syslog 외에 다른 프로토콜도 쉽게 수용할 수 있을 것이다.

 

또 다른 방법은 mssql 대신 오라클을 사용하는 것이고...

PC 서버 대신 unix 서버(hp, sun, ibm 등)이나 정식 서버를 사용하는 것이다.

마찬가지로 unix 서버를 사용하는 경우에는 syslog daemon을 이용해도 크게 무리는 없지만,

db로 저장하는 부분에 대해서는 프로그램이 필요하다.

그러나  sqlldr 등을 활용하며 대용량 로그에 대한 db insert가 훨씬 용이하고 빠르기 때문에,

개발자 입장에서 볼 때 오라클을 이용하는 것이 훨씬 낫다.

 

실제로 하나씩 insert 하는 것보다...

sqlldr를 이용한 insert가 훨씬 낫다는 것을 테스트 해본 적이 있다.

프로그램으로 초당 수천건의 데이터를 처리해 DB에 저장하는 것은 그리 쉬운 일은 아니다.

 

물론 데이터의 안정성 등에 대해서도 가장 나은 편이다.

단점이야 항상 그렇듯이... 비용이 많이 든다는 것이겠지만...

 

어쨌거나...

쌓여있는 로그에 대한 검색 기능 또한 개발의 중요한 이슈이다.

 

때문에 어떤 검색 기능이나 통계 기능을 원하느냐가

처음에 DB를 설계할 때의 중요한 고려사항이 되기 때문에,

어떻게 보면... 이 부분이 가장 중요한 부분이다.

  

솔루션을 제공하는 업체는 제공할 수 있는 모든 기능을 나열하고,

솔루션을 도입하는 업체는 그 중에 원하는 기능을 골라 도입하지만,

나중에 알고 보면 그 기능은 특정 장비 또는 상황에 국한되어서만 제공할 수 있는 경우가 많다.

때문에 솔루션을 도입할 때는 현재의 운영중인 네트워크 환경에 적용할 수 있는지

확인을 거친 후 도입해야 한다. 쉽지만은 않은 일이다.