Asset 49

Simplified Log Monitoring using Swarmpit for a Docker Swarm Cluster

by Devops

Introduction

In our earlier blog post A Simpler Alternative to Kubernetes – Docker Swarm with Swarmpit we talked about how Docker Swarm, a popular open-source orchestration platform along with Swarmpit, another open-source simple and intuitive Swarm Monitoring and Management Web User interface for Swarm, we can do most of the activities that one does with Kubernetes, including the deployment and management of containerized applications across a cluster of Docker hosts with clustering and load balancing enabling for simple applications.

We know monitoring container logs efficiently is crucial for troubleshooting and maintaining application health in a Docker environment. In this article, we explore how this can be achieved easily using Swarmpit’s features for real-time monitoring of service logs with its strong filtering capabilities, and best practices for log management.

Challenges in Log Monitoring

Managing logs in a distributed environment like Docker Swarm presents several challenges:

    • Logs are distributed across multiple containers and nodes.
    • Accessing logs requires logging into individual nodes or using CLI tools.
    • Troubleshooting can be time-consuming without a centralized interface.

Swarmpit's Logging Features

Swarmpit simplifies log monitoring by providing a centralized UI for viewing container logs without accessing nodes manually.

Key Capabilities:

    • Real-Time Log Viewing: Monitor logs of running containers in real-time.
    • Filtering and Searching: Narrow down logs using service names, container IDs, or keywords.
    • Replica-Specific Logs: View logs for each replica in a multi-replica service.
    • Log Retention: Swarmpit retains logs for a configurable period based on system resources.

Accessing Logs in Swarmpit

To access logs in Swarmpit:

    1. Log in to the Swarmpit dashboard.
    2. Navigate to the Services or Containers tab.
    3. Select the service or container whose logs you need.
    4. Switch to the Logs tab to view real-time output.
    5. Use the search bar to filter logs by keywords or service names.

Filtering and Searching Logs

Swarmpit provides advanced filtering options to help you locate relevant log entries quickly.

    • Filter by Service or Container: Choose a specific service or container from the UI.
    • Filter by Replica: If a service has multiple replicas, select a specific replica’s logs.
    • Keyword Search: Enter keywords to find specific log messages.

Best Practices for Log Monitoring

To make the most of Swarmpit’s logging features:

    • Use Filters Effectively: Apply filters to isolate logs related to specific issues.
    • Monitor in Real-Time: Keep an eye on live logs to detect errors early.
    • Export Logs for Advanced Analysis: If deeper log analysis is required, consider integrating with external tools like Loki or ELK.

Conclusion

Swarmpit’s built-in logging functionality provides a simple and effective way to monitor logs in a Docker Swarm cluster. By leveraging its real-time log viewing and filtering capabilities, administrators can troubleshoot issues efficiently without relying on additional logging setups. While Swarmpit does not provide node-level logs, its service, and replica-specific log views offer a practical solution for centralized log monitoring.

This guide demonstrates how to utilize Swarmpit’s logging features for streamlined log management in a Swarm cluster.

Optimize your log management with the right tools. Get in touch to learn more!

Contact us

Frequently Asked Questions (FAQs)

No, Swarmpit provides logs per service and per replica but does not offer node-level log aggregation.

Log retention depends on system resources and configuration settings within Swarmpit.

Yes, for advanced log analysis, you can integrate Swarmpit with tools like Loki or the ELK stack.

No, Swarmpit does not provide built-in log alerting. For alerts, consider integrating with third-party monitoring tools.

Yes, Swarmpit allows keyword-based filtering, enabling you to search for specific error messages.

Asset 44

Guide to enable Single Sign On(SSO) between Grafana, GitLab and Jenkins using Keycloak

by Devops

Introduction

As businesses scale their operations, centralised identity management becomes crucial to ensure security and operational efficiency. Keycloak, a powerful open-source Identity and Access Management (IAM) solution, simplifies this by offering Single Sign-On (SSO) and centralized authentication. This guide will walk you through integrating Keycloak with Grafana, GitLab, and Jenkins, streamlining user management and authentication.

In this guide, we will:

    • Configure Keycloak as the Identity Provider (IdP).
    • Set up OAuth2/OpenID Connect (OIDC) for Grafana, GitLab, and Jenkins.
    • Provide detailed troubleshooting tips and insights to avoid common pitfalls.

By following this guide, you’ll have a unified authentication system, ensuring that users can access Grafana, GitLab, and Jenkins with one set of credentials.

Keycloak Overview

Keycloak is an open-source Identity and Access Management (IAM) solution that provides SSO with modern security standards such as OpenID Connect, OAuth2, and SAML. It supports various identity providers (e.g., LDAP, Active Directory) and provides a rich user interface for managing realms, users, roles and permissions.

Architecture Diagram

This diagram illustrates the integration of Keycloak as a central identity and access management system. It facilitates Single Sign-On (SSO) for various external identity providers (IDPs) and internal applications.

Components:

    1. Keycloak
      • Acts as the core Identity Provider (IdP) for the architecture.
      • Manages authentication, authorization, and user sessions across connected services.
      • Facilitates Single Sign-On (SSO), allowing users to log in once and access multiple services seamlessly.
    2. External Identity Providers (IDPs)
      • Keycloak integrates with external IDPs for user authentication.
      • OpenID Connect (OIDC) and SAML protocols for federated identity management.
      • Google and Microsoft for social and enterprise logins.
      • Keycloak redirects user login requests to these external providers as configured, enabling users to authenticate with their existing credentials.
    3. Internal Applications
      • Keycloak provides SSO support for internal services.
      • GitLab for source code management.
      • Jenkins for continuous integration/continuous delivery (CI/CD) pipelines.
      • SonarQube for static code analysis and quality monitoring.
      • These applications delegate authentication to Keycloak. When users access these services, they are redirected to Keycloak for login.

Workflow:

    1. Authentication with External IDPs:
      • A user trying to log in to any service is redirected to Keycloak.
      • If configured, Keycloak can redirect the user to an external provider (e.g., Google or Microsoft) to authenticate.
      • Once authenticated, the user is granted access to the requested service
    2. Single Sign-On (SSO):
      • Keycloak generates and manages an SSO session after successful authentication.
      • Users only need to log in once. All other integrated services (e.g., GitLab, Jenkins, SonarQube) can reuse the same session for access.
    3. Authorization:
      • Keycloak ensures proper access control by assigning roles and permissions.
      • Applications fetch user roles and permissions from Keycloak to enforce fine-grained authorization.

Keycloak's Key Features

    • Single Sign-On (SSO): Users log in once to access multiple services.
    • Centralized Authentication: Manage authentication for various services from a central location.
    • Federated Identity: Keycloak can authenticate users from LDAP, Active Directory or other identity providers.
    • Role-based Access Control (RBAC): Assign users specific roles and permissions across services.

Prerequisites

Before beginning, ensure you have the following:

    • Keycloak: Installed and running. You can deploy Keycloak using Docker, Kubernetes, or install it manually.
    • Grafana: Installed and running.
    • GitLab: Installed and running (either self-hosted or GitLab.com).
    • Jenkins: Installed and running.
    • SSL Certificates: It’s highly recommended to secure your services with SSL to ensure secure communication.

Ensure you have administrative access to each service for configuration purposes.

Part 1: Keycloak Setup

Step 1: Install and Access Keycloak

Keycloak can be deployed via Docker, Kubernetes, or manually on a server.

For Docker:

docker run -d \

  -p 8080:8080 \

  -e KEYCLOAK_USER=admin \

  -e KEYCLOAK_PASSWORD=admin \

  quay.io/keycloak/keycloak:latest

For Kubernetes, you can deploy Keycloak with Helm or a custom Kubernetes manifest. Make sure Keycloak is accessible to Grafana, GitLab, and Jenkins, either through DNS or IP.

Step 2: Create a New Realm

A Realm in Keycloak is a space where you manage users, roles, clients, and groups. Each realm is isolated, meaning users and configurations don’t overlap between realms.

    • From the Keycloak admin console, click on the top-left dropdown and select Add Realm.
    • Name the realm (e.g., DevOpsRealm) and click Create.
    • Ensure you select an appropriate Display Name and Internationalization settings if your user base spans different regions.

Step 3: Add Users and Assign Roles

You can now create users and assign them roles:

    • Navigate to Users -> Add User.
    • Fill in the user details and click Save.
    • After the user is created, go to the Credentials tab and set the password.
    • You can also manage roles under the Role Mappings tab to define custom permissions.

Step 4: Configure Clients (Grafana, GitLab, Jenkins)

Clients in Keycloak represent the applications that will use Keycloak for authentication. For each service (Grafana, GitLab, Jenkins), we’ll create a client that uses the OIDC protocol.

    • Grafana Client Setup:

      1. Go to Clients -> Create.
      2. Set the Client ID to grafana, and choose OpenID Connect as the protocol.
      3. Set the Root URL to http://<grafana-host>, and the Redirect URIs to http://<grafana-host>/login/generic_oauth.
      4. Enable the following flows: Standard Flow, Implicit Flow (if needed), and Direct Access Grants.
      5. Save the client and navigate to the Credentials tab to copy the generated Client Secret.
    • GitLab Client Setup:
      1. Go to Clients -> Create.
      2. Set the Client ID to gitlab and choose OpenID Connect.
      3. Set the Redirect URI to http://<gitlab-host>/users/auth/openid_connect/callback.
      4. Enable Standard Flow and Implicit Flow if GitLab requires it.
      5. Save the client and copy the Client Secret from the Credentials tab.
    • Jenkins Client Setup:
      1. Add a new client for Jenkins, following the same steps as above.
      2. Set the Redirect URI to http://<jenkins-host>/securityRealm/finishLogin.
      3. Export the client-json file from client actions to configure in the next steps.
      4. Export the json file as shown below.

Part 2: Integrating Keycloak with Grafana

Step 1: Configure Grafana for OAuth2

Grafana supports OAuth2 natively, and Keycloak uses OpenID Connect as the protocol for OAuth2.

    • Grafana’s Configuration: Locate the grafana.ini file (or environment variables for a Docker container) and configure OAuth2 settings: 

[auth.generic_oauth]
enabled = true
client_id = grafana
client_secret = <Grafana_Client_Secret>
auth_url = http://<keycloak-host>/realms/<Your_Realm>/protocol/openid-connect/auth token_url = http://<keycloak-host>/realms/<Your_Realm>/protocol/openid-connect/token
api_url = http://<keycloak-host>/realms/<Your_Realm>/protocol/openid-connect/userinfo scopes = openid profile email

    • Restart Grafana: After updating the configuration, restart Grafana:

For Manual:

systemctl restart grafana-server

For Docker:

docker restart <grafana-container-name>

Part 3: Integrating Keycloak with GitLab

GitLab supports OIDC natively for SSO, making it straightforward to integrate with Keycloak.

Step 1: Configure GitLab for OpenID Connect

    • GitLab Configuration: Open GitLab’s gitlab.rb configuration file and enable OIDC:

gitlab_rails[‘omniauth_enabled’] = true
gitlab_rails[‘omniauth_providers’] = [ 

{
 name: “openid_connect”,
 label: “Keycloak”,
 args: {
   name: “openid_connect”,
   scope: [“openid”, “profile”, “email”],
   response_type: “code”,
   issuer: “http://<keycloak-host>/realms/<Your_Realm>”,

   discovery: true,

   uid_field: “preferred_username”,

   client_auth_method: “basic”,

   client_options: {

     identifier: “<GitLab_Client_ID>”,

     secret: “<GitLab_Client_Secret>”,

     redirect_uri: “http://<gitlab-host>/users/auth/openid_connect/callback”

   }

  }

 }

]

    • Reconfigure GitLab: After editing gitlab.rb, run:

For Manual:

sudo gitlab-ctl reconfigure

For Docker:

docker restart <gitlab-container-name>

Step 2: Test the Integration

Log out of GitLab, then visit the login page. You should see a “Sign in with Keycloak” option. Clicking it will redirect you to Keycloak for authentication, and once logged in, you’ll be redirected back to GitLab.

Troubleshooting GitLab Integration:

    • Invalid UID Field: If authentication succeeds but user data is incorrect, check that uid_field in the gitlab.rb configuration is set to preferred_username.
    • Client Secret Mismatch: Ensure the client_secret in GitLab matches the secret in Keycloak’s client settings.
    • Invalid Token Response: If you get errors related to invalid tokens, ensure your GitLab instance is reachable from Keycloak and that your OAuth2 flow is configured correctly in Keycloak.

Part 4: Integrating Keycloak with Jenkins

Step 1: Install and Configure Keycloak Plugin

    • Install the Plugin: In Jenkins, go to Manage Jenkins -> Manage Plugins, search for the Keycloak OpenID Connect Plugin, and install it.
    • Configure Keycloak in Jenkins:
      1. Go to Manage Jenkins -> Configure Security.
      2. Under Security Realm, choose Keycloak Authentication.
      3. Upload the client-json file which is exported from the client configuration step.
      4. Upload the json file in keycloak json field.
    • Save and Test the Configuration: Log out of Jenkins and test the login with Keycloak.

Troubleshooting Jenkins Integration:

    • Redirect URI Mismatch: Double-check that the redirect URI set in Keycloak matches Jenkins’ redirect path (/securityRealm/finishLogin).
    • Access Denied Errors: Ensure users have been assigned roles in Keycloak that map to appropriate Jenkins permissions.
    • Plugin Issues: If the plugin behaves unexpectedly, verify you have the latest version installed and that Jenkins’ logs provide more detailed errors.

Note: All the 3 apps are now integrated with keycloak. So if you login to any service with keycloak, automatically you’ll be logged into all the 3 apps.

Conclusion

Integrating Keycloak with Grafana, GitLab, and Jenkins provides a unified and secure authentication system. This setup reduces complexity, enhances security, and improves user experience by enabling SSO across your DevOps tools.

Simplify authentication and enhance security across your systems. Get started today!

Contact us

Frequently Asked Questions (FAQs)

Keycloak is an open-source Identity and Access Management (IAM) solution that supports Single Sign-On (SSO) for applications. It provides centralized user management, secure authentication, and protocol support like OAuth2 and OpenID Connect. By using Keycloak, you can streamline access control and enhance security across multiple applications, reducing the need for managing credentials separately in each tool.

Yes, Keycloak supports integration with multiple applications using different authentication protocols like OpenID Connect, OAuth2, and SAML. You can create separate clients in Keycloak for each application (Grafana, GitLab, Jenkins), all managed under a single realm.

Yes, Grafana, GitLab, and Jenkins can all be integrated with Keycloak using the OpenID Connect (OIDC) protocol. This ensures consistent and secure authentication across all services using Keycloak as the Identity Provider.

Permissions and roles can be managed both within Keycloak and each application. In Keycloak, you can assign roles to users, which can be passed to the application during authentication. Each application (Grafana, GitLab, Jenkins) can then map these roles to their internal permission models. For example, in Grafana, you can map Keycloak roles to Grafana’s organization roles.

A "redirect URI mismatch" error occurs when the redirect URI specified in Keycloak doesn’t match the one configured in the client application. Ensure that the redirect URI in the client configuration in Keycloak matches exactly with what’s defined in Grafana, GitLab, or Jenkins, including protocols (http vs https), port numbers, and path names.

If you receive an "invalid client ID or secret" error, verify the following:

  • Ensure that the client ID and client secret entered in the application’s configuration (Grafana, GitLab, Jenkins) match exactly what is defined in Keycloak for that particular client.
  • Regenerate the client secret in Keycloak if necessary and update it in the application configuration.
  • Check that there are no typos in the configuration files, and ensure the Keycloak client is enabled.

Yes, Keycloak allows customization of its login page. You can modify themes, change the logo, colors, and layout, or create a completely custom login page by uploading a custom theme to Keycloak. This allows you to offer a consistent branding experience for your users across different applications.

If user information is not being retrieved correctly (e.g., email, profile data), ensure that:

  • The scopes (openid, profile, email) are configured correctly in the client settings for each application.
  • The User Info endpoint is accessible, and there are no network restrictions blocking it.
  • The appropriate claims are being released from Keycloak. You may need to check the Mappers in Keycloak’s client configuration to ensure that the correct user attributes are being sent.

Keycloak handles user sessions centrally. For Grafana, GitLab, and Jenkins, ensure that:

  • Session timeouts and token expiration settings in Keycloak are configured appropriately to match the expected behavior in your applications.
  • Token introspection is working, allowing the applications to verify tokens issued by Keycloak.
  • If users are logged out from Keycloak, they are also logged out from the integrated applications (SSO logout).
Asset 42@2x

Why Choose Grafana a Comprehensive Alerting System Compared to Nagios, Datadog, Elastic Stack and Splunk

by Devops

Why Choose Grafana? A Comprehensive Alerting System Compared to Nagios, Datadog, Elastic Stack, and Splunk

With the emerging world of data, monitoring and alerting systems have become vital to maintaining the reliability of applications and infrastructure. With tons of data produced every single second, businesses require powerful tools to present this data and quickly react to any incidents. Grafana — the leading open-source technology for monitoring and observability — is already among the most popular tools teams use to convert raw data into actionable real-life insight.

In this article, we will discuss how Grafana is the complete alerting system, showing how it compares to other monitoring tools, including Nagios, Datadog, Elastic Stack & Splunk. By comparing the pros and cons of each, readers can formulate a better sense of what Grafana is capable of and if it’s the right choice for their organization’s monitoring needs.

What is Grafana?

Grafana is a free platform used for monitoring, visualization, and analytics. It allows its users to turn large and complex datasets into informative visualizations by giving them the option of creating interactive and customizable dashboards. Monitoring of applications, services, and infrastructure can be done in real time with the help of Grafana, which makes it a good tool for teams, having a user-friendly interface. Therefore, it works exceedingly well for DevOps as well as IT operations.

It can work with an extensive range of data sources, such as Prometheus, InfluxDB, MySQL, Elasticsearch, etc. This means that adding Grafana to your display will allow you to see data from many systems all on one dashboard.

Additionally, dashboards in Grafana are also customizable, allowing users to present their data according to their requirements and preferences. Bar graphs, Heatmaps, and tables are some of the forms that can be used for data presentation depending on the metrics.

Also, the development of Grafana is aided by its active user base that helps monitor and alert users by contributing towards developing plugins and writing extensive documentation. Now, users will never feel lost in any application since there will always be installation guides and help provided.

Overview of Competing Tools

Nagios

Nagios is a monitoring solution whose service is based on infrastructure that has been in operation for several years. One of its strongest points includes user alerting, which has made it possible for users to keep track of application health, network performance, and server uptime. While it is accurate to say that there exists a robust alerting framework, the Nagios GUI is very tedious to navigate, and there is often a large manual workload for configuring alerts.

Datadog

Datadog is relatively new on the market, offering an application performance management and monitoring solution, entirely cloud-based, that provides visibility across your applications and infrastructure in its entirety. It works well with several cloud-based systems allowing its users to gather metrics, logs, and traces within seconds. It’s, quite literally, a powerful alerting system that enables keeping an eye on an application’s performance and infrastructure at any given moment. Unfortunately, its expensive model could be a deterrent for small organizations as once the level of use of the service increases, the cost would too.

Elastic Stack (ELK)

Elastic Stack, colloquially known as ELK, encompasses three tools – ElasticSearch, Logstash, and Kibana. This enables both analysis and visualization of logs. However, its capabilities get particularly enhanced when being used to process large amounts of log data. Thus, for organizations with a log-centric focus, ELK is a preferred choice. You can also set alert-based patterns via either the ElastAlert tool or using native alerting features provided in Kibana. It is worth noting though that maintaining and keeping the ELK stack up and running would require significant expertise and resources.

Splunk

Turning our attention to Splunk, we see that it currently reigns in the field of operational intelligence. More specifically, they provide real-time analysis and insights into machine-generated data. What puts Splunk at the forefront in terms of service, is that it combines effective analytics with an advanced search feature. Thereby allowing the organization to reduce their incident response time significantly. Splunk’s alerting system is arguably intricate as it doesn’t entirely allow for great customization, setting up alerts based on complex queries is doable. The downside, however, is a rather expensive licensing model. Splunk is notoriously expensive with their pricing model making scaling a challenge when trying to push them to their limits.

 

Feature

Grafana

Nagios

Datadog

Elastic Stack (ELK)

Splunk

Primary Focus

Visualization, monitoring, and alerting across multiple data sources

Infrastructure monitoring and alerting

Cloud-native monitoring and observability

Log analysis, search, and visualization

Data analysis, real-time insights, and log management

Alerting System

Unified alerting, customizable alerts across multiple data sources

Static alerts, tied to host/service monitoring

Extensive, integrated alerting for metrics and logs

Basic alerting with the additional configuration required

Advanced alerting with machine learning (ML) models

Ease of Use

User-friendly, intuitive UI, low learning curve

Complex setup, higher learning curve

Easy-to-use, modern cloud-native interface

Moderate complexity requires an Elasticsearch setup

Complex requires a deep understanding of configuration

Customization

Highly customizable dashboards support multiple data sources

Less flexible, more manual configuration

Highly customizable, SaaS-based with many options

High level of customization through Elasticsearch and Kibana

Highly customizable, but complex for large deployments

Notification Channels

Supports multiple channels: Slack, PagerDuty, email, Teams

Limited notification options, typically email

Broad range: Slack, email, PagerDuty, webhooks

Limited out-of-the-box, requires integration

Advanced notification options, but complex to set up

Integration

Integrates with Prometheus, Loki, Elasticsearch, MySQL, Pand PostgreSQL

Integrates with third-party plugins and services

Extensive cloud integration (AWS, Azure, GCP)

Deep integration with Elasticsearch for log analysis

Supports numerous services, but the complex integration process

Visualization

Best-in-class, customizable, interactive dashboards

Limited visualization capabilities

Advanced visualizations for metrics, logs, traces

Good visualization through Kibana, customizable

Strong visualization but more for advanced users

Scalability

Scales well with time series databases like Prometheus

Limited scalability without external tools

Excellent scalability for cloud and large deployments

Scales with Elasticsearch clusters

Scales well, but resource-intensive and costly

Community and Support

Strong open-source community, rich plugin ecosystem

Large community, but more focused on plugins

Strong support via SaaS, extensive documentation

Active open-source community, with paid support options

Strong enterprise support, but costs are high

Cost

Open-source, with paid enterprise options

Open-source, but requires third-party integrations for advanced features

Paid SaaS, usage-based pricing

Open-source (free), paid enterprise options available

Expensive enterprise-level pricing

Grafana’s Alerting Features

The skills of monitoring teams are significantly enhanced by Grafana’s alerting system which is quite robust and flexible to use. Central to this functionality are the alert rules, which enable the user to impose limitations on metrics, logs, and traces. With Grafana’s Unified Alerting system that was embedded with the software version 8, the user can operate different alerts from a single point, whereby fetching data from sources such as Prometheus, Loki, and Elasticsearch. This single-point management system is more effective in alert management as opposed to the Nagios-based swift tools that are closely tied to alerting tools and thus result in a disintegrated monitoring setup.

Grafana has the ability to alert a wide array of users and the alerting setup is another defining factor that has set Grafana aside from the others. Users can make advanced queries through their integrations with Prometheus by utilizing PromQL allowing them to build risks inside the metrics which can then be used for alerts. Also, Grafana integrates lots of notification channels such as PagerDuty, Slack, Microsoft Teams, and webhooks, among others. Such diversity assists the teams in instilling alerts over their communication workflows as it suits them best.

With Grafana’s contextual alerting, usability is improved as it binds alerts with relevant graphs. There is also a setting where a graph is displayed whenever an alert is triggered, making the diagnosis of the issue easier. Moreover, in the process of solving the problem, it is also beneficial that Grafana automatically marks events on graphs so users know when and where the problem was.

The platform also avoids alert fatigue through alert grouping and deduplication. Several alerts can be sent as one instead of a barrage of messages which greatly enhances communication and cuts out unwanted sounds. With Prometheus, Grafana allows users to not be burdened with constant notifications of similar types due to alert deduplication use.

Overall, the simple interface of Grafana makes any command related to setting alerts extremely easy, which is beneficial for new users while not compromising the experience of professionals. The API of the platform is also very helpful in automation as it allows integration with CI/CD pipelines and up-to-date DevOps processes. Such simplicity in work, in combination with powerful alerting features, is what makes Grafana a good tool for any company in need of a deep monitoring system.

Comparison of Alerting Systems

User Interface and Experience

Grafana is a better experience in terms of its user interface and experience as its design is more friendly. Users design the platform in such a way that navigating through its features becomes easy, which makes setup and management straightforward for those who are not familiar with monitoring tools. This stands in stark contrast to systems such as Nagios and Splunk which are a little bit easier to use but come with a complexity that requires a lot of time and effort to understand. For example, in Nagios, setting up alerts frequently requires sifting through configuration files and using a command-line interface which may turn out to be a pretty intimidating task for users with a limited technical background. Splunk, on the other hand, is a great tool but it also requires teams to understand how to use its query language and how to configure the tool which slows down the initial deployment of the team.

Alert Configuration

Grafana enhances alert management via a single unified system which allows users to define alert notifications based on any visualization or metrics from multiple data sources. Thanks to Prometheus and PromQL, complex alert conditions can easily be met, allowing for changes in response to conditions occurring. Note that Nagios, on the other hand, makes it necessary to adjust manually every alert which might unify some systems, but make several errors. Splunk is more advanced, yes, but the way search queries need to be configured can be a bit more than any user would want to deal with.

Notification Flexibility

Grafana shines in its flexibility in notification channels, where it supports an enormous number of notification channels: email, Slack, PagerDuty, and Microsoft Teams, among others. This means alerts can be pushed to the correct teams in real-time, enabling prompt responses to issues. Datadog and Elastic Stack also offer several options for notifications; however, being open-source, Grafana offers far more customization and integration opportunities. For organizations looking to customize their alerting processes in order to fit with particular workflows, Grafana is a more flexible solution.

Scalability

Scalability is one important factor for an organization, particularly as the need to monitor scales up and becomes very large. In this respect, Grafana has a good architecture that can scale effectively with data sources, such as Prometheus, which are designed to have high availability and scalability, which makes it perfect for large environments. However, Datadog is also scalable but becomes expensive with more data. Built with robust scalability options, the Elastic Stack may be a bit complex in terms of management. What Grafana does well is it captures the powerful monitoring features without incurring the high costs of some cloud-native products.

Integration with Existing Systems

Its biggest advantage is its seamless integration with other systems that may already exist in an organization. It supports multiple data sources such as Prometheus, Loki, Elasticsearch, and many more. Therefore, the existing tools are easily utilized by organizations with less disruption. It allows teams to see and alert on data coming from different sources in one place, thus making it a smooth workflow. And though Nagios and Splunk, for example, tend to be siloed products that may only more readily work with other systems with more configurations or separate instances, the integration of APIs and webhooks into Grafana increases its flexibility in deployment in various workflows. Such a feature explanation makes it appealing to teams that want to enhance the monitoring and alerting capabilities without overhauling their existing processes.

Conclusion

Grafana’s alerting system provides a great balance of visual appeal, flexibility, and ease of use, which makes it a great contender for organizations looking to enhance their monitoring capabilities. The unified alerting framework, support for multiple data sources, and rich community support help teams manage alerts effectively while reducing noise and improving response times.

Grafana can be a perfect choice for those organizations that are searching for an all-around monitoring stack. It complements other tools that are very strong in areas like log analysis or deep metrics monitoring. This way, the organization can get an even more complete solution for varied operational needs.

Empower Your Business with Data-Driven Insights. Reach out to us today!

Contact us

Frequently Asked Questions (FAQs)

Grafana focuses on data visualization and dashboarding, whereas Nagios is more traditional in the system and network monitoring. Grafana supports multi-source data integration and is highly customizable for visual representations, while Nagios excels in alerting and plugin-based monitoring.

You can customize Grafana dashboards by adding panels for different data sources, applying custom queries, and using built-in or third-party plugins to tailor the visualization. The layout and metrics displayed can be configured to suit your monitoring preferences.

Prometheus can be easily integrated with Grafana as a data source. Grafana pulls data from Prometheus using its API and allows you to create dynamic dashboards based on the time-series data collected by Prometheus.

Some popular plugins include the Zabbix plugin for Zabbix integration, Loki for log monitoring, and the Pie Chart plugin for specific visualizations. Plugins for cloud services like AWS and Google Cloud also extend Grafana's monitoring capabilities.

Splunk is a powerful tool for log analysis and management, with advanced search capabilities. Grafana, on the other hand, excels at real-time data visualization from multiple sources and is often used alongside Prometheus for metrics monitoring. Splunk is more enterprise-focused, while Grafana offers flexibility in open-source and cloud-native environments

Unified Alerting is Grafana's system for managing alerts across multiple data sources. You can configure it by setting up conditions for metrics or logs that trigger alerts, and by defining notification channels like email, Slack, or webhook for sending alerts.

Grafana allows you to connect and visualize data from multiple sources like Prometheus, Loki, Elasticsearch, InfluxDB, and more, all in one dashboard. You can configure queries for each data source and display the results in different panels on the same dashboard.

The ELK stack (Elasticsearch, Logstash, Kibana) is a comprehensive solution for log aggregation, search, and analysis, whereas Grafana is primarily focused on metrics and visualization. Grafana, when used with Loki, can handle logs but lacks the deep search and indexing capabilities of ELK.

Grafana is often preferred for open-source, highly customizable setups, while Datadog offers an all-in-one solution with built-in metrics, logs, and traces for cloud environments. Datadog provides a more managed experience but at a higher cost.

Asset 40@2x

Proactive Alerting for Cloud Applications using Grafana

by Devops

When to Use Grafana and How to Set Up Alerting in Grafana

Alerting now has become critical. As monitoring gives one an overview of the system, alerting is a near-real-time alert and notification system that immediately notifies the team regarding the occurrence of an issue in time to take some quick action before things go bad. For example, suppose a server uses more than its expected CPU usage. In that case, an alert will alert the team to address the matter before it leads to downtime or performance degradation. In short, alerting allows you to preclude problems that have a big impact on your system or business.

In this article, we will discuss the basic role of alerting in a monitoring system and exactly how alerting works inside Grafana, one of the powerful open-source tools for monitoring and visualization. After briefly discussing the importance of monitoring and alerting, we’ll guide you through the steps to set up alerting in Grafana.

Importance of Alerting in Monitoring Systems

Monitoring is the process of continuously collecting data from various parts of the system and understanding it over a while to trace patterns or anomalies. It helps in capacity planning, exhibits performance bottlenecks, and guides optimization efforts by showing a whole picture of health without initiating action. Instead of this, alerting is an active response mechanism that informs the teams when certain conditions or thresholds have been met; the objective being keeping the teams informed of problems as they occur.

Main Differences

Objectives: Monitoring is concerned with long-term data collection and analysis while alerting is directed at the immediate need for issue detection and response.

Timing: Monitoring is always on, capturing data at all times, while alerts are event-driven, which means they become effective only when certain conditions are met.

Key Benefits of Alerts

Continuous Monitoring Without Human Intervention: The alerts automate the process, ensuring that issues are flagged without constant human oversight.

Real-Time Update-Alerts: It is based on predefined conditions to send instant notifications and thus, ensure rapid responses to critical changes. The right people get notified and thus ensure proper escalations are managed.

Types of Alerts

Threshold-Based Alerts: Threshold-based alerts are identified based on definite thresholds, such as which could raise an alert when the CPU exceeds 90%.

Anomaly Detection Alerts: Intended to track and look for unusual patterns or behaviours that might not be detected using typical thresholds.

Event-Based Alerts: These alerts react to critical events, such as the failure of an application process or missing critical data; thus, teams are alerted to important occurrences.

Setting Up Alerting in Grafana (Step-by-Step Guide)

Prerequisites to Setup Alerts

Before you can have alerts working in Grafana, you need to have the environment set up just as outlined below:

Data Source Integration: You will need a data source integrated with Grafana; some examples of sources are Prometheus. Alerts work based on the time-series data retrieved from such sources.

Understanding Alert Rules: An alert rule is a query that checks the state of a defined metric and determines whether an alert should be triggered given certain predefined conditions.

Step1: Login to Grafana with the required credentials

Step2: Create a new dashboard or open an existing dashboard where the notification alert needs to be setup

Steps to Create Alerts

Step 1: Create a Panel for Visualization

Add New Panel: First, add a new panel to your Grafana dashboard where you will visualize the metric that you are going to monitor.

Select Visualization Type: From the list, pick a visualization type that best fits either a Graph or Singlestat based on what sort of data you wish to monitor.

Step 2: Configure Alert

Alerting Menu Access: Navigate to the Alerting section from the menu.

New Alert Rule: From the subsection under Alerting, you click New Alert Rule to start the process of setting up an alert.

Data Source: Under the list of choices for a data source select such as Prometheus.

Write the Query: Type the query that fetches the metric you need to monitor. Be sure the query accurately reflects the condition you need to monitor.

Set the Threshold: How to check the input, i.e. whether the value is above a certain value, or similar. You could choose this condition as “is above” with a threshold value (for example, 80 for CPU usage).

Enter Values for Alerting Rule Options

Name: Give the rule a descriptive name for the alert, like “High CPU Usage Alert”.

Alert Conditions: Define a query that specifies the conditions under which the alert should be triggered.

Alert Evaluation Behavior: Select how frequently to check the alert (in this case, every 5 minutes).

Labels and Notifications: Add relevant tags to help categorize your alerts, such as environment or service. Describe the action instructions for the alert message that will go out once the alert is triggered. Include some background information regarding the issue so it can be easily recognized.

Include Contact Information: Determine the contact information where the alert notifications are to be delivered, such as email, Slack, or Google Chat/Hangout, PagerDuty & Webhooks. Remember, you’ll have to set up the notification channels in Grafana beforehand. In the URL section attach the Web hook of the above channels where you want to get notified.

Step 3: Testing your Alerts

Test the Alert: Use the testing feature in Grafana to test if your alert configuration is properly set. Thus, you will be reassured that under well-defined conditions, alerting works.

Step 4: Finalize the Alert

Save Alert: When all the settings for configuring are made, you can save the alert rule created by clicking Save.

Enable Alert: Finally, ensure to enable the alert so it can start monitoring for the defined conditions.

Conclusion

Alerting is one of the most important features of a modern monitoring system, that can enable teams to be able to respond to issues at their earliest sign rather than allowing them to spin out of control. With proper alert definitions integrated with monitoring, organizations can avoid more downtime, increase reliability, and make all these complex systems work flawlessly.

Alerts in Grafana must be actional and should not be vague. Avoid the over-complication of rules on alerts. Regularly update the alerts since the infrastructure and environments are always in the update, it has to be properly grouped and prioritized, and advance notification options like webhooks or third-party tools.

In this post, we focused on how Grafana excels at detailed alert settings and is suitable for monitoring metrics of the system, complementing tools like Uptime Kuma, which is good for simple service uptime tracking. In the following release, we dig deeper into Uptime Kuma, examining it in much more depth, then, of course, showing its setup from the ground up. Stay tuned to find out how these two tools can work together to create a seamless, holistic monitoring and alerting strategy.

Have questions about Grafana, alerting, or optimizing your monitoring setup? Our team is here to assist

Contact us

Frequently Asked Questions (FAQs)

The purpose of configuring notification alerts is to ensure timely awareness of issues in your systems by monitoring specific metrics. Alerts allow you to proactively respond to potential problems, reducing downtime and enhancing system performance.

You can access Grafana by logging in with the required credentials. If you don't have an account, you'll need to create one or request access from your administrator.

You can set up alerts on both existing dashboards and new ones. Simply open the dashboard where you want to configure the alert or create a new dashboard if needed.

You can use various visualization types, such as Graph or Singlestat, depending on how you want to display the metric you're monitoring.

In the alerting section under "Rules," select "New Alert Rule" and choose your data source (e.g., Prometheus, InfluxDB) when writing the query to retrieve the metric you want to monitor.

You can define alert conditions by specifying when the alert should trigger based on your chosen metric. This could be when the metric crosses a certain threshold or remains above or below a specific value for a defined duration.

Setting a threshold value determines the specific point at which an alert will be triggered, allowing you to control when you are notified of potential issues based on the behaviour of the monitored metric.

Yes, you can customize the alert messages by setting annotations in the alerting rule. This allows you to tailor the content of the notification that will be sent when the alert is triggered.

You can set contact points for notifications, such as Email, Hangouts, Slack, PagerDuty, or Webhooks. Attach the webhook URL for the channel where you want to receive alerts.

Testing the alert with the "Test Rule" button allows you to simulate the alert and see how it would behave under current conditions, ensuring the configuration works as expected before saving.

Server monitoring involves tracking the performance and health of servers to ensure they are running efficiently and to quickly identify and resolve any issues. It is important because it helps prevent downtime, ensures optimal performance, and maintains the reliability of services.

Grafana provides real-time insights into server metrics such as CPU usage, memory utilization, network traffic, and disk activity. It offers customizable dashboards and visualization options to help interpret data and spot anomalies quickly.

 

Alerts are configured in Grafana with custom rules and thresholds. Integrating with Google Chat, the system sends immediate notifications to the relevant team members when any anomalies or performance issues arise.

Node-exporter and Prometheus are used for data collection. Node-exporter gathers system-level metrics, while Prometheus stores these metrics and provides querying capabilities.

Grafana can monitor a wide range of metrics, including CPU usage, memory utilization, disk I/O, network traffic, application response times, and custom application metrics defined through various data sources.

Yes, Grafana supports integration with numerous third-party applications and services, including notification channels like Slack, Microsoft Teams, PagerDuty, and more, enhancing its alerting capabilities.

The data collection frequency can vary based on the configuration of the data source (like Prometheus) and the specific queries you set up. You can typically configure scrape intervals in your Prometheus setup.

Yes, Grafana allows you to share dashboards with team members via direct links, snapshots, or by exporting them. You can also set permissions to control who can view or edit the dashboards.

If you encounter issues, check the Grafana logs for error messages, review your alert configurations, and ensure that your data sources are properly connected. The Grafana community and documentation are also valuable resources for troubleshooting.

Yes, Grafana allows you to create complex alert conditions based on multiple metrics using advanced queries. You can combine metrics in a single alert rule to monitor related conditions.

If a data source goes down, Grafana will typically show an error or a warning on the dashboard. Alerts configured with that data source may also fail to trigger until the connection is restored.

Yes, Grafana allows you to visualize historical data by querying data sources that store time-series data, such as Prometheus. You can create dashboards that analyze trends over time.

Annotations are markers added to graphs in Grafana to indicate significant events or changes. They can provide context for data trends and help identify when specific incidents occurred.

Alerts are conditions set to monitor specific metrics and trigger under certain circumstances, while notifications are the messages sent out when those alerts are triggered, informing users of the situation.

Yes, Grafana offers some customization options for its UI, including themes and layout adjustments. You can also configure dashboard variables to create dynamic and user-friendly interfaces.

Yes, you can use Grafana's API to programmatically create and manage dashboards, allowing for automation in scenarios such as CI/CD pipelines or large-scale deployments.

Grafana offers extensive documentation, tutorials, and community forums. Additionally, there are many online courses and video tutorials available to help users learn the platform.

Optimizing DevSecOps with SonarQube and DefectDojo Integration

Optimizing DevSecOps with SonarQube and DefectDojo Integration

by Devops

In the evolving landscape of software development, the importance of integrating security practices into every phase of the software development lifecycle (SDLC) cannot be overstated.

This is where DevSecOps comes into play a philosophy that emphasizes the need to incorporate security as a shared responsibility throughout the entire development process, rather than treating it as an afterthought.

By shifting security left, organizations can detect vulnerabilities earlier, reduce risks, and improve compliance with industry standards. DevSecOps isn’t just about tools; it’s about creating a culture where developers, security teams, and operations work together seamlessly. However, having the right tools is essential to implementing an effective DevSecOps strategy.

In this article, we’ll delve into the setup of DefectDojo, a powerful open-source vulnerability management tool, and demonstrate how to integrate it with SonarQube to automate Code Analysis as part of the CICD Process and also capture the vulnerability identified in the testing so it can be tracked to closure. 

Why DevSecOps and What Tools to Use?

DevSecOps aims to automate security processes, ensuring that security is built into the CI/CD pipeline without slowing down the development process. Here are some key tools that can be used in a DevSecOps environment:

SonarQube: Static Code Analysis

SonarQube inspects code for bugs, code smells, and vulnerabilities, providing developers with real-time feedback on code quality. It helps identify and fix issues early in the development process, ensuring cleaner and more maintainable code.

Dependency Check: Dependency Vulnerability Scanning

Dependency Check scans project dependencies for known vulnerabilities, alerting teams to potential risks from third-party libraries. This tool is crucial for managing and mitigating security risks associated with external code components.

Trivy: Container Image Scanning

Trivy examines Docker images for vulnerabilities in both OS packages and application dependencies. By integrating Trivy into the CI/CD pipeline, teams ensure that the container images deployed are secure, reducing the risk of introducing vulnerabilities into production.

ZAP: Dynamic Application Security Testing

ZAP performs dynamic security testing on running applications to uncover vulnerabilities that may not be visible through static analysis alone. It helps identify security issues in a live environment, ensuring that the application is secure from real-world attacks.

Defect Dojo: Centralized Security Management

Defect Dojo collects and centralizes security findings from SonarQube, Dependency Check, Trivy, and ZAP, providing a unified platform for managing and tracking vulnerabilities. It streamlines the process of addressing security issues, offering insights and oversight to help prioritize and resolve them efficiently.

DefectDojo ties all these tools together by acting as a central hub for vulnerability management. It allows security teams to track, manage, and remediate vulnerabilities efficiently, making it an essential tool in the DevSecOps toolkit.

Installation and Setup of DefectDojo

Before integrating DefectDojo with your security tools, you need to install and configure it. Here’s how you can do that:

Prerequisites: 

1. Docker
2. Jenkins

Step1: Download the official documentation from DefectDojo github repository using the link

Step2: Once downloaded, navigate to the path where you have downloaded the repository and run the below command.

docker-compose up -d –-build

Step3: DefectDojo will start running and you will be able to access it with http://localhost:8080/ . Enter the default credentials that you have set and login to the application.

Step4: Create a product by navigating as shown below

Step5: Click on the created product name and create an engagement by navigating as shown below

Step6: Once an engagement is created click on the created engagement name and create a test from it.

Step7: Copy the test number and enter the test number in the post stage of the pipeline.

Step8: Building a pipeline in Jenkins to integrate it with DefectDojo inorder to generate vulnerability report

pipeline {

    agent {

        label ‘Agent-1’

    }

    environment {

        SONAR_TOKEN = credentials(‘sonarqube’)

    }

    stages {

        stage(‘Checkout’) {

            steps {

                checkout([$class: ‘GitSCM’, branches: [[name: ‘dev’]],

                    userRemoteConfigs: [[credentialsId: ‘parameterized credentials’, url: ‘repositoryURL’]]

                ])

            }

        }

        stage(‘SonarQube Analysis’) {

            steps {

                script {

                    withSonarQubeEnv(‘Sonarqube’) {

                        def scannerHome = tool name: ‘sonar-scanner’, type: ‘hudson.plugins.sonar.SonarRunnerInstallation’

                        def scannerCmd = “${scannerHome}/bin/sonar-scanner”

                        sh “${scannerCmd} -Dsonar.projectKey=ProjectName -Dsonar.sources=./ -Dsonar.host.url=Sonarqubelink -Dsonar.login=${SONAR_TOKEN} -Dsonar.java.binaries=./”

                    }

                }

            }

        }

        // Other stages…

        stage(‘Generate SonarQube JSON Report’) {

            steps {

                script {

                    def SONAR_REPORT_FILE = “/path/for/.jsonfile”

                    sh “””

                    curl -u ${SONAR_TOKEN}: \

                        “Sonarqube URL” \

                        -o ${SONAR_REPORT_FILE}

                    “””

                }

            }

        }

    }

    post {

        always {

            withCredentials([string(credentialsId: ‘Defect_Dojo_Api_Key’, variable: ‘API_KEY’)]) {

                script {

                    def defectDojoUrl = ‘Enter the defect dojo URL’  // Replace with your DefectDojo URL

                    def testId = ’14’  // Replace with the correct test ID

                    def scanType = ‘SonarQube Scan’

                    def tags = ‘Enter the tag name’

                    def SONAR_REPORT_FILE = “/path/where/.json/file is present”

                    sh “””

                    curl -X POST \\

                      ‘${defectDojoUrl}’ \\

                      -H ‘accept: application/json’ \\

                      -H ‘Authorization: Token ${API_KEY}’ \\

                      -H ‘Content-Type: multipart/form-data’ \\

                      -F ‘test=${testId}’ \\

                      -F ‘file=@${SONAR_REPORT_FILE};type=application/json’ \\

                      -F ‘scan_type=${scanType}’ \\

                      -F ‘tags=${tags}’

                    “””

                }

            }

        }

    }

}

The entire script is wrapped in a pipeline block, defining the CI/CD pipeline in Jenkins.

agent: Specifies the Jenkins agent (node) where the pipeline will execute. The label Agent-1 indicates that the pipeline should run on a node with that label.

environment: Defines environment variables for the pipeline.

SONAR_TOKEN: Retrieves the SonarQube authentication token from Jenkins credentials using the ID ‘sonarqube’. This token is needed to authenticate with the SonarQube server during analysis.

The pipeline includes several stages, each performing a specific task.

stage(‘Checkout’): The first stage checks out the code from the Git repository.

checkout: This is a Jenkins step that uses the GitSCM plugin to pull code from the specified branch.

branches: Indicates which branch (dev) to checkout.

userRemoteConfigs: Specifies the Git repository’s URL and the credentials ID (parameterized credentials) used to access the repository.

stage(‘SonarQube Analysis’): This stage runs a SonarQube analysis on the checked-out code.

withSonarQubeEnv(‘Sonarqube’): Sets up the SonarQube environment using the SonarQube server named Sonarqube, which is configured in Jenkins.

tool name: Locates the SonarQube scanner tool installed on the Jenkins agent.

sh: Executes the SonarQube scanner command with the following parameters:

-Dsonar.projectKey=ProjectName: Specifies the project key in SonarQube.

-Dsonar.sources=./: Specifies the source directory for the analysis (in this case, the root directory).

-Dsonar.host.url=Sonarqubelink: Specifies the SonarQube server URL.

-Dsonar.login=${SONAR_TOKEN}: Uses the SonarQube token for authentication.

-Dsonar.java.binaries=./: Points to the location of Java binaries (if applicable) for analysis.

stage(‘Generate SonarQube JSON Report’): This stage generates a JSON report of the SonarQube analysis.

SONAR_REPORT_FILE: Defines the path where the JSON report will be saved.

sh: Runs a curl command to retrieve the SonarQube issues data in JSON format:

  1. -u ${SONAR_TOKEN}:: Uses the SonarQube token for authentication.
  2. “Sonarqube URL”: Specifies the API endpoint to fetch the issues from SonarQube.
  3. -o ${SONAR_REPORT_FILE}: Saves the JSON response to the specified file path.

post: Defines actions to perform after the pipeline stages are complete. The always block ensures that the following steps are executed regardless of the pipeline’s success or failure.

withCredentials: Securely retrieves the DefectDojo API key from Jenkins credentials using the ID ‘Defect_Dojo_Api_Key’.

script: Contains the script block where the DefectDojo integration happens.

defectDojoUrl: The URL of the DefectDojo API endpoint for reimporting scans.

testId: The specific test ID in DefectDojo where the SonarQube report will be uploaded.

scanType: Indicates the type of scan (in this case, SonarQube Scan).

tags: Tags the scan in DefectDojo.

SONAR_REPORT_FILE: Points to the JSON file generated earlier.

sh: Runs a curl command to POST the SonarQube JSON report to DefectDojo:

-X POST: Specifies that this is a POST request.

-H ‘accept: application/json’: Indicates that the response should be in JSON format.

-H ‘Authorization: Token ${API_KEY}’: Authenticates with DefectDojo using the API key.

-F ‘test=${testId}’: Specifies the test ID in DefectDojo.

-F ‘file=@${SONAR_REPORT_FILE};type=application/json’: Uploads the JSON file as part of the request.

-F ‘scan_type=${scanType}’: Indicates the type of scan being uploaded.

-F ‘tags=${tags}’: Adds any specified tags to the scan in DefectDojo.

Step 9: Verify the Integration

After the pipeline executes, the vulnerability report generated by SonarQube will be available in DefectDojo under the corresponding engagement. You can now track, manage, and remediate these vulnerabilities using DefectDojo’s robust features.

Conclusion

Integrating security tools like SonarQube with DefectDojo is a critical step in building a secure DevSecOps pipeline. By automating vulnerability management and integrating it directly into your CI/CD pipeline, you can ensure that security remains a top priority throughout the development process.

In this article, we focused on setting up DefectDojo and integrating it with SonarQube. In future articles, we will cover the integration of additional tools like OWASP ZAP, Trivy, and Dependency-Check. Stay tuned to further enhance your DevSecOps practices.

Frequently Asked Questions (FAQs)

DefectDojo is an open-source application security vulnerability management tool. It helps organizations in managing, tracking, and remediating security vulnerabilities efficiently. It integrates with a variety of security tools for automating workflows and provides continuous security monitoring throughout the SDLC.

The prerequisites for setting up DefectDojo are Docker, to run DefectDojo inside a container, and Jenkins, for integrating pipelines in CI/CD.

To install DefectDojo:

  1. Download the official DefectDojo documentation from its GitHub repository.
  2. Navigate to the path where you downloaded the repository.
  3. Run the docker-compose up -d --build command to build and start the DefectDojo container and its dependencies.

Once DefectDojo is running, you can access it via a web browser at http://localhost:8080/. Log in with the credentials set during installation, and you can start managing security vulnerabilities by creating products, engagements, and tests.

Yes, DefectDojo integrates seamlessly with other security tools like SonarQube, OWASP ZAP, Trivy, and Dependency-Check. It allows the centralization of vulnerability management across multiple tools, making it an indispensable part of the DevSecOps pipeline.

Get in touch with us and elevate your software security and performance

Contact us
Blogbanner_2

Keycloak deployment on Kubernetes with Helm charts using an external PostgreSQL database

by Devops

Prerequisites:

  1. Kubernetes cluster set up and configured.
  2. Helm installed on your Kubernetes cluster.
  3. Basic understanding of Kubernetes concepts like Pods, Deployments, and Services.
  4. Familiarity with Helm charts and templating.

Introduction:

Deploying Keycloak on Kubernetes with an external PostgreSQL database can be challenging, especially when using Helm charts. One common issue is that keycloak deploys with  a default database service when we use Helm chart, making it difficult to integrate with an external database. 

In this article, we’ll explore the problem we encountered while deploying Keycloak on Kubernetes using Helm charts and describe the solution we implemented to seamlessly use an external PostgreSQL database.

Problem:

The primary issue we faced during the deployment of Keycloak on Kubernetes using Helm was the automatic deployment of a default database service. This default service conflicted with our requirement to use an external PostgreSQL database for Keycloak. The Helm chart, by default, would deploy an internal database, making it challenging to configure Keycloak to connect to an external database.

Problem Analysis

  1. Default Database Deployment: The Helm chart for Keycloak automatically deploys an internal PostgreSQL database. This default setup is convenient for simple deployments but problematic when an external database is required.
  2. Configuration Complexity: Customizing the Helm chart to disable the internal database and correctly configure Keycloak to use an external PostgreSQL database requires careful adjustments to the values.yaml file.
  3. Integration Challenges: Ensuring seamless integration with an external PostgreSQL database involves specifying the correct database connection parameters and making sure that these settings are correctly propagated to the Keycloak deployment.
  4. Persistence and Storage: The internal database deployed by default may not meet the persistence and storage requirements for production environments, where an external managed PostgreSQL service is preferred for reliability and scalability.

To address these issues, the following step-by-step guide provides detailed instructions on customizing the Keycloak Helm chart to disable the default database and configure it to use an external PostgreSQL database.

Overview Diagram:

Step-by-Step Guide

Step 1: Setting Up Helm Repository

If you haven’t already added the official Helm charts repository for Keycloak, you can add it using the following command:

helm repo add codecentric https://codecentric.github.io/helm-charts

helm repo update

By adding the official Helm charts repository for Keycloak, you ensure that you have access to the latest charts maintained by the developers. Updating the repository ensures you have the most recent versions of the charts.

Step 2: Customizing Helm Values

Objective: Customize the Keycloak Helm chart to avoid deploying the default database and configure it to use an external PostgreSQL database.

Configure Keycloak for development mode

Create a values.yaml File

  1. Create a new file named values.yaml.
  2. Add the following content to the file 

image:

  # The Keycloak image repository

  repository: quay.io/keycloak/keycloak

  # Overrides the Keycloak image tag whose default is the chart appVersion

  tag: 24.0.3

  # The Keycloak image pull policy

  pullPolicy: IfNotPresent


resources:

  requests:

    cpu: “500m”

    memory: “1024Mi”

  limits:

    cpu: “500m”

    memory: “1024Mi”


args:

  – start-dev

  – –hostname=<url>

  – –hostname-url=<url>

  – –verbose


autoscaling:

  # If `true`, a autoscaling/v2beta2 HorizontalPodAutoscaler resource is created (requires Kubernetes 1.18 or above)

  # Autoscaling seems to be most reliable when using KUBE_PING service discovery (see README for details)

  # This disables the `replicas` field in the StatefulSet

  enabled: false

  # The minimum and maximum number of replicas for the Keycloak StatefulSet

  minReplicas: 1

  maxReplicas: 2


ingress:

  enabled: true

  #hosts:

  #  – <url>

  ssl:

    letsencrypt: true

    cert_secret: <url>

  annotations:

    kubernetes.io/ingress.class: “nginx”

    kubernetes.io/tls-acme: “true”

    cert-manager.io/cluster-issuer: letsencrypt

    cert-manager.io/acme-challenge-type: dns01

    cert-manager.io/acme-dns01-provider: route53

    nginx.ingress.kubernetes.io/proxy-buffer-size: “128k”

    nginx.ingress.kubernetes.io/affinity: “cookie”

    nginx.ingress.kubernetes.io/session-cookie-name: “sticky-cookie”

    nginx.ingress.kubernetes.io/session-cookie-expires: “172800”

    nginx.ingress.kubernetes.io/session-cookie-max-age: “172800”

    nginx.ingress.kubernetes.io/affinity-mode: persistent

    nginx.ingress.kubernetes.io/session-cookie-hash: sha1

  labels: {}

  rules:

    –

      # Ingress host

      host: ‘<url>’

      # Paths for the host

      paths:

        – path: /

          pathType: Prefix

  tls:

    – hosts:

        – <url>

      secretName: “<url>”

      

extraEnv: |

 – name: PROXY_ADDRESS_FORWARDING

   value: “true”

 – name: QUARKUS_THREAD_POOL_MAX_THREADS

   value: “500”

 – name: QUARKUS_THREAD_POOL_QUEUE_SIZE

   value: “500”

 

This configuration file customizes the Keycloak Helm chart to set specific resource requests and limits, ingress settings, and additional environment variables. By setting the args to start Keycloak in development mode, you allow for easier initial setup and testing.

Configuring for Production Mode

  1. Add or replace the following content in values.yaml for production mode:

args:

  – start

  – –hostname=<url>

  – –hostname-url=<url>

  – –verbose

  – –optimized

  – -Dquarkus.http.host=0.0.0.0

  – -Dquarkus.http.port=8080

Note: The production configuration includes optimizations and ensures that Keycloak runs in a stable environment suitable for production workloads. The –optimized flag is added for performance improvements.

Configuring for External Database

  1. Add the following content to values.yaml to use an external PostgreSQL database:

args:

  – start

  – –hostname-url=<url>

  – –verbose

  – –db=postgres

  – –db-url=<jdbc-url>

  – –db-password=${DB_PASSWORD}

  – –db-username=${DB_USER}

 

postgresql:

  enabled: false

This configuration disables the default PostgreSQL deployment by setting postgresql.enabled to false. The database connection arguments are provided to connect Keycloak to an external PostgreSQL database.

Step 3: Deploying Keycloak with PostgreSQL and Custom Themes Using Helm

Objective: Add custom themes to Keycloak and deploy it using Helm.

  1. Add the following to values.yaml to include custom themes:

extraInitContainers: |

  – name: theme-provider

    image: <docker-hub-registry-url>

    imagePullPolicy: IfNotPresent

    command:

      – sh

    args:

      – -c

      – |

        echo “Copying custom theme…”

        cp -R /custom-themes/* /eha-clinic

    volumeMounts:

      – name: custom-theme

        mountPath: /eha-clinic

extraVolumeMounts: |

  – name: custom-theme

    mountPath: /opt/jboss/keycloak/themes/

extraVolumes: |

  – name: custom-theme

    emptyDir: {}

This configuration uses an init container to copy custom themes into the Keycloak container. The themes are mounted at the appropriate location within the Keycloak container, ensuring they are available when Keycloak starts.

Step 4: Configuring Keycloak

Objective: Log in to the Keycloak admin console and configure realms, users, roles, client applications, and other settings.

Access the Keycloak admin console using the URL provided by your ingress configuration.

  1. Log in with the default credentials (admin/admin).
  2. Configure the following according to your application requirements:
  • Realms
  • Users
  • Roles
  • Client applications

The Keycloak admin console allows for comprehensive configuration of all aspects of authentication and authorization, tailored to the needs of your applications.

Step 5: Configuring Custom Themes

Objective: Apply and configure custom themes within the Keycloak admin console.

  1. Log in to the Keycloak admin console using the default credentials (admin/admin).
  2. Navigate to the realm settings and select the “Themes” tab.
  3. Select and configure your custom themes for:
  • Login pages
  • Account pages
  • Email pages

Custom themes enhance the user experience by providing a personalized and branded interface. This step ensures that the authentication experience aligns with your organization’s branding and user interface guidelines.

Conclusion

By following the steps outlined in this article, you can deploy Keycloak with PostgreSQL on Kubernetes using Helm, while also incorporating custom themes to personalize the authentication experience. Leveraging Helm charts simplifies the deployment process, while Keycloak and PostgreSQL offer robust features for authentication and data storage. Integrating custom themes allows you to tailor the authentication pages according to your branding and user interface requirements, ultimately enhancing the user experience and security of your applications.

Frequently Asked Questions (FAQs)

Keycloak is a modern applications and services open-source identity and access management solution. It offers various functionalities such as single sign-on, identity brokering, and social login which help in making user identity management easy as well as application security

Deploying Keycloak on Kubernetes means that you can have an elastic application that can be extended according to the number of users, resistant to failure on case of external services unavailability or internal server crashes; it is also easy to manage, has numerous protocols for authentication mechanisms and connects with different types of external databases.

Helm charts are pre-configured Kubernetes resource packages that simplify the efficient management and deployment of applications on Kubernetes.

To disable the default PostgreSQL database, set postgresql.enabled to false in the values.yaml file.

Provide the necessary database connection parameters in the values.yaml file, including --db-url, --db-password, and --db-username.

You can add custom themes by configuring init containers in the values.yaml file to copy the themes into the Keycloak container and mounting them at the appropriate location.

Asset 2 (1)

Integrating Apache Jmeter with Jenkins

by Devops

In the world of software development, ensuring the performance and reliability of applications is paramount. One of the most popular tools for performance testing is Apache JMeter, known for its flexibility and scalability. Meanwhile, Jenkins has become the go-to choice for continuous integration and continuous delivery (CI/CD). Combining the power of JMeter with the automation capabilities of Jenkins can significantly enhance the efficiency of performance testing within the development pipeline. In this article, we’ll explore the integration of JMeter with Jenkins and how it can streamline the performance testing process.

Apache Jmeter

Apache JMeter is a powerful open-source tool designed for load testing, performance testing, and functional testing of applications. It provides a user-friendly GUI that allows testers to create and execute several types of tests, including HTTP, FTP, JDBC, LDAP, and more. JMeter supports simulating heavy loads on servers, analyzing overall performance metrics, and finding performance bottlenecks.

With its scripting and parameterization capabilities, JMeter offers flexibility and scalability for testing web applications, APIs, databases, and other software systems. Its extensive reporting features help teams assess application performance under different conditions, making it an essential tool for ensuring the reliability and scalability of software applications. More information available here Apache JMeter.

Jenkins

Jenkins is one of the most popular open-source automation servers widely used for continuous integration (CI) and continuous delivery (CD) processes in software development for several years now. It allows developers to automate the building, testing, and deployment of applications, thereby streamlining the development lifecycle. Jenkins supports integration with various version control systems like Git, SVN, and Mercurial, enabling automatic triggers for builds whenever code changes are pushed.

Its extensive plugin ecosystem provides flexibility to integrate with a wide range of tools and technologies, making it a versatile solution for managing complex CI/CD pipelines. Jenkins’ intuitive web interface, extensive plugin library, and robust scalability make it a popular choice for teams aiming to achieve efficient and automated software delivery processes. The Jenkins docs has a page to help with the Jenkins installation process.

Why Integrate JMeter with Jenkins?

Traditionally, performance testing has been a manual and time-consuming process, often conducted as a separate part of the development lifecycle by test teams. The results had to then be shared with the rest of the team as there was no automated execution or capturing of the test results as part of the CICD pipeline. However, in today’s fast-paced software development environment, there’s a growing need to automate the complete testing processes to include execution of Performance tests as part of the CICD pipeline. By integrating JMeter with Jenkins, organizations can achieve the following benefits:

Automation: Jenkins allows you to automate the execution of JMeter tests as part of your CI/CD pipeline, enabling frequent and consistent performance testing with minimal manual intervention.

Continuous Feedback: Incorporating performance tests into Jenkins pipelines provides immediate feedback on the impact of code changes on application performance, allowing developers to find and address performance issues early in the development cycle.

Reporting: Jenkins provides robust reporting and visualization capabilities, allowing teams to analyze test results and track performance trends over time, helping data-driven decision-making.

Our Proposed Approach & its advantages

We’ve adopted a new approach in addition to using the existing JMeter plugin for Jenkins wherein we enhance the Jenkins Pipeline to include detailed notifications and better result organization.

The key steps of our approach are as follows.

  1. We can install JMeter directly on the agent base OS. This ensures we have access to the latest features and updates.
  2. We use the powerful Blaze Meter plugin to generate our JMeter scripts.
  3. We’ve written a dedicated Jenkins pipeline to automate the execution of these Jmeter scripts.
  4. We have also defined the steps as part of the Jenkins script to distribute the Execution Status and log by email to chosen users.
  5. We also store the results in a configurable Path for future reference.

All of this ensures better automation, flexibility or control of the execution, notification and efficient performance testing as part of the CICD Pipeline.

Setting Up Blaze Meter & Capturing the Test Scripts

To automate the process of script writing we should use the Blaze Meter tool. Navigate to chrome extensions and search for Blaze Meter. Click on add to chrome. Access Blaze Meter official website and create an account there for further process.

Open chrome and now you can find the Blaze Meter extension on the top right corner.

Click on the Blaze Meter chrome extension. A toolbox will be visible. Open the application where you want to record the scripts for Jmeter. Click on the record button to start.

Navigate through the application and perform necessary operations as end users of the application would. Click on the stop button to stop the recording.

Now Blaze Meter has recorded the scripts. To save it in. jmx format, click on save, check the Jmeter only box and click on save as shown in the screenshot below.

For more information on how to record a Jmeter script using Blaze Meter, follow the link

Modifying the Test Scripts in JMeter

The recorded script can then be opened in JMeter, and necessary changes can be made as per the different Load and Performance Scenarios to be assessed for the application.

Select the generated .jmx file and click on open

In addition to these you can add listeners to the thread groups, for better visibility of each sample results.

Setting up a Jenkins pipeline to execute JMeter tests

Install Jenkins: If you haven’t already, install Jenkins on your server following the official documentation.

Create a New Pipeline Job: A new pipeline job should be created to orchestrate the performance testing process. Click on new item to create a pipeline job and select pipeline option.

Post creating a new pipeline, navigate to configure and mention the scheduled time in the below format.

(‘H 0 */3 * *’)

Define Pipeline Script: Configure the pipeline script to execute the JMeter test at regular intervals using a cron expression.

 pipeline {

    agent {

        label ‘{agent name}’

    }

This part of the Jenkins pipeline script specifies the agent (or node) where the pipeline should run. The label ‘{agent name}’ should be replaced with the label of the specific agent you want to use. This ensures that the pipeline will execute on a machine that matches the provided label.

stages {

      stage(‘Running JMeter Scripts’) {

          steps {

              script {

 sh ”’

    output_directory=”{path}/$(date +’%Y-%m-%d’)”

    mkdir -p “$output_directory”

    cd {Jmeter Path}/bin

    sh jmeter -n -t {Jmeter Script Path} -l “$output_directory/{Result file name}” -e -o “$output_directory”

    cp “$output_directory”/{Result file name} $WORKSPACE

    cp -r $output_directory $WORKSPACE

    ”’

       }

            }      

}

This stage named ‘Running JMeter Scripts’ has steps to execute a shell script. The script does the following:
1. Creates an output directory with the current date.
2. Navigates to the JMeter binary directory.
3. Runs the JMeter test script specified by {Jmeter Script Path}, storing the results in the created directory
4. Copies the result file and output directory to the Jenkins workspace for archiving.

post {

        always {

            script {

                currentBuild.result = currentBuild.result

                def date = sh(script: ‘date +\’%Y-%m-%d\”, returnStdout: true).trim()

                def subject = “${currentBuild.result}: Job ‘${env.JOB_NAME}'”

                def buildLog = currentBuild.rawBuild.getLog(1000)

                emailext(

                    subject: subject,

                    body: “”” Hi Team , Jmeter build was successful , please contact team for the results “””,

                    mimeType: ‘text/html’,

                    to: ‘{Receiver Email}’,

                    from: ‘{Sender Email}’,

                    attachLog: true ,

                )

            }

     }

This post block runs after the pipeline completes. It retrieves the last 1000 lines of the build log and sends an email notification with the build result, a message, and the build log attached to specified recipients.

View the generated reports.

In Linux instance navigate to the path where the .html files are stored i.e. the output report of the jmeter scripts

Before you open the HTML file, move the complete folder to your local device. Once the folder is moved open the .html file and you’ll be able to analyze the reports

Conclusion

By following the steps described and the approach suggested, we have shown how Integrating JMeter with Jenkins enables teams to automate performance testing and incorporate it seamlessly into the CI/CD pipeline. By scheduling periodic tests, storing results, and sending out email notifications, organizations can ensure the reliability and scalability of their applications with minimal manual intervention. Embrace the power of automation and elevate your performance testing efforts with Jenkins and JMeter integration. For any assistance in automation of your Performance tests please get in touch with us at [email protected] or leave us a note at form and we will get in touch with you.

Frequently Asked Questions (FAQs)

You can download the latest version from the Apache JMeter homepage, after download extract the downloaded files to a directory on the agent machine and Make sure to add the JMeter bin directory in the system's PATH variable so that all JMeter commands can be run from the command line.

Its a Chrome extension that helps users to record and create JMeter scripts easily. To use it, install the BlazeMeter extension from the Chrome Web Store and record the desired scenarios on your web application, and export the recorded script in .jmx format. This script can then be modified in JMeter and used in your Jenkins pipeline for automated performance testing.

Create a new pipeline job in Jenkins and define the pipeline script to include stages for running JMeter tests. The script should include steps to execute JMeter commands, store the results, and send notifications. Here's a example script for you 

pipeline {

    agent { label 'your-agent-label'

 }

    stages {

        stage('Run JMeter Tests') {

            steps {

                script {

                    sh '''

                    output_directory="/path/to/output/$(date +'%Y-%m-%d')"

                    mkdir -p "$output_directory"

                    cd /path/to/jmeter/bin

                    sh jmeter -n -t /path/to/test/script.jmx -l "$output_directory/results.jtl" -e -o "$output_directory"

                    cp "$output_directory/results.jtl" $WORKSPACE

                    cp -r "$output_directory" $WORKSPACE

                    '''

                }

            }

        }

    }

    post {

        always {

            emailext (

                subject: "JMeter Test Results",

                body: "The JMeter tests have completed. Please find the results attached.",

                recipientProviders: [[$class: 'DevelopersRecipientProvider']],

                attachLog: true

            )

        }

    }

}

You can schedule the JMeter test execution using the cron syntax in the Jenkins pipeline configuration. For example, to run the tests every three hours, you can use:<br><br>

H 0 */3 * * *

<br><br>

This will trigger the pipeline at the top of the hour every three hours.

After the JMeter tests are executed, the results are typically stored in a specified directory on the Jenkins agent. You can navigate to this directory, download the results to your local machine, and open the HTML reports generated by JMeter for detailed analysis.