Docs » Get started guide for Splunk Observability Cloud admins » Get started guide phase 1: Onboarding readiness

Get started guide phase 1: Onboarding readiness πŸ”—

In the onboarding readiness phase of the getting started journey for Splunk Observability Cloud, you set up users, teams, and access controls using roles and token management. The following sections cover the primary setup steps for the onboarding readiness phase.

To get a high-level overview of the entire getting started journey, see Get started guide for Splunk Observability Cloud admins.

Note

This guide is for Splunk Observability Cloud users with the admin role.

To configure your users, teams, and tokens, complete the following primary tasks:

  1. Create a trial for your organization

  2. Analyze your network communication and access requirements

  3. Decide how to manage user access

  4. Plan your team structure and token management strategy to control access

Note

Work closely with your Splunk Sales Engineer or Splunk Customer Success Manager as you get started. They can help you fine tune your Splunk Observability Cloud journey and provide best practices, training, and workshop advice.

Create a trial for your organization πŸ”—

If you have a Splunk technical contact, they can create a Splunk Observability Cloud trial for your organization and provide you with the link to log in to your trial organization. Alternatively, you can sign up for a trial. See Splunk Observability Cloud free trial and guided onboarding.

Analyze your network communication and access requirements πŸ”—

Before you begin bringing data into Splunk Observability Cloud from your infrastructure and applications, analyze your required network communications and access requirements.

  1. Validate that network connections between your environment and Splunk Observability Cloud are allowed. See Exposed ports and endpoints to determine which ports you need to open in the firewall and what protocols you need to turn on or off in the Collector.

  2. If your organization requires a proxy, see Allow Splunk Observability Cloud services in your network.

  3. For Kubernetes, you need administrator access to monitored hosts of Kubernetes clusters to install the Splunk Distribution of the OpenTelemetry Collector.

  4. Whether you use a guided setup for data management or an advanced installation method, you use the Splunk Distribution of the OpenTelemetry Collector to ingest, process, and export metric, trace, logs, and metadata into Splunk Observability Cloud. You can run the Splunk Distribution of the OpenTelemetry Collector as a custom user, not a root or admin user. For the majority of use cases, the collector doesn’t require privileged access to function.
    1. Collector components might require privileged access. Use care when allowing privilege access for components. For example, a receiver might require the Collector to run in a privileged mode, which might be a security concern. Receivers and exporters might expose buffer, queue, payload, and worker settings in configuration parameters. Setting these parameters might expose the Collector to additional attack vectors including resource exhaustion.

    2. Collector components might also require external permissions including network access or role-based access.

    See Security guidelines, permissions, and dependencies for more details about managing your architecture security.

Decide how to manage user access πŸ”—

Select from these 3 options for managing user access:

  1. Use Splunk Cloud Platform as the unified identity provider. See Unified Identity: Splunk Cloud Platform and Splunk Observability Cloud for more information.

  2. Use an external Lightweight Directory Access Protocol (LDAP) and control access through Single Sign-On (SSO). See Configure SSO integrations for Splunk Observability Cloud for more information.

  3. Use Splunk Observability Cloud user management to allow access using a username and password. See Manage users and teams.

Plan your team structure and token management strategy to control access πŸ”—

If you plan to roll out Splunk Observability Cloud across your organization, you likely have multiple internal customers with different access requirements for the various features in Splunk Observability Cloud. Complete the following steps to create a consistent team structure and corresponding token management strategy.

  1. Define team and token naming conventions

  2. Plan your team structure

  3. Manage your tokens

Define team and token naming conventions πŸ”—

Before creating teams and tokens, determine your naming convention. A naming convention helps you to track token assignments and control data-ingestion limits. Aligning team and token names also helps you to identify token owners when viewing the usage reports. For example, you can align team and token names in the following way:

  • Team name: FRONTEND_DEV_TEAM

  • Token names: FRONTEND_DEV_TEAM_INGEST, FRONTEND_DEV_TEAM_API, FRONTEND_DEV_TEAM_RUM

Plan your team structure πŸ”—

Create a plan for your team structure and user roles within teams. A user with an admin role can manage teams, which includes adding and removing users and assigning a team manager. For an overview of the various team roles and permissions, see Team roles and permissions.

By default, every user can join any team in your organization. If you want to restrict users from being able to join any team, you can turn on the enhanced team security setting. Use enhanced team security to assign usage rights to each team and their associated tokens. See Turn on enhanced team security.

Manage your tokens πŸ”—

Use tokens to secure data ingestion and API calls in Splunk Observability Cloud. Tokens are valid for 1 year and you can extend them for another 60 days. Your organization has a default token that is automatically generated when the organization is created.

To learn more about token management, see the following topics:

Optional and advanced configurations πŸ”—

Consider these optional and advanced configurations to customize your setup as they apply to your organization.

Request a custom URL for your organization πŸ”—

Create a Splunk support request to request a custom URL for your organization, for example, acme.signalfx.com. See Splunk Observability Cloud support for support contact options.

Separate your teams with a parent-child setup πŸ”—

If you want to create separate environments, you can use parent-child organizations. Perhaps you want a development environment and a production environment, or you want to make sure Team A is fully separated from Team B. Parent-child organizations are 2 or more separate organizations, where your original organization is the parent organization which includes your original usage entitlement. You can then have 1 or more organizations as child organizations within the parent organization. The organizations are fully separated, including users and data.

You can request a parent-child organization setup by creating a support case. See Splunk Observability Cloud support for support contact options.

Set up Log Observer Connect for the Splunk Platform πŸ”—

If your organization has an entitlement for Splunk Log Observer Connect, Splunk Observability Cloud can automatically relate logs to infrastructure and trace data.

See Set up Log Observer Connect for Splunk Enterprise or Set up Log Observer Connect for Splunk Cloud Platform.

Education resources πŸ”—

Next step πŸ”—

Next, prepare for an initial rollout of the Splunk Observability Cloud products that are relevant to your organization. See Get started guide phase 2: Initial rollout.

This page was last updated on Nov 04, 2024.