Nobl9 supports Role-Based Access Control (RBAC) to enable granular user permissions and access to resources in the Nobl9 platform.
There are two levels of permissions (1) the Organization level and (2) the Project level:
Projects are the primary logical grouping of resources in the Nobl9 platform. They are intended for use in Organizations where many users are spread across multiple teams and/or departments. Projects group and organize all resources between various users in the Nobl9 platform. This way, they divide and share resources between multiple teams and/or departments.
A Project can group all resources, including:
Projects cannot be nested inside one another, but Data Sources or Alert Methods can be shared across many Projects. Resources cannot be moved between different projects. If you create a resource in a wrong Project, you have to delete it first, then go to the correct Project, and create a resource directly in it. For more details, check the Managing Shared Resources section below.
❗ Caution: If you are using
sloctlversion is older than 0.0.56, you will not be able to use the
💡 Note: When you create a Project, you are automatically assigned to it as a Project Owner.
Organization Admins have full read and write access to all areas in the Nobl9 platform. They are responsible for setting up SSO and user management. Organization Admins can:
💡 Note: Org Admins can only edit the Annotations that they own.
By default, anyone who signs into the Nobl9 platform is an Organization User. Organization Users can be granted access to one or more Projects. They can be assigned to an Owner, Editor, Viewer or Integrations User role within a Project. Organization User can:
💡 Note: Organization Users can only see the contents of a Project if they were granted access to this project by the Organization Admin or the Project Owner.
The Organization Viewer can access all resources and UI in the Nobl9 platform in a read-only mode. Organization Viewers can:
💡 Note: Organization Viewers cannot edit any resources in the Nobl9 platform.
The Project Owner has read- and write- access to their Project(s). Project Owners can:
💡 Note: Project Owners can only edit the Annotations that they own.
The Project Editor is the primary user of the Noble9 platform. Project Editors can:
The Project Viewer is the primary consumer of data in the Noble9 platform. Project Viewers can:
💡 Note: Project Viewer cannot create, edit or delete resources.
Project Integrations User
The Project Integrations User can use a Data Source or an Alert Method from a given project without the possibility to create, edit or delete this Project’s resources. Integrations Users can:
💡 Note: For example, if a user is an Editor in Project A and an Integrations User in Project B, it means that they can use Data Sources and Alert Methods from Project B in Project A. However, they cannot edit any resources in Project B.
|Organization Admin||Organization User||Organization Viewer|
|View all resources||Yes||Depends on project access granted to this user||Yes|
|Add, remove, and suspend users||Yes||No||No|
|Assign and remove user roles (on an organization and project level)||Yes||No||No|
|Create projects and resources||Yes||Projects only||No|
|View resource usage summary report||Yes||No||Yes|
|Create access keys1||Yes||Yes||Yes|
1 All Nobl9 users can create Access Keys.
|Project Owner||Project Editor||Project Viewer||Project Integrations User|
|Add existing users to the project||Yes||No||No||No|
|Create/edit alert policies||Yes||Yes||No||No|
|Add/Use integrations||Yes||Yes||No||Can use but cannot create integrations|
|View SLO details||Yes||Yes||Yes||Yes|
|Create access keys||Yes||Yes||Yes||Yes|
Roles in the Nobl9 platform can be managed on the Organization and Project levels. To access the user management UI, navigate to Settings > Users.
Organization roles can only be assigned and changed by Organization Admins. Organization Admins can also invite new users to their organization, delete them or suspend their accounts.
Project roles can be assigned either by Organization Admins or by the Owners of a given Project.
💡 Note: Project Owners cannot invite new users, delete or suspend user accounts.
💡 Note: An invitation to join Nobl9 will be automatically sent to the user, and their role will be applied once they log in. The status of the invited user is automatically set to ‘Pending.’ It will be changed to ‘Active’ after the user accepts the invitation. Organization Admin can resend the invitations to users that are on the ‘Pending’ status.
Click the Trash icon at the right end of the given row:
💡 Note: Deleted users will be permanently removed from the organization. Their Access Keys will be permanently removed. They will not be able to log in to the Nobl9 platform via the UI and access Nobl9 through the
💡 Note: Suspended users will not be removed from the database, but they will not be able to access the Nobl9 platform via the UI or the
sloctlapplication. Access Keys that belong to a suspended user will be temporarily deactivated.
Admins can reactivate users by navigating to the Settings > Users and changing the user’s status to ‘Active.’
In the user list, find the user you wish to update. Hover over the user and click the icon on the right-hand side of the user list.
💭 Tip: If the user has access to multiple Projects, click the down-pointing arrow next to the user name to display the list.
In the dialog box in the ‘Projects’ column, select or enter a Project that you want to assign to the user.
💡 Note: Organization Admins and Project Owners can manage Project-level permissions.
❗ Caution: A user cannot be assigned to a Project without any role. If an Organization Admin or a Project Owner selects a Project without choosing the user’s role in this project, this change will not be saved.
💭 Tip: To remove a Project role from a user, you must unassign this user from the project.
Users can manage and review their projects in the Catalog menu in the main navigation pane. The Catalog view allows users to edit and delete resources that belong to a given project directly from the Project Details tab.
To access the Project Details panel:
The Project Details tab allows users to review and edit Services, SLOs, Data Sources, Alert Policies, Alert Methods, and users that belong to the specific Project. Using the Project Details tab, users can directly access all resources, edit them through the UI wizards or delete them:
Project permissions affect what data is visible and what actions are available to the users within a Project in their Catalog > Projects tab:
Project permissions also restrict the content that is visible to the users in the Settings > Users tab:
Project permissions affect what resources can be accessed by the users, for example:
💡 Note: The same limitations apply to
sloctl. The Role Bindings that are visible depend on the role that is assigned to the user.
Nobl9 enables command-line access through the
sloctl tool. You can use Sloctl and share access with other users through an Access Key.
💭 Tip: Secret is displayed only once. Save it for future use.
💡 Note: A single user can have 2 keys in an organization. The User is only allowed to view and manage their Access Keys.
You can reactivate your Access Key by going to Settings > Access Keys and clicking the ‘Enable’ icon next to the Access Key that you wish to reactivate.
💡 Note: A disabled Access Key is not removed from Nobl9’s database. Users will not be able to use disabled Access Keys to access Nobl9 via the
sloctltool. Disabled Access Keys will be included in the maximum quota of 2 Access Keys per user in an organization.
💡 Note: The Client’s secret is displayed only once: save it for your future use.
Data Sources and Alert Methods are global resources in Nobl9. They can be used across Projects but a User must have the following roles assigned:
Integrations Users can only use Data Sources and Alert Methods, they cannot edit or delete these integrations. They also cannot add, edit or delete any other resources in projects they are assigned to with this role.
The Integrations User role gives Project Owners control over the usage of their Data Sources and Alert Methods. Project Owners have to explicitly agree that users who do not belong to their projects can use their integrations.
Alternatively, you can share Data Sources and Alert Methods across the entire organization. To share them:
Service Health Dashboard (or Dashboard) provides a high-level overview of the reliability of your organization’s services. The Dashboard targets product managers or executives who do not require a granular view of each SLO and instead are looking for a holistic view of reliability within their organization. Engineers or SREs can also use it to see a snapshot of the current state of their environment and drill down for more information.
The Dashboard gives an aggregated view of the overall organizational health. It shows which Services are at risk or have burned through their error budget. All Services are grouped by Projects in the Dashboard.
Using Dashboard users can check:
The Dashboard displays services in terms of their health, following the below coloring pattern and naming logic:
|Service X||Remaining error budget|
Exhausted: At least one of the SLOs in this Service has burnt its error budget in the current time window, and at least one SLO for this Service has less than 20% of the error budget left.
For example, Service Y displays an ‘Exhausted’ status because SLO B has already burnt its error budget in a specified time window:
|Service Y||Remaining error budget|
💡 Note: Each Service is evaluated based on the current time window. This way, the Dashboard gives a high-level view of all Services in the user’s organization, even if the error budgets for each SLO are calculated differently (e.g., based on time slices or occurrences).
Users can adjust how the Services are displayed on the Dashboard and choose the view mode that suits your needs best. To change the display mode:
The Dashboard enables a more detailed view as well. Clicking a specific Service on the Dashboard shows a summary of the SLOs with their remaining budgets. To access Service details:
💡 Note: You can see the details of the specific SLOs by clicking on the relevant SLO icon:
Users can filter the data displayed on the Service Health Dashboard to see only those services that are available, at risk, or exhausted. To apply filters, hover over the filter icon at the top of the screen and choose the relevant category.
💡 Note: Filters can be combined.
The Dashboard also allows users to sort the display. This feature affects how the Projects are ordered on the Dashboard. By default, Projects are sorted by State. This display mode follows the below assumptions (from the left-hand side to the right-hand side of the UI):
The same rules apply to how the individual Services are ordered in a Project (from top to bottom):
This way, users can quickly identify these Projects and Services that require immediate attention.
Projects can also be sorted alphabetically:
This display mode affects only the order of projects on the Dashboard. It does not affect the logic of displaying Services in a Project. This way, users can readily see on the left-hand side of the page those Services that are Exhausted or At risk.
To change the sorting mode:
If you are searching for a specific project, click the ‘Search’ box in the top-right corner of the Dashboard and enter the name of the Project. The screen will update once you enter the Project name.
This guide presents an overview of labels in the Nobl9 platform and explains how to create and manage labels through the Nobl9 UI and sloctl.
Labels are key-value pairs that can be attached to SLOs, Services, and Alert Policies in the Nobl9 platform. Labels allow users to define attributes of resources and use them to filter and group SLOs across Services in the SLO Grid view and Reports. Each label must be unique for a given SLO, but many SLOs can carry the same label.
Labels can be attached to SLOs when creating or editing a Service in the SLO Wizard. Users can select existing pre-defined labels or add new ones that are specific to their organization.
Requirements for Labels
_) and dashes (
-) between the alphanumeric characters.
The following are the most common use cases for labels in the Nobl9 platform:
unit: error per s.
💡 Note: You can choose up to 20 labels that will be attached to your Service. Click the ‘Save Service’ button.
💡 Note: You can choose up to 20 labels that will be attached to your Alert Policy. Click the ‘Save Alert Policy button.
Nobl9 allows you to filter by multiple labels:
|SLO||Label 1||Label 2|
|SLO A has the labels||
|SLO B has the labels||
|SLO C has the labels||
|SLO D has the labels||
User filters by
Applying filters displays:
Labels allow you to easily filter through the SLOs. To filter your SLOs:
💡 Note: You can share the results of your filtering directly with anyone from your team by copying the deep link from your browser address bar.
💭 Tip: You can easily review the applied filters by hovering over the icon. To remove any of the filters, click the ‘x’ icon next to the relevant filter. Once you remove a filter, the change is applied in the link as well.
Nobl9 allows you to filter your reports by labels. To do that:
💡 Note: You can share the results of your report filtering directly with anyone from your team by copying the deep link from your browser address bar.
Retrieving SLO or Service config also returns all the labels that are set on the objects and allows filtering them.
There are two versions of syntax accepted by sloctl while filtering by labels:
Labels can be separated by a comma without spaces, for example:
bin/sloctl get slo -A -l key1=value1,key2=value2,key3=value3
Labels can be separated by a
-l with spaces in between, for example:
bin/sloctl get slo -A -l team=green -l team=orange -l key=value
Assumptions for label commands in
If you retrieve resources for two or more labels that have the same
key, they are connected by an ‘or’ logical operator, for example:
bin/sloctl get slo -A -l team=green -l team=red
slocl retrieves all resources that have
team=red attached to them
If you retrieve resources for two or more labels that have different
keys, they are connected by an ‘and’ logical operator, for example:
bin/sloctl get slo -A -l team=green -l geo=eu
sloctl retrieves all resources that have both
geo=eu labels attached to them.
apiVersion: n9/v1alpha kind: Service metadata: name: webapp-service displayName: WebApp Service project: default labels: key: - value team: - green - orange noble: spec: description: Web Application Service
Nobl9 TechDocs: Data Exports
Reference the Data Exports for more in-depth documentation about how to use the Nobl9 with other platforms.
This section explains how Nobl9 configuration is represented in the
and how you can express them in
apiVersion: n9/v1alpha kind: AlertPolicy🡕 | SLO🡕 | Service🡕 | Agent🡕 | DataExport | Direct🡕 | Integration🡕 metadata: name: string displayName: string # optional project: string # optional spec:
Please, note that names should be unique within a project. It is not possible to have two objects of same kind with exactly the same name in a given project.
The DataExport defines the configuration to export your data from Nobl9.
💡 Note: DataExport is a premium feature. Please contact your Nobl9 sales representative to enable the DataExport feature.
apiVersion: n9/v1alpha kind: DataExport metadata: name: string displayName: string # optional project: string spec: exportType: S3 | Snowflake | GCS spec: bucketName: string # Required name of s3 bucket or gcs bucket. # Required for S3 and Snowflake export types. # This is the Amazon Resource Name (ARN) of the role # that the Nobl9 is assuming to upload files. roleArn: string
apiVersion: n9/v1alpha kind: DataExport metadata: name: s3-data-export displayName: S3 data export project: default spec: exportType: S3 spec: bucketName: examplebucket roleArn: arn:aws:iam::123456789:role/example