Projects allow you to organize your resources and events based on environment, team, or any other criteria you have. Using projects, you can categorize notifications and send them to the people who need them the most. You can also view the app by showing pages for only the events and resources in a project.
How To Enable Projects
The projects feature is disabled by default. To enable projects, navigate to the Projects page via Account > Projects. This will bring you to a page that briefly describes projects and the steps to configure them.
Click the checkbox next to the word “Enabled” to turn on the projects functionality.
One projects are enabled, you’ll have to complete the following steps:
Create projects
Categorize resources into projects
Set up notification routing based on projects
Creating A Project
When you first enable projects, there will be no projects in your account. In the Integrations page, you will now be able to create projects from the projects dropdown. Initially, the dropdown will look like this:
When you open the dropdown, you’ll see all your projects and the create button. Click the Create Project button at the bottom of the dropdown to open the project creation dialog.
To create a project, you’ll just need to enter a name for your new project and then save the project.
That’s it! You can repeat that process as many times as you need to create the projects that apply to your infrastructure.
Categorizing Resources Into Projects
Now that you’ve created some projects, you’ll want to categorize your resources into projects. To do so, navigate to the Integrations page via Setup > Integrations. Blue Matador supports a number of integration types; the following sections describe how to set up projects with each of them.
Configuring Projects For AWS Resources
The first step when configuring projects for an AWS account is to pick default projects for resources to belong to. Unless you set up additional categorization rules, all resources will be put into your default project. You may not need to set up additional rules if all the resources in the AWS account should belong to the default projects.
If your AWS account contains resources that belong to different projects, you can set up additional rules. Click on Add Rule to add a categorization rule.
These rules can classify AWS resources using two methods: by resource name, or by tagging. You can include many rules and mix rule types to get the project setup you’d like.
If your AWS resources are classified using a naming convention, you can set up a Name Rule to add them to a project. Name rules allow you to select an AWS resource type (such as EC2 Instance, Route53 Zone, or S3 Bucket) and an operator (like Starts With, Ends With or Contains). Next, you enter the value the name should conform to. Finally, select the projects that resources matching the rule should be sent to.
If your AWS resources are classified using tags, you can set up a Tag Rule to add them to a project. A tag rule is a combination of one or more key value pairs that map to a project. Any resource whose tags match all the key value pairs you’ve specified will be added to the project.
For example, given an AWS integration that has the following configuration:
Consider the following resources:
An RDS table named “prod-table” and tagged with “env:prod” would be sent to “Default” because it does not match any other rules.
An S3 Bucket named “prod-assets” and tagged with “env:prod” would be sent to “Production” because it is an S3 Bucket whose name starts with “prod-”.
An EC2 instance named “prod-misnamed” and tagged with “env:staging” would be sent to “Staging” because it has the “env:staging” tag and is not an S3 Bucket.
Configuring Projects For Kubernetes Resources
The first step when configuring projects for a Kubernetes cluster is to pick default projects for resources to belong to. Unless you set up additional categorization rules, all resources will be put into your default projects. You may not need to set up additional rules if all the resources in the cluster should belong to the default project.
If your Kubernetes cluster contains resources that belong different projects, you can set up additional rules. Click on Add Rule to add a categorization rule.
These rules can classify Kubernetes resources using two methods, by resource name, namespace, or labels. You can include many rules and mix rule types to get the project setup you’d like.
If your Kubernetes resources are classified using a naming convention, you can set up a Name Rule to add them to a project. Name rules require that you select an operator (like Starts With, Ends With or Contains) and a value the name should conform to. You will also select the projects that resources matching the rule should be sent to.
If you have organized your Kubernetes resources into namespaces, you can set up a Namespace Rule to add them to a project. Namespace rules require that you select a string operator and a value the namespace should conform to. Once you select the projects the rule sends resources to, all resources whose namespace matches the rule will be placed in the specified project.
If your Kubernetes resources are classified using labels, you can set up a Label Rule to add them to a project. A label rule is a combination of one or more key value pairs that map to a project. Any resource whose labels match all the key value pairs you’ve specified will be added to the project.
For example, given a Kubernetes cluster that has the following configuration:
Consider the following resources:
A pod named “service-59f19db08e-adv50” in the namespace “infrastructure” labeled “app.kubernetes.io/component:service” would be sent to the “Default” project because it does not match any other rules.
A pod named “prod-service2-a4f59db88c-mkv4n” in the namespace “infrastructure” labeled “app.kubernetes.io/component:service2” would be sent to the “Production” project because its name begins with “prod-”.
A pod named “prod-prometheus-34057d38cc-2ki2p” in the namespace “monitoring” labeled “app.kubernetes.io/component:prometheus” would be sent to both the “Monitoring” and “Production” projects because it is in the monitoring namespace and its name begins with “prod-”
A pod named “db-1ff59db8ba-xrv66” in the namespace “infrastructure” labeled “app.kubernetes.io/component:staging” would be sent to the “staging” project because it has the appropriate label.
Configuring Projects For Linux Agents
Linux agents determine their projects by reading project IDs out of their config file. When installing agents, use the project dropdown to select the project you’d like to install agents into. Then, run the outputted command on the server you’d like to install an agent on.
If you’d like to update the project for an already installed agent, just select the projects you’d like from the dropdown. Then copy the value for the PROJECTS variable from the command. It should be a comma separated list of UUIDs. Finally, on the server you’d like to update, add the following line to /etc/bluematador-agent/config.ini:
; replace with the value you copy pasted
projects = 383aaa2a-de1c-4b48-8722-4ec70fb6c2e3
The Blue Matador agent will automatically pick up the changes and start reporting your project within 10 minutes.
Configuring Projects For Windows Agents
Windows agents determine their projects by reading project IDs out of their config file. When installing agents, use the project dropdown to select the project you’d like to install agents into. Then, copy the config to C:\Program Files\Blue Matador\BlueMatador\config.ini just as you normally would.
If you’d like to update the project for an already installed agent, just select the projects you’d like from the dropdown. Then copy the last line of the configuration in the dialog. Finally, on the server you’d like to update, paste the line at the end of C:\Program Files\Blue Matador\BlueMatador\config.ini.
The Blue Matador agent will automatically pick up the changes and start reporting your project within 10 minutes.
Configuring Projects for Chef
Chef agents determine their projects by reading project IDs out of their attributes file. When installing agents, use the project dropdown to select the project you’d like to install agents into. Then, run chef on the server you’d like to install an agent on.
If you’d like to update the project for an already installed agent, just select the projects you’d like from the dropdown. Then copy the last line of the config into your attributes file and run chef.
The Blue Matador agent will automatically pick up the changes and start reporting your project within 10 minutes.
Configuring Notification Routing By Project
It’s probably the case that not everyone in your organization cares about all resources in your infrastructure. You can set up notification routing by project to make sure that everyone gets notifications for only the resources they are responsible for.
To get started navigate to the Notifications Page via Setup > Notifications.
Each type of notification integration allows you to configure which projects it will send notifications for. In the notification setup dialog, you’ll see a table that will let you turn on notifications by project and event severity. Just click the checkboxes for the things that should be routed to that notification integration. Selecting [all] will route all notifications of that type regardless of project, even when new projects are created. Selecting [unassigned] will send notifications for any resources that do not have any projects assigned.
Viewing App Pages By Project
Once you’ve configured projects, you can view any page in the app by project. To do so, use the dropdown next to the Blue Matador logo to select the project you’d like to view.
This will make it so the pages are scoped to that project. For example, when you’re on the dashboard, selecting a project will make it so the dashboard shows only the alerts, warnings, and anomalies that affected resources in the project. Visiting the Resources Page via Explore > Resources with a project selected will show only the resources that have been associated with the project.
If you want to view all events and resources, just pick [all] from the dropdown. Selecting [unassigned] will show you all the events and resources that have not been assigned a project; this can be helpful in making sure all resources have been properly categorized!
Managing Projects
You can view your currently configured projects at any time by returning to the Projects page via Account > Projects. For each project, you will see its Name, a unique ID for each project (used by agent configuration), as well as Edit and Delete buttons.
Clicking on the Edit button will allow you to change the name of a project. Project names must be between 1 and 100 characters in length. Click the Save Project button to save your changes.
Clicking on the Delete button will allow you to delete a project. Deleting a project will remove it entirely from the Blue Matador UI, and new resources and events will no longer be tagged with that project. Project deletion cannot be undone. Click the Delete Project button to confirm.