Ask HN: Product to improve monitoring and documentation: a good idea?
4 points
by d--b
22 days ago
| 2 comments
| HN
Hi HN,

I have an idea for a product, but I want to test the waters before building anything.

Here is the landing page I put together today:

https://www.get-aerial.com/

The idea is to make a tool where you can draw documentation diagrams totally freeform, like: User does X, signal gets sent to DB, process X picks up files here, etc. But instead of being static, you'd have the ability to hook that diagram to actually running code.

That way your code could post hearbeats or logs to my endpoint, and you'd see the node being active in the diagram.

The idea is that this would help:

1. keep documentation diagrams up-to-date

2. allow for full-tech-stack logical monitoring

Any takers?

dvrj101
22 days ago
[-]
so the documentation get's parsed by a program which detect hook parts , set them up and look for any trigger then update that part of documentation to show that particular node is active?

edit- or the hooks are already set the program just link them to which part of documentation get's update. Like a tag system?

reply
d--b
22 days ago
[-]
Thanks for the feedback.

I was thinking much more freeform.

In the code, you'd send events to the backend using something like:

`post_to_aerial("task_X","some args")`

In Aerial, you would then match "task_X" to some icon or some part of your documentation. The way I envision it is that Aerial is very visual, so it's mostly diagrams.

In a way, if you start by drawing the diagram the way you envision things to run, you could setup the monitoring before the code itself, in a sort of "monitoring-driven-development".

reply
codingdave
22 days ago
[-]
Yep, I'm sure there would be takers of such a product, because such products exist. When I worked in banking, we used Control-M for such things. I have not kept up on similar products in the 20 years since then, but I'm sure more modern competitors exist as well.
reply
d--b
22 days ago
[-]
What I am thinking about is slightly different. A scheduler really only looks at tasks, and the problem with that is that they don't know anything about the data that the tasks operate on. So looking at tasks only doesn't give you a good view of your data flow.

I've used schedulers for a long time, but they tend to get really messy as well.

But yeah, you're right that people are used to schedulers and they'd probably expect the kinds of features I am thinking of to be in there as well.

reply
d--b
22 days ago
[-]
In fact, more modern orchestrating solutions like kubernetes/nomad really focus on the physical aspects of how things run, rather than the logical aspect.

A health dashboard for Kubernetes will show you CPU usage, RAM load and network latency, instead of a map of all your database tables being populated or not.

reply