🥇New Relic만으로는 안 됩니다: Datadog 및 Atatus 살펴보기

SRE/DevOps 엔지니어의 환경에서는 어느 날 클라이언트(또는 모니터링 시스템)가 나타나 "모든 것이 손실되었습니다"라고 보고하는 것은 누구도 놀랄 일이 아닙니다. 사이트가 작동하지 않고, 결제가 이루어지지 않으며, 삶이 쇠퇴하고 있습니다. ... 그러한 상황에서 아무리 도움을 주고 싶어도 간단하고 이해하기 쉬운 도구 없이는 이를 수행하는 것이 매우 어려울 수 있습니다. 종종 문제는 애플리케이션 코드 자체에 숨겨져 있으므로 현지화하기만 하면 됩니다.

그리고 슬픔과 기쁨 속에서…

우리는 New Relic과 오랫동안 깊은 사랑에 빠졌습니다. 이는 애플리케이션 성능을 모니터링하기 위한 탁월한 도구였으며, 에이전트를 사용하여 마이크로서비스 아키텍처 등을 계측할 수 있는 도구이기도 합니다. 서비스 가격 정책이 변경되지 않았다면 모든 것이 훌륭했을 것입니다. 비용 2013 년에 3배 이상 성장. 또한 지난해부터 체험 계정을 얻으려면 개인 관리자와의 커뮤니케이션이 필요해 잠재 고객에게 제품을 선보이기 어렵게 됐다.

일반적인 상황: New Relic은 "영구적으로" 필요하지 않으며 문제가 시작되는 순간에만 기억합니다. 그러나 여전히 정기적으로 비용을 지불해야 하며(서버당 월 140달러) 자동으로 확장되는 클라우드 인프라에서는 합계가 상당히 커집니다. 종량제 옵션이 있지만 New Relic을 활성화하려면 애플리케이션을 다시 시작해야 하며, 이로 인해 애플리케이션이 시작된 문제 상황이 손실될 수 있습니다. 얼마 전 뉴렐릭에서는 새로운 요금제를 선보였습니다. 베이직 라인, - 언뜻 보면 Professional에 대한 합리적인 대안처럼 보이지만 자세히 살펴보면 몇 가지 중요한 기능이 누락된 것으로 나타났습니다(특히 주요 거래, 교차 애플리케이션 추적, 분산 추적).

결과적으로 우리는 더 저렴한 대안을 찾기 시작했고 Datadog과 Atatus라는 두 가지 서비스를 선택했습니다. 왜 그들에게?

경쟁사 소개

시장에 다른 솔루션이 있다는 점을 바로 말씀드리겠습니다. 우리는 오픈 소스 옵션도 고려했지만 모든 클라이언트가 자체 호스팅 솔루션을 호스팅할 수 있는 여유 용량을 갖고 있는 것은 아닙니다... - 또한 추가 유지 관리가 필요합니다. 우리가 선택한 커플은 가장 가까운 것으로 밝혀졌습니다. 우리의 필요:

PHP 애플리케이션에 대한 기본 제공 및 개발된 지원(우리 고객의 스택은 매우 다양하지만 이는 New Relic에 대한 대안을 찾는 맥락에서 확실한 리더입니다)
저렴한 비용(호스트당 월 100달러 미만)
자동 계측;
쿠버네티스와의 통합;
New Relic 인터페이스와의 유사성은 눈에 띄는 장점입니다(엔지니어들이 익숙하기 때문입니다).

따라서 초기 선택 단계에서 우리는 특히 다음과 같은 몇 가지 널리 사용되는 솔루션을 제거했습니다.

Tideways, AppDynamics 및 Dynatrace - 비용;
Stackify는 러시아 연방에서 차단되었으며 데이터가 너무 적게 표시됩니다.

기사의 나머지 부분은 문제의 솔루션을 먼저 간략하게 제시한 다음 New Relic과의 일반적인 상호 작용 및 다른 서비스에서 유사한 작업을 수행하면서 얻은 경험/인상에 대해 이야기하는 방식으로 구성되어 있습니다.

선정된 경쟁사 소개

약 새로운 유물, 아마 모두가 들어 보셨나요? 이 서비스는 10여년 전인 2008년에 개발을 시작했습니다. 우리는 2012년부터 적극적으로 사용해 왔으며 PHP, Ruby, Python 등 정말 많은 수의 애플리케이션을 통합하는 데 아무런 문제가 없었으며 C# 및 Go와의 통합 경험도 있습니다. 서비스 작성자는 애플리케이션 모니터링, 인프라, 마이크로서비스 인프라 추적, 사용자 장치용 편리한 애플리케이션 생성 등을 위한 솔루션을 보유하고 있습니다.

그러나 New Relic 에이전트는 독점 프로토콜에서 실행되며 OpenTracing을 지원하지 않습니다. 고급 계측에는 특히 New Relic에 대한 편집이 필요합니다. 마지막으로 Kubernetes 지원은 아직 실험적입니다.

2010년부터 개발 시작 데이터 도그 Kubernetes 환경에서의 사용 측면에서 보면 New Relic보다 눈에 띄게 더 흥미로워 보입니다. 특히 NGINX Ingress, 로그 수집, statsd 및 OpenTracing 프로토콜과의 통합을 지원하므로 사용자 요청이 연결되는 순간부터 완료까지 추적하고 이 요청에 대한 로그를 찾을 수 있습니다(둘 다 웹 서버 측에서) 그리고 소비자의 경우).

Datadog을 사용할 때 때때로 마이크로서비스 맵을 잘못 구축하고 일부 기술적인 단점을 발견했습니다. 예를 들어, 서비스 유형을 잘못 식별하여(Django를 캐싱 서비스로 착각) 널리 사용되는 Predis 라이브러리를 사용하는 PHP 애플리케이션에서 500 오류를 발생시켰습니다.

아타투스 - 가장 어린 악기 2014년에 서비스가 시작됐다. 마케팅 예산은 나열된 경쟁사보다 확실히 열등하며 언급이 훨씬 덜 일반적입니다. 그러나 도구 자체는 기능(APM, 브라우저 모니터링 등)뿐만 아니라 외관에서도 New Relic과 매우 유사합니다.

중요한 단점은 Node.js와 PHP만 지원한다는 것입니다. 반면에 Datadog보다 눈에 띄게 잘 구현되었습니다. 후자와 달리 Atatus에서는 애플리케이션이 코드를 수정하거나 추가 레이블을 추가할 필요가 없습니다.

New Relic으로 작업하는 방법

이제 우리가 일반적으로 New Relic을 어떻게 사용하는지 알아 보겠습니다. 해결책이 필요한 문제가 있다고 가정해 보겠습니다.

그래프로 보면 쉽게 알 수 있어요 스파이크 - 분석해보자. New Relic에서는 웹 애플리케이션에 대한 웹 트랜잭션이 즉시 선택되고, 모든 구성요소가 성능 그래프에 표시되며, 오류율, 요청률 패널이 있습니다... 가장 중요한 것은 이러한 패널에서 직접 서로 다른 패널 간에 이동할 수 있다는 것입니다. 예를 들어 MySQL을 클릭하면 데이터베이스 섹션으로 이동합니다.

고려중인 예에서 활동이 급증한 것을 볼 수 있으므로 PHP, 이 차트를 클릭하면 자동으로 다음으로 이동합니다. 거래 내역:

본질적으로 MVC 모델의 컨트롤러인 트랜잭션 목록은 이미 다음과 같이 정렬되어 있습니다. 시간이 가장 많이 소요됨, 이는 매우 편리합니다. 애플리케이션이 수행하는 작업을 즉시 확인할 수 있습니다. 다음은 New Relic이 자동으로 수집하는 긴 쿼리의 예입니다. 정렬을 전환하면 다음을 쉽게 찾을 수 있습니다.

가장 많이 로드된 애플리케이션 컨트롤러
가장 자주 요청되는 컨트롤러
컨트롤러 중 가장 느립니다.

또한 각 트랜잭션을 확장하여 코드가 실행될 때 애플리케이션이 수행한 작업을 확인할 수 있습니다.

마지막으로 애플리케이션은 긴 요청(2초 이상 걸리는 요청) 추적의 예를 저장합니다. 다음은 긴 트랜잭션에 대한 패널입니다.

두 가지 방법 모두 시간이 많이 걸리는 것을 볼 수 있으며, 동시에 요청이 실행된 시간에 해당 URI와 도메인도 표시됩니다. 이는 로그에서 요청을 찾는 데 도움이 되는 경우가 많습니다. 가다 추적 세부정보, 이러한 메소드가 호출되는 위치를 확인할 수 있습니다.

그리고에 데이터베이스 쿼리 — 애플리케이션이 실행되는 동안 실행된 데이터베이스에 대한 쿼리를 평가합니다.

이러한 지식을 바탕으로 우리는 애플리케이션 속도가 느려지는 이유를 평가하고 개발자와 협력하여 문제 해결 전략을 세울 수 있습니다. 실제로 New Relic은 항상 명확한 그림을 제공하지는 않지만 조사 벡터를 선택하는 데 도움이 됩니다.

긴 PDO::Construct 우리를 pgpoll의 이상한 기능으로 이끌었습니다.
시간이 지남에 따라 불안정 Memcache::Get 가상 머신이 잘못 구성되었다고 제안했습니다.
템플릿 처리 시간이 의심스럽게 증가하여 개체 저장소에 500개의 아바타가 있는지 확인하는 중첩 루프가 발생했습니다.
등등…

또한 코드를 실행하는 대신 외부 데이터 저장소와 관련된 항목이 메인 화면에서 커지는 경우가 있습니다. Redis 또는 PostgreSQL은 모두 탭에 숨겨져 있습니다. 데이터베이스.

거래에서 수행되는 방식과 유사하게 조사 및 정렬 쿼리에 대한 특정 기반을 선택할 수 있습니다. 요청 탭으로 이동하면 각 애플리케이션 컨트롤러에서 이 요청이 몇 번 발생하는지 확인할 수 있으며 호출 빈도도 추정할 수 있습니다. 그것은 매우 편안합니다:

탭에 유사한 데이터가 포함되어 있습니다. 외부 서비스, 객체 저장소 액세스, 센트리로 이벤트 전송 등과 같은 외부 HTTP 서비스에 대한 요청을 숨깁니다. 탭의 내용은 데이터베이스와 완전히 유사합니다.

경쟁자: 기회와 인상

이제 가장 흥미로운 점은 New Relic의 기능을 경쟁업체가 제공하는 기능과 비교하는 것입니다. 불행하게도 우리는 프로덕션 환경에서 실행되는 한 애플리케이션의 한 버전에서 세 가지 도구를 모두 테스트할 수 없었습니다. 하지만 최대한 동일한 상황/구성을 비교하려고 노력했습니다.

1. 데이터독

Datadog은 서비스 벽이 있는 패널로 우리를 맞이합니다.

이는 애플리케이션을 구성 요소/마이크로 서비스로 나누려고 시도하므로 예제 Django 애플리케이션에서는 PostgreSQL에 대한 2개의 연결을 볼 수 있습니다(defaultdb и postgres), Celery, Redis도 있습니다. Datadog을 사용하려면 MVC 원칙에 대한 최소한의 지식이 필요합니다. 즉, 사용자 요청이 일반적으로 어디에서 오는지 이해해야 합니다. 이는 일반적으로 도움이 됩니다. 서비스 지도:

그건 그렇고, New Relic에도 비슷한 것이 있습니다.

... 내 생각에 그들의 지도는 더 간단하고 명확해졌습니다. 하나의 애플리케이션의 구성 요소를 표시하지 않고(Datadog의 경우처럼 지나치게 상세하게 만들 수 있음) 특정 서비스나 마이크로서비스만 표시합니다.

Datadog으로 돌아가 보겠습니다. 서비스 맵에서 사용자 요청이 Django로 오는 것을 볼 수 있습니다. Django 서비스로 가서 마지막으로 우리가 기대했던 것을 살펴보겠습니다.

불행히도 여기에는 기본적으로 그래프가 없습니다. 웹 거래 시간, 메인 New Relic 패널에서 볼 수 있는 것과 유사합니다. 그러나 일정 대신 구성할 수 있습니다. 소요 시간(%). 으로 전환하면 충분합니다. 유형별 요청당 평균 시간...그리고 이제 익숙한 그래프가 우리를 바라보고 있습니다!

Datadog이 다른 차트를 선택한 이유는 우리에게 미스터리입니다. 또 다른 실망스러운 점은 두 경쟁업체와 달리 시스템이 사용자의 선택을 기억하지 못하기 때문에 유일한 해결책은 사용자 정의 패널을 만드는 것입니다.

하지만 저는 이러한 그래프에서 관련 서버의 메트릭으로 전환하고, 로그를 읽고, 웹 서버 핸들러(Gunicorn)의 로드를 평가하는 Datadog의 기능에 만족했습니다. 모든 것이 New Relic과 거의 동일합니다... 그리고 조금 더 있습니다(로그)!

그래프 아래에는 New Relic과 완전히 유사한 트랜잭션이 있습니다.

Datadog에서는 트랜잭션을 호출합니다. 자원. 요청 수, 평균 응답 시간 및 선택한 기간 동안 소요된 최대 시간을 기준으로 컨트롤러를 정렬할 수 있습니다.

리소스를 확장하여 New Relic에서 이미 관찰한 모든 내용을 볼 수 있습니다.

리소스에 대한 통계, 내부 호출의 일반화된 목록, 응답 코드별로 정렬할 수 있는 요청의 예가 있습니다... 그건 그렇고, 우리 엔지니어들은 이 정렬을 정말 좋아했습니다.

Datadog의 모든 예제 리소스를 열고 연구할 수 있습니다.

요청 매개변수, 각 구성요소에 소요된 시간의 요약 차트, 호출 순서를 보여주는 폭포형 차트가 표시됩니다. 폭포형 차트의 트리 보기로 전환할 수도 있습니다.

그리고 가장 흥미로운 점은 요청이 실행된 호스트의 로드를 확인하고 요청 로그를 확인하는 것입니다.

훌륭한 통합!

탭이 어디에 있는지 궁금할 것입니다. 데이터베이스 и 외부 서비스, 뉴렐릭에서와 같이. 여기에는 아무것도 없습니다. Datadog은 애플리케이션을 구성 요소로 분해하므로 PostgreSQL이 고려됩니다. 별도의 서비스, 외부 서비스 대신 찾아볼 가치가 있습니다. aws.storage (애플리케이션이 액세스할 수 있는 다른 모든 외부 서비스에서도 유사합니다.)

다음은 예입니다. postgres:

기본적으로 우리가 원했던 모든 것이 있습니다:

요청이 어떤 "서비스"에서 왔는지 확인할 수 있습니다.

Datadog은 NGINX Ingress와 완벽하게 통합되어 요청이 클러스터에 도착하는 순간부터 엔드투엔드 추적을 수행할 수 있으며 통계 지표 수신, 로그 및 호스트 지표 수집도 가능하다는 점을 상기시켜 드리는 것도 나쁘지 않을 것입니다. .

Datadog의 큰 장점은 가격입니다. 발전하다 인프라 모니터링, APM, 로그 관리 및 종합 테스트, 즉 계획을 유연하게 선택할 수 있습니다.

2.아투스

Atatus 팀은 자신들의 서비스가 "New Relic과 동일하지만 더 우수하다"고 주장합니다. 이것이 정말로 그런지 봅시다.

메인 패널은 비슷해 보이지만 애플리케이션에 사용된 Redis와 memcached를 확인할 수는 없었습니다.

APM은 기본적으로 모든 트랜잭션을 선택하지만 일반적으로 웹 트랜잭션만 필요합니다. Datadog과 마찬가지로 메인 패널에서 원하는 서비스로 이동할 수 있는 방법이 없습니다. 더욱이 트랜잭션은 오류 뒤에 나열되는데, 이는 APM에 있어 그리 논리적이지 않은 것 같습니다.

Atatus 트랜잭션에서는 모든 것이 New Relic과 최대한 유사합니다. 단점은 각 컨트롤러의 역학이 즉시 표시되지 않는다는 것입니다. 컨트롤러 테이블에서 이를 찾아 정렬해야 합니다. 가장 많은 시간을 소비함:

일반적인 컨트롤러 목록은 탭에서 사용할 수 있습니다. 둘러보기:

어떤 면에서 이 테이블은 Datadog을 연상시키며 저는 New Relic의 유사한 테이블보다 더 좋아합니다.

각 트랜잭션을 확장하고 애플리케이션이 수행한 작업을 확인할 수 있습니다.

패널은 또한 Datadog을 더 연상시킵니다. 많은 요청과 일반적인 통화 그림이 있습니다. 상단 패널에는 오류 탭이 제공됩니다. HTTP 실패 느린 쿼리의 예 세션 추적:

트랜잭션으로 이동하면 추적의 예를 볼 수 있고 데이터베이스에 대한 요청 목록을 가져오고 요청 헤더를 볼 수 있습니다. 모든 것이 New Relic과 유사합니다.

일반적으로 Atatus는 알림 블록에 호출을 붙이는 일반적인 New Relic 없이 상세한 추적에 만족했습니다.

그러나 New Relic과 같이 초고속 요청(<5ms)을 차단하는 필터가 부족합니다. 반면에 최종 거래 응답(성공 또는 오류)이 표시되는 점은 마음에 들었습니다.

패널 데이터베이스 애플리케이션이 외부 데이터베이스에 요청하는 내용을 연구하는 데 도움이 됩니다. Redis와 memcached도 프로젝트에 참여하고 있지만 Atatus는 PostgreSQL과 MySQL만 찾았다는 점을 상기시켜 드리겠습니다.

요청은 응답 빈도, 평균 응답 시간 등 일반적인 기준에 따라 정렬됩니다. 또한 가장 느린 쿼리가 있는 탭에 대해서도 언급하고 싶습니다. 매우 편리합니다. 또한 PostgreSQL에 대한 이 탭의 데이터는 확장 프로그램의 데이터와 일치했습니다. pg_stat_statements - 훌륭한 결과!

탭 외부 요청 데이터베이스와 완전히 동일합니다.

조사 결과

제시된 두 도구 모두 APM 역할을 잘 수행했습니다. 그들 중 누구라도 필요한 최소값을 제공할 수 있습니다. 우리의 인상은 다음과 같이 간략하게 요약될 수 있습니다.

데이터 도그

장점 :

편리한 관세 일정(APM 비용은 호스트당 31 USD)
Python과 잘 작동했습니다.
OpenTracing과의 통합 가능성
쿠버네티스와의 통합;
NGINX Ingress와의 통합.

단점 :

모듈 오류로 인해 애플리케이션을 사용할 수 없게 만든 유일한 APM(predis)
약한 PHP 자동 계측;
서비스와 그 목적에 대한 부분적으로 이상한 정의.

아타투스