Troubleshooting
Debugging
You will find instructions on how to set up a development environment on the contribute section.
Also keep in mind that this is just a small-ish extension of Superset. You can refer to Superset Contribute section for more information about how to set up a development/debugging installation. Then follow our manual install section to figure out how to activate our customizations. And start your superset instance with a debugging tool (your python IDE, pdb etc).
Logging
There are at least 3 logging pipes:
Superset app logging
Basically, the logs are sent to stdout. It is relying on standard python logging package but passing through Superset's own logging class Cf config.py .
The geOrchestra customizations provides with an alternative logging class used in replacement. You can use this basis to add any customizations you need.
You can change the logging level by changing the LOG_LEVEL config value ot providing the eponym environment variable.
To know more about logging in python, have a look at
Gunicorn access logs
Gunicorn also writes access logs. Those are configured in the entrypoint when running docker/kubernetes and can be configured by setting the corresponding envivonment variables.
When running it as a classic service, you'll have a similar configuration.
Event logger
Superset implements a separate logging for all superset events. Superset stores it by default in the applicative database (in your superset schema). This behaviour is configured in Superset main config.py file.
By default geOrchestra overrides this in https://github.com/georchestra/superset/blob/main/config/superset/superset_georchestra_config.py#L84 and disables the event logging
Why not use the DBEventLogger ?
By default, Superset uses a DBEventLogger, storing all actions on
Superset, in the DB.
Problem is that it can bloat the DB after some time.
And since we now have to allow writing to the event logs to Public role
to avoid having error messages (see related commit), writing logs in the DB
doesn't feel that safe anymore.
We can alternatively use the StdOutEventLogger that logs those events
on stdout.
By default, the NullEventLogger doesn't log them at all,
it will be up to the platform admins to see if they want to log them and how.
On the longer term, we'll probably be considering adding back some logging mechanism for analytics purposes.
"Chunk load error"
You might encounter sometimes errors when loading a Superset page. For instance a "chunk load error". A priori in the situation where your geOrchestra instance uses the Gateway (not reported for now with the Security Proxy).
Those are quite annoying. But can be avoided.
Looking at the gateway logs, you will likely notice PrematureCloseException or similar exceptions everytime a chunk load error happens. The issue is Superset/gunicorn closing connections while upstream reverse-proxies are still thinking them active. Setting the env var GUNICORN_KEEPALIVE to 30 (seconds) does the trick. Maybe we don't need to increase them that much, but the default, 2s, seems really too short (and is documented in https://docs.gunicorn.org/en/stable/settings.html#keepalive).
In any case, we need to make sure that:
gunicorn keepalive >= gateway max-idle-time >= traefik/nginx ingress idleConnTimeout.
Ref. Superset issue 28259