Hello Qlik Users!
We would like to announce the deprecation of the Centralized Logging service in Qlik Sense Enterprise on Windows by the end of 2021.
We will remove the Centralized Logging service to make Qlik Sense Enterprise on Windows more reliable and performant.
Logging will continue to be available in file format. We are updating the monitoring applications to support this change and provide you with the same insights.
With Qlik Sense Enterprise May 2021 and on, a fresh installation of Qlik Sense Enterprise on Windows will not deploy Centralized Logging.
We will provide a firm date for the removal of the service later this year.
As always, feel free to contact us if you have any questions.
Thank you for choosing Qlik!
Qlik Global Support
Could we know why is it going to be deprecated?From this post I see there are some issues with latest releases of PostgreSQL 12... but is there any other reason?Knowing them could be helpful, to explain to customers why it is going to be removed (even if, in most of our environments, we avoided installing it)Many thanks,RIccardo
@rzenere_avvale deprecation of centralized logging is not related to the PostgreSQL database.
My experience is that centralized logging has had limited value for most customers. These would be my main explanation of why database logging is not required in general.
Thanks @ToniKautto, those are the same reasons why we avoided to deploy it!Riccardo
Additionally, the logging service never captured all of the logs from the system. None of the microservices have ever used it, so it was never able to fully replace file based logging.
Given the growing number and importance of these services, it would be imprudent to rely only on the contents of the logging database.
@mountaindude : Do I remember correctly and Butler SOS relies on Logging DB? What will this mean for realtime monitoring for Qlik Sense?
I've recently added an extra measure to the central logging settings, so it also includes a certain disk drives free space %-ratio to the performance logging. That is in addition to the current performance measures, where some of them only exist in the centralized logging database - not in the filelogs.
How do you advice to proceed in order to expose such a measure in the future?
Wow, this is shaping up to be the most interesting thread of the week!
@rva_be-terna Good question. Butler SOS does close to real-time monitoring of QSEoW, but achieves this mainly by querying the health check REST endpoint."Mainly" means that the main metrics come from the health check API. But you're right - log db is queried too in order to get warnings/errors.
My experience is that it's *increadibly* useful to get a time-correlated view of a) metrics for # user sessions/RAM/CPU/what apps are in memory and b) warnings/errors. Seeing those side-by-site enables you to quickly identify what might have caused some sudden drop in available RAM, users being kicked from a proxy etc.
Not having access to a central log db means Butler SOS will have to be adapted. Not too difficult though. The obvious solution would be to deploy log extenders (=XML files that tell Sense's logging framework to forward select events to Butler SOS). That way Butler SOS would still get the warnings/errors - in fact this setup would be closer to real-time than today's log-db solution.
On a related topic. I've played around a fair bit with Loki for processing of Sense logs. Loki monitors the log files, send them off to InfluxDB from where the metrics can be visualised using Grafana. If you prefer Prometheus instead of InfluxDB that works too, of course.
This solution is actually pretty awesome... Loki monitors the Sense log files and feed select metrics into Prometheus. True, you are looking at some serious regex hacking to get Loki properly configured, but if you are like me and don't mind crazy regex syntax, that's ok.I'll see if I can get around to writing a blog post about this, I suspect it could be of use for others too.
Butler SOS and Loki/... would be slightly overlapping, but not completely so. Butler SOS is way easier to set up and get going, and also give some metrics that are kind of hard to get using Loki.The best monitoring setup for QSEoW is IMHO
This became a longer text than anticipated... Anyway, lot's of goodness to be found in those tools!
@mountaindude I personally would love to see a blog post about this implementation!Riccardo
@jfkinspari You should put a request into Ideation to let PM's know what you're looking for. They might have some suggestions as well.
Will anything be lost if we just switch it off now, assuming no one is using the DB for any applications?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.