Specify 7.12.1.1, docker, multiple collections on one host. I'm trying to keep the server logs clean enough that a new WARNING or ERROR means something, and a census of one day's logs since a recreate shows most of the volume is routine operations logged at WARNING. Counts are per container for one working day.
Every save that touches preparations or a collection object logs ten specifyweb.specify.api.validators warnings, field "X" does not exist in <class ...>, for fields the frontend always sends: totalcountamt, actualtotalcountamt, currentdetermination, ismemberofcog on Collectionobject; actualcountamt, isonloan, isongift, isondisposal, isonexchangeout, isonexchangein on Preparation. 31 saves in one collection = 310 warnings. If these are known virtual fields, they should be skipped silently or logged once at DEBUG.
Every gunicorn worker boot logs specifyweb.backend.trees.apps: Failed to retrieve default tree creation information. and specifyweb.backend.setup_tool.apps: Failed to retrieve last active setup task. With --max-requests recycling that is dozens per day per container, on a healthy instance where nothing failed. run_key_migration_functions also logs each "Running ..." step at WARNING, and migration_utils.schema_writer logs Table does not exist in latest state of the datamodel, skipping Schema Config seven times per boot. Successful, expected steps belong at INFO.
specifyweb.specify.models_utils.relationships: Updating independent collections via the API is experimental and the structure may be changed in the future fires on ordinary form saves (41 in one collection in one day). If it is aimed at API integrators, a warning per request to the admin log is the wrong place for it.
django.request: Forbidden: /notifications/messages/ appears whenever a logged-out tab keeps polling notifications; a client that stops polling on 403, or a 204, would end it.
None of these are actionable by an administrator, and together they are over 90% of our WARNING volume. Missed some real items in the noise. Could we tidy this up? Thanks!
Specify 7.12.1.1, docker, multiple collections on one host. I'm trying to keep the server logs clean enough that a new WARNING or ERROR means something, and a census of one day's logs since a recreate shows most of the volume is routine operations logged at WARNING. Counts are per container for one working day.
Every save that touches preparations or a collection object logs ten
specifyweb.specify.api.validatorswarnings,field "X" does not exist in <class ...>, for fields the frontend always sends: totalcountamt, actualtotalcountamt, currentdetermination, ismemberofcog on Collectionobject; actualcountamt, isonloan, isongift, isondisposal, isonexchangeout, isonexchangein on Preparation. 31 saves in one collection = 310 warnings. If these are known virtual fields, they should be skipped silently or logged once at DEBUG.Every gunicorn worker boot logs
specifyweb.backend.trees.apps: Failed to retrieve default tree creation information.andspecifyweb.backend.setup_tool.apps: Failed to retrieve last active setup task.With --max-requests recycling that is dozens per day per container, on a healthy instance where nothing failed.run_key_migration_functionsalso logs each "Running ..." step at WARNING, andmigration_utils.schema_writerlogsTable does not exist in latest state of the datamodel, skipping Schema Configseven times per boot. Successful, expected steps belong at INFO.specifyweb.specify.models_utils.relationships: Updating independent collections via the API is experimental and the structure may be changed in the futurefires on ordinary form saves (41 in one collection in one day). If it is aimed at API integrators, a warning per request to the admin log is the wrong place for it.django.request: Forbidden: /notifications/messages/appears whenever a logged-out tab keeps polling notifications; a client that stops polling on 403, or a 204, would end it.None of these are actionable by an administrator, and together they are over 90% of our WARNING volume. Missed some real items in the noise. Could we tidy this up? Thanks!