A few weeks ago I was working in an installation using Sitecore 8.2 update 2 in a Virtual Machine at Azure.
As per you can see in the diagram below, I have 2 Content Delivery behind a Load Balancer to split the traffic.
![Sitecore Azure Environment Load Balancer Blog Vinicius Deschamps](https://viniciusdeschamps.com.br/wp-content/uploads/2020/05/sitecore-azure-environment-load-balancer-blog-vinicius-deschamps.png)
After setting up the Azure Load Balancer, I noticed that the traffic never went through and the Virtual Machines weren’t responding on HTTP, so I have decided to test it locally.
Connect locally, and make sure Sitecore is alive
I connected in both CD1 & CD2, and as expected Sitecore loaded up just fine!
Weird! I might be missed something at Azure Load Balancer level.
Connect to Azure Portal and check Load Balancer configuration
I checked configuration by configuration until reached out Health Probe which is used to verify if the website is available or not
![Azure Load Balancer Health Probe Blog Vinicius Deschamps](https://viniciusdeschamps.com.br/wp-content/uploads/2020/05/azure-load-balancer-health-probe-blog-vinicius-deschamps.png)
So, my HealthProbe is looking for /sitecore/service/heartbeat.aspx, and for some reason cannot use it which is causing the failures to access the website from outside passing by the Azure Load Balancer.
Connect locally, and make sure Heartbeat.aspx works
I connected one more time on both CD1 to access the Heartbeat address http://localhost/sitecore/service/heartbeat.aspx and it was failing with the following error message
![Sitecore HTTP Error 500 Internal Server Error Heartbeat.aspx Blog Vinicius Deschamps](https://viniciusdeschamps.com.br/wp-content/uploads/2020/05/sitecore-http-error-500-internal-server-error-heartbeat-aspx-blog-vinicius-deschamps-1024x352.png)
The same error was occurring on CD2, so let’s dig in!
Check Sitecore logs for detailed information
In Sitecore logs, I have found the following entry
![Sitecore_heartbeat_logs](https://sitecoresysadmin.files.wordpress.com/2017/08/sitecore_heartbeat_logs.png)
At least tells me something, and looks like Heartbeat didn’t like the way one of my databases in ConnectionStrings.config is set but which one?
I have googled the error and found a post from my colleague and Sitecore MVP Glen McInnis named Azure Traffic Manager and Sitecore Herartbeat where he shows an example to exclude LocalSQLServer and Webforms Remote using Sitecore.Services.Heartbeat.ExcludeConnection inside of Sitecore.config
However, at this point, it wasn’t clear which database was the issue – if any! – and I had to do it by trial and error. And as expected the last show did the trick!
Reporting.apikey was the root cause of it, and accordingly to Sitecore Database Connection Strings for Configuring Servers it is optional for Content Delivery and Content Management Servers!
Well, if that’s the case, then I have two options:
1.Comment out directly on ConnectionStrings.config
<!– <add name=”reporting.apikey” connectionString=”” /> –>
OR
2. Add a proper exclusion using Sitecore.Services.Heartbeat.ExcludeConnection inside of Sitecore.config
<setting name=”Sitecore.Services.Heartbeat.ExcludeConnection” value=”LocalSqlServer|reporting.apikey” />
Recommended read
- Sitecore Heartbeat
- Azure Traffic Manager and Sitecore Heartbeat
- Creating an Internet-facing load balancer using the Azure portal
I hope you liked it, and thanks for reading!
And I’ll see you on my next post!
Deixe um comentário