Skip to main content
N
nikhilsvaish1-Visitor
1-Visitor
April 15, 2019
Solved

Thingworx 8.4 store logs in Azure Managed Postgresql DB

  • April 15, 2019
  • 1 reply
  • 1255 views

Hi,

We are deploying Thingworx 8.4 on Azure VM with connectivity to Azure managed Postgres. Our production would comprise of 3 instances of Azure VM running Thingworx platform and all of them connected to one DB (with geo-redundancy soln)

Could someone clarify following questions please?

1. All logs are stored in ThingworxStorage folder. As per the details given in post below, "If ThingworxStorage folder is accidentally deleted, entities and data are secure in the external database".

https://www.ptc.com/en/support/article?n=CS257403&source=snippet

          a) Which DB tables are these logs stored?

          b) Can I configure two postgres DB such that transactional logs are pushed into one DB while Thingworx configurations go into another postgres DB? If yes, then where can I set the DB connection strings?

 

2. I believe the License is loaded in DB. So for running Thingworx Platform on 3 VM instances with one DB, do I need to purchase 3 licenses from PTC as each Thingworx platform would generate its own device id?

 

Best answer by PaiChung

I think you might be mixing up some different logs.

Thingworx uses a local or mapped ThingworxStorage folder to store the Thingworx application/script/etc logs and these are stored as .log files (text files)

These are NOT transaction logs in terms of how Databases have transaction logs.

Thingworx stores all Model information and persisted data in the Persistence Provider (Database)

 

You can map drives so all Thingworx instances use the same ThingworxStorage folder BUT this should NOT be the case for the LOGs folder, because concurrent writes to the same log file can cause hanging threads and issues within the Thingworx platform.

 

You can NOT have multiple active Thingworx instances use the exact same persistence provider, this will cause locking issues that will crash Thingworx.

 

Right now there is no true horizontal scaling in Thingworx where hopefully in the future this becomes a possible scenario.

 

If you look at how Thingworx HA works right now with Zookeeper, it has all Thingworx nodes with Tomcat running and Thingworx initialized, but Zookeeper designates the instance of Thingworx that is actually connected to the Persistence Provider. ie. only one active instance is connected to the database at one time.

 

Hopefully this clears up some things for you.

1 reply

P
PaiChung22-Sapphire IAnswer
22-Sapphire I
April 16, 2019

I think you might be mixing up some different logs.

Thingworx uses a local or mapped ThingworxStorage folder to store the Thingworx application/script/etc logs and these are stored as .log files (text files)

These are NOT transaction logs in terms of how Databases have transaction logs.

Thingworx stores all Model information and persisted data in the Persistence Provider (Database)

 

You can map drives so all Thingworx instances use the same ThingworxStorage folder BUT this should NOT be the case for the LOGs folder, because concurrent writes to the same log file can cause hanging threads and issues within the Thingworx platform.

 

You can NOT have multiple active Thingworx instances use the exact same persistence provider, this will cause locking issues that will crash Thingworx.

 

Right now there is no true horizontal scaling in Thingworx where hopefully in the future this becomes a possible scenario.

 

If you look at how Thingworx HA works right now with Zookeeper, it has all Thingworx nodes with Tomcat running and Thingworx initialized, but Zookeeper designates the instance of Thingworx that is actually connected to the Persistence Provider. ie. only one active instance is connected to the database at one time.

 

Hopefully this clears up some things for you.

Terms & ConditionsCookie settingsAccessibility statement