각 웹 서버에 statsd 인스턴스가 있고 그런 다음이를 collectrd와 같은 것으로 푸시한다는 생각입니까?웹 노드 당 statsd 실행 인스턴스가 필요합니까?
메트릭 통화가 udp로 매우 가볍기 때문에 페이지 당 statsd를 3-5 회 호출 할 수 있다는 것을 알았습니다. 어떤 점에서 문제가 발생하는지 궁금합니다.
너무 빨라서 초당 수천 건의 전화를 걸 수 있으며 화재 나 잊어 버린 요청 유형이기 때문에 문제가되지 않습니다.
각 웹 서버가 statsd 인스턴스를 실행하고 의 인스턴스를 가지고 있고 그 다음에이를 collectrd와 같은 것으로 푸시한다는 생각입니까?
Statsd는 Collectd를 대체합니다. LAN을 통해 단일 statsd 인스턴스를 가질 수 있으며 모든 '페이지'전송 메트릭을 가질 수 있습니다. 다음 논리적 단계는 이러한 측정 항목을 시각화하는 것입니다. 여기 Graphite을 생각해보십시오.
내가 메트릭 통화 UDP입니다 그래서 그들은 매우 가벼운 것으로 알고 있습니다하지만 이 3-5 페이지 당 statsd 호출하고이 어떤 점에서 문제가 발생할 것입니다 만약 내가 이 궁금하게 할 수 있음을 의미?
분당 하나의 statsd에 대해 10K 통화를하고 있습니다. 문제는 여러 가지가 될 수 있습니다. 서버가 CPU, 메모리, 네트워크 또는 IO 경계를 잡을 수 있습니다. 예 UDP는 TCP보다 훨씬 가볍습니다. 규모에 대해 걱정하지 마십시오. 거기에는 지금 활주로가 많이 있습니다.
갖는 여러 statsd 인스턴스 :
하지 않는 한 확장 성 관점에서, 여러 statsd 클라이언트를 가지고 정말 나쁜 생각이 될 것입니다. 나중에 구성을 변경하는 것이 골치 거리가됩니다. n statsd 중 어떤 것이 잘못 구성되었는지 디버깅하는 것도 어렵습니다. 따라서 '경량'오버 헤드는 관리 할 수없는 아키텍처에 대한 초대입니다. 지금까지 견고성에 관한 한, statsd의 어떤 실패도 직면하지 않고 현재의 요구보다 훨씬 많은 일을하는 사람들이 있습니다. 내가 말했듯이, 나는 분당 10K 메트릭을하고있다.
견고성 ' 술을 사용하려면 노드 당 1 개의 statsd 인스턴스가 있어야합니다. 하나의 인스턴스에 대한 메트릭 만 가져올 때 중요하지 않은 경량입니다.
statsd를 중앙 집중화하고 해당 프로세스/상자가 죽으면 다른 프로세스/상자를 세울 때까지 완전히 눈이 멀어집니다. 가장 좋은 상황이 아닙니다.
일반적으로 관리 및 설정하는 데 드는 오버 헤드가 적기 때문에 단일 인스턴스로 시작하는 것이 좋습니다. 각 웹 서버에서 StatsD 인스턴스를 실행중인 경우 메트릭과 함께 호스트 이름을 보내면 Graphite 측의 항목을 무시하지 않아야합니다. 또한 측정 기준을 이해하려면 Graphite/Dashboard 측면에서 더 많은 작업을해야합니다. 모든 호스트가 하나의 StatsD 인스턴스로 보내지 않는 설치에서 모든 로그인 카운터를 얻으려면 모든 호스트를 합계해야하며 페이지로드 타이밍은 호스트를 기준으로하므로 전체적인 그림을 얻으려면 더 많은 작업을 수행해야합니다. 이 모든 것이 불가능하지는 않지만 시작하기가 더 복잡합니다. 그렇기 때문에 단일 상자로 시작하는 성능을 빠르게 능가하는지 확실히 모르는 경우 단일 인스턴스로 시작하는 것이 더 쉽다고 생각하는 이유입니다.