Our goal is to have StatsD deployed on k8s cluster running on AWS. Currently all existing applications using UDP to send StatsD metrics. As we understood from the kubernetes docs and tests we performed, currently there's no support for UDP listeners while using external loadbalancer (CLB, ALB, NLB), we could use NodePort to expose UDP port but we need support for multiple nodes and failover scenarios when nodes replaced or failing. Please share your suggestions or experience of running such setup.

  • Why does it need an external load-balancer? Most metric collection services I've seen running on container orchestration platforms like EKS and ECS are colocated and use service discovery (DNS-based load-balancing) for container-to-container communication. Would that be feasible for your stack?
    – Woodland
    Jun 23, 2020 at 16:24
  • @WoodlandHunter Thank you for your suggestion, the service should be publicly exposed as metrics reported from different clusters or instances, not necessarily from the same cluster.
    – rombob
    Jun 23, 2020 at 16:29
  • Totally understandable. I had a similar issue (collecting StatsD in ECS Fargate across multiple AWS accounts, no UDP support github.com/aws/containers-roadmap/issues/445 ) and opted to deploy small collector "services" in each of those accounts instead of a centralized one, but it isn't ideal. Another not-ideal-but-might-work-okay option would be to use Spot.io's Managed Instance. It would effectively be a pet server (boo) but it persists the root volume and maintains its ENI despite failure. I've used it as a helpful interim solution help.spot.io/managed-instances
    – Woodland
    Jun 23, 2020 at 16:44
  • 1
    @WoodlandHunter we considered deploying pet UDP to TCP proxy, still feels like ugly hack, could be temporary solution until UDP listener support is ready
    – rombob
    Jun 23, 2020 at 17:19


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.