Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamically generate the diagram #446

Open
rehandalal opened this issue May 13, 2020 · 8 comments
Open

Dynamically generate the diagram #446

rehandalal opened this issue May 13, 2020 · 8 comments
Labels
enhancement New feature or request

Comments

@rehandalal
Copy link
Contributor

It might be nice to stop using a fixed SVG and instead dynamically generate the diagram using something like JointJS

@rehandalal rehandalal added the enhancement New feature or request label May 13, 2020
@leplatrem
Copy link
Contributor

What would be the input to generate the diagram?

@mostlygeek
Copy link
Contributor

Had a conversation with @rehandalal about this:

Context: We are building out more services that report telemetry about how things are working on the client's machine. The diagram in Poucave's UI is a great and easy way to quickly see how the system is behaving. However, the current poucave UI is a "team view" for the product delivery team and the systems they were interested in.

Poucave supporting more "team views" would make it more useful to monitor other systems like sync, push, etc.

@leplatrem
Copy link
Contributor

There are different ways to achieve this.

Adding views to a single instance, or run multiple instances.

Since running Poucave is pretty cheap, I would have a preference for the latter 🤷
And if we want to integrate them all together, then one instance can use the other instances endpoints to report their status 🤯

@mostlygeek
Copy link
Contributor

mostlygeek commented Mar 31, 2021

I like the multiple instances approach.

Poucave is cheap to run but expensive to set up. The setup is expensive because it's not automated and requires getting ops to configure each one. If we can make the setup/deployment process as easy as adding/updating a configuration we could keep poucave simple (+1) and still get custom pages.

I have to admit, the idea of Poucave checks building on other poucave checks frightens me a bit. :)

@leplatrem
Copy link
Contributor

If we can make the setup/deployment process as easy as adding/updating a configuration we could keep poucave simple (+1) and still get custom pages.

I agree. Let's see, concretely to setup a new instance, currently we need to:

  • implement (if any missing) the specific checks
  • write the .toml configuration file to leverage the desired checks
  • draw the SVG and annotate it with the specific object id syntax
  • deploy the app with the 2 config.toml & diagram.svg files

This ticket originally suggested that we could generate the diagram from the config file (indicating links and labels for example).

Now, maybe that the idea of having different views could be closer to issue #373 ?

@mostlygeek
Copy link
Contributor

mostlygeek commented Mar 31, 2021

Regarding tags, tags were originally designed to create a single "up or down?" endpoint for a group of checks. They weren't designed for what this issue is about, or even creating custom UI for team views. @rehandalal changed my thinking here.


Thinking about it more, I would argue that poucave now has two purposes:

  1. It's original purpose: platform for creating complex checks for detecting systemic failures.
  2. A status page to understand what's going on in the system as a whole.

For the second purpose, the SVG is so valuable because it gives context to the checks. It helps people understand the system quickly:

image

I think this is really the problem we're solving: People want to their own custom poucave page (svg, checks, etc) but it's not easy enough to get a custom one.

How can we make poucave more self serve so people can:

  • self serve
  • land new checks
  • create and update their page with an automated flow
  • have a place to ask for help (slack, #delivery?) when they're stuck

@leplatrem
Copy link
Contributor

leplatrem commented Apr 1, 2021

How many and how often do you think we'd have to create new pages?

Things to consider:

  • drawing a SVG is a piece of cake
  • creating a config.toml with the list of checks is pretty straightforward (see example)
  • landing new checks is already self-serve (pull-requests in this repo). Plus the checks can come from other repos as long as they are available in the PYTHONPATH.
  • A single poucave instance cannot scale indefinitely, because it uses in-memory cache and thus a single HTTP worker

Some possible approaches:

  • have an easy to use script/template to create new poucave instances in cloudops-infra (svg + config + domainname as input)
  • change the deployment recipe in cloudops-infra so that it would deploy one [instance|url|domain] for each folder containing the SVG & config files (instead of a single one)
  • bloat the current code to add notions of views and pages

@mostlygeek
Copy link
Contributor

How many and how often do you think we'd have to create new pages?

One or two for 2021 would be my estimate. It's not worth automating now. However, when we have a few more customers and use cases on poucave it will get the attention of other teams. At that point putting effort into making it more self serve will accelerate its adoption.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants