[SERVER-9497] Quota exceeded error (12501) should be in mongo log Created: 29/Apr/13 Updated: 11/Jul/16 Resolved: 29/May/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Logging |
| Affects Version/s: | 2.4.3 |
| Fix Version/s: | 2.2.5, 2.4.5, 2.5.1 |
| Type: | Improvement | Priority: | Critical - P2 |
| Reporter: | Chris | Assignee: | Andrew Emil (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
MongoDB, Linux, Java driver |
||
| Participants: |
| Description |
|
The following two assertions are not being triggered in {logLevel: 0}. My assumption would be the two following events are significant enough to warrant a log entry in all cases:
Thank you! |
| Comments |
| Comment by Daniel Pasette (Inactive) [ 31/May/13 ] |
|
commit 819500d00d46fe0e69ce4cfb4398f04ce79b8471 Added logging preceding assertion in database.cpp for exceeded quotas |
| Comment by Andrew Emil (Inactive) [ 29/May/13 ] |
|
link to commit: https://github.com/mongodb/mongo/commit/34ee0f47bee10c3e2bddbd8c1c733de5b6b780bc |
| Comment by Eliot Horowitz (Inactive) [ 08/May/13 ] |
|
I think your requirements are sufficiently different than that of a typical deployment, that log level 1 might actually be correct. uasserts, dup keys for example are definitely not things we can put at default log levels. |
| Comment by Kurt [ 07/May/13 ] |
|
Log level 1 isn't really a feasible thing for us to run. Would you actually recommend that for a production DB? We get frequent support tickets where customers say "MongoDB has lost my data", these assertions are generally how we talk them off the ledge. I'm not sure how to convince them that Mongo is doing a good job if we can't reasonably go back and see what's been happening on production DBs. |
| Comment by Eric Milkie [ 07/May/13 ] |
|
All user asserts are available at debug log level 1. |
| Comment by Ben [ 07/May/13 ] |
|
I would also say that having all the user asserts, even the duplicate key, are important for us to have in the logs. We can't get access to the customers driver to see what errors are firing so in supporting a customer if we don't have info in the logs we can't help them at all. The duplicate index is one that happens from time to time too. We get customers who complain that writes don't save ... we go and find these in the logs and help them find that they were saving dup keys. So they are all valuable to us running mongo successfully for our customers. Will there be any way for us to keep these on, even if it means a config option? |
| Comment by Kurt [ 07/May/13 ] |
|
We're having difficulty troubleshooting problems for some users without these showing in the logs, can you make these logged at the default log level?
|
| Comment by Eliot Horowitz (Inactive) [ 01/May/13 ] |
|
I think quota exceeded makes sense in the logs. Duplicate key errors I definitely do not think belong there. You wouldn't expect to see duplicate index or foreign key violations in a relational database log by default, and I think the same principles apply here. |
| Comment by Chris [ 01/May/13 ] |
|
Timeline / response? |
| Comment by Chris [ 29/Apr/13 ] |
|
Although MongoDB drivers recently changed to safe writes by default, I would make a distinction between read errors and write errors. Read errors can log at level 1, will cause odd behavior at the application level, but are not destructive to data. In my opinion, all write errors should be logged at the default log level. I consider write errors destructive to data, and should be available in an audit log of a database – even at default log level. edit: repaired grammar. |
| Comment by Scott Hernandez (Inactive) [ 29/Apr/13 ] |
|
Currently all user asserts (errors) are logged at level 1. This includes things like the ones you have listed as well as more, like invalid dbrefs, too many fields in a compound index, validation checks when changing replication configs, regular expression too long, distinct results larger than 16MB, can't remove from a capped collection, etc. These are all errors returned to clients when they make the request which causes the error state. Do you want all of these to be logged at the default level (0)? |