u/Broad_Technology_531

Im building a startup in the DevOps space. We’ve got a solid MVP, and I’m looking to bring on a few design partners for feedback and validation before I turn it into a paid product.

I’ve been doing tons of cold outreach, writing blogs, tweeting, but I’m getting little to no response, and I’m starting to lose patience.
Funny enough, we’re definitely getting attention from competitors, others in the space, and even investors but we still have no customers.

Question how is everyone else getting their first customers/design partners?

Im building a startup in the DevOps space. We’ve got a solid MVP, and I’m looking to bring on a few design partners for feedback and validation before I turn it into a paid product.

I’ve been doing some cold outreach, but I’m getting little to no response, and I’m starting to lose patience.
Funny enough, we’re definitely getting attention from competitors, others in the space, and even investors but we still have no customers.

Question how is everyone else getting their first customers or design partners?

I wrote a post on how to generate RED metrics from your traces at the Collector before they hit your backend and why you'd want to do that instead of letting your backend handle it.

I also added some tips on how not to blow up your metric cardinality in the process.

Fleet management within the open telemetry framework is difficult and often confusing. No doubt the contributors to these projects have done an amazing job developing protocols and a supervisor implementation, it’s just difficult by nature and learning another protocol/configuration/technology is daunting to a lot of admins whose time is already in short supply. Recent development has exposed me to these technologies and I wanted to capture and share my understandings and experience in a blog. While I cannot capture the full breadth or nuance of these solutions I have hit on some high points that I think are useful and might help simplify some of these topics for folks like myself.

Telemetry has been exploding due to all these new AI workloads and I feel like there hasn’t been a lot of guidance around controlling this. Everybody’s observability bill is up and these backend vendors are raking it in; datadog stock went up almost 100% in the last 30 days (yes, some of the rise is due to their new AI observability tooling, but if you read the earnings report, their revenue from their backend business is booming even more. They call it non-AI revenue). And all these vendors are selling you a paid solution for it. They’re giving you levers and knobs to drop/sample telemetry after ingest. But it’s baked in to the price, because, of course it is! They have to make their money somehow, and after your telemetry is shipped and landed in their backend and then deleted, you’ve undoubtedly paid for it. Edge reduction itself isn't new. cribl, vector, and collector processors have done it for years, but doing it in the collector with OTTL means no proprietary agent and no lock-in.

With otel graduating last month and opamp becoming a very real thing, it’s so easy to drop/sample telemetry on the edge. It saves you egress, shipping, and ingestion. Not to mention, you are not using a vendor’s propriety tooling to control your telemetry, meaning you’re not locked in. Wana switch backends tomorrow? You can--all your config is based on OSS standards. Anyways, I wrote up a practical guide on how to actually do it, with real config examples, if anyone's interested

I've worked in the observability industry for a while and set up a lot of collectors for customers. Wanted to put together an end to end writeup covering the things most blogs skip when monitoring a Kubernetes cluster with OTel.

Covers the full agent + gateway pattern. Agent runs as a DaemonSet for node local stuff (container logs, kubelet stats, hostmetrics, OTLP from local pods). Gateway is a Deployment for cluster-wide telemetry(k8s_events, k8s_cluster, and the only connection to your backend).

Goes through every receiver and processor on both sides, the right processor order on the agent, the k8sattributes pod_association gotcha that breaks pod lookups, and the service.name fallback chain from the OTel K8s spec.

I didn't cover auto-instrumentation in this blog. I focused mainly on the OTel collector setup

Curious to see how others are monitoring their Kubernetes clusters