DEV Community: Gregory Savvidis

Hands-on Monitoring and Alerting guide for Azure resources

Gregory Savvidis — Wed, 18 Jun 2025 09:04:25 +0000

When talking about software quality and detecting flaws early, what immediately comes to mind is writing tests and enforcing them as soon as possible in the CI/CD process. Overall, quality is about ensuring reliability throughout the entire implemented solution. This can be tightly coupled with monitoring resources, tracking performance and setting up early alerting mechanisms. By proactively detecting issues like high CPU usage, memory leaks, or slow response times, teams can prevent failures before they impact users.

In this article we are going to focus on other aspects of quality that do not necessarily require writing and executing tests, but instead utilize metrics and logs provided by the Azure Portal directly and visualize them on an Azure Workbook as an interactive and customizable data visualization tool within Azure Portal.

Setting the scene

Imagine you're part of a DevOps team responsible for maintaining an application hosted on Azure. Before going to production you would like to be in a position to early detect slowdowns and occasional service disruptions. Without a clear picture of the system's health and performance, it's difficult to pinpoint the cause and respond quickly. This lack of visibility and proactive alerting leads to longer downtime and frustrated customers. To address this, we need a robust monitoring and alerting strategy using Azure's built-in tools - starting with identifying where the problem lies, setting up monitoring for relevant metrics and building alerting rules that help us react before users are affected.

Let's say we're responsible for maintaining an Orders API, which handles incoming HTTP requests from a web frontend app to process customer orders. It's hosted on Azure App Service and backed by an Azure SQL Database while Application Insights and/or Log Analytics workspace is enabled. Recently, support tickets have reported that requests to the /submit-order endpoint occasionally take too long or fail, especially during high traffic periods.

To diagnose and resolve this, we want to answer the following questions:

Is the API experiencing high response times or failures?
What's causing the slowdown - CPU/memory pressure, database latency, or something else?
Would it be useful to set up alerts notifying us as soon as performance degrades?

Our approach will follow these steps:

Monitor metrics to understand the API's real-time performance (e.g., response time, request count, error rate)
Enable Diagnostic Logs to capture deeper insights into failures and long-term trends using Log Analytics
Use KQL Queries to investigate patterns and detect anomalies
Create a Workbook to visualize the data in a centralized, interactive dashboard
Define Alerts with thresholds that will notify us when performance degrades or errors spike.

This structured approach ensures we're not just reacting to problems, but actively detecting and preventing them.

Monitor metrics

To begin with troubleshooting the performance issues on /submit-order endpoint, we start by examining the available metrics provided by the Azure App Service that hosts our Orders API. These metrics give us a snapshot of how the application is performing in real time.

Navigate to Metrics in Azure Portal

Go to the Azure Portal
In the search bar, type and select your App Service (e.g., orders-api-prod)
In the left-hand menu under Monitoring, click Metrics.

After clicking on Metrics, we can choose the one we want to monitor and see a graphical representation of it. For example, we can select from the dropdown the Response time and get the following graph:

Other metrics can be utilized to address user complaints and align with our system architecture. For example we can choose from the following:

Server response time - Tells us how long it takes to respond to HTTP requests
Requests - Shows the number of incoming requests. Spikes here may correlate with performance issues
HTTP 5xx errors - Indicates server-side errors, which can be tied to crashes or overload
CPU Percentage - Helps determine if the instance is under CPU pressure
Memory Working Set - Tracks memory usage over time

Monitor logs

While metrics give us a real-time snapshot of the Orders API's performance, Application Insights and/or Log Analytics workspace logs provide a deeper and more granular view of what's actually happening inside the application. Logs can help answer questions like:

Which specific requests are failing and why?
Are there specific error messages or exceptions being thrown?
How is the backend database responding?
What patterns can we identify over time?

Access and Explore Logs

Once logging is enabled and data starts flowing into your workspace:

Go to your Log Analytics Workspace
Click on Logs (reference "Metrics section under Monitoring" image)
In the query editor, you'll see several predefined tables such as:
- AppRequests – HTTP request data (e.g., method, URL, duration)
- AppExceptions – Exceptions thrown by your app
- AppTraces – Custom traces or log messages from your code
- AppDependencies – External calls, e.g., to databases or APIs

In the query editor we use Kusto Query Language (KQL), a read-only query language optimized for fast and efficient data exploration, enabling users to filter, aggregate and visualize large datasets easily.

Here are a few useful KQL queries to start exploring what's happening behind the scenes:

Slow Requests to /submit-order:

Count of Failed Requests:

Top Exception Messages:

Configure Diagnostic Settings

In case the AppExceptions table is not available or any other necessary tables, we can enable Diagnostic settings to send these logs to a specific Log Analytics Workspace.

To start capturing logs, we need to ensure our App Service is sending data to a Log Analytics Workspace:

Go to your Orders API App Service in the Azure Portal
Under Monitoring, click Diagnostic settings
Click Add diagnostic setting
Give your setting a name and check:
- Application Logging
- Request Logs
- Failed request tracing
- AppServiceHTTPLogs

5. Select Send to Log Analytics Workspace and choose an existing workspace or create a new one
6. Click Save

Note: Logs can differ depending on the resource type. For App Services, HTTP logs and application logs are particularly useful.

Once the Diagnostic settings are set, the steps are identical with the previous case where we use KQL query on the Log Analytics workspace.

Workbooks

Understanding metrics, logs, and queries is the first step in enabling Azure resource monitoring. Once this foundation is established, we can analyze individual resources by visiting them and monitoring their behavior. However, for a more comprehensive and centralized approach, it is essential to consolidate metrics and logs in a single, structured view.

One of the visualization tools provided by the Azure Portal is Azure Workbooks. This feature allows users to analyze and visualize data from various Azure resources, logs, and metrics within a single, interactive interface.

Creating an Azure Workbook is a straightforward process. Simply type Azure Workbooks in the Azure Portal search bar, select the service, and click on the Create button. From this point, users can choose to create either an empty Workbook or select from preconfigured templates that cater to common monitoring scenarios.

Regardless of the option chosen, users can click on Edit to customize the Workbook according to their requirements. Within the edit mode, clicking on the Add button allows the inclusion of various visualization components

As seen on the image above, we are able to utilize multiple options to make our Workbook meet our needs:

Text - add markdown or HTML-based text to provide descriptions, explanations, or headers
Query - run Kusto Query Language (KQL) queries to fetch data from Log Analytics, Azure Resource Graph, or Application Insights
Parameters - Define dropdowns, text inputs, or checkboxes to make Workbooks dynamic and interactive
Links & Tabs - Add navigation links or tabs to switch between different sections of a Workbook
Metrics - Fetch real-time Azure Metrics (e.g., CPU usage, memory utilization) and display them visually
Group - helps in organizing content logically, making the Workbook easier to read

We can choose Metrics where the predefined metrics (per resource) are available to be displayed or Query where the same KQL query from before can be applied.

Once the data is loaded we can choose the preferred visualization option:

Charts (area, bar, line, pie, scatter, time)
Grids
Tiles
Stats
Graphs
Maps
Text visualization

Creating custom Workbooks provides a graphical visualization of the resources both for tech and non tech people.

Alerting

Creating Alert rules is a very easy process, as we can simply reuse the same metrics and/or queries that we have used on our Azure Workbook. Following these steps it will allow us to set up an alert:

Click Create Alert rule
Under Scope, select the Azure resource you want to monitor
Under Condition, define the metrics and queries condition that should trigger the alert
Under Actions, select or create an Action Group to define who gets notified
Provide a name and severity level for the alert rule.
Click Create to finalize the alert rule

Conclusion

In conclusion, effective Monitoring and Alerting in Azure is essential for maintaining visibility, performance, and security across cloud resources. Azure Workbooks provide a centralized and interactive way to visualize metrics and logs, enabling teams to analyze data efficiently. Meanwhile, Azure Alerts ensure proactive monitoring by automatically notifying the right people and triggering automated actions when predefined conditions are met. By leveraging Action groups, organizations can streamline alert management and ensure timely responses to potential issues.

Combining these tools allows for a comprehensive monitoring strategy, where teams can track, analyze, and respond to system behavior in real time. With proper Workbook customization, Alert rule configuration, and Action group management, businesses can optimize performance, reduce downtime, and enhance overall cloud reliability.

In case you are looking for a dynamic and knowledge-sharing workplace that respects and encourages your personal growth as part of its own development, we invite you to explore our current job opportunities and be part of Agile Actors.

Schema validation testing with Prism

Gregory Savvidis — Mon, 26 May 2025 10:52:15 +0000

In this article we will discuss schema validation testing using Prism, the differences it has with contract testing and provide an introduction on how we can run it locally.

Current state and issues

Our team is part of an organisation whose aim is to create a cloud-native SaaS bank operating system that will empower banks to evolve to a new era by leaving behind the (old) monolithic approach.

As part of the development lifecycle, when we release our code or product, we need to be as much accurate and confident as possible. One of the common undesired occasions is when we receive customer’s feedback during that lifecycle, which causes a lot of back and forth that actually costs.

The preferred way would be to have a frequent check that will most probably catch errors easier and earlier before reaching the end user. This is where Prism comes into play.

In our case, we had an e2e suite that was running user journeys against microservices. Obviously that is not a one of a kind situation, but due to the architectural structure the microservices were being hit either directly or via proxies (Apigee or Ambassador) so we needed a way to validate the requests and the responses.

One feasible way where we can set up a structure and actually validate the requests and the responses would be with PACT contract testing. This approach will provide the confidence that we seek for but the disadvantage occurs on the amount of time and effort that needs to be spent both from the Consumer and the Provider teams. However, despite having PACT tests, there are cases where we need to be as autonomous as possible and do a validation within the team’s scope. Here is where Prism comes into play.

What is Prism?

Prism is an open-source HTTP Mock & Proxy Server that acts as a transformation and validation layer between the actual and the expected result. It can be used as a contract testing tool as well as a logging one. Prism works in collaboration with OpenAPI v2 and OpenAPI v3, that generates request and response objects based on the provided yaml or json files.

So, in our case, during the execution, we had it validating the called endpoint’s request and response bodies against those generated objects.

In case that any of the examined objects did not match with the expected ones, Prim provides information regarding the error that can be easily used to generate a report.

Schema testing vs Contract testing

Schema testing uses a generalised notation that defines the structure that a request and response are supposed to have at a point in execution time. It validates that a system is compatible to a given schema.

Contract testing, on the other hand, defines how two systems are able to communicate by agreeing on what should be sent between them and providing concrete examples (contracts) to test the agreed behaviour.

The difference between them arises with contract testing going one step further on just defining a schema, requiring both parties to come to a consensus on the allowed set of interactions allowing evolution over time.

In simple words, contract testing is more concrete as it defines strictly how the two systems are supposed to communicate, while schema testing is more abstract as there is a general validation on the expected structure of the request and response payloads.

How to use Prism

Our E2E suite is developed using Spring Boot, so we decided to use the Spring’s Thymeleaf library to construct and customise the reports and then inform the related microservice teams. Using Thymeleaf we created a boilerplated prism-report.html file that was updated on demand when errors occurred during the execution.

As already stated, Prism can help checking for discrepancies between an API implementation and the OpenAPI document that describes. To start of we need to install Prism either locally

npm install @stoplight/prism-cli

or via a Docker image:

docker pull stoplight/prism

The generic run command is:

npx prism proxy <OPEN_API_SPEC_YAML_FILE> <UPSTREAM_URL> — port <PROXY_PORT>

where,

a) OPEN_API_SPEC_YAM_FILE is the yaml file that OpenAPI uses to generate the DTOs

b) UPSTREAM_URL is the host/proxy that the request goes by

c) PROXY_PORT is the assigned port for requests (we can provide any port we want)

How we decided to use it

Finally, in order to make the whole process as autonomous as possible, we created a Jenkinsfile that runs in a daily manner and does the aforementioned validation and then posts the results on a specific Slack channel.

As shown below there is a stage in our Jenkinsfile that runs a bash script to kick off the validation. The whole suite is Dockerised so we have the ability to provide the service(s) as environment variable(s). We can define, with PRISM_PROXY_CHOICE, if we want to run a specific service or all of them.

stage("Run Prism Schema validation") {  
       steps {  
         catchError(buildResult: 'SUCCESS', stageResult: 'UNSTABLE') {  
          script {  
            sh '''  
             if [ "${PRISM_PROXY_CHOICE}" != "All" ] ; then  
              export PRISM_PROXY_SERVICES=${PRISM_PROXY_CHOICE};  
             fi  

            ./ci/execution/dockerRunExecutor.sh  
            '''  
          }  
        }  
      }  
     }

In our bash script we retrieve the OpenAPI specs that Prism will run against. In the code block below, you will observe that we have assigned a specific port for each Apigee/Ambassador service, so we can have the validations isolated and the produced result will be categorised per service. So, for example, if a request is made to any endpoint of firstgateway it will automatically be redirected to localhost:5000 where the Prism Server will perform the schema validation.

OPENAPI_SPECS_PATH=./src/main/resources/openapi-specs  

GATEWAYS_PORT_MAPPING=("firstgateway:5000"  
  "secondgateway:5001"  
  "thirdgateway:5002"  
  "fourthgateway:5003"  
  "fifthgateway:5004"  
  "sixthgateway:5005"  
  "seventhgateway:5006"  
  "eighthgateway:5007"  
  "ninethgateway:5008")  

if [ -z "${PRISM_PROXY_SERVICES}" ] || [ "${PRISM_PROXY_SERVICES}" = "All" ] ; then  
  #If prism prismProxyService is empty then start proxy service for all available gateways  
  echo "Starting prism proxy for all gateways"  
  for gatewaymap in "${GATEWAYS_PORT_MAPPING[@]}"; do  
    GATEWAY=${gatewaymap%%:*}  
    PRISM_PORT=${gatewaymap#*:}  
    prism proxy -h 0.0.0.0 ${OPENAPI_SPECS_PATH}/${GATEWAY}.yaml ${PRISM_UPSTREAM_URL} -p ${PRISM_PORT} &  
  done  
else  
  for prismProxyService in ${PRISM_PROXY_SERVICES//,/ }; do  
    for gatewaymap in "${GATEWAYS_PORT_MAPPING[@]}"; do  
      GATEWAY=${gatewaymap%%:*}  
      PRISM_PORT=${gatewaymap#*:}  

      if [ ${prismProxyService} == ${GATEWAY} ]; then  
        echo "Starting Prism Proxy Server for ${GATEWAY} on port ${PRISM_PORT} listening to ${PRISM_UPSTREAM_URL}"  
        prism proxy -h 0.0.0.0 ${OPENAPI_SPECS_PATH}/${GATEWAY}.yaml ${PRISM_UPSTREAM_URL} -p ${PRISM_PORT} &  
      fi  
    done  
  done  
fi

During execution, we have created a store where we keep information regarding each request (service name, path, method, response). Prism adds an extra sl-violations header, which we use after each test to update a PrismStore that saves the above information plus some extra ones like severity, error location and response code. That store will be used with Cucumber’s AfterAll annotation to complement our custom Thymeleaf report file (as shown in the last image).

After the execution stage is completed, as part of the clean up stage, we generate the report and call sendMessage() method to send a slack notification to ensure that all related teams would be informed soon enough to proceed with any needed updates before the broken functionality is deployed to any client environments.

post {  
      always {  
        script {  

          sh '''  
            ./ci/utils/cleanUp.sh  
          '''  

            publishHTML(target: [  
                allowMissing: false,  
                alwaysLinkToLastBuild: false,  
                keepAll: true,  
                reportDir: 'target/prismproxy/',  
                reportFiles: 'prism_report.html',  
                reportName: 'PrismProxyReport',  
                reportTitles: 'Prism Test Report'])  

            sendMessage()  
          }  
       }  
    }

Conclusion

To sum up, in this article we tried to have our first approach with Prism. We explained what Prism is and what can it bring to the table. We mentioned the key differences between Prism as a schema validation tool and Pact as contract testing tool. Last but not least we explained how we decided to use Prism as part of our E2E suite and generate a report that will provide handy results to any team during the development lifecycle.

In case you are looking for a dynamic and knowledge-sharing workplace that respects and encourages your personal growth as part of it’s own development, we invite you to explore our current job opportunities and be part of Agile Actors!

Branching and merging strategies

Gregory Savvidis — Mon, 26 May 2025 09:00:11 +0000

In this article we will present the most popular branching strategies and their differences, as well as set the scene for teams that want to start using a comprehensive branch naming convention.

Branching strategy

Branches are primarily used as means for teams to develop features giving them a separate workspace for their code, which are usually merged back to the main branch once the new feature is implemented. A branching strategy, therefore, is the strategy that software development teams adopt when writing, merging and deploying code when using a version control system.

Adhering to a branching strategy will help developers to work together without stepping on each other’s toes. In other words, it enables teams to work in parallel to achieve faster releases and fewer conflicts by creating a clear process when making changes to source control.

Branching Strategies

GitFlow strategy

GitFlow is a branching strategy that uses feature branches and multiple primary branches. It is characterized for the long-lived branches and large commits as part of the merging strategy.

There are 5 types of branches: main (previously called master), develop, feature, release and hotfix

main: production-ready code, all branches are merged on main after developed/tested
develop: pre-production code, new features that are being tested
feature: add new features to the code, cut from develop and merge back once completed and reviewed
release: prepare release with finish touches and minor bugs separately from main/develop
hotfix: quickly address changes in main branch, merged to main and develop

Overall it is well-defined and straight forward, but it hides complexity when merging code from development branches to main branch. The two step merging (develop and main) may slow down the development process.

(source: https://skynix.co/resources/navigating-git-branching-strategies-a-comprehensive-comparison)

2. GitHub Flow strategy

GitHub Flow is a lightweight and straightforward branching strategy designed for continuous delivery and deployment. It focuses on simplicity and works best for projects with a single production version. The main branch contains production-ready code (code that is deployable at all times) and feature branches contain new features/bug fixes will merged to main to introduce new work (possibly exist for several days or even weeks).

The main features here are:

main branch: contains production-ready code
feature branches: created from main branch to introduce new functionality
frequent commits and pushes: commit and push changes regularly to ensure progress is saved and visible
pull requests: create pull request to merge the new code from the feature branch to the main branch
deployment: once the new code is merged the main branch in deployed

Overall good when there is a single production version, but does not support multi-version codebase and the lack of short-lived branches will make main branch to be multiple heads in front of the feature branch.

(source: https://skynix.co/resources/navigating-git-branching-strategies-a-comprehensive-comparison)

3. GitLab Flow strategy

GitLab Flow is a simpler approach of GitFlow branching strategy that combines feature-driven development with issue tracking. The main branch is the central branch where all development work converges, while optional pre-production and production branches enable thorough testing and stable deployments.

The main features here are:

main branch: primary branch where all features and fixes are merged
feature branches: created from main branch to introduce new functionality
pre-production branches (optional): branches like test and staging for additional test and validation before merging to main
production branch: a stable branch used to deploy the main branch when ready for production
version branch: create branches like v1 or v2 to maintain and update different versions independently

(source: https://www.abtasty.com/blog/git-branching-strategies)

4. Trunk-Based strategy

Trunk-Based Development is a streamlined and fast-paced workflow where all developers work closely on a single branch, typically the main branch called trunk. Changes are integrated into main frequently, promoting continuous integration and rapid deployment. Feature branches are short-lived and deleted immediately after merging.

The main features here are:

main branch: single source of truth, containing production-ready code at all times
feature branches: temporary branches created for new features or fixes
pull requests: create pull request to merge the new code from the feature branch to the main branch
deployment: once the new code is merged the main branch in deployed

(source: https://www.abtasty.com/blog/git-branching-strategies)

Branch naming strategy

Branches should follow a specific best practices pattern to facilitate collaboration among the team. The following pattern needs to be followed in Azure DevOps, as it distinguishes the structure of the branch name into separate directories under Branches section:

<change_type> / <User Story> — <Description>

prefixes (change type) must be related to the content of the branch
- feature: introducing new feature functionality
- bug: addressing/resolving reported bugs
- chores: maintenance tasks that are not features or bugs (e.g. introduce comments or documentation)
- release: release preparation branch (if we decide to have one)
work item (User Story) must the one from Azure Board
description must be descriptive to help team members to quickly understand the purpose of the branch at a glance.

Prefer lowercase and hyphens for better readability

Example: feature/123456-add-new-functionality

In addition, there are tools that can help in setting the branch naming standards up. Some of the most popular tools are:

Husky: Adds Git hooks to enforce naming rules at pre-commit or pre-push stages, ensuring consistency before pushing changes.
Commitizen: Focuses on commit message conventions but can complement branch naming standards to keep everything consistent.
Git Hooks: Native hooks that can be customised to enforce branch naming patterns during commits, merges, or pushes.
SonarQube: Primarily a code quality tool, but can integrate with Git to enforce branch naming conventions as part of quality gates.
GitFlow: A branching model that can be enforced with tools in Git platforms like GitHub or GitLab, encouraging branch naming conventions such as feature/ or hotfix/.
GitHub Branch Protection Rules: Indirectly enforces branch naming conventions by restricting pushes to specific branches and requiring pull request reviews.
Semantic Release: Automates versioning and change log generation, often used alongside structured branch naming (e.g., feature/, bugfix/, release/) to manage releases automatically.

Code review process

raise PR once the new code is completed and push to a remote branch. On each PR:
- provide a meaningful title (as it will be visible in the history of the main branch)
- provide a description that will quickly describe the purpose of the PR (verbalizing the title of the PR)
- provide the US related to this work
- add mandatory tech related reviewers
refer to team member (preferably with content knowledge) to review
then it comes to reviewers’ responsibility to review and provide feedback on the code

Reviewers’ responsibilities:

verify language/code related patterns and security risks
verify common patterns are followed between old and new code
create clear comments describing the area that needs to be altered
once the comments are resolved, each reviewer needs to state if his/her comments are addressed

Keep in mind that any new code that is about to be merged, needs to have the respective Unit Tests in place (meaning that the Unit Tests will already be part of the code that is about to be reviewed/merged).

Merge policy

Define how changes from different branches are integrated into the main codebase

Types of merging

direct merge: merge directly into main with all commits from feature branch available on main
squash merge: combine all commits into one before merging, to keep main branch history clean
rebase: move changes from feature branch on top of the main branch, creating linear history

Preferably we need to combine squash and rebase, meaning that all commits of the feature branch need to be squashed into single commit and then rebase the main branch on the feature branch and resolve conflicts to keep commit history clean. After resolving the conflicts, a PR can be raised as described above.

How can Trunk-Based strategy and the Merge policy be effective on important aspects

Discover flaws early: By integrating small changes/features into the main branch (trunk) and run specific tasks as part of the CI (as described above) we can minimize the risk of introducing large and hard to find bugs, as we ensure that every small piece of code merged is not causing any issues/failures.
Enable fast and smooth CI/CD process: By having the above mechanism in place, we can merge code quickly and safely (as already mentioned) which gives us the necessary confidence to proceed and deploy the new features in stages above DEV and TEST.
Give some control over what is released when: By combining short-lived branches (and/or a release related branch potentially) with clean commit history, we have the flexibility to point over what is about to be deployed on any stage. A release branch should be the option when a ABN/PROD deployment is about to take place.
Note: any changes/bug fixes that are implemented on release branch, SHOULD also be available on main branch so a PR from release branch to main needs to be raised
Easy Rollback: By ensuring that our main branch (trunk) is continuously stable, reverting to a previous working version is straightforward.

Conclusion

In conclusion, effective branching and merging strategies are essential for maintaining streamlined collaboration and minimizing conflicts in software development lifecycle. By choosing the right strategy teams can align their workflows with project goals, team size, and release cadence. Prioritizing clear guidelines for development process, reduces errors, and promotes a cohesive codebase. Ultimately, the success of any branching and merging approach lies in consistent communication and adaptability to evolving project needs.