The ability to monitor your Sitecore instances is essential. Knowing your application is available and performing in production as expected is critical. To be proactive and respond to changes in performance as opposed to reactive after an incident has occurred, you need a continuous overview of the state of the application and the underlying infrastructure. This involves gathering metrics like CPU, memory usage, and storage consumption as well as any application-related metrics. However, when monitoring a containerized Sitecore instance we cannot apply our usual methods and tools to provide us with all the data we need. In this post, I will show you some of the native tools to help you monitor Sitecore containers.
The docker stats command display a live stream (updated every second) of running containers resource usage statistics docker stats:
- CPU % – the percentage of the host’s CPU the container is using.
- PRIV WORKING SET – refers to the total physical memory (RAM) used by the process.
- NET I/O – the amount of data the container has sent and received over its network interface.
- BLOCK I/O – the amount of data the container has read to and written from block devices on the host.
In this post, I will show you some useful commands and tips for managing your Sitecore containers, images and other docker resources that get created when standing up your containers. The Docker documentation is awesome but it is fairly extensive so I’ll cover some useful commands you should be familiar with.
PS> docker container ls – lists running containers by default, you need to use -a flag to list all containers not just running containers. You can use -f flag to filter containers.
PS> docker container ls -f “name=93x*”
If you want to see the most recently created use -l flag.
If you have built your Sitecore container images and they reside locally and you want to share them with your team the recommended approach is a private registry and there are a few services available. However, Azure Container Registry (ACR) allows you to store docker images in repositories and can take advantage of the azure pipelines to automatically rebuild these images when they need to be updated. In this post, I will show you how to push your local images to a private ACR. This also works if you need to move your images from one private registry to another.
If you are running Sitecore in a container then you’ve most likely switched Docker desktop to Windows container mode. But what if you want to run a Linux container simultaneously? For example, you might want to fire up, JMeter and Grafana on Linux containers. It turns out this is possible in your local development environment and is fairly straightforward.
Don’t worry this is not another post about running Sitecore in a container! No this is a post about getting the Sitecore HabitatHome demo solution up and running quickly and I mean quickly without too much effort. I just happen to use docker in the process. HabitatHome is a solution built using SXA on Sitecore XP following Helix principles. It is extremely useful if you need to showcase SXA capabilities to an existing or a potential new customer.
This is where my good friend Andy Uzick found himself a few weeks ago but had already started down the path of standing up the SXA HabitatHome demo on a temporary Azure PAAS instance not using docker. I thought with docker surely this would be much easier.
Okay, so we all know the difference between Renderings and Final Renderings right? Final renderings were introduced in Sitecore 8 to make it possible to have different layouts for the various language and versions of an Item. Awesome!!
- __Renderings – a shared field where you specify the common layout for all languages and versions of the item.
- __Final Renderings – a versioned field where you specify individual layouts for languages and versions of the item.
I ran into an issue where I needed to modify the __Final Renderings for specific templates. A parameter of a component for a specific language in use on a site, needed to be updated. Continue reading
The JMeter GUI is great for creating and debugging test plans, however, as I have mentioned in a previous post it is not recommended for running your actual test plan. JMeter is simply not designed to produce high loads in GUI mode, as it can consume a lot of resources and potential produce unreliable load test results. While it is recommended you run your actual test in CLI mode, this means you have to wait until the test is complete before you can see the results. While this might be okay for short tests but for longer running soak tests you might want to examine the results while the test is running. In this post, I will show you how this can be achieved using InfluxDB and Grafana.
InfluxDB is a time-series database built for high-performance handling of time-stamped data. JMeter provides a backend listener InfluxdbBackendListenerClient to write the data to InfluxDB. Grafana is an open-source metric analytics and visualization suite. It is most commonly used for visualizing time series data for infrastructure and application analytics. Continue reading