Yet Another Tridion Blog

This post is part of a bigger topic Autoscaling Publishers in AWS . Autoscaling works based on some metrics. For Tridion Publishers we are going to define a Publish_Alarm  in CloudWatch that uses the custom metric Waiting for Publish  in order to trigger the alarm or not. The alarm defines a threshold that, if passed, sets its state to ALARM. Otherwise, if the metric is below, it sets the state to OK. Based on these states, one can define the Scaling Policies of an Auto Scale Group (more about this in a later post). We are going to create an alarm that monitors the custom metric Waiting for Publish . In the first screen of creating the alarm, we select this metric. On the second screen, we specify the threshold and the duration it takes to consider this alarm triggered. For example, I used a threshold of 1000 items that has to be surpassed for 3 consecutive readings (each reading happening at 1 minute interval). We leave the Actions section empty for now. We will ent

This post is part of a bigger topic  Autoscaling Publishers in AWS . In order to define autoscaling of some servers, we need some metrics that we can use to create the autoscaling logic, i.e. when to spin up new instances and when to terminate them. A good measure for this, in Tridion terms, is the size of the Publishing Queue. Namely for Publishers autoscaling, it's useful to look at the number of items in the Publishing Queue that are in the state "Waiting for Publish". The approach is to read this metric somehow from the Tridion Content Manager database and make it available in AWS, so that we can use it later. AWS CloudWatch provides a way to define and/or intercept events that can trigger some code execution. The code executed is supposed to read the Publishing Queue and push the count of items into CloudWatch as a custom metric. 1. Define Lambda Function This function represents the code that is executed by the CloudWatch rule. The function reads the size of