env var or flag to enable debug logs

[midhunkrishna]

The problem:

I have an OSRM server running in production and returning 207 error code. Now, if I look into the log file, the data is not very useful in debugging what might be the reason why this is happening ( since log level is info ).

From the issues on this repo itself, to get debug logs, I have to recompile the binary with debug flags. This, of course, is not an option with the production server.

If there is an option to toggle the log level via an ENV variable or a flag, that will be helpful.

[danpat]

We never return code 207, we only return 200, 400 and 500. I suspect debug logging would not help you here, it sounds like your requests are not making it to the server.

OSRM debug logging is currently disabled at compile time, for performance reasons. If I get a chance, I'll do some profiling - measure the cost of enabled-but-not-visible debug log messages. If the hit is negligible, we could consider doing this and making logDEBUG always compiled in, but not visible by default.

[wangyoucao577]

@danpat I did some profiling for the enable/disable compile control for the debug logs:

Test env

• aws r5.2xlarge (8 cpus, 64GB memory)
• latest us-west OSM, about 1.7GB
• osrm binaries build type: default(i.e. -DCMAKE_BUILD_TYPE=Release)
• algorithm: MLD
• commands
  • time osrm-extract -p osrm-backend/profiles/car.lua us-west-latest.osm.pbf >1.log 2>&1
  • time osrm-partition us-west-latest.osrm >2.log 2>&1
  • time osrm-customize us-west-latest.osrm >3.log 2>&1
  • NOTE: use >1.log 2>&1 redirect logs to file to reduce output to possiblity bad performance on write to stdout/stderr.

Benchmark

branch/commit	osrm-extract	osrm-partition	osrm-customize
master-68dcab7	real 8m39.028s user 41m53.692s sys 1m13.904s	real 5m11.227s user 26m24.147s sys 0m24.994s	real 1m16.134s user 7m5.574s sys 0m10.759s
feature-1ada466	real 8m38.764s user 41m49.624s sys 1m13.393s	real 5m12.573s user 26m9.168s sys 0m29.120s	real 1m15.741s user 7m2.858s sys 0m10.665s
feature-1ada466 with extra flag -l DEBUG	real 8m42.247s user 41m56.933s sys 1m12.340s output debug logs: 1459	real 5m12.860s user 26m27.149s sys 0m24.648s output debug logs: 1	real 1m15.749s user 7m3.277s sys 0m10.805s output debug logs: 0

The only differences between master-68dcab7 and feature-1ada466 is the commit 1ada4660817139c436e9afe13e8360d2458dc5c3 which removes compile-time-control for debug log.

Conclusion

• There's no significant time cost increasing by remove the compile-time-control for debug log, performance is acceptable.
• Also, the debug logs are are not mass(only totally 1460 for 1.7GB us-west OSM), it will NOT affect a lot of performance in theory.

I think it's totally ok to remove the compile-time-control for debug log based on above benchmark. I'll try to file a PR to remove the compile-time-control since the debug logs are very helpful for issues analysis.

[wangyoucao577]

@midhunkrishna Now you can always compile your release mode binary with -DENABLE_DEBUG_LOGGING=ON on latest master. Then you're able to get debug log by runtime option -l DEBUG on production env without recompiling.