통계 및 흑연의 고 가용성, 웹 액세스 가능 및 확장 가능한 배포

statsd / graphite를 설정하여 HTML 장치에서 실행되는 JS 앱 (즉, 포함 된 LAN 환경이 아니거나 직접 제어하지 않는 대량의 수신 데이터로)을 기록 할 수 있습니다.

나의 제약 :

• 진입 점은 HTTP를 말해야합니다. 이는 간단한 HTTP-UDP 통계 프록시 (예 : github의 httpstatsd)로 해결됩니다.
• 단일 서버의 장애에 저항해야합니다 (Murphy의 법칙에 맞서기 위해
• 수평 확장 가능해야합니다 : 웹 스케일, 베이비! :)
• 아키텍처는 가능한 한 단순하고 저렴하게 유지되어야합니다
• 내 서버는 가상 머신입니다
• 데이터 파일은 NFS를 사용하여 파일러 어플라이언스에 저장됩니다.
• 처리 할 때 tcp / udp 하드웨어로드 밸런서를 가지고 있습니다

간단히 말해, 데이터 경로 : [client]-(http)-> [http2statsd]-(udp)-> [statsd]-(tcp)-> [graphite]-(nfs)-> [filer]

지금까지 나의 발견 :

• http2statsd 부분을 쉽게 확장 할 수 있습니다 (상태 비 저장 데몬)
• statsd 부분의 스케일링은 간단하지 않습니다 (sum, avg, min, max ...와 같은 집계 데이터에 대해 흑연의 불일치 값으로 끝날 것입니다). HTTP 데몬이 키를 샤딩하기 위해 일관된 해싱을 수행하지 않는 한. 어쩌면 아이디어 ... (그러나 HA 질문이 있습니다)
• 흑연 부분의 스케일링은 샤딩 (탄소 릴레이 사용)을 통해 수행 할 수 있습니다 (그러나 HA 문제도 해결하지 못함). 분명히 여러 속삭임 인스턴스가 동일한 NFS 파일을 쓰면 안됩니다.
• 파일러 부분의 크기 조정은 문제의 일부가 아니지만 IO가 적을수록 좋습니다.
• 공유 NFS 데이터 만 읽을 수 있기 때문에 테스트하지는 않았지만 webapp 확장이 명백해 보입니다.

그래서 누군가가 통계 / 흑연 배포를 위해 공유 할 경험과 모범 사례가 있는지 궁금합니다.

일관된 해싱을 사용하는 statsd 프록시가 있으며, 각각 고유 한 메트릭 이름 세트를 사용하여 여러 통계 수집기간에 통계 트래픽을 분산시킬 수 있습니다. 아키텍처에서 중요한 확장 성 요소이므로 통계 프로세스를 확장 할 수 있습니다.

그래파이트는 까다 롭지 만 무한한 스케일이 필요하지 않으며 서비스 또는 다른 정적 매개 변수로 미세 샤딩을 수행 할 수 있기를 바랍니다.

가장 어려운 부분은 webapp를 확장하는 것이며 가장 무거운 그래프 쿼리가 무엇인지에 달려 있습니다. 그러나 항상 가장 어려운 그래프에 대한 데이터를 사전 집계하고 대부분의로드를 제거 할 수 있습니다.

나는이 모든 고통을 피하기 위해 꽤 오랫동안 HostedGraphite를 사용 해 왔으며,이 사람들은 Carbon에 대한 자체 Riak 백엔드를 구현하고 모든 스케일링을 수행했습니다.