Deprecation of Centralized Logging in Qlik Sense Enterprise on Windows

[Jamie_Gregory]

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! 

Kind regards,

Qlik Global Support 

[rzenere_avvale]

Hey @Jamie_Gregory,

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

[ToniKautto]

@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.

• Modern IT monitoring tools tend to be simpler to integrate with file-based logs than PostgreSQL based log storage
• Archiving logs to data lakes is typically also simpler with files rather than exporting database content 
• Logging database requires additional resources, as logging can be quite intense, especially in a larger deployment. If not managed properly this can become a bottleneck in deployment and cause general performance issues.  
• For critical system problems, the database might also not be fully available. File-based logs are typically preferred or required in parallel, to ensure reliable access for troubleshooting and monitoring. 

[rzenere_avvale]

Thanks @ToniKautto, those are the same reasons why we avoided to deploy it!

Riccardo

[Andrew_Delaney]

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.

[rva_be-terna]

@mountaindude :  Do I remember correctly and Butler SOS relies on Logging DB? What will this mean for realtime monitoring  for Qlik Sense?

Thx,

Roland

[jfkinspari]

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?

[mountaindude]

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

• Butler SOS (with data in InfluxDB) for things like session count, users, apps in memory etc
• Loki for general Sense log monitoring/data extraction. Data stored in Influxdb
• Telegraf to capture Windows metrics (disk metrics, network level in/out metrics, per-core CPU metrics etc). Store data in InfluxDB
• Use Traefik as reverse proxy in front of QSEoW. Traefik can be configured to store connection level metrics in Influxdb => Easy way to detect broken links/URLs in the Sense site, end user network level latency and more
• Some automated tool for simulating end user access to the Sense environment. Selenium is a starting point, but might not be quite flexible enough if you want to log (to Influxdb of course...) page/chart load times in real time. If you do that logging though, you can suddenly alert in real-time when actual end user access is (too) slow. Cache warming can help with some slow-app scenarios, this is a separate thread though.
• Grafana is the go-to tool for creating real-time dashboards based on time-series metrics. True awesomeness.

This became a longer text than anticipated... Anyway, lot's of goodness to be found in those tools!

[rzenere_avvale]

@mountaindude I personally would love to see a blog post about this implementation!

Riccardo

[Jamie_Gregory]

@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.

[Cat_db01]

Will anything be lost if we just switch it off now, assuming no one is using the DB for any applications?

https://community.qlik.com/t5/Knowledge-Base/How-To-Enable-Disable-Centralized-Logging-Mode/ta-p/171...

David