Joined 1 year ago
they do.
The landing page is up again now but unfortunately will have to default to accepting demo requests for now :(
I agree with the philosophical principle! If you give a rigid observer an incentive to 'remove bugs', it will happily silence all alerts and report success.
Our goal is to make sure that doesn't happen. The investigation agent is actually a separate agent with a separate goal.
In practice, we rarely see the agent just silencing stuff. When this happens, I get on it and make it an eval case :)
1. Counter-positioning. Most existing tools have invested heavily in their web platforms and compete on their UI/UX. But actually, what matters to our clients is that bugs are fixed. Our top clients would rather never open our tool at all. If our competitors want to beat us, they essentially have to fight against their established business models that hinge on users looking at their browsers.
2. Evals. In order to have the most accurate RCA analysis you need a very good suite of evals: what was the right root cause in this bug? what is the right fix?. We're investing into this heavily, and as one of the early movers we have a big advantage here.
At the same time, I tend to approach strategy with a lot of caution. A lot of the canonical reasoning behind 'startup positioning' is based on extrapolation from trends, but surprisingly few analogies work in economics.
Our focus right now is: - talking to our users - making sure they have the best experience
Could you please send me an email at ash [at] superlog.sh? I'd love to hear more about your use case - we might have something for you very soon!
I'm afraid a collector and the operator are still the recommended way to go by OpenTelemetry (https://opentelemetry.io/docs/platforms/kubernetes/getting-s...). We're still working on a custom skill for Kubernetes, but the general skill should give you a sane default already.
A good way to start can be to start sending traces/logs directly by instrumenting the service and putting our backend as the collector.
I also help out personally whenever our clients have any questions on setting up the telemetry :)
There are good ways to link operations between different services with OpenTelemetry (for example, passing the parent trace id in an inter-service HTTP/gRPC request). It's a bit tedious to do by hand, that's why we're publishing the skill that does that for you.
And totally agreed on config changes and deploy info. We've seen that having good environment and version control (commit hash, file name, line number) tagging is extremely important for root cause analysis, so we go hard on this in the skills.
We also have many infra integrations in our roadmap to make sure that we can deeply analyze the infra/config side of things.
We have an eval suite with code+telemetry fixtures and a golden RCA+patches and an LLM-as-a-Judge. So whenever we get feedback from our users and they're OK with it, we use their feedback to create an eval case (it's still quite manual since you have to calibrate the case).
We use Superlog to observe Superlog, so I often extract cases from our own errors. The PRs get better and better, but, of course, it's sort of a continuous improvement process.
