from thought-provoking sessions to a DevOps Shakespeare performance and open spaces about Career Management, Personal Learning and "GenAI Therapy session" I've got a lot to mull over
many thanks to the hard-working organizers, sponsors, my fellow speakers, and the great group of attendees
So, I’m curious: there’s a growing number of hosting platforms specifically for the #Fediverse. For those involved in this, who are comfortable with answering: is there a particular set of tools you use for managing, monitoring, and spinning up instances?
Are those tools open source?
I’m mainly wondering about whether there’s some kind of open platform / dashboard / infra tools that could serve a particular need for hosting / managing / provisioning Fedi servers, and whether the existing hosts in the space would benefit from a shared project of some sort.
@deadsuperhero
Well, I have been on this soapbox for the past 8 years at least.
Fwiw, @getsentry has excellent dev rel staff and there are some #OpenSource stars who work there (although as I sink into my nap, the only name that springs to mind is Anthony Sottile.).
The folks at @hachyderm have done a lot of research into care & feeding of mastodon servers, so it's feasible to put together an opinionated collection of signals as a default #o11y config.
I think @hazelweakly's observations are incredibly spot on, and I do hope the discourse on this new generation of o11y can keep growing. We've been sharpening the same tools of logging+metrics+tracing for years now, we need new approaches.
The OTel End User Working Group is kicking off 2024 with this all-star panel moderated by Ana Margarita Medina, featuring @honeycombio@mipsytipsy, Equinix's @renice, and me, as we talk about where Observability is headed in 2024.
Jumping into the deep end with my #cloudnative predictions for 2024. Find out what my 3 predictions are around stress, careers, and costs. #observabililty#o11y
What happens when you're an Observability vendor migrating to @opentelemetry? @jea knows exactly what that's like, as he shares the story of how he worked on migrating to OpenTelemetry at ServiceNow Cloud Observability (formerly Lightstep).
Outside of "how much" and "where is all of it," what should you talk to your users about re: their #o11y data needs?
Workflows?
Tooling gaps?
Metrics to improve?
Platform feature requests?
Current toil that feels unnecessary?
What other data should you bring to the discussion?
The most important factor in getting your logs under control is routing them to the right place, /dev/null included. If you're trying to optimize log costs in a system that's already charged you dollars per gig on ingress, you've already lost the battle.
Teams should have a regular review to determine what of their #Observability data is actually being used. Otherwise, "just in case" becomes a value-less justification with uncapped costs.
The Speed of Light Will Cap Traditional Centralized #Observability
There are lots of reasons that DevOps teams have been looking into #o11y Pipelines and their in-flight processing possibilities: cost, performance. But I rarely hear about the hardest limit:
Because Observability is a meta-practice, at what point does it deserve focused attention instead of being an afterthought? Launch? A scale threshold? Downtime thresholds? Dev burnout?
In order to improve your Observability practice, you first need to write down what you want from it. Otherwise, the path beyond Collect > Search > Display becomes impossibly murky.