Uncategorized

Prometheus vs. Zabbix

by

Introduction

Free open-source software makes an excellent answer when the budget is limited or if you simply don’t want to spend money unnecessarily. Thus, Zabbix and Prometheus can be very attractive choices if you are currently looking for the best open-source network monitoring software on the market. However, even though both Zabbix and Prometheus are free and open-source, these two products have very, very different characteristics. So, before you make your choice, make sure that you understand the differences of Zabbix vs Prometheus by continue reading below!

Installation and Setting Up

First of all, let us see the comparisons between Zabbix vs Prometheus in terms of installation requirements. Generally speaking, you can say that Zabbix is a ‘basic’ monitoring solution for people who need a full-fledged monitoring application that covers a lot of features right out of the box. It is easy, simple, and quick to set up. However, an application that is ready out of the box like Zabbix typically lacks customizability. Hence, it may not cover everything if you have some custom or special requirements.

Unlike SolarWinds that we discussed in Zabbix vs SolarWinds, Prometheus is a free, open-source option. Prometheus is a very flexible platform that collects metrics for custom-built monitoring. It is not exactly ready out of the box because it will require you to install some other tools such as the separate Alert Manager. The configuration requires manual editing of files. However, such design enables more extensive and comprehensive customization that can cover custom/special requirements.

By the way, Zabbix’s core is written in C, whereas the web GUI is written in PHP. Hence, Zabbix often has a smaller footprint. It stores data in a relational database.

Prometheus is written in the Go language. It has its own non-relational database which is embedded into the back-end. Since the database is specially designed for storing monitoring data, its performance is often faster.

Features and Performance

One of the best features of Zabbix is the powerful web GUI. It provides nice visualization, and it is quite powerful. You can use Zabbix to monitor web-based services as well as servers and other types of hardware. In addition, Zabbix also provides several monitoring options. SNMP is optional. You can use dedicated agents instead to collect data from the hosts.

However, Zabbix lacks real-time reporting as well as advanced report templates. Regarding the performance, it is strong and efficient on small and medium-sized networks. It is suitable for up to 10,000 nodes, but you may start to notice little performance degradation at 1,000 nodes.

Prometheus has a basic tool for exploring and visualizing data in simple graphs, and it has a minimal dashboard builder. However, you can pair it with a modern visualization tool like Grafana to enhance the power. As explained above, Prometheus excels in customization. For example, it supports both “pull” and “push” models for checking.

Prometheus’s performance is generally faster and more stable, even when handling a large network. It is often recommended for cloud, SaaS, and OpenStack monitoring.

Conclusion
If you need a simple ‘traditional’ monitoring solution for monitoring hardware and services, Zabbix is the way to go. It is ready out of the box, and the performance is reliable for up to 10,000 nodes. However, if you have some custom/special requirements and you need a lot of customization, Prometheus is the way to go. Prometheus is more recommended for monitoring a very large network, cloud, SaaS, and OpenStack

Ansible vs Chef

by

Introduction

Configuration management is the process of keeping computers, servers, and software in order and a consistent state. The process is used for ensuring that all systems are working as they are supposed to. Sometimes, if they are not doing so, then you have to make small modifications to the systems.

If modifications are performed on many systems and servers, without being documented, then the whole infrastructure can become unstable and inconsistent. Configuration management makes sure that none of these modifications go undetected. Tools, such as Ansible, Chef, and Puppet are used for configuration management.

What is Ansible?

Ansible is a simple open-source IT automation engine that has many modules for interacting with applications and services that a DevOps engineer needs. It can automate application deployment, intra-service orchestration, and the complete application lifecycle

It is easy to deploy Ansible as it does not use custom security infrastructure on the client-side. The modules are pushed to clients. After executing these modules locally on the client-side, the execution result is pushed back to the servers of Ansible. Connecting with clients with Ansible is simple as SSH keys are used. Client details, such as IP address and hostname are stored in inventory files that Ansible can use.

Playbooks are an important part of Ansible that is coded using a simple language called YAML. Tricky tasks are converted into repeatable playbooks to simplify the configuration. These playbooks can be easily understood and debugged if necessary

What is Chef?

Chef is another powerful configuration management tool that is used for infrastructure automation. It was developed by Adam Jacobs, founder of the software firm OpsCode. Whether you are working in a hybrid environment or the cloud, Chef will automate the infrastructure configuration, management, and deployment.

Chef helps companies become more efficient and faster by automating their application lifecycle. Repetitive configuration tasks can be automated using this software.

Chef is written using the Ruby programming language. And, it has a command-line interface that has a DSL-based on Ruby. It can be run on a client-server or as a standalone tool. Chef is open-source and can be used for cloud configuration. This tool can translate system administration tasks into definitions called recipes and cookbooks.

You can run Chef on a variety of platforms, such as Windows, Linux, FreeBSD, Solaris, Cisco IO, AIX, and Nexus. It is also compatible with a large number of cloud platforms like Google Cloud Platform, Amazon Web Services (AWS), OpenStack, Microsoft Azure, and IBM Bluemix. Using the knife utility, Chef can be integrated with several cloud platforms easily

Ansible vs Chef: (comparison)

he Ansible vs Chef comparison will be conducted based on the following parameters:

Installation and set up

For Ansible, no agents are executed on client machines. So, no client-server installation is needed. SSH connections are used for logging in a client’s computer and configuring the nodes. No special setup is required for the client’s virtual machine. Therefore, the installation is easy.

In Chef, the server will run on the master machine. And, the Chef client agent will run on every client machine. All tested configurations are stored in workstations that are pushed to the central server of Chef. So, setting all this up is a bit tricky.

Configuration management

Ansible uses YAML (Yet Another Markup Language) for managing its configurations. This language resembles the English language and is simple to understand. Using YAML, the configurations are pushed to the individual nodes.

In Chef, Ruby Domain Specific Language is used. This language pulls configurations from the server. So, you need to know Ruby well enough. This has a steeper learning curve than YAML.

Static/dynamic inventories

Ansible can use static and dynamic inventories, such as a flat INI file containing hosts divided into sections. This flexibility is not offered by Chef as you have to individually register hosts on the Chef server.

Source of truth

The source of truth is the authoritative configuration for a system. In Ansible, this can be the playbook being deployed. Source control systems, such as Git can be used as a source of truth.

In Chef, the Chef server acts as the source of truth. Here, you have to upload updated cookbooks, sometimes to multiple servers. It is difficult to maintain the consistency of cookbooks this way.

Conclusion

The chef is older, has better documentation, and can handle difficult tasks. But, it is trickier to install as compared to Ansible. Chef’s Ruby DSL is preferred by developers and DevOps engineers. But, it has a steep learning curve as compared to Ansible, which uses simple YAML.  In the Ansible vs Chef battle, the choice depends upon the requirements of the company

What is ansible and How to Install and Configure Ansible

by

Introduction

Ansible is an IT automation tool intended to facilitate the management of remote servers. Ansible requires Python (version 2.7 or 3.5 and higher) to run. Ansible is run from a centralized control node and can manage any server accessible over SSH. Remote servers that are managed by Ansible are called managed nodes.

By default, Ansible communicates with managed nodes using OpenSSH. SSH is not the only communication mechanism Ansible supports. You can run tasks on the control server locally, in a docker container or even a Windows server. The control node will require Linux to run.

What is IT Automation?

Today, System Administrators and DevOps Engineers must manage complex IT infrastructure in the cloud and across multiple sites. Modern web applications typically consist of an API service, a front-end service, and a database service. Manually managing such complex systems would require a lot of time and would be prone to mistakes.

IT automation uses software to provision IT infrastructure, deploy applications and, to manage services configuration changes. The software you use to fill this role needs to provide a reliable and repeatable way to manage your IT tasks. Ansible’s approach to IT automation centers around the ‘playbook’. You can think of an Ansible playbook as a recipe that describes the steps needed to set up your IT infrastructure, deploy your applications and then configure those services.

Advantages of Ansible

Ansible is very easy to learn and allows you to get up and running with automation more quickly than other tools. Ansible is agentless, so you don’t have to install and maintain an Ansible client on your managed nodes. This dramatically simplifies the management of Ansible updates.

Drawbacks of Ansible

Ansible, of course, is not a perfect tool. If an SSH connection is interrupted partway through a playbook run, that node could end up in a partially configured state. Ansible also has a reputation for being slow and may require additional performance tuning to meet your requirements

Install Ansible

L

Step 1: Install the EPEL Repository
Installing Ansible is pretty straightforward. First, we’ll need to install the CentOS 7 EPEL repository
				
					yum install epel-release
Step 2: Install Ansible

Next, we install the Ansible package from the EPEL repository

				
					yum install ansible

Step 3: Create a User for Ansible

As security best practice denotes, it is a good idea to avoid logging into your Linux servers as root. We will create a non-root user on our control node and our managed nodes that will run our Ansible playbooks. This user defines the admin Ansible will utilize to log into our managed nodes. Here we have used “admin”’ for the user, but any username can be substituted. To follow along with our examples, you will want to use the same username on both the Control node and our managed Nodes. Log onto the control node to add a user and set a password

				
					useradd admin
passwd admin
Step 3b: Configure the Control Node User for Passwordless Super User Access

On the managed node, we need to ensure our Ansible user can utilize the sudo command without a password. Run the following command to open the sudoers file for editing

				
					visudo

Step 5: Configure our Admin User for SSH Access

We need to ensure our admin user can access the managed node over SSH without a password. We will set up an SSH key pair to allow this. Log onto the control node as the admin user and run the following command to generate an SSH key pair. Note: Just hit enter at the prompts to accept the defaults.
				
					ssh-keygen

Now we can copy the public key to our managed node with the following command.

				
					ssh-copy-id node.kb.liquidweb.com

Step 6: Create an Ansible Inventory

Ansible requires an inventory list so it can identify your managed nodes. To add our managed node to the inventory, we need to login to our Control node as the admin user. Next, we will add a new inventory file. Make sure you are logged onto the Control node as the admin user.

				
					vim /home/admin/inventory

Type ‘i’ to enter insert mode and add the managed node hostname to the inventory file.

				
					node.kb.liquidweb.com

Next, type ‘[ESC]+:wq’ to save the file.

Step 7: Create an Ansible Playbook

To test our configuration, we will create a simple playbook to install Nginx on our managed node. First, we will create and open a new file. File names are not particularly important as far as Ansible is concerned. You should, of course, use descriptive file names. Make sure you are logged onto the control node as the admin user.

				
					vim /home/admin/install-nginx.yml

Ansible’s playbooks are written in a language called YAML. YAML is intended to be human-readable. Looking at the text below, you should be able to tell what the expected results are. I’ll break the syntax down in just a moment, but for the time being, type ‘i’ to enter insert mode and add the following text to your playbook. Then type ‘[ESC]+:wq’ to save and exit.

Ansible’s playbooks execute ‘plays’. A play is a list of tasks that will be performed on the nodes. In the example above, we used the ‘hosts’ keyword to specify a list of just a single node. You can, however, specify a list of hosts, using comma-separated values. To install software with Ansible, we require root access to utilize yum. We use the keyword “become” in the play to instruct Ansible that the root user is required to execute the task.

The ‘tasks’ keyword initiates the list of tasks to be completed. Each task is given a unique name using the ‘name’ keyword. We then use the yum module provided by Ansible to install the first epel repository, and then we use the second entry to install nginx.

Step 8: Run the Playbook

Running a playbook is rather easy. We use the “ansible-playbook” command and then specify the inventory file with the “-i” option followed by the path to the playbook. Make sure you are logged onto the control node as the admin user.

				
					ansible-playbook -i /home/admin/inventory /home/admin/install-nginx.yml

Conclusion

We’ve only scratched the surface with Ansible so far. You can group the servers in your inventory together by using group names. This grouping allows you to execute playbooks on only your webservers or, only on your database servers. You can also run ad-hoc commands. Ad-hoc commands are tasks that you need to run only once. For instance, if you needed to reboot all of your web servers. All in all, Ansible is an excellent tool you can use to save time, money and effort to automate tasks across a single or multiple remote servers.