In the previous post in this series on monitoring Sitecore containers I showed you how to instrument your Solr container, in this post, I’ll show you how to instrument the Sitecore SQL container and expose metrics for Prometheus to scrape.
There are several SQL exporters available in the Prometheus community some of these are SQL agnostic. Those that support MSSQL, either obtain their metrics via performance counters or by querying SQL directly. I recommend you review the different exporters and then choose an exporter that meets your specific requirements or you create your own custom exporter.
Lets take a look some of these exporters and see if they would be a good fit for exporting metrics from Sitecore SQL container.
So I’ve been involved in several projects where I’ve had to setup geo-distributed Sitecore environments and/or scale the Sitecore Content Management and Content Delivery roles along with the plethora of roles XP Scaled provides. I’ll share some of those experiences here and some hurdles and how to overcome them.
Geo-Distributed Content Delivery
You can configure one or more content delivery servers for improved scalability and better performance. If you expect to have high numbers of visitors or want to configure servers in different geographic locations, ideally nearest to your customers.
In order to reduce latency you will want your web database in the same region as your CD. If you have multiple clusters in different regions you will need to consider how you plan to keep these web dbs up-to-date. Normally you would implement multiple publish targets, however Sitecore also supports geo-replication of the web database. See my post on Publish Targets vs Azure Geo replication for more details.
What other services and or roles do you need to support Content Delivery and where should these be located? More on this later… Continue reading →
When designing for a Geo-Distributed Sitecore implementation you have a decision to make on how you are going to handle updates to your Web databases located in different regions.
Traditionally you would set up a multiple publishing targets – one for each region and publish to each target. However, Sitecore supports Azure Active Geo-Replication of the read-only web database for Sitecore 9.0 and above. Which means you only need to publish to one web database and let Azure SQL replication update the other regions.
While this still experimental it offers faster publishing as you only publish to one target and let Azure handle the updating to the other regions.
Shared Web System DB
For this to work you need to setup a shared web system database to contain a copy of the EventQueue and Properties table, as these cannot be shared and must remain common amongst each Content Delivery role.
I recently presented at Atlanta Sitecore Usergroup and gave a demo using Data Exchange Framework (DEF) 2.0 and the SQL Provider – to read customer records from a SQL table and create items in Sitecore. You can read more about the DEF 2.0 here. In this follow-up post, I’ll walk through the DEF configuration required for the demo.