All posts by Nathan Liefting

Monitoring your cat’s health with Zabbix and the Litter Robot 3

Post Syndicated from Nathan Liefting original https://blog.zabbix.com/monitoring-your-cats-health-with-zabbix-and-the-litter-robot-3/22413/

In this blog post, you will learn how to set up monitoring for your Litter Robot 3. There’s some amazing community scripts already available to connect to the Litter Robot through a selfmade API, which we’ll be using in combination with some Python scripts and Zabbix.

 

Introduction

Technology is everywhere. On the streets, in our offices and even in our houses. This also means that many people have ‘smart’ lighting, fridges, cameras and a lot more. Personally, I have avoided these home automations for a long time, deeming them time-consuming. But, I think any IT Engineer sometimes feels there is a need to build and automate more and more. Thus, my house has also had a bit of smart home make-over and I’ve started setting up Zabbix at home to monitor everything ‘smart’.

One of the things I cannot live without in our house is our smart litterbox. It keeps the litterbox clean and the smell in the house nice, as well as it provides some very useful insights into my cats ‘potty’ behaviour. One of my cats “Jerry” has some issues with Feline Urinary Tract Disease (FLUTD). This has led Jerry to have some odd litterbox usage, which in his case can be fatal if not treated early on.

So, let’s bring Zabbix into the mix! Even though the Litter Robot has an app where I can see the usage, I want to be able to receive alerts from Zabbix if the Litter Robot usage goes over a certain threshold. Alerting me early on if issues might be arising again. Let’s set things up.

How to

Setting up the script

To make this all possible, we will need to get some information from our Litter Robot or Litter Robots if we have more than one in our account. There’s no official documented API available for the Litter Robot, but there is a way to get information from the device by connecting to the Whisker services. To make things easy for us, we’ll be using a community-made Python library to set up the connection and execute some functions:

https://github.com/natekspencer/pylitterbot

This library contains a number of functions that we can utilize to get information from the Litterbox, but also to make changes to it:

  • refresh()
  • start_cleaning()
  • reset_settings()
  • set_panel_lockout()
  • set_night_light()
  • set_power_status()
  • set_sleep_mode()
  • set_wait_time()
  • set_name()
  • reset_waste_drawer()
  • get_activity_history()
  • get_insight()

Utilizing this library we’ve made some scripts available at the Github page below.

https://github.com/OpensourceICTSolutions/zabbix-litterrobot

Login to your Zabbix environment and install the Python library to your Zabbix server or proxy first with:

pip install pylitterbot

Next, execute the following command to download the scripts and put them in the right location.

mkdir /usr/lib/zabbix/
mkdir /usr/lib/zabbix/litterrobot/
cd /usr/lib/zabbix/litterrobot/

wget https://raw.githubusercontent.com/OpensourceICTSolutions/zabbix-litterrobot/main/litterrobot_get_robots.py
wget https://raw.githubusercontent.com/OpensourceICTSolutions/zabbix-litterrobot/main/litterrobot_get_insights.py
wget https://raw.githubusercontent.com/OpensourceICTSolutions/zabbix-litterrobot/main/litterrobot_get_activity.py

These scripts will have to be executed by Zabbix server’s (or proxy’s) local Zabbix agent, and thus we’ll also have to download the correct UserParameter files.

cd /etc/zabbix/zabbix_agent2.d/
or
cd /etc/zabbix/zabbix_agentd.d/

wget https://raw.githubusercontent.com/OpensourceICTSolutions/zabbix-litterrobot/main/litterrobot_userparams.conf

Then, we have to make sure that the Zabbix agent will be able to use these new parameters by enabling unsafe user parameter option (since there is an @ in the username). Edit /etc/zabbix/zabbix_agent2.conf or /etc/zabbix/zabbix_agentd.conf and add the following:

UnsafeUserParameters=1

Then we restart the agent with the following command:

systemctl restart zabbix-agent
or
systemctl restart zabbix-agent2

Setting up Zabbix

With the scripts in place and the Zabbix agent ready to execute them, we can set up our monitoring in the Zabbix frontend. To do this, we will have to download and import the template. You can find the 6.2 version template here: https://github.com/OpensourceICTSolutions/zabbix-litterrobot/blob/main/zabbix_litterrobot_python_template.yaml

After downloading the template, import it into Zabbix.

Create a new host for your Litter Robot:

Then make sure to add your username and password as macros:

The result

The result is that we can now find all of our important information about the Litter Robot 3 in Zabbix:

Not only that, after we have an idea of how many times per day our cat(s) usually go to the toilet we can start to use the triggers:

There’s a message for when the drawer is full, but also a Warning and High trigger for when there are more than 12 or 15 cycles respectively. This is a default set for my two cats, your cats might have different potty behavior – update your macros accordingly.

As well as create some useful graphs:

Conclusion

Our pets are a big part of our life and sometimes it can be hard to communicate with them. Cats are very likely to hide their feelings, but one of the telling signs something is wrong with them is the number of times they visit the litterbox. Jerry has had a hard time, but our Litter Robot has helped us and our veterinary keep an eye on him to get ahead of his FLUTD. Using Zabbix we can keep Jerry out of surgery as much as possible.

And keep both (Midna on the left, Jerry on the right) of them racing through the house and enjoying all of their 9 lives.

I hope you enjoyed reading this blog post and if you have any questions or need help configuring anything in your Zabbix setup feel free to contact me and the team at Opensource ICT Solutions. We build a ton of cool integrations like this and much more!

Nathan Liefting

https://oicts.com

A close up of a logo Description automatically generated

Backups to the rescue!

Post Syndicated from Nathan Liefting original https://blog.zabbix.com/backups-to-the-rescue/23442/

In this blog post, you will learn how to set up backups for your Zabbix environment. There’s a wide variety of different options when it comes to taking backups of our Zabbix environment, for us, it will just be a matter of choosing the right fit.

 

Introduction

Monitoring is an important part of our IT infrastructure and often times when our monitoring isn’t working for a certain period, we feel like we are blind as to what is going on with our different IT components. As such, taking backups of our Zabbix environment is an important part of running a production Zabbix environment, as we do want to be prepared for a possible issue that might corrupt or even lose our data. It’s always a possibility and as such we should be prepared.

For Zabbix, there are a few different methods on how to take backups and it all starts at the database level. Both the Zabbix frontend as well as the Zabbix server write their data into the Zabbix database as we can see in the illustration below:

This means that both our configuration as well as all of our collected values are present in the same Zabbix database and if we take a database backup, we back up (almost) everything we need. So, let’s start there and have a look at how we can make a database backup.

How to

MySQL backups

Let’s start with the most used variant of Zabbix databases: MySQL and it’s forks like MariaDB and Percona. All of them can easily be backed up using built-in functionality like the MySQL Dump command and we can then use other industry standards to get things going. First, we have to understand the tables in our database though. Most of the tables in your Zabbix environment contain configuration data and as such, they are all important to backup. There are a few tables that we need to consider, however, as they can contain Giga or even Terabytes of data. These are the History, Trends and Events tables:

It is possible to omit these tables from your backup and make smaller, more manageable backups. To make the backup we can then start using tools like MySQL Dump:

Once we have taken a backup, we can easily import that back into our environment using the MySQL Import command or simply using the cat command:

Do not forget, taking and importing large backups can take a long time. This completely depends on your MySQL database performance tuning settings as well as the underlying resources like CPU, Memory and Disk I/O. Also, make sure to check out the MySQL documentation:

MySQL Dump:  https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html / https://mariadb.com/kb/en/making-backups-with-mysqldump/

MySQL Import: https://dev.mysql.com/doc/refman/8.0/en/mysqlimport.html / https://mariadb.com/kb/en/mysqlimport/

 

Alternatively, it’s also possible to create backups using tools like xtrabackup and mariadbbackup.

PostgreSQL backups

We can actually use the same kinds of methods for the PostgreSQL backups. Keep the required tables in mind and fire away with the built-in tools:

 

Then we can restore it by loading the file into postgres:

What about the configuration files?

Once we have a database backup, everything is backed up, right? Well, almost everything. With just a database backup we are quite safe, but (and this is oftentimes overlooked) there are a lot of configuration files and perhaps even custom scripts we need to take into account! There are three parts to this story – the Zabbix server, the Zabbix frontend, and also the Zabbix additional components. All of them have their own set of configuration files and locations that are used for storing custom scripts.

The Zabbix frontend location and configuration files can be different, depending on the environment, as we have a few choices to make. Are we running Apache or Nginx? On what Linux distribution? All of these have to be considered when making configuration backups. In general, the locations for the configuration would be:

/etc/nginx/
/etc/httpd/
/etc/apache2

There’s also a symlink to the Zabbix frontend configuration file located in /etc/zabbix/ but we will get to that one in a bit.

Then we have the Zabbix server itself, which keeps its configuration in /etc/zabbix/ and if we’re following best practices any script should be placed in /usr/lib/zabbix. So we need:

/etc/zabbix/
/usr/lib/zabbix

Let’s add them to the list and find a method to back up these files. Crontab is a built-in tool that we can use, but there are definitely other (perhaps better) solutions out there. Let’s add the following to cron:

I also added a find command here, which will serve as our roll-over or rotation toll. It will find files older than 180 days and delete them from /mnt/backup/config_files/. Make sure to pick a good (network) folder to store these files as it’s important to keep these safe. Feel free to change the number of days you’d like to store the files for.

What about the additional components like Zabbix proxy, Zabbix Java gateway and Zabbix web service (used for PDF reporting)?. Well, these have configuration files as well. Make sure to run a backup on the devices running these additional components. As for Zabbix proxies – they have the same file locations as Zabbix server:

For Zabbix Java gateway and Zabbix web service, we can omit the /usr/lib/zabbix/ folder.

Don’t forget the import/export files!

In general, database backups are slow to make, but also slow to import back unless we do not include the history/trends in the backup. But even then, restoring an entire database simply because someone made an error on a single template is a hassle. Zabbix ships with the built-in frontend export functionality, allowing us to export (and then import) entire parts of the configuration instantly! We can use these for a number of different parts of the configuration:

  • Hosts
  • Templates
  • Media types
  • Maps
  • images
  • Host groups (API ONLY)
  • Template groups (API ONLY)

All of these are available through the Zabbix API allowing us to choose whether we do a manual configuration backup from the frontend, as well as providing us with automation options using that API. You could even manage and update your Zabbix configuration from GIT entirely if you write the right scripts for this.

Frontend backups

To run an export from the frontend simply go to one of the supported sections like Configuration | Templates and select the export data format. When selecting multiple entities, keep in mind that they will all be exported to a single file.

We can then make our edits and import files from the frontend as well:

For Templates this will even result in a nice diff pop-up window, detailing all the changes, deletes and additions to the templates:

 

API backups

For the API things get a little more complicated as we need to select a mode of execution. Of course, it’s possible to do a curl command from the CLI or even use something like Postman:

Request body

The response will then look something like this:

But this feature really starts to shine once we combine it with our own automation scripts. Use it wisely!

High availability

So, what about high availability? Isn’t that some form of a backup?

Well yes and no. High availability is not an “IT backup” in the form of making sure we can recover something that is broken. But it is a backup in the way that if a Zabbix server instance fails, another one takes over for it. HA is somewhat out of scope for this blog post, but it’s still worth mentioning. There are several solutions to set up Zabbix as a full high availability cluster. For MySQL we can use a Primary/Primary setup, for the frontend we can use load balancing techniques like HAProxy and for the Zabbix server, we can use the built-in high availability method. Combine all of these together and you’ll definitely be able to serve your every (production ready!) need.

Conclusion

To conclude, there are many options to start taking backups of our Zabbix environment. It all starts at the database and these backups are definitely vital to keep things safe in case of disaster. When making the backups, do not forget about the configuration files and custom scripts as well as the frontend backup option. Combining all of these solutions will safeguard our environment, but if that isn’t enough – do not forget about industry standards like snapshots. Even further safeguarding our environment on multiple levels.

I hope you enjoyed reading this blog post. If you have any questions or need help configuring anything on your Zabbix setup feel free to contact me and the team at Opensource ICT Solutions. We build a ton of cool integrations like this and much more!

Nathan Liefting

https://oicts.com

A close up of a logo Description automatically generated

The post Backups to the rescue! appeared first on Zabbix Blog.

Setting up manual ticket creation using Zabbix frontend scripts

Post Syndicated from Nathan Liefting original https://blog.zabbix.com/setting-up-manual-ticket-creation-using-zabbix-frontend-scripts/15550/

In this blog post, you will learn how to set up manual ticket creation through the use of Zabbix frontend scripts. We will use Jira Service Desk as an example, but this guide should work for any type of service desk or help desk system, as we can apply this technique for other systems in a similar fashion.

 

Introduction

Zabbix already has the ability to automatically create tickets through the use of Media Types and Actions. This way we can filter out certain issues based on host groups, severity, tags and a lot more. But what if your action misses a problem because of your filters? Or what if you simply want to limit the number of tickets that are created by actions? That’s when we can use Zabbix Frontend Scripts to manually create a ticket from the Zabbix Frontend, while automatically filling in the ticket info with a click of a button.

Let’s check take a look at how we can achieve this.

How to

Setting up Jira

As mentioned, in this example we’ll use Jira. Why? Simply because personally I am a big fan of the Atlassian product suite and it’s what I had available on hand. Feel free to apply this technique to any service desk system out there though, as we are definitely not limited to Jira Service Desk.

To make the frontend script work we are going to need a working integration (Media Type in Zabbix terminology). You can check out https://zabbix.com/integrations to see if the service desk system of your choosing is already available out of the box. If not, you can always use a community solution or build your own integration. Jira Service Desk is already available though, meaning we can use the settings pre-defined in Zabbix. For Jira Service Desk we’ll need:

  • jira_url – The actual URL of your Jira instance. For example: https://company.atlassian.net/
  • jira_user– Jira user login, in our instance this is my email.
  • jira_project_key– Numeric key of the Jira project. We can find this in the URL once we go to our Jira Service Desk project settings. For example: pid=10054
  • jira_issue_type– Number of the issue type to be used when creating new issues from Zabbix. Check out the Project Settings -> Request types and use the number in the URL for the request type you’d like to use.
  • jira_password– Password or API token. We can create this at: https://id.atlassian.com/manage/api-tokens

Make sure to save the API token somewhere, as you can only copy it over once.

Setting up the frontend script

Now once you have set up everything on the Jira (or which ever other service desk you use) side, we can continue with the next step which is setting up the Frontend script. If we look at the particular Zabbix Media Type, we can see something interesting.

The Jira ServiceDesk default Media Type is of course already set up, but that’s not the most interesting part – although super useful nevertheless. Looking at the Media Type we have our Parameters and the Javascript script. If we take a look at the Frontend Script configuration and compare it with our Media Type, that’s when it gets interesting:

With release of Zabbix 5.4 it is now possible possible for us to execute webhooks directly with a Frontend script, as we can see we have the same Parameter and Script options available in this section. Meaning that most of what we have to do is navigate to Administration -> Scripts and copy over the Media Type Parameters and script. So, let’s do that and fill in the parameters with default values:

Do not forget to do the same thing for the script part:

Once you’ve set this up, we aren’t completely done yet. We have copied the default parameter values as defined by Zabbix in the default Jira ServiceDesk Media Type. Now that we’ve copied those from the Media Type to the Frontend script, we still need to edit them to reflect our Jira ServiceDesk parameters. We need to edit the following fields:

alert_message: We can add our own alert message here, which will be filling out the body of our Jira Service Desk ticket. Use the Zabbix built-in macro’s wisely here. Something like:

There is a problem on {HOST.HOST} - {EVENT.NAME} with severity: {EVENT.SEVERITY} since {EVENT.DATE}

alert_subject: This will be the subject of our Jira ticket, again heavily reliant on Built-in Macro’s. It can be something like:

Severity:{EVENT.SEVERITY} Problem on:{HOST.HOST} - {EVENT.NAME}

event_source: We set this to 0, meaning it is a problem. Normally this is dynamic, but we can make it static for the script.

0

 

Then, as discussed in the earlier part of this post we need to edit the following parameters:

jira_password 

jira_request_type_id 

jira_servicedesk_id

jira_url 

jira_user 

 

Once you have set up all of those parameters, it should now look like this:

The result

Now, if all of the information from the previous steps is filled in, we can test the integration. Navigate to Monitoring -> Problems and click on any of the problem names:

Which will open a dropdown menu. Go to ServiceDesk and click the Create Jira ticket button.

This will then kick of our new Zabbix frontend script. The webhook script will be using the Jira API to create a ticket and voila:

A ticket is created, right from the frontend. It’s just that easy.

Conclusion

Using Media Types is great and I would definitely recommend using them. If you have set up the correct filtering using host groups, severities, tags and perhaps more than that, you can already keep the ticket count to a minimum. But there’s always a downside to using a lot of filters, you might miss something. That’s where our Frontend Script implementation kicks in. Maybe your filter missed a ticket, maybe you don’t want automated tickets at all. We can use the script to manually create tickets, quickly from the frontend and solve that issue.

You’ve now got a powerful way to do so, fully compatible with Zabbix most of the times out of the box! As Zabbix adds more and more of this functionality it becomes easier and easier to do so, if you just know where to look.

I hope you enjoyed reading this blog post and if you have any questions or need help configuring anything on your Zabbix setup feel free to contact me and the team at Opensource ICT Solutions. We build a ton of cool integrations like this and much more!

Nathan Liefting

https://oicts.com

A close up of a logo Description automatically generated