Prestashop: Application healthcheck
Is your feature request related to a problem? Please describe.
More often than not, we need to make sure that a specific PrestaShop instance is healthy and working as expected, that it is accessible, can connect to the DB and generally able to serve as expected.
Thing is, if we want to check a given instance (in HTTP) status (accessing a given page), we'll be redirected to the shop's main domain, which is not the check's purpose.
If I have 3 PrestaShop instances (ps1, ps2 and ps3) for meshop.com, I want to ensure that my 3 instances are up and running, not just meshop.com (where I'm redirected to if not careful).
meshop.com <---------- redirected to main domain
| | then can fall to either 3 of the
LB | prestashop instances
| |
/ | \ |
/ | \ |
P1 P2 P3 <------ Checking instance P3
There are workarounds (playing with Host header, etc..) but those are not always applicable and are still workarounds.
Describe the solution you'd like
Some healthcheck's feature would be :
- A dedicated path (/health for example) to access the healthcheck
- No shop's main domain redirection (accessible through private IP, localhost, internal domain, whatever)
- Checking some PS internals
- Preferably connecting to the shop's DB and performing a simple request (sysdate or else)
- Returning the result OK or NOK following the results of the checks (with a proper HTTP Code)
- Maintenance mode should not disable the healthcheck (for example)
Describe alternatives you've considered
As said, their are some workarounds to perform healthchecks, for example : working with Host header to avoid redirect, which implies access to the shop's DB prior to the call, which can be prone to error if the configuration file is not the same as the application's.
Again, this is a workaround, far from a proper solution : it does not manage the shops' maintenance mode, for example.
Thing is, those may be hard to implement (especially in a containerized environment) and are difficult to maintain (and potentially prone to errors).
Additional context
Nope, but let me know if you need anything else.
djodjo3
All 23 comments
@PrestaShop/prestashop-core-developers WDYT ?
marionf
on 21 Mar 2019
I think it's too late to build this for 1.7.6 but it should definitely be done for 1.7.7
To avoid attacks, I think maybe the endpoint should be protected by some kind of barrier, like a token or something like that.
eternoendless
on 21 Mar 2019
To avoid attacks, I think maybe the endpoint should be protected by some kind of barrier, like a token or something like that.
Honestly, I don't really see why this page should be protected.
First, it should _not_ contain any sensitive data, it's just a health check.
Also, a standard shop being public, any other page _should_ be a better attack vector (either in terms of resources consumption or data access).
But maybe I'm missing something ?
djodjo3
on 21 Mar 2019
If it's a known endpoint it could be used to detect which (approximate) version of PS your shop is based on.
eternoendless
on 21 Mar 2019
This is also something you can do with a custom module.
Also, as @eternoendless said, it needs to be secured!
PierreRambaud
on 21 Mar 2019
The health check could be on the back office side. This allows the entrypoint to be hidden behind an unknown folder.
Quetzacoalt91
on 21 Mar 2019
Maybe better to add this in a native module but not installed by default. It's not common to use an health check :/
PierreRambaud
on 21 Mar 2019
I disagree, @PierreRambaud ... _healthchecks_ are very used and IMHO it's almost required (maybe not for a "final user", but for the developer/sysadmin hosting the shop).
A /healthcheck (or something like that) under the back office side (as @Quetzacoalt91 proposed) sounds very useful for me...
bhean
on 22 Jun 2019
It's a common use for services and app working as microservices where you can define which service is up or down. A simple /healthcheck that returns only a 200 OK if database and configuration are load is pretty useless 馃
If you need this kind of route only for LB, you can create a simple module to do that.
For more details we need time to define what PrestaShop service we want to add in the healthcheck.
PierreRambaud
on 22 Jun 2019
It's a common use for services and app working as microservices where you can define which service is up or down.
I don't really see your point.
First because i've seen and used HC before "microservice" was even a word.
Second, because I don't think that an HC should check and test ALL the app's functionalities and internals. It's not an "unit tests endpoint".
A simple /healthcheck that returns only a 200 OK if database and configuration are load is pretty useless 馃
I honestly don't think it's "useless", but I'm guessing it depends on what you're focusing on.
From a pure application standpoint, maybe not useless, but not much, I can relate.
From a run standpoint, it gives you plenty : your networks are available, your webserver is running, your configurations are correct, your DB is running, the applications internals are OK aswell, etc..
That your whole stack is running, in fact.
Which is far from "useless" from where I stand.
Still, I feel like we have different expectations about an HC purpose.
djodjo3
on 22 Jun 2019
I don't really see your point.
PrestaShop contains many many services. As I said before, if you only want to check your app is responding, you can create a simple module.
It will test Database and HTTP. But this not means your app's working proplery. It's not an healthcheck, it's more a ping like "Hey, are you here".
When I said "microservice" it's more about, what service can be checked and what is the trafic / health of each element:
- database: high trafic
- Front: low usage
- Admin: high usage
- Api: No one connected
- ...
It checks the health of each service like heart bpm, which helps you to define where the problem comes from
PierreRambaud
on 22 Jun 2019
I agree with @PierreRambaud that this would be better in a module. PrestaShop is already a big application with lot and lot of features. Only a small group of our users will use this feature, so if we integrate the HC in the core, it will be a useless feature for most of them.
If a module provide the HC, people who need it can install it, people who do not need it do not install it.
Also it seems you guys are disagreeing on what a HC is 馃槄indeed the definition can differ from people, to the very basic ping "I'm up !" to the complete status check. The "ping" HC would be useful to monitor uptime and detect quickly downtimes while the "full" HC would be useful for advanced monitoring (for example if your app is very slow, maybe your uptime is great but the users will not use it) and performance optimization.
matks
on 22 Jun 2019
@djodjo3 I think building a HealthCheck module is not a lot of work, I'll give it a try. But before diving in the code, can you confirm the following specs would match your need:
1) The module provides an API endpoint /modules/healthcheck/status.php
2) In order to provide flexibility, the admin could configure the API endpoint to be either
- available for all
- require a unique API token (to be configured in Back-Office)
3) The API endpoint performs the following checks: - a few READ queries on standard prestashop SQL tables (customers, orders, products)
- one WRITE query to a dedicated SQL table (healthcheck_logs) (maybe using
Configuration::set(...)? this would help checking Configuration class is working as expected)
4) If previous operation were carried successfully, API endpoint returns a HTTP 200 JSON document{"status":"ok"}. If any of the previous operation failed, API endpoint returns a HTTP 400 JSON document{"status":"nok"}
I dont think we need more for a basic implementation.
matks
on 22 Jun 2019
@djodjo3 馃啓 馃槃 ?
matks
on 16 Jul 2019
I agree with @djodjo3 for the healthcheck. We have the same needs.
Healthcheck is mainly to remove a server from a loadbalancer, so we just need to confirm that apache, mysql is running and basic prestashop configuration is ok.
To me what @PierreRambaud offered is more a status availability page. It's a different need.
The main problem to do it with a module is that currently we cannot request each server by its internal, we will be redirected to the canonical url.
So there is a need to have a way to disable canonical redirection on a very specific healthcheck page only.
cedricfontaine
on 10 Oct 2019
I think it's too late to build this for 1.7.6 but it should definitely be done for 1.7.7
To avoid attacks, I think maybe the endpoint should be protected by some kind of barrier, like a token or something like that.
1.7.7 is frozen very soon so if we want to do it, we better hurry up 馃槃
matks
on 30 Jan 2020
The main problem to do it with a module is that currently we cannot request each server by its internal, we will be redirected to the canonical url.
So there is a need to have a way to disable canonical redirection on a very specific healthcheck page only.
About this: can you explain further how you setup the loadbalancer and the different shops ?
Because in a standard reverse proxy configuration, the strategy which defines which server you hit is managed by the reverse proxy settings, not PrestaShop 馃 ?
matks
on 30 Jan 2020
Same here:
Thing is, if we want to check a given instance (in HTTP) status (accessing a given page), we'll be redirected to the shop's main domain, which is not the check's purpose.
If I have 3 PrestaShop instances (ps1, ps2 and ps3) for meshop.com, I want to ensure that my 3 instances are up and running, not just meshop.com (where I'm redirected to if not careful).meshop.com <---------- redirected to main domain | | then can fall to either 3 of the LB | prestashop instances | | / | \ | / | \ | P1 P2 P3 <------ Checking instance P3
I dont see how, on either Module or PrestaShop side, we can control the load balancing mechanism 馃
matks
on 30 Jan 2020
I dont see how, on either Module or PrestaShop side, we can control the load balancing mechanism
@matks Actually, you don't. The load balancer is used to manage ingress traffic (from public to private network).
In this case, we want to monitor each _private_ instance health - and by default, accessing the instance directly, you're redirected to the main shop URL, through the LB, and then you don't monitor the private instance you targeted :/
djodjo3
on 30 Jan 2020
Exact.
For example, in AWS, the health check option is really limited and the only way to do it is to call the private instance and check the http response. If we don't receive HTTP 200, the private instance will be removed.
cedricfontaine
on 30 Jan 2020
All right, so the target is to build a healthcheck module (easy) that is able to provide a pingable URL which disables the canonical URL redirection 馃槃
matks
on 3 Feb 2020
Hello @sowbiba what's the status of this issue ? Are you still working on it ?
colinegin
on 14 May 2020
@colinegin The PR is actually gone in QA. ;)
Progi1984
on 27 May 2020
Related issues
matks
路
3Comments
PrestaShark
路
3Comments
marionf
路
3Comments
esistgut
路
3Comments
prestonBot
路
3Comments
Most helpful comment
@matks Actually, you don't. The load balancer is used to manage ingress traffic (from public to private network).
In this case, we want to monitor each _private_ instance health - and by default, accessing the instance directly, you're redirected to the main shop URL, through the LB, and then you don't monitor the private instance you targeted :/