curl "https://beta-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/api" -H "Accept: application/json, application/vnd.oai.openapi+json; version=3.0"
application/geo+json.
application/gml+xml;profile=\\\"http: //www.opengis.net/def/profile/ogc/2.0/gml-sf2\\\";version=3.2" , try to get that right...
curl "https://beta-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/collections/selite/items" -H "Accept: application/json"
{
"code" : "500",
"description" : "HTTP 406 Not Acceptable"
}
"Accept: application/json", but maybe this is a direction with many interworking issues (over f=json).
Accept: headers via issue #313 .
User-Agent and compression Accept. Upgraded OWSLib to 0.20.0 (now WFS auth should work) and enhanced OGC OAFeat Probe support. German translation patches contributed by @astroidex.
GHC_RUNNER_IN_WEBAPP=True. The default for Docker is False. There has been some discussion and an issue around this: #303. We are a bit cautious to change this default as it may silently affect existing installs. Especially in a Docker deployment it is good practice to separate the 3 main GHC components (UI, Healthcheck Runner and database). docker-compose is a convenient way, see this example.
Check. You could write a Check Plugin for a specific 401-Check. Out of my head: the Run report would specify the specific HTTP-error code. I think both your options apply: AFAIK in HTTP (Basic, Token) Authentication is a one-time request/response: if there are no auth-headers or if the auth-headers contain the wrong credentials, a 401 response is returned. GHC supports two Auth methods: Basic and Bearer Token per Resource (endpoint) which can be configured in the UI and will be sent with each HTTP-request in the HTTP headers.
@MichaelOstling thanks, that is actually a scenario (add CSW and then monitor referenced OWS services) proposed at a FOSS4G presentation (think by GeoCat). This would require a new (CSW) Probe Plugin. This is similar to the GeoNode monitoring: a GeoNode endpoint is added and then all its referenced OWS-es endpoints are automatically fetched and added to a GHC instance. There is already a CSW Resource Type.
Export/Import JSON is really only used for Unit-testing, it is quite radical: wiping all existing data in the DB.
There is no API yet, it is our next-planned big Feature. Lack of time and funding. There is a spec already:
https://github.com/geopython/GeoHealthCheck/wiki/API-Specification .
@KoalaGeo yes, interesting question. Having some thoughts: there are many many FOSS monitoring frameworks, Prometheus/Grafana (I use mostly), Icinga, Datadog, etc. And Zabbix offcourse. True, a lot of what GHC is does is covered (scheduling, data collection, notification, visualization). The heart of GHC are the often extensive Probes/Checks for OGC and other APIs (like GeoNode). With a lot of complex work delegated to OWSLib. These would all have to be (re)written (for Zabbix Agent2) in GoLang. Plus the Probe/Check configuration-capabilities are extensive.
On the other hand integrations with existing monitoring systems has been projected for GHC at the level of data sampling for existing monitoring systems. The current GHC API already allows for summary data, so a simple core-Zabbix command-based shell extension could at least do a curl-type GHC API call and e.g. report number of failing Resources or even more. Even GHC Probes could be executed via commands, so that level of integration is also possible.
Hello Humans - I'm stucked starting runner bcs. pytz doesnt know Europe/UTC... any hints where to start troubleshooting?
pytz.exceptions.UnknownTimeZoneError: 'Europe/UTC'
1 reply