Add a new check.

Don't click on check type.

Type "grafana.com" in the target.

Select a probe.

The "save" button is not enabled.

Click the check type, select something, click again, go back to PING. Now save is enabled.

Users should be able to create alerts for their checks

The list of probes should be sorted alphabetically in the UI

We should provide the ability to control the number of metrics getting generated by checks. At least the ability to choose between a basic set of metrics and all the metrics.

In v0.0.10 we switched UI elements to use sliders+input fields for checks. If a user types a decimal value in the input we don't show an error on tab out, but do show an error when saving the check. Possibly might want to allow saving decimals or not allow them to be entered.

otherwise grafana displays "Panel plugin not found: grafana-worldmap-panel" with the provided dashboards.

When editing a check with a TLS config, the form fields are showing default values instead of the saved values.

Deleting the last regex validation in an http check won't persist.

We should change the regex inputs to be less duplicative. See this mock up from Anthony:

https://user-images.githubusercontent.com/8415072/88956580-17382a80-d28d-11ea-8c34-58c1e1b3d5ee.png

Not sure what's invalid about a simple HTTP check (possibly invalid value for IP version), but even if the API returns an error, the application does not display it, so it looks like it didn't do anything.

The "Response latency by probe" panel in the DNS dashboard is not working because the query is missing a closing parenthesis.

Has any thought been given to decoupling this to where it can be ran with an on-prem instance of Grafana/Prometheus/Loki? I know it's a sales driver for Grafana Cloud but this would be a major step forward for those that are running On-Prem stacks.

Target validation check:

See this image, in the label of the "response latency by probe" panel it says "Value".

This affects HTTP, TCP and DNS dashboards.

Depends on https://github.com/grafana/synthetic-monitoring-api/issues/110

When the plugin is disabled, we need to send a request to notify the API so the tenant can be cleaned up from the backend. We'll need to send the request from here

If you set the API server to something invalid during set up and hit setup, no error is displayed.

When creating a probe, this is what you see:

it would be nice to have some visual feedback as to what those numbers correspond to.

• In the Checks page, when you have the option to create a new check, "Grafana" is misspelled
  
• The dashboard folder is currently named "SyntheticMonitoring" without a space
  

The latitude and longitude fields do not allow decimals when creating a new probe.

To reproduce:

• Navigate to Synthetic Monitoring -> Probes
• Click New Probe
• Enter decimal values in the Latitude and Longitude fields.
• Click Save and it gives an error

Some options:

• Show usage per check
• Total roll up usage for all checks
• Total costs per check
• Total costs for Synthetic Monitoring
• Tooltip explaining parameters that affect usage
• Explore making calculated usage outside of form/sticky

Should we use approximate numbers that we're calculating on the frontend or use actual usage numbers?

When adding a new probe, the latitude and longitude fields require you to enter negative numbers for west and south, but that's pretty weird.

If you click the field the cursor is after the 0. If you hit backspace, that doesn't work. You cannot enter a minus. What you have to do is enter the value back go back to the first character and enter the minus.

It shows checked when it should not be checked and vice-versa. It also doesn't handle default values correctly.

Uptime label hints that this is uptime of probe but what we are seeing is the success rate for all the checks that that probe is running for that tenant over the last 3 hours.

changing the label from "uptime" to "success rate" would make this less confusing,

https://suraj/dev is accepted as a valid http check url, but it shouldn't be. We should improve the quality of the URL validation.

For a DNS or PING check, something like "https://example.org/" is an invalid target.

For HTTP, a URL with an HTTP or HTTPS schema is required (this is already verified)

If you create a check, associate it with a probe, save it, and then delete all the probes, going to the list of checks and clicking on that check causes the application to not display anything. The display suggests it's trying to load something, but it never does anything else.

It's possible that the empty list of probes is throwing the code that displays the drop down with the list of probes off.

Right after you add a check and are taken back to the list of checks, the new check is not shown. This is most evident when there are no checks, but it happens all the time.

The check target input should validate the following cases as being bad (no domain):

• http://hostname/
• https://suraj/dev

We should give an indication of how many active series a check will generate when creating.

We are rolling our own form state right now. The code will be simpler and more reliable if we leverage the

errors from update call for probes are not shown to users,

See attached gif for details:

Steps to reproduce

go to Plugin Config page and click on links under Includes section

When multiple instances of the synthetic monitoring plugin are installed (e.g. by adding them to the plugin directory with multiple names?), the code hits:

The current message is:

The error message should be updated with an explanation for what to do. Ideally the error message can point to the directories containing each instance.

Could this refer to multiple instances of the SM datasource?

When dealing with a dozens or more checks, it would be nice to have an interface where the user can get an overview of which checks are running on which probes. Since the number of probes is fixed (~ 20 public probes, plus however many private ones), this could be organized in a matrix, with one row per check. It would be nice to be able to disable a check, and add / remove checks to individual probes, as well as add a check to all available probes (a check without any probes is invalid, so clearing the probes could be an option, but it should not be possible to store that configuration).

Enhancement suggestion, assuming this feature isn't part of Synthetic Monitoring already. Set and configure dependency checks. Ability to not check endpoints if another endpoint is not available. Probably most useful with internal probes. For example, if my WAN IP is down, I may not want to check if my web server behind the WAN IP is up. This would prevent alert storms.

As an active WorldPing customer and looking forward to the new version and features.
Assuming this is the new location for https://github.com/raintank/worldping-app

See community post, where I mentioned:

"I notice WorldPing does 5x ICMP requests then wait for reply. Another tool we use does 1x ICMP request then wait for reply, 5x. We have a set of remote destinations that don’t like the 5x request and reports 1 out of five drop on most polling cycles.

..... adjust this functionality and go to request>reply, instead of 5x request burst?
..... Is there anything to WP using 18 byte vs. some other size ICMP request size?

We should have something in the UI that allows folks to enable/disable all their checks with a toggle/button/some sort of UI control.

Steps to reproduce(in Grafana Cloud):

1. install & setup SM
2. un-install SM plugin
3. delete Synthetic Monitoring Proxy data source
4. re-install plugin
5. go to plugin config page, and it will be stuck in loading state.

expected behavior:

1. plugin works, and can be configured

Any place the success rate metric shows up, it only fetches on mount. This means that if you don't refresh the page you don't get up to date metrics. We should periodically refresh the data so the user is always seeing the current success rate.

During setup, the common case will be that the user will have one hosted metrics and one hosted logs instance.

When the user gets to the instance selection screen, they see this:

simply pressing setup produces an error (good!) but it's not clear that the problem is that instances have not been selected: a pop up message from the browser says "Missing metrics instance".

Steps to reproduce:

1. Create a private probe; SM->Probes, click "New"
2. Delete the probe; SM->Probes, select probe, click "Delete Probe"

No on-screen error is displayed, but an error is received from the network request:

{ "msg":"failed to delete probe 23 from database",
  "err":"deleting probe: Error 1054: Unknown column '$1' in 'where clause'"}

The same error is received whether a probe was ever online or not.

we have decided to re-brand worldping as "Synthetic Monitoring". This is more inline with existing solutions in the market and is aligned with this no-ops monitoring capability being part of Grafana Cloud, rather then a standalone product.

We should set up a pipeline to run tests/builds on PRs

It should deploy on merge to master (or maybe not, TBD)

It's currently possible for users to select metric/logs instances belonging to different stacks when initializing via admin key. This will result in a broken experience. We should revamp the instance selection UI to select based on stack instead of instance type.

What would you like to be added:
Logs indicating which user created a specific check.
Logs indicating which user updated which check, and what the update was (at least which section of the check was modified is any, when the user clicks "Save")

Why is this needed:
When dealing with a lot of users it becomes mandatory to backtrack actions or know who did what.
At this moment what we can get from the logs is the users who updated a check, and when they updated it, but we cannot tell what the modification was. We can also see when a user creates a check, but not which check.

When adding a new check, select HTTP, and enter "grafana.com" for the target. The red frame goes away, but the save button is not enabled.

The current length limit for a check job name is 32 characters, which feels restrictive.

The list of return codes presented to the user should be expanded to include all the values supported by the backend. The default value should be "NOERROR".