-
-
Notifications
You must be signed in to change notification settings - Fork 69
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
Monitor alternative responses from returned from a resouce #19
Comments
I can see the usefulness of this story. The implementation may become complex though. As a suggestion for a minimal implementation: have a text string/keyword that should (not) be present in the response to determine success or failure. Example 1: testing a WMS request using XML failure responses (using Example 2: testing WFS GetFeature URL: response should contain the keyword The implementation should not be too complex and would cover many use cases. Many URL monitoring services like http://uptimerobot.com/ have this generic feature. A step further is to associate these URL resource type requests to a particular OGC: resource instance within GHC. |
This would be best applied to Options for an initial
Thoughts? |
Yes, my proposal was for Hence, having a As for implementation: I guess you meant the
WFS-specific (
Many more checks can be thought of: minimum filesize (prevent blank images), featurecount, etc For OGC specific XML-based services this would entain response parsing according to XML-schema's via Does this make sense? Still a bit new to GHC... |
@justb4 thanks for the explanation, you're right I meant adding Having said this, I'm thinking we can design a plugin system which allows users to:
Putting things in plugins allows more flexibility without creating a meta-language/configuration. Thoughts? |
An extensible plugin-system together with standard plugins for healthchecks would be valuable. Thinking this a bit further and staying close to what I think was GHC's initial aim: to check the health of mainly OGC-services: I think having a "checklist" against any OGC-endpoint would be very valuable. Putting specific checks against WWW:LINKs without a reference to their (OGC) endpoint may be a bit diverting from that goal. Currently the default/minimum "checklist" for an OGC-endpoint is to fetch and parse its |
Pending a re-architecture, as to support an extensive checking system (via plugins), at least our GHC instances would be very much helped with a check on any
We could even add a config setting to enable the Exception check |
@tomkralidis should I make the above change with |
@justb4 sorry for the delay. When would an OGC service be registered as a |
@tomkralidis in our setup we register individual OGC requests like GetMap and GetFeature as WWW:LINKs. Currently many error situations are not caught. The OGC: Resources are only checked for Capabilities responses. Those can never catch all individual request-errors. Just like WWW:LINK responses are checked for a <title>, my idea is to check for any <*Exception> for none-image responses. Not ideal but for time being will catch many errors where the Caps and even WWW:LINK give 200 are ok (see presentation). Another option is to introduce an OGC:LINK, as individual requests (GetMap, GetFeature, GetObservation, etc) and always check for Exceptions. Yet, another is to allow single keyword yes/no match as many uptime checkers support. Problem is that that requires a DB mod. |
Perhaps we can keep |
Not clear to me how to silently upgrade the DB, if SQLAlchemy has some mechanism. Also |
ah, ok. Let's go with your proposal in #19 (comment) as first pass and iterate from there? |
We now have a generic Exception-check for WWW:LINK resources. I would like to close this issue and resume in the new issue #82 to implement not just alternative responses but generic OGC-specific checks. |
+1 |
User Story
As a user, admin
I want to configure a resource to expect a certain result from a "test"
So that I can ensure the service is not only alive, but also returning appropriate values.
Discussion
The text was updated successfully, but these errors were encountered: