Hacker News Reader

Comment by eganist | Hacker News Reader

Do you already have data models and ML to handle these tasks today, or are you still building data models with the aid of the clients who sign up for the service?

If you have a functioning platform today, what percentage of events end up needing human escalation?

Asking these questions considering the early stage of your product.

View on HN

Hi, one of the founders here: The service is designed to not require specific data models, because that does not scale, nor does it keep up with changes in application behavior. Instead, the ML engine learns data structures, normal behavior of logs and metrics, and normal correlations between them for each app deployment on the fly. Then when things break it does a very good job of generating incidents. We make user feedback easy, so if we are "over-eager" in detecting a certain kind of incident, your response trains the ML quickly. We do improve the ML engine with experience of course (and have added some user controls), but now have dozens of applications using us, and cumulatively have over a thousand successfully detected incidents under our belts.

Hi eganist,

The tasks the SW handles are (1) detecting when it looks like an incident should be raised, (2) gathering up all the evidence around that incident, and (3) notifying the user via Slack or other webhook. The purposes are to (a) detect unknown unknowns for which you won't have an alert rule built, and (b) reduce MTTR by having pulled together evidence of impact and root-cause into an incident report.

Re: human involvement: a human still needs to review and potentially act on the incident report. The idea is that we've (1) alerted on an incident and (b) given you a great summary / starting point. You can provide feedback on the report to let the system know which sorts of incidents were good / ok / lame, and the system will refine future incidents based on this simple feedback mechanism.

Re data/data models: there are no app-specific/ stack-specific / user-specific rules built-in, and each user's dataset is learned/structured independently. As an example, suppose you are running postgres. We will learn that logstream structure from scratch as it comes in; there is no code that looks for the word "postgres" or "replication", for example, nor is there a built-in understanding of the timestamp formats supported by postgres. The structuring is done de novo for each log stream, anomalies are detected in very generic ways, and the model that decides what rises to the level of an incident is abstract and works the same for any app, also without special rules.

This design is quite intentional: there won't be any pre-built rules or connectors for your application, for example, and autonomous incident detection only works if it can grok an arbitrary stack OOTB.

Here's a link to a blog that shows how the system works on a few sorts of incidents, although the UI is much prettier now with charts instead of just text in the incident report:

https://www.zebrium.com/blog/is-autonomous-monitoring-the-an...

I hope this has answered your questions!

Reply on news.ycombinator.com