모니터링이 죽었나요? — 긴 라이브 모니터링

2008년부터 우리 회사는 주로 인프라 관리 및 웹 프로젝트에 대한 400시간 기술 지원에 종사해 왔습니다. 우리 회사는 15명 이상의 고객을 보유하고 있으며 이는 러시아 전자 상거래의 약 15%에 해당합니다. 따라서 매우 다양한 아키텍처가 지원됩니다. 무언가가 떨어지면 우리는 XNUMX분 이내에 그것을 고쳐야 할 의무가 있습니다. 하지만 사고가 발생했다는 사실을 이해하려면 프로젝트를 모니터링하고 사고에 대응해야 합니다. 어떻게 해야 하나요?

적절한 모니터링 시스템을 구성하는 데 문제가 있다고 생각합니다. 문제가 없었다면 내 연설은 "Prometheus + Grafana 및 플러그인 1, 2, 3을 설치하십시오."라는 하나의 주제로 구성되었을 것입니다. 불행히도 더 이상 그런 식으로 작동하지 않습니다. 그리고 가장 큰 문제는 모든 사람들이 소프트웨어 구성 요소 측면에서 2008년에 존재했던 것을 계속해서 믿고 있다는 것입니다.

모니터링 시스템의 구성과 관련하여 감히 말씀드리자면... 유능한 모니터링 기능을 갖춘 프로젝트는 존재하지 않습니다. 그리고 상황이 너무 나빠서 무언가가 떨어지면 눈에 띄지 않게 될 위험이 있습니다. 결국 모든 사람은 "모든 것이 모니터링됩니다"라고 확신합니다.
아마도 모든 것이 모니터링되고 있을 것입니다. 하지만 어떻게?

우리 모두는 다음과 같은 이야기를 접했습니다. 특정 개발팀, 특정 관리자가 작업 중이고 개발팀이 그들에게 와서 "우리는 출시되었습니다. 이제 모니터링합니다."라고 말합니다. 무엇을 모니터링합니까? 어떻게 작동하나요?

좋아요. 우리는 구식 방식으로 모니터링합니다. 그리고 그것은 이미 변화하고 있으며 서비스 A를 모니터링하고 서비스 B가 되어 서비스 C와 상호 작용하는 것으로 나타났습니다. 그러나 개발 팀은 "소프트웨어를 설치하면 모든 것을 모니터링해야 합니다!"라고 말합니다.

그럼 무엇이 바뀌었나요? - 모든 게 바뀌었다!

2008년 모든 것이 괜찮습니다

두 명의 개발자, 하나의 서버, 하나의 데이터베이스 서버가 있습니다. 모든 것이 여기에서 시작됩니다. 몇 가지 정보가 있으며 zabbix, Nagios, cacti를 설치합니다. 그런 다음 CPU, 디스크 작동 및 디스크 공간에 대한 명확한 경고를 설정합니다. 또한 사이트가 응답하고 주문이 데이터베이스에 도착하는지 확인하기 위해 몇 가지 수동 검사를 수행합니다. 그리고 그게 전부입니다. 우리는 어느 정도 보호받고 있습니다.

관리자가 모니터링을 제공하기 위해 수행한 작업량을 비교하면 98%가 자동으로 수행되었습니다. 모니터링을 수행하는 사람은 Zabbix 설치 방법, 구성 방법 및 경고 구성 방법을 이해해야 합니다. 2% - 외부 확인의 경우: 사이트가 데이터베이스에 응답하고 요청하는지, 새 주문이 도착했는지 확인합니다.

2010 부담이 커지고 있어요

우리는 검색 엔진을 추가하여 웹을 확장하기 시작했습니다. 우리는 제품 카탈로그에 모든 제품이 포함되어 있는지 확인하려고 합니다. 그리고 그 제품 검색이 작동합니다. 데이터베이스가 작동 중인지, 주문이 이루어지고 있는지, 사이트가 외부적으로 응답하고 두 서버에서 응답하는지, 다른 서버로 리밸런싱하는 동안 사용자가 사이트에서 쫓겨나지 않는지 등등. 더 많은 엔터티가 있습니다.

더욱이, 인프라와 관련된 실체는 여전히 관리자의 머리에서 가장 큰 실체로 남아 있습니다. 내 머릿속에는 모니터링을 하는 사람이 zabbix를 설치하고 구성할 수 있는 사람이라는 생각이 아직도 남아 있습니다.

그러나 동시에 외부 검사 수행, 검색 인덱서 쿼리 스크립트 세트 생성, 인덱싱 프로세스 중에 검색 변경 사항을 확인하는 스크립트 세트, 상품이 다음으로 전송되는지 확인하는 스크립트 세트에 대한 작업이 나타납니다. 배달 서비스 등 등등.

참고: 저는 "스크립트 세트"를 3번 썼습니다. 즉, 모니터링을 담당하는 사람은 더 이상 단순히 zabbix를 설치하는 사람이 아닙니다. 코딩을 시작하는 사람입니다. 하지만 아직까지 팀의 마음에는 변한 것이 없습니다.

그러나 세상은 변화하고 있으며 점점 더 복잡해지고 있습니다. 가상화 계층과 여러 가지 새로운 시스템이 추가되었습니다. 그들은 서로 상호 작용하기 시작합니다. 누가 "마이크로서비스 냄새가 난다"고 말했나요? 그러나 각 서비스는 여전히 개별적으로 웹사이트처럼 보입니다. 우리는 그것이 필요한 정보를 제공하고 스스로 작동한다는 것을 이해할 수 있습니다. 그리고 당신이 5-7-10년 동안 개발된 프로젝트에 지속적으로 참여하는 관리자라면 이 지식이 축적됩니다. 새로운 수준이 나타나고, 깨닫고, 또 다른 수준이 나타나며, 깨닫습니다...

하지만 10년 동안 프로젝트에 동행하는 사람은 거의 없습니다.

모니터링맨의 이력서

20명의 개발자를 즉시 ​​고용하고 15개의 마이크로서비스를 작성한 새로운 스타트업에 입사했는데 관리자가 다음과 같은 지시를 받았다고 가정해 보겠습니다. “CI/CD를 구축하세요. 제발." CI/CD를 구축했는데 갑자기 다음과 같은 말을 듣게 됩니다. “애플리케이션이 어떻게 작동하는지 이해하지 못한 채 “큐브”에서 프로덕션 작업을 하는 것은 어렵습니다. 동일한 "큐브"에 샌드박스를 만들어 보세요.
이 큐브에 샌드박스를 만듭니다. 그들은 즉시 다음과 같이 말합니다. "우리는 프로덕션에서 매일 업데이트되는 스테이지 데이터베이스를 원합니다. 그래야 데이터베이스에서 작동하지만 동시에 프로덕션 데이터베이스를 망치지 않는다는 것을 이해할 수 있기 때문입니다."

당신은 이 모든 것 속에 살고 있습니다. 발매까지 2주 남았는데, "이제 모니터링 하자..."라고 하더라고요. 클러스터 인프라 모니터링, 마이크로서비스 아키텍처 모니터링, 외부 서비스 작업 모니터링...

그리고 제 동료들은 일반적인 계획을 머릿속에서 꺼내 이렇게 말합니다. “여기서는 모든 것이 명확합니다! 이 모든 것을 모니터링할 프로그램을 설치하세요.” 예, 예: Prometheus + Grafana + 플러그인.
그리고 그들은 “XNUMX주 동안 모든 것이 안전한지 확인하세요”라고 덧붙입니다.

우리가 보는 많은 프로젝트에서는 모니터링을 위해 한 사람이 할당됩니다. 2주 동안 모니터링을 할 사람을 고용하고 그 사람을 위해 이력서를 작성한다고 가정해 보겠습니다. 지금까지 우리가 말한 모든 것을 고려할 때 이 사람은 어떤 기술을 가져야 합니까?

• 그는 철 기반 시설의 운영에 대한 모니터링과 세부 사항을 이해해야 합니다.
• 그는 Kubernetes 모니터링의 세부 사항을 이해해야 합니다(모든 사람이 "큐브"로 이동하기를 원합니다. 모든 것을 추상화하고 관리자가 나머지를 처리하기 때문에 숨길 수 있기 때문입니다). 자체, 인프라 및 애플리케이션 모니터링 방법을 이해합니다. 내부에.
• 그는 서비스가 특별한 방식으로 서로 통신한다는 것을 이해하고 서비스가 서로 상호 작용하는 방식을 구체적으로 알아야 합니다. 다른 방법이 없기 때문에 일부 서비스가 동기적으로 통신하는 프로젝트를 보는 것이 가능합니다. 예를 들어 백엔드는 REST를 통해, gRPC를 통해 카탈로그 서비스로 이동하고 제품 목록을 수신하여 다시 반환합니다. 여기서 기다릴 수 없습니다. 그리고 다른 서비스에서는 비동기적으로 작동합니다. 주문을 배송업체로 옮기고, 편지를 보내는 등의 작업을 수행합니다.
  당신은 아마도 이미 이 모든 것에서 수영을 했을 것입니다. 그리고 이를 모니터링해야 하는 관리자는 더욱 혼란스러워졌습니다.
• 작업이 점점 더 많아짐에 따라 그는 올바르게 계획하고 계획할 수 있어야 합니다.
• 따라서 서비스를 구체적으로 모니터링하는 방법을 이해하려면 생성된 서비스에서 전략을 수립해야 합니다. 그는 프로젝트의 아키텍처와 개발에 대한 이해 + 개발에 사용되는 기술에 대한 이해가 필요합니다.

완전히 일반적인 경우를 기억해 봅시다. 일부 서비스는 PHP에 있고, 일부 서비스는 Go에 있고, 일부 서비스는 JS에 있습니다. 그들은 어떻게든 서로 협력합니다. 여기서 "마이크로서비스"라는 용어가 유래되었습니다. 개발자가 프로젝트 전체를 이해할 수 없는 개별 시스템이 너무 많기 때문입니다. 팀의 한 부분은 자체적으로 작동하고 나머지 시스템이 어떻게 작동하는지 알지 못하는 서비스를 JS로 작성합니다. 다른 부분은 Python으로 서비스를 작성하고 다른 서비스의 작동 방식을 방해하지 않으며 자체 영역에 격리되어 있습니다. 세 번째는 PHP 등으로 서비스를 작성하는 것입니다.
이 20명 모두가 15개의 서비스로 나누어져 있으며, 이 모든 것을 이해해야 하는 관리자는 단 한 명입니다. 멈추다! 15명의 사람이 전체 시스템을 이해할 수 없기 때문에 시스템을 20개의 마이크로서비스로 나누었습니다.

하지만 어떻게든 모니터링이 필요합니다...

결과는 무엇입니까? 결과적으로 전체 개발자 팀이 이해할 수 없는 모든 것을 생각해내는 사람이 한 명 있으며, 동시에 그는 위에서 지적한 하드웨어 인프라, Kubernetes 인프라 등을 알고 수행할 수 있어야 합니다.

무슨 말을 해야 할까요... 휴스턴, 문제가 생겼어요.

최신 소프트웨어 프로젝트 모니터링은 그 자체로 소프트웨어 프로젝트입니다.

모니터링이 소프트웨어라는 잘못된 믿음에서 우리는 기적에 대한 믿음을 갖게 됩니다. 그러나 아쉽게도 기적은 일어나지 않습니다. zabbix를 설치하고 모든 것이 작동할 것이라고 기대할 수는 없습니다. Grafana를 설치하고 모든 것이 괜찮기를 바라는 것은 의미가 없습니다. 대부분의 시간은 서비스 운영 및 상호 작용에 대한 점검을 구성하고 외부 시스템의 작동 방식을 확인하는 데 소요됩니다. 실제로 90%의 시간은 스크립트 작성이 아닌 소프트웨어 개발에 사용됩니다. 그리고 이는 프로젝트 작업을 이해하는 팀에 의해 처리되어야 합니다.
이런 상황에서 한 사람이라도 모니터링에 투입된다면 재앙이 일어날 것입니다. 이는 어디에서나 일어나는 일입니다.

예를 들어 Kafka를 통해 서로 통신하는 여러 서비스가 있습니다. 주문이 도착했고 주문에 대한 메시지를 Kafka에 보냈습니다. 주문에 대한 정보를 듣고 상품을 배송해 주는 서비스가 있습니다. 주문에 대한 정보를 듣고, 사용자에게 문자를 보내는 서비스가 있습니다. 그러다가 더 많은 서비스가 나타나고 우리는 혼란스러워지기 시작합니다.

그리고 출시까지 얼마 남지 않은 단계에서 관리자나 개발자에게도 이 내용을 전달한다면, 그 사람은 이 프로토콜 전체를 이해해야 할 것입니다. 저것들. 이 정도 규모의 프로젝트는 상당한 시간이 소요되므로 시스템 개발 시 이를 고려해야 합니다.
그러나 특히 스타트업에서는 모니터링이 나중으로 연기되는 경우가 많습니다. “이제 우리는 개념 증명(Proof of Concept)을 만들고 이를 시작하고 실패하게 놔둘 것입니다. 우리는 희생할 준비가 되어 있습니다. 그러면 우리는 그것을 모두 모니터링할 것입니다.” 프로젝트가 돈을 벌기 시작하면(또는 만약) 사업이 더 많은 기능을 추가하기를 원합니다. 왜냐하면 프로젝트가 작동하기 시작했기 때문에 더 많은 기능을 출시해야 하기 때문입니다! 그리고 이전의 모든 것을 먼저 모니터링해야 하는 시점에 도달했습니다. 이는 1%의 시간이 아니라 훨씬 더 많은 시간이 소요됩니다. 그런데 모니터링을 위해서는 개발자가 필요하며 개발자가 새로운 기능을 작업하도록 하는 것이 더 쉽습니다. 결과적으로 새로운 기능이 작성되고 모든 것이 엉망이 되며 끝없는 교착 상태에 빠지게 됩니다.

그렇다면 처음부터 프로젝트를 모니터링하는 방법과 모니터링해야 하는 프로젝트를 받았지만 어디서부터 시작해야 할지 모르는 경우 어떻게 해야 할까요?

먼저, 계획을 세워야 합니다.

서정적 여담: 인프라 모니터링으로 시작하는 경우가 많습니다. 예를 들어 Kubernetes가 있습니다. Grafana와 함께 Prometheus를 설치하고 "큐브"를 모니터링하기 위한 플러그인을 설치하는 것부터 시작하겠습니다. 개발자뿐만 아니라 관리자도 "우리는 이 플러그인을 설치하겠지만 플러그인은 설치 방법을 알고 있을 것입니다."라는 불행한 습관을 갖고 있습니다. 사람들은 중요한 일부터 시작하기보다는 간단하고 간단한 일부터 시작하는 것을 좋아합니다. 인프라 모니터링도 쉽습니다.

먼저 무엇을 어떻게 모니터링할지 결정한 다음 도구를 선택하세요. 다른 사람들이 당신을 대신해 생각할 수 없기 때문입니다. 그리고 그래야 할까요? 다른 사람들은 범용 시스템에 대해 스스로 생각했거나 이 플러그인이 작성되었을 때 전혀 생각하지 않았습니다. 그리고 이 플러그인의 사용자가 5명이라고 해서 그것이 아무 쓸모가 있다는 의미는 아닙니다. 아마도 이전에 이미 5001명이 있었다는 이유만으로 당신은 5000번째가 될 것입니다.

인프라 모니터링을 시작하고 애플리케이션의 백엔드가 응답을 중지하면 모든 사용자와 모바일 애플리케이션의 연결이 끊어집니다. 오류가 나타납니다. 그들은 당신에게 와서 “애플리케이션이 작동하지 않습니다. 여기서 무엇을 하고 계시나요?”라고 말할 것입니다. - “모니터링 중입니다.” — "애플리케이션이 작동하지 않는 것을 보지 못하면 어떻게 모니터링합니까?!"

1. 사용자의 진입점부터 정확하게 모니터링을 시작해야 한다고 생각합니다. 사용자가 애플리케이션이 작동하는 것을 보지 못한다면, 그것은 실패입니다. 그리고 모니터링 시스템은 이에 대해 먼저 경고해야 합니다.
2. 그래야만 인프라를 모니터링할 수 있습니다. 아니면 병렬로 하세요. 인프라가 있으면 더 쉽습니다. 여기서 마침내 zabbix를 설치할 수 있습니다.
3. 이제 작동하지 않는 부분을 이해하려면 애플리케이션의 루트로 이동해야 합니다.

나의 주요 아이디어는 모니터링이 개발 프로세스와 병행하여 이루어져야 한다는 것입니다. 다른 작업(CI/CD 생성, 샌드박싱, 인프라 재구성)을 위해 모니터링 팀의 주의를 분산시키면 모니터링이 지연되기 시작하고 개발을 따라잡지 못할 수도 있습니다(또는 조만간 중지해야 할 것입니다).

레벨별 모든 것

이것이 모니터링 시스템의 구성을 보는 방법입니다.

1) 적용 수준:

• 애플리케이션 비즈니스 로직 모니터링
• 서비스의 상태 지표를 모니터링합니다.
• 통합 모니터링.

2) 인프라 수준:

• 오케스트레이션 수준 모니터링;
• 시스템 소프트웨어 모니터링;
• 철분 수준 모니터링.

3) 다시 응용 프로그램 수준 - 그러나 엔지니어링 제품인 경우:

• 애플리케이션 로그 수집 및 모니터링
• APM;
• 트레이싱.

4) 경고:

• 경고 시스템의 조직;
• 의무 시스템의 조직;
• 사고 처리를 위한 "지식 기반" 및 작업 흐름을 구성합니다.

중요한 일이야: 우리는 이후가 아니라 즉시 경고를 받습니다! 모니터링을 시작하고 "어떻게든 나중에" 누가 경고를 받을지 알아낼 필요가 없습니다. 결국 모니터링의 임무는 무엇입니까? 시스템의 어느 부분에서 문제가 발생하고 있는지 파악하고 적절한 사람들에게 이에 대해 알리는 것입니다. 이것을 끝까지 놔두면 “아무것도 안 돼”라고 외치는 것만으로도 올바른 사람들은 뭔가 잘못되고 있다는 것을 알게 될 것입니다.

애플리케이션 계층 - 비즈니스 로직 모니터링

여기서는 애플리케이션이 사용자에게 작동하는지 확인하는 방법에 대해 설명합니다.

이 수준은 개발 단계에서 수행되어야 합니다. 예를 들어 조건부 Prometheus가 있습니다. 확인을 수행하는 서버로 이동하여 엔드포인트를 가져오고 엔드포인트가 API를 확인합니다.

사이트가 작동하는지 확인하기 위해 홈 페이지를 모니터링하라는 요청을 자주 받으면 프로그래머는 API가 작동하는지 확인해야 할 때마다 가져올 수 있는 핸들을 제공합니다. 그리고 현재 프로그래머들은 여전히 ​​/api/test/helloworld를 받아 쓰고 있습니다.
모든 것이 작동하는지 확인하는 유일한 방법은 무엇입니까? - 아니요!

• 이러한 검사를 만드는 것은 기본적으로 개발자의 작업입니다. 단위 테스트는 코드를 작성하는 프로그래머가 작성해야 합니다. 왜냐하면 관리자에게 "야, 여기 25개 기능 모두에 대한 API 프로토콜 목록이 있으니 모두 모니터링해줘!"라고 유출하면 되니까요. -아무것도 잘되지 않을 것입니다.
• "hello world"를 인쇄하면 API가 작동해야 하는지, 작동하는지 아무도 알 수 없습니다. 모든 API 변경은 검사 변경으로 이어져야 합니다.
• 이미 그러한 문제가 있는 경우 기능을 중지하고 이러한 검사를 작성할 개발자를 할당하거나 손실을 감수하고 검사된 항목이 없으며 실패할 것임을 수락하십시오.

기술적인 팁:

• 검사를 정리하려면 외부 서버를 구성해야 합니다. 프로젝트가 외부 세계에 액세스할 수 있는지 확인해야 합니다.
• 개별 엔드포인트뿐만 아니라 전체 API 프로토콜에 대한 검사를 구성합니다.
• 테스트 결과로 prometheus-endpoint를 생성합니다.

애플리케이션 계층 - 상태 지표 모니터링

이제 우리는 서비스의 외부 상태 지표에 대해 이야기하고 있습니다.

우리는 외부 모니터링 시스템에서 호출하는 외부 검사를 사용하여 애플리케이션의 모든 "핸들"을 모니터링하기로 결정했습니다. 그러나 이것은 사용자가 "보는" "핸들"입니다. 우리는 서비스 자체가 제대로 작동하는지 확인하고 싶습니다. 여기에 더 좋은 이야기가 있습니다. K8에는 상태 확인 기능이 있으므로 적어도 "큐브" 자체에서는 서비스가 작동하고 있음을 확신할 수 있습니다. 하지만 내가 본 수표 중 절반은 "hello world"라는 동일한 인쇄였습니다. 저것들. 그래서 그는 배치 후 한 번 당겼고 모든 것이 괜찮다고 대답했습니다. 그게 전부입니다. 그리고 서비스가 자체 API를 제공하는 경우 동일한 API에 대한 수많은 진입점이 있으며, 서비스가 작동하는지 알고 싶기 때문에 모니터링도 필요합니다. 그리고 우리는 이미 내부적으로 이를 모니터링하고 있습니다.

이를 기술적으로 올바르게 구현하는 방법: 각 서비스는 현재 성능에 대한 엔드포인트를 노출하고 Grafana(또는 다른 애플리케이션)의 그래프에서 모든 서비스의 상태를 확인합니다.

• 모든 API 변경은 검사 변경으로 이어져야 합니다.
• 상태 지표를 사용하여 즉시 새로운 서비스를 생성하세요.
• 관리자는 개발자에게 와서 "내가 모든 것을 이해할 수 있도록 몇 가지 기능을 추가하고 이에 대한 정보를 내 모니터링 시스템에 추가하세요"라고 요청할 수 있습니다. 하지만 개발자들은 대개 “출시 XNUMX주 전에는 아무 것도 추가하지 않을 것입니다.”라고 대답합니다.
  개발 관리자에게 그러한 손실이 있을 것임을 알리고 개발 관리자의 경영진에게도 알리십시오. 모든 것이 무너져도 누군가는 여전히 전화를 걸어 "지속적으로 떨어지는 서비스"(c)를 모니터링하도록 요구할 것이기 때문입니다.
• 그건 그렇고, Grafana용 플러그인을 작성하도록 개발자를 할당하십시오. 이는 관리자에게 좋은 도움이 될 것입니다.

애플리케이션 계층 - 통합 모니터링

통합 모니터링은 비즈니스에 중요한 시스템 간의 통신 모니터링에 중점을 둡니다.

예를 들어, 서로 통신하는 서비스가 15개 있습니다. 이들은 더 이상 별도의 사이트가 아닙니다. 저것들. 우리는 서비스를 자체적으로 끌어오고 /helloworld를 가져오고 서비스가 실행 중인지 이해할 수 없습니다. 주문 웹 서비스는 주문에 대한 정보를 버스에서 버스로 보내야 하기 때문에 창고 서비스는 이 메시지를 수신하고 추가 작업을 수행해야 합니다. 그리고 이메일 배포 서비스는 이를 어떻게든 추가로 처리해야 합니다.

따라서 각 개별 서비스를 찔러보면 그것이 모두 작동한다는 것을 이해할 수 없습니다. 왜냐하면 우리에게는 모든 것이 소통하고 상호 작용하는 특정 버스가 있기 때문입니다.
따라서 이 단계는 다른 서비스와의 상호 작용을 위해 서비스를 테스트하는 단계를 표시해야 합니다. 메시지 브로커를 모니터링하여 통신 모니터링을 구성하는 것은 불가능합니다. 데이터를 발행하는 서비스와 이를 받는 서비스가 있다면 브로커를 모니터링할 때 좌우로 날아다니는 데이터만 보게 됩니다. 우리가 이 데이터의 상호 작용을 내부적으로 모니터링할 수 있었다고 해도(특정 생산자가 데이터를 게시하고, 누군가가 이를 읽고, 이 흐름은 계속해서 Kafka로 이동합니다.) 한 서비스가 한 버전으로 메시지를 보낸 경우에는 여전히 정보를 제공하지 않습니다. 하지만 다른 서비스에서는 이 버전을 예상하지 못해 건너뛰었습니다. 서비스에서 모든 것이 작동하고 있음을 알려주므로 이에 대해 알 수 없습니다.

내가 추천하는 것:

• 동기 통신의 경우: 엔드포인트는 관련 서비스에 요청합니다. 저것들. 우리는 이 끝점을 선택하고 서비스 내부에 스크립트를 가져옵니다. 스크립트는 모든 지점으로 이동하여 "거기서 끌어당길 수 있습니다. 저쪽으로 끌어당길 수 있습니다..."라고 말합니다.
• 비동기 통신의 경우: 수신 메시지 - 엔드포인트는 버스에서 테스트 메시지를 확인하고 처리 상태를 표시합니다.
• 비동기 통신의 경우: 나가는 메시지 - 엔드포인트가 테스트 메시지를 버스로 보냅니다.

일반적으로 발생하는 것처럼 버스에 데이터를 전송하는 서비스가 있습니다. 우리는 이 서비스에 와서 통합 상태에 대해 알려달라고 요청합니다. 그리고 서비스가 다른 곳(WebApp)에서 메시지를 생성해야 하는 경우 이 테스트 메시지를 생성합니다. 그리고 OrderProcessing 측에서 서비스를 실행하면 먼저 독립적으로 게시할 수 있는 내용을 게시하고 종속적인 내용이 있는 경우 버스에서 일련의 테스트 메시지를 읽고 이를 처리할 수 있음을 이해하고 보고합니다. , 필요한 경우 추가로 게시하고 이에 대해 그는 말합니다. 모든 것이 괜찮습니다. 나는 살아 있습니다.

우리는 "전투 데이터에서 이것을 어떻게 테스트할 수 있습니까?"라는 질문을 자주 듣습니다. 예를 들어, 동일한 주문 서비스에 대해 이야기하고 있습니다. 명령은 상품이 상쇄된 창고로 메시지를 보냅니다. "내 상품이 상각될 것입니다!" 때문에 전투 데이터에서는 이를 테스트할 수 없습니다. 해결책: 처음부터 전체 테스트를 계획하십시오. 또한 모의를 만드는 단위 테스트도 있습니다. 따라서 비즈니스 운영에 해를 끼치지 않는 커뮤니케이션 채널이 있는 더 깊은 수준에서 수행하십시오.

인프라 계층

인프라 모니터링은 오랫동안 자체 모니터링으로 간주되어 왔습니다.

• 인프라 모니터링은 별도의 프로세스로 시작할 수 있고 시작해야 합니다.
• 정말로 원하더라도 실행 중인 프로젝트에서 인프라 모니터링을 시작해서는 안 됩니다. 이는 모든 DevOps에게 고통입니다. "먼저 클러스터를 모니터링하고 인프라를 모니터링하겠습니다." – 예: 첫째, 아래에 있는 내용을 모니터링하지만 애플리케이션에 들어가지는 않습니다. 애플리케이션은 DevOps에게는 이해할 수 없는 것이기 때문입니다. 그것이 그에게 유출되었는데 그는 그것이 어떻게 작동하는지 이해하지 못합니다. 그러나 그는 인프라를 이해하고 그것부터 시작합니다. 하지만 아닙니다. 항상 애플리케이션을 먼저 모니터링해야 합니다.
• 경고 수를 너무 많이 늘리지 마십시오. 최신 시스템의 복잡성을 고려하면 경고가 끊임없이 발생하므로 어떻게든 이러한 경고를 처리해야 합니다. 그리고 당직자는 수백 개의 다음 알림을 살펴본 후 "나는 그것에 대해 생각하고 싶지 않습니다."라고 결정할 것입니다. 경고는 중요한 사항에 대해서만 알려야 합니다.

사업부로서의 적용 수준

요점 :

• 고라니. 이것이 업계 표준입니다. 어떤 이유로 로그를 집계하지 않는 경우 즉시 수집을 시작하세요.
• APM. 애플리케이션 모니터링(NewRelic, BlackFire, Datadog)을 신속하게 종료하는 방법으로 외부 APM. 적어도 무슨 일이 일어나고 있는지 이해하기 위해 이것을 일시적으로 설치할 수 있습니다.
• 트레이싱. 수십 개의 마이크로서비스에서는 요청이 더 이상 자체적으로 유지되지 않기 때문에 모든 것을 추적해야 합니다. 나중에 추가하는 것은 매우 어려우므로 개발 중에 즉시 추적을 예약하는 것이 좋습니다. 이는 개발자의 작업이자 유용성입니다. 아직 구현하지 않았다면 구현해 보세요! Jaeger/Zipkin 참조

경고

• 알림 시스템 구성: 여러 가지를 모니터링하는 경우 알림 전송을 위한 통합 시스템이 있어야 합니다. Grafana에서 가능합니다. 서양에서는 모두가 PagerDuty를 사용합니다. 경고는 명확해야 합니다(예: 어디서 왔는지...). 그리고 알림이 수신되도록 제어하는 ​​것이 좋습니다.
• 근무 시스템 구성: 모든 사람에게 경고를 보내서는 안 됩니다(모든 사람이 군중 속에서 반응하거나 아무도 반응하지 않음). 개발자도 대기해야 합니다. 책임 영역을 정의하고 명확한 지침을 작성하고 월요일과 수요일에 정확히 누구에게 전화할지, 화요일과 금요일에 누구에게 전화할지 기록해야 합니다. 큰 문제가 발생하면 그들은 당신을 깨우거나 방해하는 것을 두려워할 것입니다. 사람들은 일반적으로 특히 밤에 다른 사람에게 전화해서 깨우는 것을 좋아하지 않습니다. 그리고 도움을 요청하는 것이 무능함을 나타내는 것이 아니라는 점을 설명하고(“도움을 요청하는 것은 내가 나쁜 일꾼이라는 뜻입니다”) 도움 요청을 장려합니다.
• 사고 처리를 위한 "지식 기반" 및 워크플로우 구성: 각 심각한 사고에 대해 사후 조사를 계획해야 하며 임시 조치로 사고를 해결하기 위한 조치를 기록해야 합니다. 그리고 반복적으로 경고하는 것은 죄악이 되는 습관을 들이십시오. 코드나 인프라 작업에서 수정해야 합니다.

기술 스택

우리의 스택이 다음과 같다고 상상해 봅시다:

• 데이터 수집 - Prometheus + Grafana;
• 로그 분석 - ELK;
• APM 또는 추적용 - Jaeger(Zipkin).

옵션 선택은 중요하지 않습니다. 처음에 시스템을 모니터링하는 방법을 이해하고 계획을 작성했다면 요구 사항에 맞는 도구를 선택하기 시작합니다. 문제는 처음에 무엇을 모니터링하기로 선택했는지입니다. 처음에 선택한 도구가 요구 사항에 전혀 맞지 않을 수도 있기 때문입니다.

최근 어디에서나 볼 수 있는 몇 가지 기술적 사항은 다음과 같습니다.

Prometheus가 Kubernetes 내부로 밀려나고 있습니다. 누가 이걸 생각해냈나요?! 클러스터가 충돌하면 어떻게 하시겠습니까? 내부에 복잡한 클러스터가 있는 경우 클러스터 내부와 외부에 모니터링 시스템이 있어야 하며 클러스터 내부에서 데이터를 수집해야 합니다.

클러스터 내부에서는 로그와 기타 모든 것을 수집합니다. 하지만 모니터링 시스템은 외부에 있어야 합니다. 내부적으로 Promtheus가 설치된 클러스터에는 사이트 운영에 대한 외부 점검을 수행하는 시스템도 있는 경우가 많습니다. 외부 세계와의 연결이 끊어지고 애플리케이션이 작동하지 않으면 어떻게 되나요? 내부의 모든 것이 괜찮은 것으로 밝혀졌지만 사용자의 작업이 더 쉬워지는 것은 아닙니다.

조사 결과

• 모니터링 개발은 유틸리티 설치가 아니라 소프트웨어 제품 개발입니다. 오늘날 모니터링의 98%는 코딩입니다. 서비스 코딩, 외부 검사 코딩, 외부 서비스 검사, 그게 전부입니다.
• 모니터링에 개발자의 시간을 낭비하지 마십시오. 작업의 최대 30%가 소요될 수 있지만 그만한 가치가 있습니다.
• Devops는 모니터링할 수 없다고 걱정하지 마세요. 어떤 것들은 완전히 다른 사고 방식이기 때문입니다. 당신은 프로그래머가 아니었고 모니터링 작업이 바로 그들의 직업이었습니다.
• 프로젝트가 이미 실행 중이고 모니터링되지 않는 경우(그리고 귀하가 관리자인 경우) 모니터링을 위한 리소스를 할당하십시오.
• 제품이 이미 생산 중이고 "모니터링을 설정"하라는 지시를 받은 데브옵스인 경우, 제가 이 모든 내용을 작성한 내용을 경영진에게 설명하십시오.

이것은 Saint Highload++ 컨퍼런스 보고서의 확장 버전입니다.

그것에 대한 내 아이디어와 생각 및 관련 주제에 관심이 있다면 여기에서 할 수 있습니다. 채널 읽어봐 ????

출처 : habr.com