Solid OpenAI post-mortem on @kubernetes.io API overload, caused by "per-node telemetry ingestion" status.openai.com/incidents/ct... 🤔 Oddly familiar to a common DaemonSet @prometheus.io / @opentelemetry.io gotcha for metrics scrapes, we talked about in the past: youtu.be/yk2aaAyxgKw?... 🙈
Post
status.openai.comAPI, ChatGPT & Sora Facing IssuesOpenAI's Status Page - API, ChatGPT & Sora Facing Issues.
...there's even a OSS metric collection operator we maintain at Google with that optimization 🙃 github.com/GoogleCloudP... Another solution is to ofc have a cluster service discovery that pushes the targets to node agents, but pure (optimized) daemonset usually scales enough!
github.comGitHub - GoogleCloudPlatform/prometheus-engine: Google Cloud Managed Service for Prometheus libraries and manifests.Google Cloud Managed Service for Prometheus libraries and manifests. - GoogleCloudPlatform/prometheus-engine
I had an idea in this area github.com/prometheus/p...
github.comIdea: split-process service discovery · Issue #15402 · prometheus/prometheusProposal In big installations, service discovery can be a major proportion of CPU and memory usage inside Prometheus. Especially with lots of relabeling rules. Spotify reported 50% in this video. I...
Ah nice! Yea, we could make this a pattern. However it feels it would need to handle load balancing too (supporting multiple Prometheus-es), which touches "dynamic scrape target distribution problem" that is generally a bad idea (less reliable) Somewhat relevant to opentelemetry.io/docs/kuberne...
opentelemetry.ioTarget AllocatorA tool to distribute targets of the PrometheusReceiver on all deployed Collector instances
0 reposts0 likes