PHP 분산 추적 경험 공유

小云云원래의: 2018-01-25 14:10:141433검색

이 기사에서는 모든 사람에게 도움이 되기를 바라며 PHP 분산 추적에 대한 몇 가지 경험을 주로 공유합니다.

마이크로서비스를 구현한 이후로 우리는 많은 문제에 직면했습니다. 가장 큰 문제는 오류를 해결하는 방법입니다. 서비스 지향 인터페이스는 일반적으로 여러 서비스에 의존합니다. 종속 인터페이스의 속도는 인터페이스의 서비스 품질에 직접적인 영향을 미칩니다.

이러한 의존성으로 인해 발생하는 속도 저하는 온라인에서는 매우 흔한 일이지만 문제 해결이 쉽지 않습니다. 그 이유는 로그를 통해 많은 수의 로그 개발자가 온라인에서 추적되고 있기 때문에 개발자에게는 그다지 직관적이지 않으며 일부 회사에서는 이러한 현상이 발생하기 때문입니다. 개발자 온라인상에서 구체적인 실행상황을 확인하는 것은 불가능합니다. 일반적으로 이러한 작은 확률의 온라인 오류는 시스템의 숨겨진 위험을 나타냅니다. 이러한 숨겨진 위험은 증폭되거나 심지어 대규모 온라인 오류로 직접 이어질 수도 있습니다. 가장 직관적인 방법은 통계 분석을 위해 분산 추적 시스템을 사용하는 것입니다.

전문가들이 온라인 성능을 최적화하는 방법과 성능을 향상시키는 방법에 대해 이야기하는 것을 종종 볼 수 있습니다. 실제로 그들이 언급하지 않은 중요한 링크가 있습니다. 분산 추적 시스템은 대규모 인터넷 회사에서 매우 일반적이지만 중소 규모 회사는 이 시스템을 구현할 기술적 역량이 없습니다. 우리의 관점에서는 트래픽이 매우 작더라도 시스템은 여전히 회사에 매우 중요하며 이를 강화해야 문제를 찾을 수 있어야만 해결할 수 있습니다. 구현되었습니다.

분산 추적 시스템의 구체적인 구현에는 성능 캡처, 로그 작성, 로그 수집 및 정렬, 로그 전송, 로그 저장, 로그 인덱싱, 실시간 로그 분석 등을 달성해야 하는 특정 기술적 어려움이 있습니다. 대규모 흐름 시스템의 영향에 대처할 수 있는 시스템이 필요합니다. 예를 들어, 각 인터페이스가 각 요청에 대해 1,000개의 로그를 생성한다면 QPS 2000 서버는 2M의 로그를 생성할 것입니다. 요청이 5개의 인터페이스에 의존한다면 온라인 비즈니스가 더 복잡하고 트래픽이 많을 때 초당 1000만 개의 로그를 생성할 것입니다. 시간이 커지면 이 값은 증가합니다.

대형 인터넷 회사는 수십억 개의 트래픽을 견딜 수 있는 분산 추적 시스템을 많이 보유하고 있지만 소규모 회사의 경우 이 아키텍처는 매우 부담스럽고 대부분이 분산 메시징 시스템, 분산 저장 및 배포에 의존합니다. 공식 계산을 위해서는 이것만으로도 최소한 6개 이상의 서버를 사용하게 되며 이는 일반 소규모 회사에는 비용 효율적이지 않습니다.

이번에는 두 가지 유형의 오픈 소스 분산 추적이 있습니다. 하나는 중소 인터넷 회사를 위한 독립 실행형 버전입니다. 2000w 비즈니스 시스템(결제 시스템 등). 수십억 개의 분산된 PV를 지원하는 분산 추적 시스템도 있습니다. 현재 Fiery의 독립형 버전이 오픈되었습니다(https://github.com/weiboad/fiery). 이 버전은 중소기업에서 사용하도록 설계되었습니다. 전체 프로젝트는 Jar 패키지로 구성되어 있습니다. Java8 런타임이 있는 한 직접 사용할 수 있습니다. 물론 시스템에서는 간단히 작업을 수행하면 됩니다. C++ 분산 버전은 많은 것에 의존하며 운영 및 유지 관리 인력을 위한 특정 기능이 필요합니다. 독립형 버전은 상황에 따라 나중에 출시될 예정입니다. 완전히 오픈 소스이고 내부에 민감한 데이터가 포함된 이러한 핵심 거래 시스템도 완벽하게 사용 가능합니다.

현재 시장에는 여러 가지 분산 추적 방법이 있으며 그 중 일부는 회사 내부에서 사용되며 일부는 소규모 무료 및 대규모 유료 서비스입니다. 공통 분산 추적은 통계적 방법을 통해 각 블록의 성능을 기록합니다. 현재 우리가 제공하는 방법은 시중의 방법과 완전히 동일하지는 않습니다. 우리는 핵심 시스템의 분산 모니터링을 위한 시스템을 설계하면서 지속적인 실험을 통해 많은 단순화를 이루었습니다. 결제 시스템, 거래 시스템 등이 있습니다.

각 요청의 특정 상황, 반환 값, 특정 성능 및 기타 정보를 기록합니다. 테이블 분석을 통해 온라인 종속 인터페이스 성능(타사 또는 저장되지 않은 인터페이스 성능 통계)을 빠르게 발견하고 묻혀 있는 작업을 수행할 수 있습니다. 성능 순위를 위해 인터페이스도 독립적으로 분석되었습니다. 분석 테이블을 보면 재생을 요청하는 가장 느린 인터페이스를 빠르게 찾아내고 온라인 성능이 저하되는 이유를 분석할 수 있습니다. 실제로 우리는 PHP가 의존하는 데이터 리소스의 속도 저하로 인해 PHP 인터페이스의 성능이 저하되는 경우가 많다는 사실을 발견했습니다. 따라서 자원에 의존하는 데 중점을 둡니다. 사용자는 자신의 필요에 따라 다른 정보를 추가할 수 있으므로 불필요한 로그의 양을 줄이고 더욱 절약할 수 있습니다.

이 오픈 소스 Fiery는 주로 PHP 침입 포인트 라이브러리, 간소화된 로그 모니터링 푸시 모듈 및 서버의 세 부분으로 구성됩니다. 이 세 가지는 PV가 2000w 미만인 웹 사이트에 대한 분산 추적을 달성합니다.

매장지점 라이브러리는 입구에서 Traceid(UUID)를 생성합니다. 이 Traceid는 입구 서버의 IP 주소와 요청 시간을 숨깁니다. 로그 수집 후 모든 관련 로그는 이 UUID에 따라 저장됩니다. 묻힌 포인트 라이브러리는 다른 요청에 의해 전송된 Traceid를 수신하고 런타임 동안 RPCID를 전송 및 유지하는 역할을 담당합니다. RPCID는 호출 관계의 순서와 계층을 직접 복원하고 개발자에게 표시할 수 있는 계층적 카운터입니다. . 또한, PHP 작업 중 Exception이 발생하면 서버가 중복 제거 통계를 수행할 수 있도록 매장된 포인트 라이브러리에 이를 캡처하고 기록합니다. 마지막으로 이러한 로그는 서버의 로컬 디스크에 기록됩니다. 여러 PHP 프로세스가 동시에 파일을 쓰는 경우 프로세스 ID와 함께 로그를 기록하는 경우가 있습니다. 프로젝트 이름을 파일 이름으로.

Fiery 로그 캡처 및 전송의 간단한 버전을 구현했습니다. 이는 운영 및 유지 관리 담당자의 작업을 단순화하기 위한 것입니다. 현재 유사한 기능을 제공하는 오픈 소스가 많이 있지만 다른 소스에 의존해야 합니다. 운영 및 유지 관리에 매우 중요한 환경입니다. 또한 실험적인 PHP 로그 캡처 및 전송 서비스가 있지만 여전히 실험적인 기능이므로 사용자가 디버깅 및 개선에 참여할 수 있습니다.

우리는 Fiery의 서버 측과 내장된 Lucene 및 Rocksdb에서 각각 요청을 색인화하고 저장하기 위해 많은 작업을 수행했습니다. 메모리 통계에 대한 작업도 수행했으며 현재 통계 차원은 고정되어 있으며 로컬 인터페이스, 종속 인터페이스, Mysql 및 Curl의 응답만 계산합니다. 또한 호출 관계 재생 및 오류 로그 경고 중복 제거 통계도 제공합니다. 이러한 기능을 통해 라인의 주요 지점에서 성능 결함 및 시스템 이상을 신속하게 발견할 수 있습니다. 현재는 독립 실행형 버전일 뿐이며 나중에 필요할 경우 더 간단한 분산 모드로 확장할 수 있습니다.

위 서비스는 온라인 서비스에만 국한된 것이 아니고, 현재 내부적으로도 이를 활용하여 일련의 QA 테스트 환경에 접속하고, 이후 잘못된 인터페이스에서 생성된 Traceid를 직접 전송하는 등 많은 흥미로운 시도를 해왔습니다. 테스트를 위해 개발자는 Traceid를 사용하여 이 요청의 모든 호출 프로세스, 매개변수, 반환 조건 및 성능을 찾을 수 있으며, 이는 온라인에 접속하기 전에 쉽게 분석할 수 있도록 시각적으로 볼 수 있습니다. 얼마 전 제가 Fiery를 홍보하기 위해 Weibo에 글을 올렸을 때 누군가가 해킹 과정과 구체적인 세부 사항을 볼 수 있는 허니팟으로 사용될 수 있다고 언급했습니다. 후속 기능은 여전히 모든 사람이 탐색하고 개선해야 합니다. 이 시스템은 PHP 생태계의 격차를 메우기 위해 설계되었습니다.

PHP 분산 추적 경험 공유

관련 기사