Praeco is an open-source tool for alerting Elasticsearch. It can build the alert for elasticsearch in an interactive query builder. A preview of the result will be shown in charts. This tool has an easy installation & configuration process which we will learn further in this blog. We can receive alerts on commonly used channels like slack, email, and many more.
This will have two parts- first, we install & configure the Praeco; in the second part, we learn – how to create an alert?
Why do we use this over others?
In terms of open-source tools which are used for alerting in elasticsearch the most popular option is elastalert. In this creating an alert is a very hectic process because one has to write YAML which can be sometimes frustrating for those who don’t know the syntax.
Now we have to search for other options, which leads us to Praeco. This provides an interactive GUI to create the alert condition and hassle-free integration with alert channels.
As a developer or tech geek, when technology is part of your lifestyle or work, we definitely look forward to exploring all developer things. APIs & libraries are one of the important things we generally look for.
Why is it so? Because, when we use that specific technology on a daily basis, we definitely want to automate most of the things. For that, we try to explore its functional part just to make our work easy. We can use that functional part [ API/Library ], to make an automation script or application.
There are two basic ways to deploy to Kubernetes: Imperative acts as a command which is active and immediate, whereas declarative is passive, by writing manifest file and using kubectl apply.
The imperative command is the first mode of managing objects, to use CLI for CUD (Create, Update, Delete) objects on Kubernetes cluster without specifying on manifest file ahead of time. They are a blessing for Kubernetes application developers and administrators because they are very easy to remember and handy. According to K8s, it’s like a ‘Swiss Army Knife” of container orchestration and management.
Imperative commands can help in getting tasks done quickly, as well as generating definition file templates easily. It saves a considerable amount of time and prevents human errors.
Have you ever wondered that when you access the API Server through kubectl you are authenticated through the API controller, but how will you do the same from the pod side? Here the Service Account role comes into play. As k8s definition itself says “Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (for example, default).”
Things we should know about service Account,
Created in a namespace.
Used to allow processes inside pods, access to the API Server.
Default service account = default (no access to the API server).
Create your own service account.
Use it in a RoleBinding or ClusterRoleBinding.
Use the service account secret to obtain the authentication token & CA certificate.
What we will be covering today,
Creating a pod (that gets automatically created in default Service Account)
Will create a Service Account
Creating a deployment that will be using appsa Service Account.
“Murphy’s law doesn’t mean that something bad will happen. It means that whatever can happen, will happen.” This is something related to destiny but we should not totally rely upon it and should be prepared for the worst. The same philosophy referenced above applies to the tech world too. That’s the reason we should be prepared with our backup options choices possibly, a data set or Kubernetes cluster.
Kubernetes backup solutions bring down the risk and empower faster recovery time while providing key benefits like: disaster recovery and backup & restore. Now we have to explore some simple and convenient options to take Kubernetes backup. While working on a similar project I came to know about Velero which can fulfil our needs to take Kubernetes backup and restore and it is easy to use.
Velero is an open-source tool for securely backing up and restoring resources in a Kubernetes cluster, performing disaster recovery, and moving resources and persistent volumes to another Kubernetes cluster.