What is New in RavenDB 3.0: Operations–Production View

one of the most challenging things to do in production is to know what is going on ? in order to facilitate that, we have dedicate some time to exposing the internal guts of ravendb to the outside world (assuming that the outside world has the appropriate permissions).

one way to look at that is to subscribe to the log stream from ravendb, you can do it like this:

this gives you the following:

note that this requires no configuration changes, or restarting the server or database. as long as your logs subscription is active, we’ll send you a live stream of all the log activity in ravendb, which should allow you to get a lot of useful insights about what exactly it is that ravendb is doing.

this is especially important if you need to do any sort of trouble shooting, because that is when you need to have logs, and restarting the server to enable them is often out of the question (it would likely resolve the issue you want to understand). and honestly, this is a feature that we need to support customers, it is going to be much easier to just say “let us look at the logs”, rather than having to go over how to configure them, etc. another thing to note is the fact that this can all be done remotely, you don’t have to have access to the physical server. it does require you to have admin permissions on the server, so not any user can do that.

another production view that is available to you is the traffic watcher:

this gives you the option of looking at the requests that are actually hitting the server. it is a subset of information from the logs, but it is usually a lot more interesting to watch. and again, this can be done remotely as well. you can watch all databases, or just a single one.

but most importantly from support perspective is the new debug info! package. and yes, it deserver the bang in the name. what this does is gather a lot of important information from the database, all the current stats, and a lot of stuff that we need to figure out what is going on. the idea is that if you have a problem, we won’t have to ask for a lot of separate pieces of information, you can get it all as a single shot.

oh, and we can also grab the actual stack trace information from your system, so we even know exactly what your system is doing.

in my next post, i’ll discuss one last operational concern, optimizations.