stochastimus

14 ms·

31.
by stochastimus 4y ago
This is all true. So for the times you end up there, wouldn’t you prefer a tool to surface for you the things you were going to have to spend hours digging for?
32.
by stochastimus 4y ago
We go back and forth on this as well. When I talk to people I will usually say something like “we find the stuff in the logs you were going to have to dig for, and surface it in a report on your dashboard”. I think the RCaaS is in that sens
33.
by stochastimus 4y ago
I feel that vendors have really muddied the playing field by claiming ML features and then not delivering value. That’s why we tend not to talk about ML. But, I think saying that ML is unhelpful for the problem is a bit like saying program
34.
by stochastimus 4y ago
We do indeed since we need to process an amount of data in proportion to that volume, and so more resources are required - you can also run it on-prem, if you want
35.
by stochastimus 4y ago
It's really quite inexpensive - but would love to get your feedback on pricing, esp. at scale! pls. do reach out
36.
by stochastimus 4y ago
LoLz
37.
by stochastimus 4y ago
Hey! Founder here. Thanks for your comment! > That's not hard to debug I agree there's a large class of problems where that's the case, and I also agree it's perhaps easier than many of the issues we've caught in
38.
Show HN: Root Cause as a Service – Never dig through logs again
25 points by stochastimus 4y ago|19 comments
39.
Prototype Photonic Chip Reportedly Classifies Nearly 2B Images per Second(tomshardware.com)
2 points by stochastimus 4y ago|0 comments
40.
by stochastimus 4y ago
This won’t be exactly what you were looking for necessarily but when I read this I felt compelled to respond. Twice I have failed in my pursuits in such a way that going forward was essentially “starting over”; in both of these cases there
41.
AWS Blog: Autonomous root-cause detection for EKS using logs(aws.amazon.com)
2 points by stochastimus 5y ago|0 comments
42.
by stochastimus 5y ago
Awesome - my first thought was “hmm I wonder when the Julia community will implement something based on this” :)
43.
by stochastimus 5y ago
Freeman was right after all.
44.
The Case of the 50ms request(mysteries.wizardzines.com)
284 points by stochastimus 5y ago|79 comments
45.
by stochastimus 5y ago
does this mean that goto is not always considered harmful? ;-)
46.
by stochastimus 6y ago
Nope, completely custom, with a big chunk written prior to Flux anyway, but I’ve seen Flux and I’ll be looking for opportunities to play with it in future projects for sure.
47.
by stochastimus 6y ago
I enjoy seeing this sort of press for Julia. One thing I’ll say for the language is that it is good with elegant high level abstractions for productivity while at the same time being able to go as low-level as you need for optimization. My
48.
by stochastimus 6y ago
Kudos - I won’t remember a lot of the new products I’ve seen websites for, but I’ll remember this one! :)
49.
by stochastimus 6y ago
The unmentioned benefits: it is fixed-width and follows most to least significant parts left-to-right. What this means is that the significance of the parts follows the same L-R convention as numbers, making it intuitively obvious which is
50.
by stochastimus 6y ago
Here’s a question for you - for a typical L2 support person or front line MSP NOC monitor, or junior SRE, or similar - what do you think would be the error rate? I wonder if there isn’t sort of a front-end role here that can be subsumed at
51.
by stochastimus 6y ago
Yeah, I'm really hoping there's a way to reliably corral it into basic plain-language restatement of the logs themselves without it going too far afield or speculating. We will see.
52.
by stochastimus 6y ago
Great question. I guess for me as a technologist, I’m coming at it from the other side and asking what failure rate is possible, and can that rate be reduced with further prompt fiddling and other machinations? Then I will try to gauge whet
53.
by stochastimus 6y ago
Yeah, that’s a fair way to look at it. Thanks for that. It also matches my experience with giving it too much unrelated input data: even the first line of the summary will often be completely fictitious in that case.
54.
by stochastimus 6y ago
Thanks for putting that info here!
55.
by stochastimus 6y ago
Well, I've been trying really hard not to point it out because I don't want this to be like a commercial. :) But, the idea here is that the Zebrium ML picks the incident lines unsupervised; then, the GPT-3 model creates the summar
56.
by stochastimus 6y ago
From what I've read, the answer is "yes", stackoverflow was crawled. EDIT: I looked and stackoverflow is included in the Common Crawl dataset, which is one of the datasets on which GPT-3 was trained. Having said that, it&#x27
57.
by stochastimus 6y ago
I just tried this and I might stick with these settings! ;-) For the postgresql example in the blog, I used your prompt. Here's what I got: The logs were in a mess, But the expert could see, That the database was in distress.
58.
by stochastimus 6y ago
Hmm, I like this direction - so maybe, as the user is navigating the incident, let them steer the model with questions and/or additional lines. Is that sort of what you'd envision?
59.
by stochastimus 6y ago
Yeah, my experience so far has been that if I just pile a bunch of logs in there, if it's not given salient lines, the language model tends to either rat-hole on some particular detail that's irrelevant, or else construct a non-fa
60.
Using GPT-3 for plain language incident root cause from logs(zebrium.com)
106 points by stochastimus 6y ago|34 comments

More ›