Zabbix와의 인터뷰: 12가지 솔직한 답변

IT에는 '만약 작동하면 건드리지 말라'는 미신이 있습니다. 이는 우리의 모니터링 시스템에 대해 말할 수 있습니다. Southbridge에서는 Zabbix를 사용합니다. Zabbix를 선택했을 때 매우 멋졌습니다. 그리고 사실 그에게는 대안이 없었습니다.

시간이 지남에 따라 우리 생태계는 지침, 추가 바인딩을 획득하고 Redmine과의 통합이 나타났습니다. Zabbix는 속도, 거의 즉시 사용할 수 있는 HA, 아름다운 시각화, kubernethes 환경에서의 작업 최적화 등 여러 측면에서 뛰어난 강력한 경쟁자를 보유하고 있었습니다.

그러나 우리는 서두르지 않습니다. 우리는 Zabbix를 살펴보고 향후 릴리스에서 어떤 기능을 만들 계획인지 물어보기로 결정했습니다. 우리는 행사에 참석하지 않고 Zabbix 개발 이사인 Sergey Sorokin과 솔루션 설계자인 Vitaly Zhuravlev에게 불편한 질문을 했습니다. 그 결과를 알아보려면 계속 읽어보세요.

1. 회사의 연혁을 알려주세요. 제품에 대한 아이디어는 어떻게 탄생했나요?

회사의 역사는 회사 창립자이자 소유주인 Alexey Vladyshev가 은행 중 한 곳에서 데이터베이스 관리자로 일했던 1997년에 시작되었습니다. Alexey는 환경의 현재 및 과거 상태를 이해하지 않고 다양한 매개변수의 과거 값에 대한 데이터 없이 데이터베이스를 관리하는 것은 비효율적이라고 생각했습니다.

동시에, 현재 시장에 나와 있는 모니터링 솔루션은 매우 비싸고 번거로우며 많은 리소스가 필요합니다. 따라서 Alexey는 자신에게 맡겨진 인프라 부분을 효과적으로 모니터링할 수 있는 다양한 스크립트를 작성하기 시작합니다. 취미로 바뀌고 있습니다. Alexey는 직업을 바꾸었지만 프로젝트에 대한 관심은 남아 있습니다. 2000-2001년에 프로젝트는 처음부터 다시 작성되었으며 Alexey는 다른 관리자에게 개발 내용을 사용할 수 있는 기회를 제공하는 것에 대해 생각했습니다. 동시에 기존 코드를 어떤 라이선스로 출시해야 하는지에 대한 의문이 제기되었습니다. Alexey는 GPLv2 라이센스로 출시하기로 결정했습니다. 이 도구는 전문적인 환경에서 즉시 발견되었습니다. 시간이 지남에 따라 Alexey는 소프트웨어 기능 지원, 교육 및 확장에 대한 요청을 받기 시작했습니다. 그러한 주문의 수는 지속적으로 증가했습니다. 그래서 자연스럽게 회사를 설립하겠다는 결정이 내려졌습니다. 회사는 12년 2005월 XNUMX일에 설립되었습니다.

2. Zabbix 개발 역사에서 어떤 핵심 사항을 강조할 수 있습니까?

현재 다음과 같은 몇 가지 사항이 있습니다.
ㅏ. Alexey는 1997년부터 대본 작업을 시작했습니다.
비. GPLv2 라이센스에 따른 코드 공개 - 2001.
V. 자빅스는 2005년에 설립되었습니다.
d. 최초의 파트너십 계약 체결, 제휴 프로그램 생성 - 2007.
d. Zabbix Japan LLC 설립 – 2012년.
e. Zabbix LLC(미국) 설립 - 2015년
그리고. Zabbix LLC 창립 - 2018년

3. 몇 명을 고용하고 있나요?

현재 Zabbix 그룹은 개발자, 테스터, 프로젝트 관리자, 지원 엔지니어, 컨설턴트, 영업 사원, 마케팅 직원 등 70명이 조금 넘는 직원을 고용하고 있습니다.

4. 로드맵은 어떻게 작성하고, 유저들의 피드백은 어떻게 수집하나요? 다음에 어디로 이동할지 어떻게 결정합니까?

Zabbix의 다음 버전에 대한 로드맵을 작성할 때 다음과 같은 중요한 요소에 중점을 두고 있습니다. 보다 정확하게는 다음 범주에 따라 로드맵을 수집합니다.

ㅏ. Zabbix의 전략적 개선. Zabbix 자체가 매우 중요하게 생각하는 것입니다. 예를 들어 Go로 작성된 Zabbix 에이전트가 있습니다.
비. Zabbix 고객과 파트너가 Zabbix에서 보고 싶어하는 것. 그리고 그들은 기꺼이 지불할 의향이 있습니다.
V. Zabbix 커뮤니티의 희망/제안.
d. 기술 부채. 🙂 이전 버전에서 출시했지만 전체 기능을 제공하지 않았고 유연성을 충분히 제공하지 않았으며 모든 옵션을 제공하지 않았습니다.

5. Zabbix와 Prometheus를 비교할 수 있습니까? Zabbix에서 무엇이 더 좋고 무엇이 더 나쁩니까?

우리가 생각하는 가장 큰 차이점은 Prometheus가 주로 메트릭 수집을 위한 시스템이라는 점입니다. 기업에서 본격적인 모니터링을 수집하려면 시각화를 위한 grafana, 장기보관을 따로 하고, 문제가 있는 곳은 따로 관리하고, 로그는 따로 작업하고...

Prometheus에는 표준 모니터링 템플릿이 없습니다. 수출업체로부터 수천 개의 측정항목을 모두 수신한 후에는 문제가 있는 신호를 독립적으로 찾아야 합니다. Prometheus 설정 - 구성 파일. 어떤 곳에서는 더 편리하지만 다른 곳에서는 그렇지 않습니다.

Zabbix는 "~에서" 모니터링을 생성하기 위한 범용 플랫폼으로, 자체 시각화, 문제 및 표시의 상관 관계, 시스템에 대한 액세스 권한 배포, 작업 감사, 에이전트를 통해 데이터를 수집하기 위한 다양한 옵션, 완전히 다른 프로토콜을 사용하는 프록시, 플러그인, 스크립트, 모듈을 사용하여 시스템을 빠르게 확장하는 기능...

또는 예를 들어 HTTP 프로토콜을 통해 데이터를 있는 그대로 수집한 다음 JavaScript, JSONPath, XMLPath, CSV 등과 같은 전처리 기능을 사용하여 응답을 유용한 측정항목으로 바꿀 수도 있습니다. 많은 사용자는 웹 인터페이스를 통해 시스템을 구성 및 관리하는 기능, 서로 공유할 수 있는 템플릿 형태로 일반적인 모니터링 구성을 설명하는 기능, 메트릭뿐만 아니라 탐지 규칙도 포함하는 기능으로 Zabbix를 높이 평가합니다. 임계값, 그래프, 설명 - 일반 객체를 모니터링하기 위한 완전한 객체 세트입니다.

또한 많은 사람들은 Zabbix API를 통해 관리 및 구성을 자동화하는 기능을 좋아합니다. 일반적으로 나는 홀리바르를 조직하고 싶지 않습니다. 두 시스템 모두 해당 작업에 매우 적합하고 서로 조화롭게 보완할 수 있는 것으로 보입니다. 예를 들어 버전 4.2의 Zabbix는 Prometheus 내보내기 프로그램 또는 자체에서 데이터를 수집할 수 있습니다.

6. Zabbix SaaS를 만드는 것에 대해 생각해 보셨나요?

우리는 그것에 대해 생각했고 앞으로도 그렇게 할 것입니다. 그러나 우리는 이 솔루션을 고객에게 최대한 편리하게 만들고 싶습니다. 이 경우 통신 도구, 고급 데이터 수집 도구 등과 함께 표준 Zabbix를 제공해야 합니다.

7. zabbix ha는 언제 기대해야 합니까? 그리고 기다려야 할까요?

Zabbix HA는 확실히 기다려집니다. 우리는 Zabbix 5.0 LTS에서 뭔가를 볼 수 있기를 정말로 희망하지만 Zabbix 2019 로드맵이 완전히 확정되는 5.0년 XNUMX월에 상황은 더 명확해질 것입니다.

8. 왜 미디어 유형을 기본적으로 선택하는 것이 그렇게 좋지 않습니까? Slack, 텔레그램 등을 추가할 계획이 있나요? Jabber를 사용하는 사람이 있나요?

Zabbix 4.4에서는 Jabber가 제거되었지만 Webhooks가 추가되었습니다. 미디어 유형에 관해서는 시스템에서 특정 애플리케이션을 만들고 싶지 않고 표준 메시징 도구를 만들고 싶습니다. 많은 유사한 채팅이나 데스크 서비스에 HTTP를 통한 API가 있다는 것은 비밀이 아닙니다. 따라서 올해 4.4가 출시되면 상황이 바뀔 것입니다.

Zabbix에 웹후크가 등장하면 가까운 시일 내에 가장 널리 사용되는 모든 통합 기능을 즉시 사용할 수 있습니다. 이 경우 통합은 단순한 단방향 알림이 아닌 양방향으로 이루어집니다. 그리고 우리가 얻을 수 없는 미디어 유형은 우리 커뮤니티에서 수행됩니다. 이제 전체 미디어 유형을 구성 파일로 내보내고 share.zabbix.com 또는 github에 게시할 수 있기 때문입니다. 그리고 다른 사용자는 이 통합 사용을 시작하기 위해 파일을 가져오기만 하면 됩니다. 이 경우 추가 스크립트를 설치할 필요가 없습니다!

9. 가상 머신 검색 방향이 발전하지 않는 이유는 무엇입니까? vmware만 있습니다. 많은 사람들이 ec2, openstack과의 통합을 기다리고 있습니다.

아니요, 방향이 발전하고 있습니다. 예를 들어 4.4에서는 데이터 저장소 검색이 vm.datastore.discovery 키를 통해 나타났습니다. 4.4에서는 매우 멋진 wmi.getall 키도 나타났습니다. 이를 통해 perf_counter_en 키와 함께 우수한 Hyper-V 모니터링이 가능할 것으로 기대합니다. Zabbix 5.0에서는 이 방향으로 또 다른 중요한 변화가 있을 것입니다.

10. 주어진 모든 것을 빼앗아가는 템플릿을 버리고 프로메테우스처럼 할 생각은 해본 적 있나요?

Prometheus는 모든 측정항목을 자동으로 가져오므로 편리합니다. 그리고 템플릿은 단순한 측정항목 집합이 아니라 특정 유형의 리소스나 서비스를 모니터링하는 데 필요한 모든 일반 구성을 포함하는 "컨테이너"입니다. 여기에는 이미 중요한 트리거, 그래프, 탐지 규칙 세트가 있으며, 사용자가 수집되는 항목, 검사 중인 임계값 및 이유를 이해하는 데 도움이 되는 측정항목 및 임계값에 대한 설명이 있습니다. 동시에 템플릿은 다른 사용자와 쉽게 공유할 수 있으며 시스템 전문가가 아니더라도 시스템을 효과적으로 모니터링할 수 있습니다.

11. 기본적으로 측정항목이 그렇게 적은 이유는 무엇입니까? 이는 또한 작동 관점에서 설정을 크게 복잡하게 만듭니다.

기본적으로 이미 만들어진 템플릿을 의미한다면 현재 우리는 템플릿을 확장하고 개선하기 위해 노력하고 있습니다. Zabbix 4.4에는 새롭고 향상된 세트와 더 나은 기능이 포함되어 있습니다.

Zabbix의 경우 share.zabbix.com에서 거의 모든 시스템에 대해 미리 만들어진 템플릿을 언제든지 찾을 수 있습니다. 그러나 우리는 기본 템플릿을 직접 만들어 다른 사람들에게 모범을 보이고 사용자가 일부 MySQL용 템플릿을 다시 작성하지 않아도 되도록 하기로 결정했습니다. 따라서 이제 Zabbix에는 각 버전마다 더 많은 공식 템플릿만 있습니다.

12. 호스트에 연결되지 않고 예를 들어 레이블을 기반으로 하는 트리거를 구축하는 것이 언제 가능합니까? 예를 들어, n개의 서로 다른 지점에서 사이트를 모니터링하고, 2개 이상의 지점에서 사이트에 액세스할 수 없을 때 실행되는 간단한 트리거를 원합니다.

실제로 이러한 기능은 클라이언트 중 하나를 위해 작성된 Zabbix에서 수년 동안 사용할 수 있었습니다. 클라이언트 - ICANN. 예를 들어 집계된 항목을 통해 또는 Zabbix API를 사용하여 유사한 검사를 수행할 수도 있습니다. 우리는 현재 그러한 수표 생성을 단순화하기 위해 적극적으로 노력하고 있습니다.

PS: Slurms 중 하나에서 Zabbix 개발자는 Prometheus가 아닌 Zabbix를 사용하여 Kubernetes 클러스터를 모니터링하기 위해 제품에서 보고 싶은 것이 무엇인지 물었습니다.

개발자가 중간에 고객을 만나고 그들 자신에게만 국한되지 않는 것은 좋은 일입니다. 이제 우리는 진심 어린 관심을 가지고 각 릴리스를 맞이하고 있습니다. 좋은 소식은 우리가 이야기했던 점점 더 많은 기능이 구체화되고 있다는 것입니다.

개발자가 자신에게만 국한되지 않고 고객의 요구에 관심을 갖는 한 제품은 살아 있고 발전합니다. 우리는 새로운 Zabbix 릴리스를 계속 지켜볼 것입니다.

PPS: 몇 달 안에 온라인 모니터링 강좌를 개설할 예정입니다. 관심있으신 분들은 공지를 놓치지 않도록 구독해주세요. 그 동안 우리는 다음을 수행할 수 있습니다. Kubernetes의 Slurm.

출처 : habr.com