All posts by Arturs Lontons

Handy Tips #26: Displaying infrastructure status with the Geomap widget

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-26-displaying-infrastructure-status-with-the-geomap-widget/20012/

Secure your Zabbix logins from brute-force and dictionary attacks by defining password complexity requirements.

Enforcing an organization-wide password policy can be extremely unreliable if we don’t have a toolset to enforce these policies. By using native password complexity settings, we can provide an additional layer of security and ensure that our users follow our organization’s password complexity policies.

Define custom Zabbix login password complexity rules:

  • Set the minimum password length in a range of 2 – 70 characters
  • Define password character set rules

  • A built-in password list secures users from dictionary attacks
  • Prevent usage of passwords containing first or last names and easy to guess words

Check out the video to learn how to configure Zabbix password complexity requirements.

How to configure Zabbix password complexity requirements:
 
  1. As a super admin navigate to Administration → Authentication
  2. Define the minimum password length
  3. Select the optional Password must contain requirements
  4. Mark Avoid easy-to-guess passwords option
  5. Navigate to Administration → Users
  6. Select use for which we will change the password
  7. Press the Change password button
  8. Try using  easy to guess passwords like zabbix or password
  9. Observe the error messages
  10. Define a password that fits the password requirements
  11. Press the Update button

Tips and best practices:
  • It is possible to restrict access to the ui/data/top_passwords.txt file, which contains the Zabbix password deny list
  • Passwords longer than 72 characters will be truncated
  • Password complexity requirements are only applied to the internal Zabbix authentication
  • Users can change their passwords in the user profile settings

The post Handy Tips #26: Displaying infrastructure status with the Geomap widget appeared first on Zabbix Blog.

Handy Tips #25: Securing Zabbix logins with password complexity settings

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-25-securing-zabbix-logins-with-password-complexity-settings/19883/

Secure your Zabbix logins from brute-force and dictionary attacks by defining password complexity requirements.

Enforcing an organization-wide password policy can be extremely unreliable if we don’t have a toolset to enforce these policies. By using native password complexity settings, we can provide an additional layer of security and ensure that our users follow our organization’s password complexity policies.

Define custom Zabbix login password complexity rules:

  • Set the minimum password length in a range of 2 – 70 characters
  • Define password character set rules

  • A built-in password list secures users from dictionary attacks
  • Prevent usage of passwords containing first or last names and easy to guess words

Check out the video to learn how to configure Zabbix password complexity requirements.

How to configure Zabbix password complexity requirements:
 
  1. As a super admin navigate to Administration → Authentication
  2. Define the minimum password length
  3. Select the optional Password must contain requirements
  4. Mark Avoid easy-to-guess passwords option
  5. Navigate to Administration → Users
  6. Select use for which we will change the password
  7. Press the Change password button
  8. Try using  easy to guess passwords like zabbix or password
  9. Observe the error messages
  10. Define a password that fits the password requirements
  11. Press the Update button

Tips and best practices:
  • It is possible to restrict access to the ui/data/top_passwords.txt file, which contains the Zabbix password deny list
  • Passwords longer than 72 characters will be truncated
  • Password complexity requirements are only applied to the internal Zabbix authentication
  • Users can change their passwords in the user profile settings

The post Handy Tips #25: Securing Zabbix logins with password complexity settings appeared first on Zabbix Blog.

Zabbix security advisories regarding CVE-2022-23131 and CVE-2022-23134

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/zabbix-security-advisories-regarding-cve-2022-23131-and-cve-2022-23134/19720/

Here at Zabbix, the security of our product is our top priority. It has come to our attention that two potential CVE issues have been highlighted in tech media outlets  –  CVE-2022-23131 and CVE-2022-23134.

The most critical issue – CVE-2022-23131, affects only Zabbix instances where SAML SSO authentication is in use. While CVE-2022-23134 Affects Zabbix 5.4.x releases older than Zabbix 5.4.9.

Zabbix is aware of the following vulnerabilities And they have since been fixed in Zabbix version 5.4.9 and the stable release of Zabbix 6.0 LTS.

  • CVE-2022-23131 – Unsafe client-side session storage leading to authentication bypass/instance takeover via Zabbix Frontend with configured SAML
    • Affected versions: 5.4.0 – 5.4.8; 6.0.0alpha1
  • CVE-2022-23134 – Possible view of the setup pages by unauthenticated users if config file already exists
    • Affected versions: 5.4.0 – 5.4.8; 6.0.0 – 6.0.0beta1

We urge everyone who is using the SAML SSO authentication features in your environment o update your Zabbix instance to one of the aforementioned versions where the security vulnerabilities have been resolved.

keep track of any potential Zabbix security issues, the affected versions, and the required updates, visit our public Zabbix Security Advisories and CVE database page.

The post Zabbix security advisories regarding CVE-2022-23131 and CVE-2022-23134 appeared first on Zabbix Blog.

Handy Tips #24: Preventing downtimes with The Zabbix HA cluster

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-24-preventing-downtimes-with-the-zabbix-ha-cluster/19712/

Configure automated failover between Zabbix server nodes with the native Zabbix server HA cluster.

Preventing downtimes is as vital for a monitoring solution as it is for any other component of an organization’s IT infrastructure. High availability and automated failover can help you prevent unwanted downtimes by supporting multiple application nodes and failing over between them once a primary node has failed.

Deploy native Zabbix server High availability cluster:

  • Deploy two or more Zabbix server nodes
  • No external tools are required to deploy a Zabbix server HA cluster

  • Define custom failover delay before failing over to another node
  • Monitor the status of your Zabbix cluster on Zabbix dashboards

Check out the video to learn how to deploy the Zabbix server High availability cluster:

How to deploy the Zabbix server High availability cluster:
 
  1. Deploy two or more Zabbix server nodes
  2. On all cluster nodes open the Zabbix server configuration file – zabbix_server.conf
  3. On all cluster nodes provide arbitrary node name in the HANodeName parameter
  4. On both nodes provide the node address in the NodeAddress parameter
  5. Open your Zabbix frontend configuration file – zabbix.conf.php
  6. Comment out the //$ZBX_SERVER and $ZBX_SERVER_PORT parameters
  7. From the active node check the HA cluster status with zabbix_server -R ha_status command
  8. Open your Zabbix frontend GUI
  9. Navigate to Reports →  System information
  10. Confirm the Zabbix server HA cluster node status

Tips and best practices:
  • Specifying the HANodeName parameter in the Zabbix server configuration file enables the HA cluster mode
  • The NodeAddress parameter is used by the Zabbix frontend to connect to the active cluster node
  • Zabbix frontend configuration file parameters – $ZBX_SERVER and $ZBX_SERVER_PORT must be commented out for the frontend to automatically detect the active cluster node
  • The current status of the HA cluster can be managed using the dedicated runtime control options

The post Handy Tips #24: Preventing downtimes with The Zabbix HA cluster appeared first on Zabbix Blog.

Zabbix 6.0 LTS is out now!

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/zabbix-6-0-lts-is-out-now/18757/

The Zabbix team is proud to announce the release of Zabbix 6.0 LTS. The latest version comes packed with many new features, improvements, new templates and integrations.

New features

  • Out-of-the-box High Availability cluster for Zabbix server with support for one or multiple standby nodes
  • Redesigned Services section, tailored for flexible Business Service monitoring with the ability to monitor over 100k services, define flexible service calculation rules, perform root cause analysis, receive service status change alerts, and more
  • New machine learning trend functions for baseline monitoring and anomaly detection
  • Monitor your Kubernetes instance with out-of-the-box Kubernetes monitoring for pods, nodes, and Kubernetes component monitoring
  • New Audit log schema enables detailed logging for both the Zabbix frontend and backend
  • Track your host status and location with the new Geomap widget
  • The Top hosts widget provides Top N and Bottom N host views sorted by item values
  • Ability to define custom Zabbix password complexity requirements
  • Multiple UI improvements. Hosts can now be created directly from the Monitoring section.
  • Zabbix Agent2 now supports loading stand-alone plugins without having to recompile the Agent2
  • Monitor SSL/TLS certificates with a new Zabbix Agent2 item
  • Performance improvements for Zabbix Server, Proxy, and Frontend

  • All of the official Zabbix templates are now stand-alone and do not require importing additional template dependencies

  • And many other improvements and features

 

This version also provides a set of new templates for the following vendors:

  • F5 BIG-IP

  • Cisco ASAv

  • HPE ProLiant servers

  • Cloudflare

  • InfluxDB

  • Travis CI

  • Dell PowerEdge

  • pfSense

  • Kubernetes

  • Mikrotik

  • Nginx Plus

  • VMware SD-WAN VeloCloud

  • GridGain

  • Systemd

  • As well as a new Github webhook integration

The latest LTS release will receive full official support for 3 years and limited support, which consists of bug fixes for 5 years.

Find out more about Zabbix 6.0 LTS by visiting our What’s new in Zabbix 6.0 LTS webinar, covering the most important new features and improvements: https://www.zabbix.com/webinars

An overview of the new features and changes can be found on our What’s new in Zabbix 6.0 page:

https://www.zabbix.com/whats_new_6_0

What’s new in Zabbix 6.0.0 documentation section:

https://www.zabbix.com/documentation/current/en/manual/introduction/whatsnew600

Take a look at the release notes to see the full list of new features and improvements:

https://www.zabbix.com/rn/rn6.0.0

Zabbix 6.0 LTS packages

The official Zabbix packages are available for:

  • Linux distributions for different hardware platforms on RHEL, CentOS, Oracle Linux, Debian, SuSE, Ubuntu, Raspbian
  • Virtualization platforms based on VMWare, VirtualBox, Hyper-V, XEN
  • Docker
  • Packages and pre-compiled agents for most popular platforms, including macOS and MSI packages for Windows

You can find the download instructions and download the new version on the download page: https://www.zabbix.com/download

One-click deployment is available for the following cloud platforms:

  • AWS, Azure, Google Cloud, Digital Ocean, Linode, Oracle Cloud, Red Hat OpenShift, Yandex Cloud

Zabbix 6.0 also incorporates the features added in Zabbix 5.2 and Zabbix 5.4 non-LTS versions.

Upgrading to Zabbix 6.0 LTS

In order to upgrade to Zabbix 6.0 LTS, you need to upgrade your repository package and download and install the new Zabbix component packages (Zabbix server, proxy, frontend, and other Zabbix components). When you start the Zabbix Server, an automatic database schema upgrade will be performed. Zabbix Agents are backward compatible; therefore, it is not required to install the new agent versions. You can do it at a later time if needed.

If you’re using the official Docker container images – simply deploy a new set of containers for your Zabbix components. Once the Zabbix server container connects to the backend database, the database upgrade will be performed automatically.

You can find step-by-step instructions for the upgrade process to Zabbix 6.0 LTS in the Zabbix documentation.

If you’re interested in a list of changes and an additional pre-upgrade checklist – the following blog post covers the nuances of the upgrade process and takes a look under the hood at what changes are performed during the upgrade.

The post Zabbix 6.0 LTS is out now! appeared first on Zabbix Blog.

Handy Tips #23: Suppressing problems with Zabbix maintenance periods

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-23-suppressing-problems-with-zabbix-maintenance-periods/19458/

Suppress unwanted problems during planned maintenance by defining Zabbix maintenance periods.

Planned downtimes due to maintenance are a part of every administrator’s life. Be it updating your software or upgrading the underlying hardware – sooner or later we will need to schedule a planned downtime. We also need to find a way to suppress the problems that these planned maintenance jobs can cause.

Define maintenance periods in Zabbix:

  • Prevent alert storms during maintenance periods
  • Define scheduled or one-time downtimes

  • Define maintenance periods for hosts or host groups
  • Use tags to suppress only the matching problems

Check out the video to learn how to use Zabbix Sender to send custom metrics to your Zabbix instance.

How to define a Zabbix maintenance period:
 
  1. Navigate to Configuration → Maintenance
  2. Click on the Create maintenance period button
  3. Type in the maintenance period name
  4. Select the maintenance type and the activity time window
  5. Add a period during which your maintenance will take place
  6. Select hosts and/or host groups
  7. Optionally, specify tags to suppress only the matching problems 
  8. Add the maintenance period
  9. Wait until the configuration changes are picked up by the Zabbix server
  10. Navigate to Monitoring → Problems
  11. Confirm if the problems on the host are suppressed

Tips and best practices:
  • Suppressed problems can be displayed in the problems section by checking the Show suppressed problems checkbox
  • Host status is switched to/from maintenance only at the start of the minute
  • If you create a maintenance period with data collection, the triggers are processed as usual, but any related problems are suppressed
  • If you create a maintenance period with no data collection, no related metrics will be collected during the maintenance period 

The post Handy Tips #23: Suppressing problems with Zabbix maintenance periods appeared first on Zabbix Blog.

Handy Tips #22: Deploying Zabbix in the AWS cloud platform

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-22-deploying-zabbix-in-the-aws-cloud-platform/19343/

Deploy a production-ready Zabbix instance in the AWS cloud platform with just a few clicks.

With a major paradigm shift to cloud IT infrastructures, many organizations opt-in to migrate their on-prem systems to the Cloud. Zabbix provides official cloud images for the most popular cloud vendors including the AWS cloud platform.

Deploy the complete Zabbix infrastructure in AWS:

  • Deploying a fully functional environment takes less than 5 minutes
  • Select between multiple geographical regions

  • Select the EC2 Instance type best fit for your Zabbix workloads
  • Perfect for both Q/A and Production environments

Check out the video to learn how to deploy Zabbix in AWS.

How to deploy a Zabbix instance in AWS:
 
  1. Open the Zabbix Cloud Images page and select the AWS Zabbix server image
  2. Click Continue to Subscribe and subscribe to use the image
  3. Read the terms and conditions and click Continue to Configuration
  4. Select the Region in which you wish to deploy a Zabbix instance
  5. Select the launch options and the EC2 instance Type
  6. Select a VPC, a subnet, a Security group, and a key pair
  7. Make sure that the selected security group allows traffic through ports 10051, 22 and 443
  8. Press Launch to launch the instance
  9. Check the instance address and connect to the instance 
  10. Copy the initial frontend username and password
  11. Sign-in into the frontend with your credentials

Tips and best practices:
  • The initial frontend password can be obtained by connecting to the instance terminal
  • By default, the Zabbix frontend uses the UTC timezone
  • The frontend timezone can be changed by editing the php_value[date.timezone] variable in /etc/php-fpm.d/zabbix.conf and restarting the php-fpm process
  • The MySQL root password is stored in /root/.my.cnf configuration file

The post Handy Tips #22: Deploying Zabbix in the AWS cloud platform appeared first on Zabbix Blog.

Handy Tips #21: Deploying Zabbix Server with Docker containers

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-21-deploying-zabbix-server-with-docker-containers/18972/

Deploy Zabbix components in docker containers for advanced automation, scalability, and maintenance.

In the past few years, containers have gained prevalence and are being used for many different tasks – from application development to improving automation and management of existing software.

Deploy Zabbix components in Docker containers:

  • Official Docker images are available for individual components
  • Automate the deployment of your Zabbix containers

  • Use containers to quickly scale your environment
  • Upgrade to a newer Zabbix version by deploying containers from the latest container images

Check out the video to learn how to deploy the Zabbix server with Docker containers.

How to deploy Zabbix server with Docker containers:
 
  1. Connect to your Docker container host
  2. Create a new docker network. Specify the subnet and the IP range for containers.
  3. Deploy your Zabbix server container
    1. Give the container a name and assign it to the newly created network
    2. Pass the Database host, user, and password in environment variables
    3. Map the port 10051 on the host to the port 10051 on the container
    4. Select the required Docker image and tag
  4. Deploy your Zabbix frontend container
    1. Give the container a name and assign it to the newly created network
    2. Pass the Database host, user, and password in environment variables
    3. Pass the Zabbix server address in the environment variable
    4. Map port 80 on your host to port 8080 on the container
  5. Use docker ps and docker logs to check if the containers are running
  6. Connect to your Zabbix frontend and confirm that there are no issues with the environment

Tips and best practices:
  • Container logs can be accessed by using the docker logs command
  • Zabbix server checks for an existing Zabbix database. If it does not exist – it will get created.
  • Use the docker exec command to run commands inside a container
  • All of the supported container environment variables are available in https://hub.docker.com/u/zabbix

The post Handy Tips #21: Deploying Zabbix Server with Docker containers appeared first on Zabbix Blog.

Handy Tips #20: Agentless metric collection with SSH checks

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-20-agentless-metric-collection-with-ssh-checks/18795/

Collect the results of SSH commands with Zabbix agentless SSH checks.

In environments where Zabbix agent installation is forbidden either by company policies or due to restrictions on the monitored device, we can utilize one of the multiple agentless metric collection methods. One such type of metric collection method is Zabbix SSH checks.

Collect metrics with Zabbix SSH checks:

  • SSH checks are completely agentless
  • SSH checks can be executed by Zabbix server or Zabbix proxy

  •  SSH checks support Password or Public key authentication
  • Multiple commands can be executed one after another

Check out the video to learn how to collect metrics by using SSH checks.

How to collect metrics by using SSH checks:
 
  1. Navigate to Configuration → Hosts and find your host
  2. Click on the Items button next to the host name
  3. Press Create item button
  4. Provide item Name, Key and select the Type of information
  5. Select the required Authentication method
  6. Enter the authentication parameters
  7. Populate the Executed script field with your SSH command
  8. Click the Add button
  9. Wait for the data to get collected
  10. Navigate to Monitoring → Latest data and find your Host and item
  11. Check if the metric has been collected successfully

Tips and best practices:
  • Zabbix preprocessing can be used to transform the collected metrics
  • A dedicated OS user can be defined and used for Zabbix SSH checks
  • SSHKeyLocation configuration parameter defines the location of the public and private keys for Public key authentication
  • It is recommended to use libssh version >= 0.9.5 

The post Handy Tips #20: Agentless metric collection with SSH checks appeared first on Zabbix Blog.

Handy Tips #19: Preventing alert storms with trigger dependencies

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-19-preventing-alert-storms-with-trigger-dependencies/18696/

Prevent receiving a flood of unwanted alerts and receive only the most critical notifications by defining trigger dependencies.

Every IT infrastructure has multiple elements, failure of which can cause a cascading set of problems across the particular infrastructure segment. It is important to prevent an unwanted alert storm and highlight only the root cause problem within the problem chain.

Define trigger dependencies to prevent alert storms:

  • Only the most critical problems will be displayed in Zabbix
  • Dependent triggers will not generate problems until the parent trigger is in an OK state

  • Each trigger can have multiple trigger dependencies
  • Trigger dependencies can be defined between triggers on different hosts

Check out the video to learn how to define trigger dependencies.

How to define a trigger dependency:
 
  1. Navigate to Configuration → Hosts
  2. Find the host for which you will define the trigger dependency
  3. Click on the triggers button next to the host
  4. Open the trigger for which you will define the dependency
  5. Click on the Dependencies tab
  6. Click add and select the host containing the parent trigger
  7. Select the trigger on which the current trigger will depend on
  8. If required, add more trigger dependencies
  9. Click the Update button
  10. Simulate a problem to test the dependency
  11. Navigate to Monitoring → Problems and observe the trigger dependency behavior

Tips and best practices:
  • The dependent trigger will only be re-evaluated once the related item receives new metrics
  • Trigger dependency may be added between host triggers as long as it wouldn’t result in a circular dependency
  • A trigger dependency chain between multiple hosts can be created
  • Zabbix will not execute actions for the dependent trigger if the parent trigger is in a problem state

The post Handy Tips #19: Preventing alert storms with trigger dependencies appeared first on Zabbix Blog.

Top 10 reasons to migrate to Zabbix 6.0 LTS by Dmitry Krupornitsky / Zabbix Summit Online 2021

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/top-10-reasons-to-migrate-to-zabbix-6-0-lts-by-dmitry-krupornitsky-zabbix-summit-online-2021/18445/

Today we will take a look at the top 10 reasons to migrate to Zabbix 6.0 LTS. We will discuss features and changes included not only in Zabbix 6.0 LTS but also in intermediate major versions – Zabbix 5.2 and Zabbix 5.4.

The full recording of the speech is available on the official Zabbix Youtube channel.

High availability

With Zabbix 6.0 LTS, native support for Zabbix server high availability clusters is finally here. High availability setups can protect you from software and hardware failures and allow you to minimize downtime while performing maintenance tasks. Before Zabbix 6.0 LTS, users were required to use a dedicated piece of clustering software to enable high availability. Most users used a combination of Corosync + pacemaker software. This required additional knowledge related to these tools, to ensure a proper high availability cluster setup, configuration, maintenance, and other tasks related to managing your Zabbix high availability cluster. You could also use other 3rd party vendor solutions, but such solutions also require additional knowledge and in many cases incur additional licensing costs.

The native Zabbix server high availability cluster is an opt-in solution that provides high availability for the Zabbix server component. This solution consists of multiple Zabbix server instances – nodes, where each node is configured separately and uses the same database. Each node has two modes of operation – active or standby. Only a single node can be active at a time. The standby nodes do not perform any data collection, data processing, or any other Zabbix server activities. The standby nodes do not listen for connection on ports and have a minimal number of connections established to the Zabbix backend database. The high availability nodes are compatible with one another across different minor Zabbix server versions.

Learn how to deploy your own Zabbix server high availability cluster by following the steps provided in our Zabbix Summit blog post dedicated to this topic.

New Zabbix interface options

Zabbix 6.0 LTS provides multiple Zabbix interface improvements. One of the major changes that the users will notice when switching to Zabbix 6.0 LTS is the migration from screens to dashboards. The screens will be migrated to dashboards automatically during the upgrade. Dashboards consist of multiple highly customizable widgets, which can be placed on a dashboard with a click of a button. With Zabbix 6.0 LTS many new widgets will be available for different purposes – more flexible views of your metrics with the Single item value widget, a Geomap widget for a better overview of your infrastructure state, Top N/Bottom N views provide a whole new way to look at your metrics and more.

Now you will be able to save your favorite problem filters and access your filters in tabs for more simple filtering of the commonly accessed problem views.

Zabbix 6.0 LTS introduces timezone configuration on a per-user basis. Users can now have their preferred timezone configured via the user settings in the Zabbix frontend. The same is also true for language – this can also now be configured individually for each user.

The Zabbix frontend is now more customizable than ever. There are several ways in which you can customize your Zabbix frontend:

  • Replace the Zabbix logo with your company’s branding
  • Hide links to Zabbix support/integration pages
  • Set a custom help page link
  • Change the copyright notice in the footer of the frontend.

Implementing these changes requires customizing the underlying PHP code – we tried to make this as simple and accessible as possible, so you can quickly make the necessary changes yourself.

There are also many other Interface improvements, such as multi-page dashboards, third-level menus, graph improvements, and many others.

Improved security

Security is always something that we focus on when developing Zabbix. Zabbix 6.0 LTS brings many new security-related improvements and features:

  • User roles allow you to define roles with granular permissions related to the frontend access and the actions that each user role is permitted to perform
    • Roles are still based on user types – Zabbix User, Admin, Super admin, and user type restrictions still apply, but can be further customized per each role
    • User group to host group permissions (Read, Read/Write, Deny) still need to be used in combination with roles to ensure granular access to your data
    • For example, now we can define users that have access to host configuration but restrict access to other configuration sections.

In Zabbix 6.0 LTS it is possible to define custom password complexity requirements for Zabbix frontend logins. We can define password length/complexity policies and prohibit the usage of easy to guess common passwords.

The Zabbix API has also seen some security improvements. Now it is possible to generate a persistent API token for a particular user, define an expiration date and use the token in your API calls, without the need to regularly re-issue a new API token.

Zabbix 5.2 release also added the ability to store sensitive information in an external vault. As of the release of Zabbix 6.0 LTS, only HashiCorp Vault is supported, but CyberArk Vault support is also coming in Zabbix 6.2 release.

A set of architectural and structural measures have been taken to completely restructure the Zabbix Audit log. The updated Audit log entry contains records of all configuration changes made by the Zabbix server and Zabbix frontend. The new Audit log also contains additional filtering options, such as filtering Audit log entries based on the operation during which the changes were performed. The new Audit log is not only more detailed but also reworked with minimum performance impact in mind.

Scalability improvements

Many scalability improvements have been introduced between the Zabbix 5.0 LTS release and Zabbix 6.0 LTS release. These improvements not only improve the performance of existing Zabbix instances but also lay the groundwork for the design of upcoming features in later releases.

Previously, trend-based trigger functions would always use database queries to obtain the required data. Starting from Zabbix 5.4, a new type of cache – Trend function cache, has been introduced. This cache stores the results of calculated trend functions. When processing the trend functions, the Zabbix server will check the Trend function cache for the cached results. In case of failure, the Zabbix server will read the data from the database and cache the results.

The scalability improvements allow for better parallel data processing on Zabbix servers with heavy loads. Zabbix Instances with tens of thousands or more new values per second will greatly benefit from the improved performance.

The introduction of the graceful startup of the Zabbix server can help you improve performance and prevent unwanted downtimes, especially with large distributed environments. Whenever a Zabbix server gets started up after downtime, the existing Zabbix proxies start sending the data backlog to the Zabbix server. it is extremely important to maintain the stability and performance of the Zabbix server during this time window. Graceful startup improves the Zabbix server data backlog handling logic during such situations.

To prevent unwanted delays and other issues when using zabbix_get and zabbix_sender command-line tools, it is now possible to define a custom Timeout parameter for these tools.

Advanced business service monitoring

The new Busines service monitoring features allow Zabbix users to not only define complex service trees but also receive alerts in situations where the status of a business service has been changed. This is valuable to every user that wishes to monitor their business services, no matter how simple or complex the service is.

Combined with a large number of new and improved service status calculation rules. By defining custom service weights and advanced service status propagation rules, the business services can be defined in an extremely flexible fashion. Services are also not linked to individual triggers anymore, instead, we use tag-based service mapping to map our services to problem events.

The service functionality has also received scalability improvements. Zabbix can support the monitoring of over 100 000 business services. The scalability improvements have been implemented from both the UI/UX and the performance perspectives.

The old all-or-nothing business service permission approach has been redesigned to a granular read/write permissions for individual business services. This is not only an improvement from the security perspective, but also adds the ability to define services in a multi-tenant fashion, where each tenant has access only to the services that they own.

With the redesign of the business services, we have added the support for root cause analysis, allowing users to see the underlying problem which caused a particular service to change its state.

You can read more about Business service monitoring in our Zabbix Summit blog post dedicated to this topic.

Tag and template improvements

Item applications have been replaced with tags. This design decision adds consistency to filtering, mapping, grouping, and other tag-related functions when it comes to different Zabbix entities. Tags can also be used to provide additional information related to your entities in a manner that is much more flexible than it was with applications.

Universal template IDs introduced for each of the template elements allow you to define much more robust template management workflows, especially when you combine this with a CI/CD template management approach. These IDs are unique and can be used to match a particular template entity, such as item, trigger, graph, and so on. By utilizing the Universal template IDs, Zabbix now understands which entity we are trying to update, which entity no longer exists, whether it is a new entity or we are adjusting an existing entity. The default template export format is now YAML, though JSON and XML formats are still supported. This was done to improve the template management usability since the YAML format is more user-friendly and easier to edit manually. All of the official Zabbix templates available on the Zabbix git page have already been converted to the YAML format.

The redesign of the templates has also allowed us to improve the visualization of the changes made when importing a template. Now users can see the list of changes in a diff-like display and understand the impact that the template import will have on the  Zabbix entities.

Value maps have been moved to host and template levels. This is another design decision that we made to enable support for fully self-contained templates, that are easy to manage and deploy, and can be easily imported into different Zabbix environments. While global value maps might be easy to manage in small environments, this is not the case in larger environments, where different teams are working with a single or between multiple Zabbix instances. Therefore, the global value maps have been removed.

Reporting and visualization

With the addition of Scheduled reports functionality, any dashboard can now be converted into a scheduled report. While this feature was originally added in Zabbix 5.4, with the release of Zabbix 6.0 LTS and a set of new widgets, the reporting functionality has gained a lot of additional value that these widgets grant specifically from the reporting perspective. Users can create scheduled reports and receive them in their mailbox at a specific time either on a daily, weekly, monthly, or yearly basis. The time period for which the report will provide the information can also be selected.

The new Geographical map widget allows you to quickly deploy a geomap with an overview of the state of your infrastructure. The geomap widget supports filters, so we can display only a particular part of your infrastructure. Zabbix uses an open-source Javascript interactive maps library called Leaflet and supports multiple map providers such as OpenStreetMap, OpenTopoMap, USGS US Topo, and more. Users also have the ability to define and use a custom map tile provider. The map will display your infrastructure and also highlight any detected problems as well as display problem counters. This is a major step forward from the old approach, which required users to use the regular map functionality together with Zabbix API scripting, to provide information on a geographical map.

Advanced problem detection

Zabbix 5.4 release introduced a new unified syntax for defining trigger expressions, calculated, and aggregated items. There are multiple benefits that come with the new trigger syntax. First off – the syntax is now unified and can be used for defining triggers, calculated items, and providing values in maps or graph names. The syntax also has a more functional approach, instead of being object-oriented. This allows us to solve many complex use cases, for example dynamically calculate or aggregate a value from all hosts tagged with a specific tag or belonging to a specific host group. Aggregated item type has also been removed and users can now define aggregate checks under the calculated item type.

New monitoring functionality and integrations

As with every major release, Zabbix 6.0 LTS comes with a set of new items and improves the functionality of already existing items:

  • It is now possible to monitor SSL certificate validity and expiration data, such as the expiry date, issuer, version, subject, and more
  • New Zabbix Agent 2 metrics allow you to collect file owner information, file properties, extended interface info, extended TCP info, SHA2 hashes for files, and more
  • New templates for NGINX+, HPE/Dell servers, CISCO ASAv, Cloudflare

Finally – Zabbix 6.0 LTS

Many of our users and customers prefer sticking with the LTS releases instead of upgrading between each major version. As with every LTS release, there are major benefits to sticking with Zabbix 6.0 LTS:

  • LTS release receive thorough testing and full long term support
    • 3 years of full support – general, critical, and security fixes/improvements
    • 5 years of limited support – critical and security fixes

Questions

Q: Which of the current versions are still supported and for how long are they going to remain supported? What updates can we expect these versions to receive?

A: Currently we have three supported major versions available. Zabbix 5.4, which will not be supported after the release of Zabbix 6.0 LTS. We also still provide support for Zabbix 5.0 LTS and Zabbix 4.0 LTS. Zabbix 5.0 LTS will continue receiving full support until the middle of 2023 and limited support until the middle of 2025, while Zabbix 4.0 LTS will receive limited support until November 2023.

 

Q: Could you elaborate on how tags are more flexible than applications and are there any other benefits to using tags?

A: Zabbix already supports tags for most of the essential Zabbix objects, such as triggers, hosts, host prototypes, and templates. With the introduction of tags for items, tags can now be found everywhere. This way you can have tags that provide different additional information and assign values for your objects. Tags have several usages – for example, we can use them to mark events. If we have an item with a tag, this tag will mark any problem related to this item. Problem events will inherit tags from the whole tag chain – hosts, templates, triggers, items, and more. Further down the line, we can use our actions to react to specific tags. If you recall, Business services are also mapped to problems based on the tag mapping. Of course, tags can also be used for filtering and grouping different Zabbix objects.

 

Q: Is there a guideline to the migration process from an older version to Zabbix 6.0 LTS? Is there a change list that I can look at to see what other features have received an overhaul?

A: Regarding the upgrade itself – our documentation contains guidelines for both upgrading from packages and upgrading from sources. The documentation may also contain upgrade notes regarding any extra steps or precautions required when upgrading to a particular version. Regarding the feature changes – we recommend reading through the major version release notes. For example, if you’re upgrading from Zabbix 5.0 LTS to Zabbix 6.0 LTS, make sure to familiarize yourself not only with the Zabbix 6.0 LTS release notes, but also read through the Zabbix 5.2 and Zabbix 5.4 release notes, since changes introduced in these versions will also be a part of Zabbix 6.0 LTS.

The post Top 10 reasons to migrate to Zabbix 6.0 LTS by Dmitry Krupornitsky / Zabbix Summit Online 2021 appeared first on Zabbix Blog.

Handy Tips #18: Distributed monitoring with a lightweight Zabbix SQLite proxy

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-18-distributed-monitoring-with-a-lightweight-zabbix-sqlite-proxy/18401/

Distribute your monitoring by deploying a lightweight Zabbix SQLite proxy in 5 minutes.

Monitoring remote data centers can be challenging when the data collection is performed from a single location. Distributed monitoring can help us resolve potential issues such as loss of data in case of network outages, horizontal scalability, and much more.

Distribute and scale your monitoring with a lightweight Zabbix SQLite proxy:

  • Collect data in case of network outages between data centers
  • Deploy an unlimited number of Zabbix proxies

  • SQLite proxies are perfect for running on embedded hardware
  • Proxy connections can be encrypted

Check out the video to learn how to deploy a Zabbix SQLite proxy.

How to deploy a Zabbix SQLite proxy:

  1. Install the Zabbix repository and Zabbix proxy packages
  2. Locate and open the zabbix_proxy.conf configuration file
  3. Populate the Server, Hostname, and DBName parameters
  4. Enable and start the Zabbix proxy
  5. Open Administration → Proxies and click the Create Proxy button
  6. Provide the proxy name and click the Add button
  7. Open the Zabbix agent configuration file
  8. Populate the Server and/or ServerActive parameters
  9. Restart the Zabbix agent
  10. Navigate to Configuration → Hosts and open your host
  11. Select the proxy in the Monitored by proxy field and click the Update button
  12. Wait for the proxy to receive the configuration changes
  13. Navigate to Monitoring → Latest data
  14. Check if the Zabbix proxy has collected the metrics 

Tips and best practices:
  • By default, Zabbix proxies receive configuration updates once an hour
  • Each Zabbix Proxy can use a different database engine
  • Monitor the proxy performance with the Zabbix proxy templates
  • Zabbix proxies will perform preprocessing tasks before sending the data to the Zabbix server

The post Handy Tips #18: Distributed monitoring with a lightweight Zabbix SQLite proxy appeared first on Zabbix Blog.

Handy Tips #17: Master and dependent items for bulk metric collection

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-17-master-and-dependent-items-for-bulk-metric-collection/18291/

Collect metrics in bulk and reduce monitoring performance overhead with master and dependent items.

Data collection efficiency is an important aspect of monitoring. We need to ensure that our monitoring approach has a minimal impact both on the monitoring system and the system that is being monitored.

Improve your metric collection efficiency and reduce the performance overhead with master and dependent items:

  • Dependent items can extract data from a master item by using preprocessing
  • Combine multiple preprocessing steps for best results

  • Up to 3 dependency levels are supported
  • Up to 29999 dependent items for a single master item

Check out the video to learn how to define master and dependent items

How to define master and dependent items:

 

  1. Navigate to Configuration → Hosts and create a new host representing your API endpoint
  2. Input the Host name, Host group, and add an arbitrary interface
  3. Click the Add button
  4. In Configuration → Hosts Click on the Items button next to the host
  5. Click the Create item button
  6. Select the Type – HTTP agent and populate the URL with your API endpoint address
  7. Select the Type of information – Text
  8. Click the Add button
  9. Create another item of type Dependent item
  10. Define item Key and item Name with arbitrary values
  11. Open the Preprocessing tab
  12. Use a preprocessing step (ex. JSONPath) to extract the required value from the master item
  13. Click the Add button
  14. Navigate to Monitoring → Latest data and filter by your host
  15. Observe the collected metrics

Tips and best practices:
  • Dependent items don’t have their own update intervals
  • Dependent item values get updated as soon as the master item receives a new value
  • Deleting a master item will also delete the items that depend on it
  • Item of any type can be used as a master item

Handy Tips #16: Automating Zabbix host deployment with autoregistration

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-16-automating-zabbix-host-deployment-with-autoregistration/18232/

Configure Zabbix agent autoregistration to automatically deploy and start monitoring Zabbix agent hosts.

As your IT infrastructure scales up, there comes a point where manual host creation is simply not feasible. At this point, the preferable approach is to find a way to automate host deployment.

Deploy and manage hosts automatically with Zabbix active agent autoregistration:

  • Automatically deploy and start monitoring hosts
  • Assign different templates depending on hostname and host metadata

  • Receive notifications whenever a new host is deployed
  • Automatically make changes or perform offboarding of hosts

Check out the video to learn how to configure Zabbix agent autoregistration.

How to configure Zabbix agent autoregistration:

 

  1. Navigate to Configuration → Actions → Autoregistration actions
  2. Click the Create action button
  3. Define action conditions
  4. Navigate to the Operations tab and define the action operations
  5. Connect to your host and open the Zabbix agent configuration file
  6. Populate the Hostname, HostMetadata and HostInterface fields
  7. Restart the Zabbix agent
  8. Navigate to Configuration → Hosts and make sure that the host has been created
  9. Navigate to Monitoring → Latest Data and make sure that the host is receiving metrics

Tips and best practices:
  • Host name and host metadata values are case-sensitive
  • Agent restart is required to apply host name and host metadata changes
  • HostnameItem can be used to populate the host name with a Zabbix agent item value
  • HostMetadataItem can be used to populate the host metadata with a Zabbix agent item value

Gaining new insights with Business service monitoring by Aleksandrs Petrovs-Gavrilovs / Zabbix Summit Online 2021

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/gaining-new-insights-with-business-service-monitoring-by-aleksandrs-petrovs-gavrilovs-zabbix-summit-online-2021/17973/

Zabbix 6.0 LTS comes with a complete redesign of the service monitoring. From improved business service scalability to advanced service status calculation logic and alerting. Let’s take a look at the Business Service monitoring feature and how you can use it to ensure full transparency for your business services.

The full recording of the speech is available on the official Zabbix Youtube channel.

Business services can be quite complex. They tend to consist of many different moving parts with redundancy and failover mechanism in place, all of which need to be taken into consideration when we wish to analyze the current status of our services.

BSM Checklist

Let’s take a look at what needs to be done so we can successfully define and monitor our business service:

  • First, we have to define what exactly is our business service and what components does it consist of?
  • We need to understand what are our expectations when it comes to service uptime. When should the service be up and running? What are the acceptable downtimes? Should it run 24/7/365 or maybe it’s a service that is critical only during our working hours?
  • Once we know what needs to be monitored, we need to make sure that we are collecting the data that reflects the status of different service components.
  • Finally – we have to find a suitable tool to track and measure our service.

Define your business

Let’s take a look at how a business may look like. As I mentioned before – business services can consist of many different components. Let’s take a look at an example of how business services may look like:

The tree structure here represents our Business services. We can see that we have classified the services into two branches – Internal services and User services. The User services consist of components such as Websites, Helpdesk services, Phones. These general services are based on lower-level components such as the actual physical phones for the phone service, underlying software for the Website and Helpdesk services, and so on.

This can make things quite complicated since usually, organizations will have many more components to take care of. That’s why, let’s see how we can simplify this tree and define our services in a more simple manner, like the service tree below:

Now we are left with only 3 levels for our services. Let’s take a look at how we can move this to Zabbix:

Here we can see a high-level view of our services. Once again we have our Internal services and User services. These here high-level services consist of child services and define what these components consist of and what their SLAs should be. We can also define tags to provide additional details to our services – which customer uses the service, the type of service, maybe even the location that the service is used in – this part is completely up to your imagination.

Once you have defined the services, their respective components and have linked them to the problems by using tags, you will finally be able to see the full picture. Zabbix will display not only the status of the service but also the root cause of the problem. This way we can provide service status information not only on the service owner level but also provide information that your technical staff can use to fix the issue.

Configuring SLAs

Configuring Business Service monitoring can be done from the Monitoring – Services section. In Zabbix 6.0 LTS you are not required to start defining the service tree from the root service. Now you can define your own root level services. To create a service, all we have to do is switch to the Edit mode by clicking the Edit button in the upper right corner of the services screen and click the Create service button right next to it. We have also made some additional changes to the service section UI/UX. Now you also have multiple fast edit buttons next to each service. You can use them to Add a child service, edit an existing service, or delete an existing service.

Next, let’s take a look at the actual service creation steps.

  • We need to provide a name for our service
  • If the service is not a top-level service you have to select a parent service
  • Define problem tags. Problems tagged with the matching tags will affect the service status
  • Define the status calculation rule

Major improvements have been made to status calculation rules. We still support the old logic of the Use the most critical of child services / Most critical if all children have problems / Set status to ok, but there are also many advanced service status calculation rules.

  • Now we have the ability to select a specific status (Warning, Average, High, and so on) for our service in case of a problem
  • Select the number of children, More than/Less than N children, Percentage of children that should be affected for the parent service status change to take place
  • Define weights for child services and perform status changes based on the weight of the affected child services

Child services can also apply different propagation rules for the parent service

  • Child services can Increase or decrease the parent status service status by N severities, ignore the child service, apply a fixed status or apply the status depending on the problem severity

For our example let’s use an HA cluster use case. HA clusters consist of multiple nodes – for our example, we will use 3 nodes.

  • First, we define that the HA cluster consists of 3 nodes – 3 child services.
  • Each node will have equal weight – 1
  • On the parent service, we will define multiple status rules
    • If the weight of the child services is 1 (1 node is down) – the parent service will change its status to Warning
    • If the weight of the child services is 2 (2 nodes are down) – the parent service will change its status to Average
    • If the weight of the child services is 3 (all nodes are down) – the parent service will change its status to Disaster

In the above image, we can see how the corresponding status change will look like in the Services section. Note that we can also see the root cause of the parent service status change in the Root cause column.

We also have the ability to define the acceptable SLAs as well as SLA calculation uptime and downtime periods for our services. We have the option to define scheduled uptimes and downtimes, during which SLA should or shouldn’t be calculated (Such as weekends, for example), as well as one-time downtimes for one-time maintenance purposes.

Services can utilize tags to provide additional information about your services, such as the service type, service customer, service location, and more. On top of that, tags can also be used in the Service action condition logic, so you can define granular alerting logic for your service status changes.

The Child services tab allows you to quickly look at the related child services, their problem tags, and status calculation rules.

Child services can also be crosslinked between multiple parent services. This means that you don’t have to duplicate and recreate child services if they are used as a component of multiple parent services.

Track, solve and measure

Once we have configured our service, what remains is keeping track of our service statuses, SLAs and staying notified about service status changes and their root cause.

For this purpose, it is vital to secure access to our services. This is especially critical for MSPs, which may have multiple customers and each customer should have access only to the services related to that particular customer. To that end, the Roles section has also received an update related to the Service permissions. We can now define Read-Write and Read access to either specific services or services marked with a particular tag.

The Root cause section displays the root cause problems that affected the service status change. You will be able to click on the root cause problem and open it in the Problems section for further analysis of what caused your services to change their status and which host has been affected by it.

Previously I mentioned alerting on service status change, so let’s dig deeper into that. In Zabbix 6.0 LTS we have added a new type of action – Service actions. Zabbix can now react to service status changes and notify you when a service changes its status. The Service action conditions can analyze if a status has been changed on a particular service, a service that matches or contains a specific string in its name, tag, or tag value. If the conditions are true, Zabbix can send out an email, deliver a phone call or an SMS, create a ticket in your helpdesk system or perform any other alerting and notification workflow.

Many other BSM features are coming as we continue the development of Zabbix 6.0 LTS:

  • SLA graphical visualizations with support for over 100k services
  • Daily, Monthly, Weekly SLA reports
  • New service tree and SLA reporting widgets available from the dashboard
  • Service tree import and export
  • Impact analysis – see which service affects other related services in what way.

Questions

Q: Will the existing services be migrated to Zabbix 6.0 LTS?
A: The existing services will be migrated to Zabbix 6.0 LTS during the upgrade. All of the configuration for the existing services will stay intact after the migration.

Q: Does host maintenance suppress service calculation in Zabbix 6.0 LTS?
A: Host maintenance will not affect the service calculation. If you wish to define maintenance periods for your services –  use scheduled or one-time downtime options when configuring an individual service.

Q: How are the Fixed status and Ignore this service calculation rules going to work?
A: Fixed status services will not change their status no matter what happens to the child services – the service status will remain fixed. As for Ignore this service – the service status change will be ignored and will not affect the parent services.

Zabbix NOT AFFECTED by the Log4j exploit

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/zabbix-not-affected-by-the-log4j-exploit/17873/

A newly revealed vulnerability impacting Apache Log4j 2 versions 2.0 to 2.14.1 was disclosed on GitHub on 9 December 2021 and registered as CVE-2021-44228 with the highest severity rating. Log4j is an open-source, Java-based logging utility widely used by enterprise applications and cloud services. By utilizing this vulnerability, a remote attacker could take control of the affected system.

Zabbix is aware of this vulnerability, has completed verification, and can conclude that the only product where we use Java is Zabbix Java Gateway, which does not utilize the log4j library, thereby is not impacted by this vulnerability.

For customers, who use the log4j library with other Java applications, here are some proactive measures, which they can take to reduce the risk posed by CVE-2021-44228:

  • Upgrade to Apache log4j-2.1.50.rc2, as all prior 2.x versions are vulnerable.
  • For Log4j version 2.10.0 or later, block JNDI from making requests to untrusted servers by setting the configuration value log4j2.formatMsgNoLookups to “TRUE” to prevent LDAP and other queries.
  • Default both com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to “FALSE” to prevent Remote Code Execution attacks in Java 8u121.

What’s new in Zabbix 6.0 LTS by Artūrs Lontons / Zabbix Summit Online 2021

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/whats-new-in-zabbix-6-0-lts-by-arturs-lontons-zabbix-summit-online-2021/17761/

Zabbix 6.0 LTS comes packed with many new enterprise-level features and improvements. Join Artūrs Lontons and take a look at some of the major features that will be available with the release of Zabbix 6.0 LTS.

The full recording of the speech is available on the official Zabbix Youtube channel.

If we look at the Zabbix roadmap and Zabbix 6.0 LTS release in particular, we can see that one of the main focuses of Zabbix development is releasing features that solve many complex enterprise-grade problems and use cases. Zabbix 6.0 LTS aims to:

  • Solve enterprise-level security and redundancy requirements
  • Improve performance for large Zabbix instances
  • Provide additional value to different types of Zabbix users – DevOPS and ITOps teams, Business process owner, Managers
  • Continue to extend Zabbix monitoring and data collection capabilities
  • Provide continued delivery of official integrations with 3rd party systems

Let’s take a look at the specific Zabbix 6.0 LTS features that can guide us towards achieving these goals.

Zabbix server High Availability cluster

With the release of Zabbix 6.0 LTS, Zabbix administrators will now have the ability to deploy Zabbix server HA cluster out-of-the-box. No additional tools are required to achieve this.

Zabbix server HA cluster supports an unlimited number of Zabbix server nodes. All nodes will use the same database backend – this is where the status of all nodes will be stored in the ha_node table. Nodes will report their status every 5 seconds by updating the corresponding record in the ha_node table.

To enable High availability, you will first have to define a new parameter in the Zabbix server configuration file: HANodeName

  • Empty by default
  • This parameter should contain an arbitrary name of the HA node
  • Providing value to this parameter will enable Zabbix server cluster mode

Standby nodes monitor the last access time of the active node from the ha_node table.

  • If the difference between last access time and current time reaches the failover delay, the cluster fails over to the standby node
  • Failover operation is logged in the Zabbix server log

It is possible to define a custom failover delay – a time window after which an unreachable active node is considered lost and failover to one of the standby nodes takes place.

As for the Zabbix proxies, the Server parameter in the Zabbix proxy configuration file now supports multiple addresses separated by a semicolon. The proxy will attempt to connect to each of the nodes until it succeeds.

Other HA cluster related features:

  • New command-line options to check HA cluster status
  • hanode.get API method to obtain the list of HA nodes
  • The new internal check provides LLD information to discover Zabbix server HA nodes
  • HA Failover event logged in the Zabbix Audit log
  • Zabbix Frontend will automatically switch to the active Zabbix server node

You can find a more detailed look at the Zabbix Server HA cluster feature in the Zabbix Summit Online 2021 speech dedicated to the topic.

Business service monitoring

The Services section has received a complete redesign in Zabbix 6.0 LTS. Business Service Monitoring (BSM) enables Zabbix administrators to define services of varying complexity and monitor their status.

BSM provides added value in a multitude of use cases, where we wish to define and monitor services based on:

  • Server clusters
  • Services that utilize load balancing
  • Services that consist of a complex IT stack
  • Systems with redundant components in place
  • And more

Business Service monitoring has been designed with scalability in mind. Zabbix is capable of monitoring over 100k services on a single Zabbix instance.

For our Business Service example, we used a website, which depends on multiple components such as the network connection, DB backend, Application server, and more. We can see that the service status calculation is done by utilizing tags and deciding if the existing problems will affect the service based on the problem tags.

In Zabbix 6.0 LTS there are many ways how service status calculations can be performed. In case of a problem, the service state can be changed to:

  • The most critical problem severity, based on the child service problem severities
  • The most critical problem severity, based on the child service problem severities, only if all child services are in a problem state
  • The service is set to constantly be in an OK state

Changing the service status to a specific problem severity if:

  • At least N or N% of child services have a specific status
  • Define service weights and calculate the service status based on the service weights

There are many other additional features, all of which are covered in our Zabbix Summit Online 2021 speech dedicated to Business Service monitoring:

  • Ability to define permissions on specific services
  • SLA monitoring
  • Business Service root cause analysis
  • Receive alerts and react on Business Service status change
  • Define Business Service permissions for multi-tenant environments

New Audit log schema

The existing audit log has been redesigned from scratch and now supports detailed logging for both Zabbix server and Zabbix frontend operations:

  • Zabbix 6.0 LTS introduces a new database structure for the Audit log
  • Collision resistant IDs (CUID) will be used for ID generation to prevent audit log row locks
  • Audit log records will be added in bulk SQL requests
  • Introducing Recordset ID column. This will help users recognize which changes have been made in a particular operation

The goal of the Zabbix 6.0 LTS audit log redesign is to provide reliable and detailed audit logging while minimizing the potential performance impact on large Zabbix instances:

  • Detailed logging of both Zabbix frontend and Zabbix server records
  • Designed with minimal performance impact in mind
  • Accessible via Zabbix API

Implementing the new audit log schema is an ongoing effort – further improvements will be done throughout the Zabbix update life cycle.

Machine learning

New trend functions have been added which utilize machine learning to perform anomaly detection and baseline monitoring:

  • New trend function – trendstl, allows you to detect anomalous metric behavior
  • New trend function – baselinewma, returns baseline by averaging data periods in seasons
  • New trend function – baselinedev, returns the number of standard deviations

An in-depth look into Machine learning in Zabbix 6.0 LTS is covered in our Zabbix Summit Online 2021 speech dedicated to machine learning, anomaly detection, and baseline monitoring.

New ways to visualize your data

Collecting and processing metrics is just a part of the monitoring equation. Visualization and the ability to display our infrastructure status in a single pane of glass are also vital to large environments. Zabbix 6.0 LTS adds multiple new visualization options while also improving the existing features.

  • The data table widget allows you to create a summary view for the related metric status on your hosts
  • The Top N and Bottom N functions of the data table widget allow you to have an overview of your highest or lowest item values
  • The single item widget allows you to display values for a single metric
  • Improvements to the existing vector graphs such as the ability to reference individual items and more
  • The SLA report widget displays the current SLA for services filtered by service tags

We are proud to announce that Zabbix 6.0 LTS will provide a native Geomap widget. Now you can take a look at the current status of your IT infrastructure on a geographic map:

  • The host coordinates are provided in the host inventory fields
  • Users will be able to filter the map by host groups and tags
  • Depending on the map zoom level – the hosts will be grouped into a single object
  • Support of multiple Geomap providers, such as OpenStreetMap, OpenTopoMap, Stamen Terrain, USGS US Topo, and others

Zabbix agent – improvements and new items

Zabbix agent and Zabbix agent 2 have also received some improvements. From new items to improved usability – both Zabbix agents are now more flexible than ever. The improvements include such features as:

  • New items to obtain additional file information such as file owner and file permissions
  • New item which can collect agent host metadata as a metric
  • New item with which you can count matching TCP/UDP sockets
  • It is now possible to natively monitor your SSL/TLS certificates with a new Zabbix agent2 item. The item can be used to validate a TLS/SSL certificate and provide you additional certificate details
  • User parameters can now be reloaded without having to restart the Zabbix agent

In addition, a major improvement to introducing new Zabbix agent 2 plugins has been made. Zabbix agent 2 now supports loading stand-alone plugins without having to recompile the Zabbix agent 2.

Custom Zabbix password complexity requirements

One of the main improvements to Zabbix security is the ability to define flexible password complexity requirements. Zabbix Super admins can now define the following password complexity requirements:

  • Set the minimum password length
  • Define password character requirements
  • Mitigate the risk of a dictionary attack by prohibiting the usage of the most common password strings

UI/UX improvements

Improving and simplifying the existing workflows is always a priority for every major Zabbix release. In Zabbix 6.0 LTS we’ve added many seemingly simple improvements, that have major impacts related to the “feel” of the product and can make your day-to-day workflows even smoother:

  • It is now possible to create hosts directly from Monitoring – Hosts
  • Removed Monitoring – Overview section. For improved user experience, the trigger and data overview functionality can now be accessed only via dashboard widgets.
  • The default type of information for items will now be selected automatically depending on the item key.
  • The simple macros in map labels and graph names have been replaced with expression macros to ensure consistency with the new trigger expression syntax

New templates and integrations

Adding new official templates and integrations is an ongoing process and Zabbix 6.0 LTS is no exception here’s a preview for some of the new templates and integrations that you can expect in Zabbix 6.0 LTS:

  • f5 BIG-IP
  • Cisco ASAv
  • HPE ProLiant servers
  • Cloudflare
  • InfluxDB
  • Travis CI
  • Dell PowerEdge

Zabbix 6.0 also brings a new GitHub webhook integration which allows you to generate GitHub issues based on Zabbix events!

Other changes and improvements

But that’s not all! There are more features and improvements that await you in Zabbix 6.0 LTS. From overall performance improvements on specific Zabbix components, to brand new history functions and command-line tool parameters:

  • Detect continuous increase or decrease of values with new monotonic history functions
  • Added utf8mb4 as a supported MySQL character set and collation
  • Added the support of additional HTTP methods for webhooks
  • Timeout settings for Zabbix command-line tools
  • Performance improvements for Zabbix Server, Frontend, and Proxy

Questions and answers

Q: How can you configure geographical maps? Are they similar to regular maps?

A: Geomaps can be used as a Dashboard widget. First, you have to select a Geomap provider in the Administration – General – Geographical maps section. You can either use the pre-defined Geomap providers or define a custom one. Then, you need to make sure that the Location latitude and Location longitude fields are configured in the Inventory section of the hosts which you wish to display on your map. Once that is done, simply deploy a new Geomap widget, filter the required hosts and you’re all set. Geomaps are currently available in the latest alpha release, so you can get some hands-on experience right now.

Q: Any specific performance improvements that we can discuss at this point for Zabbix 6.0 LTS?

A: There have been quite a few. From the frontend side – we have improved the underlying queries that are related to linking new templates, therefore the template linkage performance has increased. This will be very noticeable in large instances, especially when linking or unlinking many templates in a single go.
There have also been improvements to Server – Proxy communication. Specifically – the logic of how proxy frees up uncompressed data. We’ve also introduced improvements on the DB backend side of things – from general improvements to existing queries/logic, to the introduction of primary keys for history tables, which we are still extensively testing at this point.

Q: Will you still be able to change the type of information manually, in case you have some advanced preprocessing rules?

A: In Zabbix 6.0 LTS Zabbix will try and automatically pick the corresponding type of information for your item. This is a great UX improvement since you don’t have to refer to the documentation every time you are defining a new item. And, yes, you will still be able to change the type of information manually – either because of preprocessing rules or if you’re simply doing some troubleshooting.

Handy Tips #15: Deploying Zabbix passive and active agents

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-15-deploying-zabbix-passive-and-active-agents/17696/

Deploy Zabbix Agent to collect OS-level metrics.

There are multiple approaches to collecting OS-level metrics – from collecting only simple ping statistics to deploying an SNMP agent or using custom scripts. In many cases, this is either not sufficient or too time-consuming and not flexible enough. By deploying the Zabbix Agent you can enable a quick and easy way to collect OS-level metrics.

Deploy Zabbix Agent and collect metrics by polling the agent or autonomously sending data to your Zabbix Server:

  • Zabbix Agent supports polling (passive) and trapping (active)
  • Negligible performance overhead
  • Can be installed from packages on Linux or the MSI installer on Windows

  • Supports the most popular Unix-like operating systems
  • Zabbix Agent can be extended with custom User Parameters

Check out the video to learn how to deploy the Zabbix Agent in passive and active modes

How to configure and deploy Zabbix passive and active agents:

  1. Install the Zabbix repository and the Zabbix Agent on your host
  2. Open the zabbix_agentd.conf configuration file
  3. Specify your Zabbix Server address in the Server and ServerActive parameters
  4. Define the name of your host in the Hostname parameter
  5. Restart the Zabbix Agent
  6. Navigate to Configuration →  Hosts
  7. Create two hosts in Zabbix frontend – one for passive and one for active checks
  8. For passive Agent host – define an Agent interface containing the address of your Zabbix Server
  9. The active agent Host name should match the Hostname parameter value in the Agent configuration file
  10. Apply the corresponding Linux by Zabbix Agent/Linux by Zabbix Agent active template
  11. Navigate to Monitoring →  Latest data and check if you have received metrics from the hosts

Tips and best practices:
  • A single Zabbix Agent can collect metrics in both passive and active modes
  • Zabbix Agent is backward compatible
  • The frontend ZBX interface icon is related only to passive checks 
  • Active Zabbix Agent doesn’t require an interface configuration in Zabbix frontend
  • For active checks, the Zabbix Agent Hostname in the configuration file must match the Host name in the frontend

Handy Tips #14: Gain new insights into your metrics with the Graph widget

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/handy-tips-13-gain-new-insights-into-your-metrics-with-the-graph-widget/17416/

Group, aggregate, and visualize your collected metrics with the Graph widget to obtain additional insights.

Sometimes simple graphs may not be sufficient – we may need to visualize data trends, display all metrics matching a pattern, or define custom draw styles for specific metrics.

The Graph widget allows you to visualize your metrics in an advanced fashion:

  • Customize your graph draw styles
  • Select between displaying History or Trend values
  • Calculate and display aggregated metric values on the fly

  • Define custom aggregation intervals
  • Define flexible problem display logic
  • Visually group metrics by defining item and host data sets

Check out the video to learn how to visualize your metrics by using the Graph widget.

How to visualize data with the Graph widget:

  1. Navigate to Monitoring → Dashboards – All Dashboards
  2. Click Create Dashboard to create a new Dashboard
  3. Left-click on an empty space and select Add Widget
  4. Select Widget type – Graph
  5. Type in the data set host and item patterns
  6. Use wildcard symbol ‘*‘ to match multiple hosts/items
  7. Click Add new data set to add a second data set
  8. Fill in the host pattern and item pattern to match a different set of metrics
  9. For both data sets, select an Aggregation function, Aggregation interval, and Aggregate – Data set
  10. Observe how metrics get aggregated in the graph on the fly

Tips and best practices:
  • Wildcards can be used in host and item pattern matching
  • The Overrides section can be used to further customize a particular set of items
  • Items within a single data set will use the same base color
  • Up to 50 items may be displayed in the graph

Deploying Zabbix in Amazon Web Services cloud platform

Post Syndicated from Arturs Lontons original https://blog.zabbix.com/deploying-zabbix-in-amazon-web-services-cloud-platform/17283/

With the rapid evolution and proliferation of different cloud services, many organizations have decided to move parts of their infrastructures from on-prem to cloud. As an essential part of your infrastructure, Zabbix is no exception – you always have the option to either deploy Zabbix on-prem or select from one of the many supported cloud service providers to deploy your Zabbix Server or Zabbix Proxy on.

In this blog post, let’s look at how we can quickly deploy Zabbix Server and Zabbix Proxy nodes in Amazon Web Services cloud platform.

Deploying the Zabbix Server in AWS

Let’s begin with the Zabbix download page. Under the Zabbix Cloud Images section, select the AWS cloud vendor and then the Cloud Image you wish to deploy. Let’s start with Zabbix Server 5.0 with MySQL DB backend and Nginx Web server backend for our frontend.

Next, we will be redirected to the AWS marketplace, where we will have to subscribe to the Zabbix Server 5.0 image.

Once we have subscribed to the Zabbix Server image, we can continue with the deployment configuration.

Next, we must select our Region, Zabbix minor version (usually the latest available), and the Fulfillment option. Once that is done, we can finalize the launch configuration.

Select the preferred Launch option, EC2 Instance Type, VPC, and Subent settings on the Launch page.

Next – We have to select or create a security group.

We also have to select or generate EC 2 Key pair – make sure to save your private key in a safe location!

Note that creating a security group based on seller settings does not guarantee that the group will have an inbound SSH access rule! Make sure to double-check the security group and manually add the SSH inbound rule if it hasn’t yet been added. We will need to access this instance via SSH to obtain the initial frontend login credentials!

Once you click on the Launch button, the deployment process for your Zabbix application will be initiated.

Accessing the application

Let’s open up the Instances section and open our newly deployed Zabbix instance

We can access the Zabbix Frontend by opening the Public IPv4 address or Public IPv4 DNS of the Zabbix instance

Note that the Zabbix frontend password is still unknown to us. Recall how I mention that we will need to access the instance via SSH to obtain the frontend password. Let’s do so now.

Write down the login credentials and use them to log in to the Zabbix instance.

Accessing the database

In case we wish to access the Zabbix database backend, we can do so from the command line. Zabbix database can be accessed by using the root user. By default, it can be used without a password.

The MySQL root password is stored in /root/.my.cnf configuration file.

Modifying the Zabbix Frontend timezone

By default, the Zabbix frontend uses the “UTC” timezone. If you need to change it, edit php_value[date.timezone] PHP variable in /etc/php-fpm.d/zabbix.conf and restart php-fpm process:

systemctl restart php-fpm

Zabbix proxy

If you wish to deploy a Zabbix proxy instance in your AWS cloud, the deployment steps are very much the same. Most likely, you will still require SSH access if you wish to perform some configuration changes in the Zabbix proxy configuration file.

Note, that by default, the SQLite proxy database is stored in /tmp/zabbix_proxy.sqlite3

As always, don’t forget the point the proxy at your Zabbix server instance by modifying the Server parameter in the Zabbix proxy configuration file, located in /etc/zabbix/zabbix_proxy.conf

And that’s all! With just a few clicks, we are able to deploy a fully functional Zabbix instance or a small Zabbix proxy to distribute or scale our monitoring. Don’t forget that AWS is just one of the many cloud service providers you can use with Official Zabbix images. If you have any questions about the AWS deployment – you are very much encouraged to leave a comment under this blog post.

If you wish to learn more about the Zabbix Monitoring solution, check out the official documentation https://www.zabbix.com/documentation/current/manual/quickstart.