With the Cachet API, we can retrieve the list of configured components at <code class=

Maybe by targeting the components with a regex? For example: <div class="snippet-c

This was done through PR <a class="issue-link js-issue-link" data-error-text="Failed t

Allow endpoint configuration through the Cachet API about cachet-url-monitor HOT 6 CLOSED

mtakaki commented on July 24, 2024

Allow endpoint configuration through the Cachet API

from cachet-url-monitor.

Comments (6)

mtakaki commented on July 24, 2024 2

I gotta say, that's a good idea. I would make this as an optional way of setting it up as not always we want to have the same check for every single component. Say you wanna monitor a page and check if the body contains an specific string, but this string is not present in the other components.

For the status code range, I'll create a separate issue for it.

Nonetheless, I will address those two things on milestone 0.4. I want to get 0.3 out of the door soon and your suggestions will take a little longer to get done.

Thanks for all these suggestion, they are great ideas!

from cachet-url-monitor.

mtakaki commented on July 24, 2024 2

I'm currently trying to wrap up the work on supporting multiple URLs, before tackling this issue. This one may be a bigger revamp, so I wanna make sure 0.3 is done and working. I'm not happy with my current approach on it, thus I'm taking longer to get it done.

Don't worry, this issue is not forgotten and it is on the top of my list to get done. It is a great idea and I really wanna get it implemented. Kudos to @xel1045 for the suggestion.

from cachet-url-monitor.

mtakaki commented on July 24, 2024

That's an interesting proposal, but what if not every URL accepts a GET request? Or is the idea to fetch all component URLs in the beginning? It would still be missing the HTTP method, expected status code, body content, etc, to properly verify the URLs.

from cachet-url-monitor.

xel1045 commented on July 24, 2024

Maybe by targeting the components with a regex? For example:

endpoint:
  match_components:
    url: "^https?://www.google.com/.*$" # optional
    title: ".*" # optional
    group_id: 1 # optional
    # [...]
  method: GET
  timeout: 0.010 # seconds
  expectation:
    - type: HTTP_STATUS
      status: 200
    - type: LATENCY
      threshold: 1
    - type: REGEX
      regex: ".*<body>.*"

That way, this configuration is optional for all installation and this is a non-breaking change.

Then, for the status code, it would be nice to accept ranges like 200-299 for all successful statuses.

from cachet-url-monitor.

jwmarshall commented on July 24, 2024

I was looking at this monitor, as well as another, for Cachet hoping to find something like what is suggested here. The idea of auto-configuring the monitor from URLs already in Cachet would be super ideal. Perhaps if we could get Cachet to support markdown descriptions for components we could use something similar to Jekyll's frontmatter to configure the other fields for this monitor?

from cachet-url-monitor.

mtakaki commented on July 24, 2024

This was done through PR #78. It's not exactly what was proposed here, but it added a client to scrape cachethq and spit out a configuration file. I don't want to increase the complexity of the configuration. Leaving it dead simple makes it less prone to mistakes.

If you guys feel this is not a good solution, please feel free to re-open it.

from cachet-url-monitor.

Allow endpoint configuration through the Cachet API about cachet-url-monitor HOT 6 CLOSED

Comments (6)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent