Configuration requirements

To run this collector, there are some configurations detailed below that you need to consider.

Overview

The Okta Resources API is used for gaining insights into the content management of activities from your organization or company. Okta Resources APIs generate system logs and other events in real time.

Okta collector migration guide (from 1.x.x to 2.x.x)

If you need to migrate an old collector version to a more recent one, please check the migration process in this article.

Devo Collector features

Data source description

You can use the Okta collector to send this information to your Devo domain. Once the gathered information arrives at Devo it will be categorized in different tables in your domain, as you can check in the following table.

Okta services

Listed in the table below are some service names, details, and how the Devo platform treats the data.

Accepted authentication methods

Minimum configuration required for basic pulling

Although this collector supports advanced configuration, the fields required to retrieve data with basic configuration are defined below.

This minimum configuration refers exclusively to those specific parameters of this integration. There are more required parameters related to the generic behavior of the collector. Check setting sections for details.

Vendor Setup

Getting Okta credentials

1. Visit Developer Okta to create an api_token and get the okta_url.

2. Log in with your company credentials (or sign up for a free developer account).

3. Click Dashboard and save the okta_url that is displayed in the top right corner (it will be used later in the config file).
   
   
   

   Open

   

4. On the top menu, go to API → Tokens.
   
   
   

   Open

   

5. Click on Create Token and enter a name for your token in the window that appears, which will be used for tracking API calls. Click Create Token.
   
   
   

6. Copy your token and click OK, got it. Note that the token will be only displayed here, so don't forget to copy it. Save it as api_token (it will be used later in the config file).
   
   
   

Run the collector

Once the data source is configured, you can either send us the required information if you want us to host and manage the collector for you (Cloud collector), or deploy and host the collector in your own machine using a Docker image (On-premise collector).

Collector service details

Verify data collection

Once the collector has been launched, it is important to check if the ingestion is performed in a proper way. To do so, go to the collector’s logs console.

This service has the following components:

Setup output

A successful run has the following output messages for the setup module:

Puller output

A successful initial run has the following output messages for the puller module:

Note that the PrePull action is executed only one time before the first run of the Pull action.

After a successful collector’s execution (that is, no error logs found), you will see the following log message:

Restart the persistence

This collector uses persistent storage to download events in an orderly fashion and avoid duplicates. In case you want to re-ingest historical data or recreate the persistence, you can restart the persistence of this collector by following these steps:

1. Edit the configuration file.

2. Change the value of the start parameter to a different one.

3. Save the changes.

4. Restart the collector.

The collector will detect this change and will restart the persistence using the parameters of the configuration file or the default configuration in case it has not been provided.

Note that this action clears the persistence and cannot be recovered in any way. Resetting persistence could result in duplicate or lost events.

[ Troubleshooting ]

This collector has different security layers that detect both an invalid configuration and abnormal operation. This table will help you detect and resolve the most common errors.

[ Common Logic ]

Check Memory Usage

To check the memory usage of this collector, look for the following log records in the collector which are displayed every 5 minutes by default, always after running the memory-free process.

• The used memory is displayed by running processes and the sum of both values will give the total used memory for the collector.

• The global pressure of the available memory is displayed in the global value.

• All metrics (Global, RSS, VMS) include the value before freeing and after previous -> after freeing memory

Differences between RSS and VMS memory usage:

• RSS is the Resident Set Size, which is the actual physical memory the process is using

• VMS is the Virtual Memory Size which is the virtual memory that process is using

Activeboards

There are a number of predefined dashboards that can be downloaded in your Devo domain.

1. Create a new Devo Activeboard in your domain.

2. In the Edit mode click on the ellipsis button and select Edit raw configuration.

3. Open the downloaded file, select all the text, and copy it to the clipboard.

4. Paste the content of the file in the raw editor. Make sure you replace completely the existing configuration.

5. Click on Save the changes. The dashboard shows up.

Rate limits

The number of API requests for an organization is limited for all APIs in order to protect the service for all users. The number of Okta-generated emails that can be sent also has rate limits.

Okta has two types of API rate limits:

• Org-wide rate limits that vary by API endpoint. These limits are applied on a per-minute or per-second basis, and some are also applied on a per-user basis. For example, if your org sends a request to list applications more than one hundred times in a minute, the org-wide rate limit is exceeded. These limits protect against denial-of-service attacks and help ensure that adequate resources are available for all customers.

• Concurrent rate limits on the number of simultaneous transactions. For example, if you sent 77 very long-lasting requests to any API endpoint simultaneously, you might exceed the concurrent rate limit.

Okta has one type of email rate limit:

• Okta-Generated Email Message Rate Limits that vary by email type. Okta enforces rate limits on the number of Okta-generated email messages that are sent to customers and customer users. For example, if the number of emails sent to a given user exceeds the per-minute limit for a given email type, subsequent emails of that type are dropped for that user until that minute elapses.

Rate limits may be changed to protect customers. We provide advance warning of changes when possible.

Check the following web pages for more information on Okta rate limits:

• Additional rate limits | Okta Developer

• Other endpoint rate limits | Okta Developer

• Management rate limits | Okta Developer

• Authentication/End-user rate limits | Okta Developer

• System Log events for rate limits | Okta Developer

• Previous rate limits | Okta Developer

• DynamicScale rate limits | Okta Developer

Change log