I think I’m going to need further details in order to investigate this issue. Is the error that you’ve posted still the only output that you receive from your logs or have you received any subsequent errors since then? If not, could you please confirm that the services for the Gateway, the Dashboard and the Pump are running on your server? Can you also please confirm as to whether Redis and MongoDB are running and that your Dashboard has been configured with the correct host name (details regarding the installation process can be found here).
Are the settings in your tyk.conf file the same as they were when you raised that issue last Friday? If so, I noticed that the enable_analytics option was set to false which might explain this error in your case. If setting this to true and restarting Tyk doesn’t fix the issue, there might be a problem with your Redis connection.
Yes, data from the Gateway is originally stored in Redis. It is then pushed into MongoDB by the Pump and the Dashboard uses the analytics data when outputting logs.
An issue in MongoDB could potentially explain this. I’m not sure if we would be able to help you with performance monitoring in MongoDB specifically (I think there are a few third party tools available that could help with this). It may be worth adding more RAM to your instance however. We usually recommend that the server MongoDB has been installed on use an SSD as well for an improved performance.
What is likely to have happened here is that the data was recorded and was sent to your mongo DB.
However, MongoDB when it does a query over a range will try to load the entire working set into memory if there is not enough ram for the query then it willy ale a long time and potentially time out.
Since detailed logging generates massive amounts of data your tyk_analytics collection will balloon and take most of your available ram, causing simple queries to fail.
Now the tyk_analytics collection where this data is stored is only used for complex queries and the log browser, not for aggregate high level views used in other parts of the dashboard.
This means that the collection can be safely converted to a capped collection, which will basically turn it into stack where old records are discarded as the cap is reached.
Converting to a capped collection means that you will no longer have the timeouts if the cap is smaller than your RAM.