The documentation on User Management covers linking user accounts to a master account. Larger organizations may wish to create team accounts, which enable customers to have siloed data sets and assets (parsers, dashboards, alerts, etc.). By dividing a large organization's data set into separate accounts, searches can return more quickly because less data is being searched. User permissions are granular.
For convenience, log volume is consolidated across team accounts into a single bill.
To illustrate the roles of these accounts, we abbreviate the associated email addresses as <name>-<role>, where <role> is either master, team, or user.
Master account (example, devops-master) - The primary team account. Aggregates log volume from associated team accounts for the purposes of billing. The master account should ingest zero "real" logs, and only contain metalogs.
Team account (examples, queue-team, messaging-team, platform-team) - An account that ingests data. Has its own users, permissions.
Linking The process of associating users with accounts. 1. This is done via invitation from a user with "Full Access." 2. From a team account, click the User menu, choose “Manage Users” and click “Send Invites.” 3. The user must accept the invitation in order to get access. 4. Once an user accepts the invitation, they can switch between teams by clicking the User Menu -> "Manage Teams" and selecting an account they have access to
Users (examples, joe-user, will-user, mac-user) - User accounts do not ingest data and can log into team accounts (if permission is explicitly granted).
Master and team accounts should be treated as standalone system accounts:
- Never link the master account to its team accounts, as permissions will not be inherited.
- The master or team accounts were not designed to be user accounts - All administrative tasks should be performed by a user with "Full Access" permissions.
- Only perform the "Invite Users" process for email addresses that are associated with users.
- If you are onboarding with Scalyr Customer Success, your Scalyr contact will facilitate the setup process - you do not need to follow these steps.
If you are an existing user, you have probably created the accounts that you intend to use. Or, if you need to switch an existing account to a different email address, please contact firstname.lastname@example.org and let us know. Otherwise, follow these steps to begin the configuration process:
1. Create the necessary email accounts before beginning. For example, if you have 3 teams, create 4 accounts (1 per team, and 1 master account). 2. Create Scalyr trial accounts for each of the email accounts that you established. 3. Contact Scalyr Support (email@example.com) to request an account modification. Specify the master account, and its associated team(s). 4. Sign in to the "master" and "team" accounts and invite the relevant users. Because master and team accounts are not designed to be user accounts, you should provide at least one user with "Full Access" permissions. Never link the master account to its team accounts. Sign out once you are done.
If the user account does not already exist, one will automatically be created. The user will need to create a password upon accepting the invitation email. If the user account exists, the user will receive an invitation email. Upon signing in, they will have access to the account.
If users are on multiple teams, they can switch between teams by clicking the User Menu > "Manage Teams", and selecting the appropriate team (displayed as hyperlink). Once the team has been selected, it will be displayed as an entry on the user menu for quick access.
Be sure to configure each of your agents with the correct API key to send logs to the appropriate account.
Example Use Case
Karate Data Co. has a significant amount of log data distributed among 3 teams (Messaging, Queue, and Platform). Due to security policies, users are only allowed to access data associated with their team(s). Each team has alerts, graphs, dashboards, and searches that are specific to their tasks and objectives. To simplify billing, Karate Data needs a single invoice that contains the combined log volume for all team accounts per month.
Karate Data has the following team structure:
- Joe works on the Messaging and Queue teams, and has access to both accounts.
- Will is a member of the Platform team and can only access the Platform account.
- Mac is the CTO.
Mac creates 4 email accounts on his platform (devops-master, messaging-team, queue-team, and platform-team). He then creates corresponding Scalyr trial accounts and contacts Scalyr Support to establish devops-master as the master account for combined billing purposes.
Once this has been completed, Mac signs in to devops-master, sends an invitation to his personal account (mac-user), grants "Full Access" permissions to the devops-master account, and logs out. He then logs in to Scalyr as mac-user.
Joe - Multi-team Overview
Joe works on the Messaging and Queue teams and requires access to data on both platforms. Mac adds Joe by sending him invitations from the messaging-team and queue-team accounts. Joe accesses the Messaging account invitation first. He does not have a Scalyr account at this time, so he is prompted to establish one by creating a new password. He then accepts the invitation to the Queue team. Joe now has access to the Messaging and Queue team accounts, and creates search queries, alerts, and dashboards that are unique to each. He is able to quickly navigate between accounts by picking the account he wishes to access from the User Menu.
Will - Single team Overview
Mac invites Will to the Platform team by sending him an invitation. Will accepts the invitation, but since he already has a Scalyr trial account, he simply logs in with his account details, then accepts the invitation. Will can now access the Platform team account.
Mac - Billing
Mac configures credit card billing on the master account by logging in as devops-master. Once this is complete, he signs out and logs in with his mac-user account. As previously mentioned, master / team accounts should not be used as user accounts (treat them like the root account)! — Users should create separate accounts for regular use.