Skip to main content
Version: 2.23.X

Deploying Models

After a model is developed, it can be put into execution to view the output of its patterns, or to verify that its pattern detection logic works as intended. This process involves creating and configuring deployments.

For more information about deployments, see Model Artifacts.

Viewing Deployments​

Deployment-related resources are found in the Deployments window. To access it, click the Deployments button on the project screen toolbar.

The Deployments window displays all existing deployments in a table with the following columns:

  • Name: Displays the name of the deployment.
  • Patterns: Displays the number of event patterns included in the deployment.
  • Status: Shows the current status of the deployment.
  • Issues: Indicates the number of issues, if any, that the deployment is experiencing. If issues are occurring, click the ! icon to open the open the deployment's Issues Log and assess the problem(s). For more information, see Addressing Issues.

Clicking the Expand (>) icon to the left of a deployment's name reveals additional fields:

  • Description: Shows a description for the deployment, if available.
  • Date Created: Displays the date and time when the deployment was created.
  • Date Modified: Displays the date and time when the most recent change to the deployment was made.
  • Patterns: Displays the names of the individual event patterns included in the deployment.
  • Flink Cluster Name: Indicates WHAT. Click the Copy icon to copy the value to the clipboard for pasting in other locations.

Click the Collapse (v) icon to hide the additional fields.

Editable deployments have an Edit (pencil) icon on the far right of their corresponding row. Click it to edit the deployment's details. For more information, see Editing Deployments. Read-only deployments have a View icon instead, which can be clicked to show the deployment's configuration.

To the right of the Edit or View icon is the More (⋮) menu. The options it contains vary depending on the status of the deployment. It may include the following options:

  • Deploy: Deploys the deployment. For more information, see Initiating Deployments.
  • Flink Dashboard: Opens the Flink Dashboard for the deployment as a new browser tab. For more information, refer to the official Flink documentation.
  • Pause & Edit: Pauses the deployment and opens its configuration for editing. For more information, see Editing Deployments.
  • Pause: Pauses the deployment (but keeps it online).
  • Stop: Stops the deployment and takes it offline. For more information, see Terminating Deployments.
  • Export: Downloads the deployment as a file to your local machine. This file can be imported into the same project at another time, into other projects, or into other instances of Cogynt. For more information, see Importing Deployments.
  • Duplicate: Makes a copy of the current deployment.
  • Delete: Deletes the deployment.

Configuring Deployments​

A deployment's details must be specified before the deployment can be put to use. This process is called "configuring" the deployment.

Creating Deployments​

New deployments can be added to projects as needed.

To create a deployment:

  1. On the project screen, click Deployments.
  2. In the Deployments window, click + New Deployment.
  3. In the New Deployment window:
    1. Under Step 1: Patterns:
      1. In the Name field, enter a name for the deployment.
      2. In the Description field, enter a description for the deployment if desired.
      3. In the Patterns list, select any patterns that should be included in the deployment. (Note: If a pattern is utilized by another deployment, it will be marked with a rocket symbol.)
      4. Filter the Patterns list using any of the following features if needed:
        1. Enter the name of a pattern in the Search field to include only matching terms in the Patterns list.
        2. Select the Filter By dropdown menu to filter patterns by tag. The Patterns list will display only patterns that have been given the selected tag(s). (If no tags are selected, all patterns are displayed.)
        3. Set the Hide Utilized toggle to On to remove utilized patterns from the list.
    2. Under Step 2: Deployment Configs:

      1. Select the Custom option button.

      2. Set the Auto Scale toggle to On to enable auto-scaling. When auto-scaling is enabled, Number of Slots is replaced by Initial number of Slots and Max number of Slots, and the Auto-Scaling Settings section is shown.

      3. Click the More (⋮) menu for additional options:

        1. Select Apply Settings from Template to use an existing deployment template to define the deployment configuration, if desired. For more information, see Using Deployment Templates.
        2. Click Reset All to Defaults to set every field of the current deployment configuration back to its default value, if necessary. Note that each field has its own Reset (circular arrow) icon for resetting individual values.

      4. Configure the deployment's settings as needed. The settings are organized into the following sections:

        • General Settings
        • Auto-Scaling Settings (shown when Auto Scale is On)
        • Checkpoint and Savepoint Settings
        • Fault Tolerance Settings
        • Custom Settings
        • Debug Settings

        For a description of each setting, see Deployment Settings Reference.

      5. Under Custom Settings:

        1. Click + NEW to add a new custom setting:
          1. In the Config Name field, specify the setting's configuration key.
          2. In the Value field, specify the setting's configuration value.
        2. Remove any unnecessary custom settings by clicking the corresponding X icon.
    3. Under Step 3: Data Ingestion:
      1. Click + Add Event Type to add new ingestion settings as necessary:
        1. From the Event Type dropdown menu, select the event type to filter against.
        2. From the Referenced Date Field, select the timestamp that the ingestion start date should reference (for example, Kafka Ingestion Time or COG_timestamp). WARNING: If you pick a field inside of your data and make it a filter, Cogynt will have to traverse every entry in your topic to find the time to filter against. Use Kafka Ingestion Time when you can, as it jumps to a time index inside of the message, which saves time and resources.
        3. In the Ingestion Start Date field, specify the date and time to begin ingestion.
      2. Remove any unnecessary events by clicking the corresponding X icon.
  4. Click Create to create the deployment, or Cancel to discard it. Alternatively, click Create and Deploy to deploy the deployment once it is created.

Deployment Settings Reference​

The following tables describe the settings available when creating or editing a deployment or a deployment template. Each setting has a Reset (circular arrow) icon that sets it back to its default value.

Settings with a unit are specified using a Number or Decimal field and, where listed, a Unit dropdown menu.

General Settings​

General settings control the resources assigned to the deployment.

SettingDescriptionDefaultUnits
Number of SlotsThe total number of parallel tasks that the deployment runs. When more than one slot is assigned, Cogynt divides the task load across the equivalent number of parallel processes. Due to the distributed nature of deployments, the total number of slots should be a divisible number. Shown when Auto Scale is Off.1N/A
Initial number of SlotsThe number of slots the deployment starts with. The deployment can scale up or down from this setting. Shown when Auto Scale is On.1N/A
Max number of SlotsThe maximum number of parallel tasks the deployment can scale up to. Shown when Auto Scale is On.20N/A
CPU core per SlotThe fraction of compute time consumed per slot, which acts as the CPU limit of each slot. For example, a value of 1.2 takes 100% of an entire core and 20% of another core.1.0N/A
Memory per SlotThe total memory available per slot, used for storing constraint and state information. Typically, the more grouped entities and constraint states, the more memory required.4 GBMB, GB

The following general settings are found under Advanced Settings.

SettingDescriptionDefaultUnits
CPU per Slot Request FactorThe factor that CPU core per Slot is divided by to determine the CPU requested for each slot when the deployment is scheduled. By default, the full CPU core per Slot amount is requested. Increase the factor to reduce the CPU requested relative to the limit, allowing more deployments to be scheduled per worker node.1.0N/A
Job Manager CPU coreThe number of CPUs assigned to the job manager, which orchestrates and coordinates the deployment's tasks. The more event patterns deployed, the more CPUs required. This acts as the CPU limit of the job manager.1.0N/A
Job Manager CPU Request FactorThe factor that Job Manager CPU core is divided by to determine the CPU requested for the job manager when the deployment is scheduled. By default, the full Job Manager CPU core amount is requested. Increase the factor to reduce the CPU requested relative to the limit, allowing more deployments to be scheduled per worker node.1.0N/A
Job Manager MemoryThe amount of memory assigned to the job manager. The more event patterns deployed, the more memory required.2 GBMB, GB
Deployment Timeout DurationThe amount of time to wait for the deployment to start before failing. Increase this value if a deployment fails due to a timeout error, which can be caused by slow machines or congested networks.60 sms, s, min, hr
Heartbeat failure thresholdThe amount of time to wait without receiving a heartbeat before considering a task manager unreachable and restarting or recovering it. Increase this value if a deployment fails with a "TaskManager heartbeat timed out" message, to give task managers more time to start up or recover.50 ss, min
Fraction of Memory for State ManagementThe fraction of allotted memory assigned to manage and store state. Increasing this value can improve performance for deployments with especially large state volume.0.4N/A
Network Buffer SizeThe amount of memory assigned to each message segment to facilitate inter-task communication. Reduce this value when encountering deployment errors relating to insufficient memory assigned to network buffers.32 KBB, KB, MB
Network Memory FractionThe fraction of allotted memory to use as network memory.0.1N/A
Minimum Network MemoryThe minimum amount of memory to use as network memory.64 MBB, KB, MB, GB
Drilldown Batch IntervalThe amount of time to aggregate drilldown records before they are published. Increase this value if drilldown performance in Cogynt Analyst Workstation is slow.10 ss, min, hr
note

CPU core per Slot and Job Manager CPU core set the CPU limit, which is the most CPU that a slot or the job manager can use. The request factors determine how much CPU is requested when the deployment is scheduled, as a fraction of that limit:

CPU requested = CPU limit ÷ request factor

For example, if CPU core per Slot is 2.0, each slot can use up to two cores. The CPU per Slot Request Factor then changes how much CPU is requested for each slot:

CPU per Slot Request FactorCalculationCPU Requested per Slot
1.0 (default)2.0 ÷ 1.02.0 cores
2.02.0 ÷ 2.01.0 core
4.02.0 ÷ 4.00.5 cores

With a factor of 2.0, each slot is still limited to two cores, but only one core is requested when scheduling. Requesting less CPU than the limit allows more deployments to be scheduled per worker node. The Job Manager CPU Request Factor works the same way with Job Manager CPU core.

Auto-Scaling Settings​

Auto-scaling settings are shown when Auto Scale is On. The auto-scaler dynamically adjusts the parallelism of a deployment by scaling operators up or down based on metrics such as throughput and resource utilization.

SettingDescriptionDefaultUnits
Max CPUThe maximum number of CPUs the auto-scaler can request. When scaling up, the auto-scaler does not exceed this value.5N/A
Max MemoryThe maximum amount of memory the auto-scaler can request. When scaling up, the auto-scaler does not exceed this value.32 GBMB, GB

The following auto-scaling settings are found under Advanced Settings.

SettingDescriptionDefaultUnits
Scale IntervalThe minimum time that scaling metrics are collected before another scale operation can be initiated. Each scaling operation takes at least this long, and may take longer if backlog-based scaling is enabled.15 minmin, hr
Scale Down Max FactorThe largest magnitude by which the number of slots is scaled down, as the maximum amount of slots to remove relative to the current amount per scale-down operation.0.8N/A
Scale Up Max FactorThe largest magnitude by which the number of slots is scaled up, as the maximum amount to multiply the current amount of slots by per scale-up operation.10N/A
Scaling Effectiveness ThresholdThe amount of processing performance improvement required to consider a scaling operation effective. If the improvement exceeds the threshold, the system continues to attempt to scale. If no improvement is observed, the auto-scaler stops attempting to scale up.0.1N/A
Backlog Based Scaling EnabledWhether scaling takes the backlog of unprocessed data into account. Enable when running live streaming data. This is not desired when processing historical data, where a large backlog is expected.OffN/A
Scaling Catch Up DurationThe estimated amount of time the deployment needs to process the backlog created during a scaling operation. The auto-scaler disregards scaling metrics taken until this duration has elapsed. Shown when Backlog Based Scaling Enabled is On.30 mins, min, hr
Autoscaling Timeout DurationThe maximum amount of time a scaling operation can take to successfully restart.15 mins, min, hr

Checkpoint and Savepoint Settings​

A checkpoint is a consistent snapshot of a deployment's state, taken periodically to enable fault tolerance. If a deployment fails, it can recover and resume processing from its latest checkpoint.

SettingDescriptionDefaultUnits
Enable CheckpointsWhether checkpoints are taken. Enabling checkpoints allows the system to recover from failures and resume processing from the last successful checkpoint.OnN/A
Checkpoint IntervalThe time between the start of each checkpoint. The smaller the value, the higher the frequency.5 mins, min, hr

The following checkpoint and savepoint settings are found under Advanced Settings.

SettingDescriptionDefaultUnits
Checkpoint Timeout DurationThe maximum amount of time a checkpoint runs before timing out. Increase this value if checkpoints are failing frequently due to timeouts.30 mins, min, hr
Enable Periodic SavepointsWhether savepoints (recovery points) are created periodically, as a safeguard against failures between auto-scaling operations. Depending on how an auto-scaling operation fails, a savepoint may be required to recover. Increasing the CPUs per slot is advised if periodic savepoints are desired.OffN/A
Periodic Savepoint intervalsThe time between the start of each savepoint. The smaller the value, the higher the frequency.1 dayhr, day

Fault Tolerance Settings​

Fault tolerance settings determine the behavior of a deployment when a job failure occurs.

SettingDescriptionDefaultUnits
Restart Attempts Before FailureThe maximum number of restart attempts tolerated before the deployment fails indefinitely and remains in a failed state. Select Infinite for the deployment to never stop attempting to restart after a failure.5N/A
Restart Counter Reset ThresholdThe amount of time the deployment must run without failure for the restart attempt counter to be reset to 0. Past restart failures are then no longer counted toward the restart attempts.1 hrmin, hr

Debug Settings​

Debug settings adjust HCEP configurations for debugging purposes.

SettingDescriptionDefaultUnits
Log LevelThe logging (verbosity) level for Cogynt. ERROR is the least verbose and logs only when an error occurs, followed by WARN, INFO, DEBUG, and TRACE, which is the most verbose. Log content can be found in the Flink task manager logs, which are accessible from the Flink Dashboard.ERRORN/A
Enable Error CollectionWhether errors and warnings are detected and shown in the Issues column. Errors are runtime errors encountered in Flink that cause the deployment to fail and restart. Warnings can be data validation errors encountered in the ingested data. Disabling this setting can boost performance if the errors encountered are non-critical.OnN/A
Flame Graph EnabledWhether the Flame Graph feature in the Flink Dashboard is enabled. A flame graph is a visual representation of the execution stack and its associated time consumption, which helps identify performance bottlenecks. When enabled, select a task in the Flink Dashboard's DAG to find the Flame Graph tab.OnN/A
Flame Graph SamplesThe number of samples required to build a flame graph.100N/A
Flame Graph Refresh IntervalThe time after which available statistics are deprecated and need to be refreshed (by resampling).1 mins, min, hr
Flame Graph Stack DepthThe maximum depth of the stack traces used to create flame graphs.100N/A
Flame Graph DelayThe delay between individual stack trace samples taken to build a flame graph.50 msms, s, min

Editing Deployments​

A paused or stopped deployment's configurations can be modified as needed.

To edit a deployment's configuration:

  1. Ensure the deployment has been paused or stopped. For more information, see Terminating Deployments.
  2. In the Deployments window, click the Edit (pencil) icon for the corresponding deployment.
  3. Modify the configuration details as necessary. For more information about the various settings, see the Deployment Settings Reference.
  4. When finished, click Save to retain the changes, or Cancel to discard them.

Importing Deployments​

Exported deployments can be imported into Cogynt. This can be useful for copying deployments from one project into other projects or other Cogynt instances.

To import a deployment:

  1. On the project screen, click Deployments.
  2. In the Deployments window, beside the + New Deployment button, click v.
  3. From the available options, select Import Deployments.
  4. Locate the file on your local machine containing the deployment to import.
  5. Click and drag the file into the field in the import dialog.

Working with Deployment Templates​

Deployment templates provide a means of storing and retrieving frequently-used deployment configurations. They can make it easier and more convenient to create new deployments.

Creating Deployment Templates​

New deployment templates can be created as needed.

To create a deployment template:

  1. On the project screen, click the Settings icon.
  2. Select the Deployment Templates tab.
  3. Click + New Template.
  4. In the New Deployment Template window:
    1. In the Name field, enter a name for the deployment template.
    2. In the Description field, enter a description for the deployment template if desired.
    3. Set the Auto Scale toggle to On to enable auto-scaling. When auto-scaling is enabled, Number of Slots is replaced by Initial number of Slots and Max number of Slots, and the Auto-Scaling Settings section is shown.
    4. Configure the deployment template's settings as needed. The settings are organized into the same sections as those of a deployment, and are described in the Deployment Settings Reference.
    5. Under Custom Settings, click + NEW to add a custom setting, and specify its Config Name and Value. Remove any unnecessary custom settings by clicking the corresponding X icon.
    6. If necessary, reset all field values to their defaults during the creation process by clicking the More (⋮) menu, then selecting Reset All to Defaults.
    7. When finished, click Save to create the deployment template, or Cancel to discard it.

Once a deployment template is created, it can be applied to new deployments. For more information, see Using Deployment Templates.

Using Deployment Templates​

When creating new deployments, templates can be used in two different ways:

  • Applying settings from a template: This method fills a deployment's default values during creation with the values specified in a template. The deployment and template remain independent of one another, and one can be modified without affecting the other.
  • Creating from a template: This method creates a deployment whose values match the selected template's. It keeps the deployment tied to the selected template. Changes made to the template automatically propagate to any deployments created from it.

To apply settings from a deployment template:

  1. In the New Deployment window, click the More (⋮) menu, and select Apply Settings from Template.
  2. In the Deployment Templates window:
    1. From the Templates list, select a template to apply. You can either manually scroll through the list of available templates, or enter a name in the Search field to find particular templates by name.
    2. Review the template's settings.
    3. Click Apply to apply the deployment template, or cancel to go back to the New Deployment window without applying the template.

Once a deployment template has been applied, you are returned to the New Deployment screen, and the template's settings are applied to the new deployment.

To create a deployment from a template:

  1. Follow the procedure in Creating Deployments until Step 3.ii.
  2. Under Step 2: Deployment Configs, select the Template option button.
  3. From the Template dropdown menu, select the template to use.
  4. Resume the Creating Deployments procedure from Step 3.iii.

Configuring Data Sources​

Data sources provide data for Cogynt to interpret. In order for Cogynt to read and process the data, connections to the relevant data sources must be configured.

To configure a data source:

  1. On the project screen, click the Settings icon.
  2. Click the Data Sources tab.
  3. Click + New Data Source.
  4. In the New Data Source window:
    1. From the Data Source Type dropdown menu, select the database to serve as the data source. (Note: Different selections will enable or remove different fields in the New Data Source window.)
    2. In the Name field, enter a name for the data source.
    3. In the Description field, enter a description for the data source if desired.
    4. In the data source Configurations section:
      • If creating a Kafka, Pinot, or OpenSearch type data source:
        1. In the Host field, enter the hostname of the data source.
        2. In the Port field, enter the port number of the data source.
      • If creating a PostgreSQL or Microsoft SQL type data source:
        1. In the Host field, enter the hostname of the data source.
        2. In the Port field, enter the port number of the data source. (Microsoft SQL Server uses port 1433 by default.)
        3. In the Database field, enter the name of the database to query.
      • If creating a Pinot, OpenSearch, PostgreSQL, or Microsoft SQL type data source, enter the credentials of a user with access to the data to query:
        1. In the User Name field, enter the user name.
        2. In the Password field, enter the password. Click the eye icon to toggle whether the characters entered should be displayed or obscured on your screen.
      • If creating a HTTP type data source:
        1. In the Base URL field, enter the Base URL of the API endpoint you wish to use.
        2. In the Authorization tab, select the required Authorization Method.
        3. If using headers, in the Headers tab, click the + Add Header button to add Header and Value pairs.
        4. In the Settings tab, configure the following settings as needed:
          1. Under Request Timeout, in the Number and Unit fields, specify the maximum duration to wait for a response from a HTTP request before failure.
          2. Under Max Retries, in the Number field, specify the number of times the system shall retry a failed request before proceeding to the next request.
          3. Under Request per Minute, in the Number field, specify the maximum amount of requests per minute allowed to be made to throttle the rate of requests.
          4. Under Max Concurrent Requests, in the Number field, specify the maximum amount of requests allowed in flight in the same time.
          5. Under Enabling Caching, toggle On to enable caching of requests and responses to reduce making duplicate requests.
            1. Under Caching Priority, from the Priority Level dropdown menu, select the cache priority for the data source. The higher the priority, the higher proportion of cache resources allotted to requests made with the data source.
            2. Under Cache Time to Live, in the Number and Unit fields, specify the maximum duration a request and response should be stored in cache before it is erased. Note that cache can be erased before the specified duration to free up resources for requests from data sources with higher cache priority settings.
    5. If using an SSL/TLS connection:
      1. Select the SSL/TLS tab:
      2. Toggle Enable SSL/TLS to "On" to use an SSL/TLS connection.
      3. From the Cert Format dropdown menu, select the format of your SSL/TLS certificate.
      4. If using JKS or PKCS#12 format:
        1. In the Truststore field, click the + Select File button and upload the appropriate truststore file from your local machine.
        2. In the Truststore Password field, enter the password for your SSL/TLS truststore. Click the eye icon to toggle whether the characters entered should be displayed or obscured on your screen.

        If client-side authentication is needed:​

        1. In the Keystore field, click the + Select File button and upload the appropriate keystore file from your local machine.
        2. In the Keystore Password field, enter the password for your SSL/TLS keystore. Click the eye icon to toggle whether the characters entered should be displayed or obscured on your screen.
        3. If using JKS format:
          • In the Key Password field, enter the password for your SSL/TLS key. Click the eye icon to toggle whether the characters entered should be displayed or obscured on your screen.
      5. If using PEM format:
        1. In the CA Certificate field, click the + Select File button and upload the appropriate CA Certificate file (.pem or .crt file) from your local machine.
        2. In the Client Certificate field, click the + Select File button and upload the appropriate Client Certificate file (.pem, .crt. or .cer file) from your local machine.

        If client-side authentication is needed:​

        1. In the Client Key field, click the + Select File button and upload the appropriate Client Key file (.pem, .crt. or .cer file) from your local machine.
          • If the Client Key file is passphrase protected, in the Passphrase field, enter the passphrase for your Client Key file. Click the eye icon to toggle whether the characters entered should be displayed or obscured on your screen.
    6. Under the Custom Settings section:
      1. Click + New to add a new custom setting:
        1. In the Name field, enter the field name for the custom setting.
        2. In the Setting Value field, enter the value for the custom setting.
      2. Click the X icon beside an existing custom setting to remove it, if necessary.
    7. Click Test Connection to verify that Cogynt can connect to the data source with the configuration entered. For more information, see Testing Data Source Connections.
    8. Click Create to create the data source, or Cancel to discard it.

Data source files can also be imported by clicking the v icon beside the + New Data Source button and selecting Import Data Source.

Testing Data Source Connections​

The Test Connection button in the New Data Source and Edit Data Source windows checks whether Cogynt can reach a data source with the configuration currently entered. Testing a connection before saving the data source, and before deploying, makes it possible to troubleshoot connectivity issues early. The data source does not need to be saved to be tested, and testing does not save any changes.

To test a data source connection:

  1. In the New Data Source or Edit Data Source window, enter the data source's configuration.
  2. Click Test Connection. The button is replaced by the Testing Connection... status while the test runs.
  3. Review the result:
    • Successfully Connected: Cogynt connected to the data source with the configuration entered.
    • Connection Failed: Cogynt could not connect to the data source. A notification describes the reason for the failure. Correct the configuration and test again.
note
  • Cogynt waits up to 30 seconds for a response. If the data source does not respond in that time, the test fails and a notification reports that the test timed out.
  • The result is displayed for ten seconds, after which the Test Connection button returns. Editing any field in the window also returns the button right away, so a changed configuration always needs to be tested again.
  • Testing the connection is optional. A data source can be created or saved without a test, or after a failed test.

Connection testing is not supported for HTTP type data sources.

Default Data Sources​

Default data sources are provided by the environment and are listed in the Data Sources tab alongside any data sources you create. The data source that Cogynt uses when Default is selected as an event type's Data Source is a default data source. For more information, see Creating New Event Types.

Default data sources are protected from changes that could break the event types that rely on them:

  • The default data source always points to the internal Kafka cluster that Cogynt is pre-installed with. Its Name, Data Source Type, and connection fields cannot be edited.
  • A default data source cannot be duplicated or deleted.

The Cogynt AI (Beta) Data Source​

The Cogynt AI (Beta) data source connects a project to the LLMs that Cogynt makes available through Amazon Bedrock. It is available by default in all projects, and no host, endpoint, or credentials need to be provided to use it.

Event types that reference the Cogynt AI (Beta) data source choose which model to use and define their own prompts. For more information, see Cogynt AI Event Types.

To configure the Cogynt AI (Beta) data source:

  1. On the project screen, click the Settings icon.
  2. Click the Data Sources tab.
  3. Locate Cogynt AI (Beta) in the list and open it for editing.
  4. In the Settings tab, configure the request and caching settings as needed. These settings are the same as those for HTTP type data sources. For descriptions of each setting, see Configuring Data Sources, step 4.4.
  5. Under Custom Settings, add any additional configurations as needed.
  6. Click Save to save the changes.
note
  • The configurations set on the Cogynt AI (Beta) data source apply to all LLM usage within the project. Individual Cogynt AI event types can override the cache settings. For more information, see Cogynt AI Event Types.
  • The Name and Data Source Type of the Cogynt AI (Beta) data source cannot be edited, and the data source cannot be duplicated or deleted.
  • The models available for selection in Cogynt AI event types depend on which models an administrator has enabled in the environment.

Initiating Deployments​

Deployments must be initiated (or activated) in order to be put to use.

To initiate a deployment:

  1. In the Deployments window, locate the deployment you wish to deploy.
  2. In the corresponding row, click the More (⋮) menu.
  3. Click Deploy.

As the deployment deploys, its state changes from Not Deployed to Deploying. Then:

  • If successful, the deployment's state becomes Running.
  • If errors prevent the deployment from initiating, the state becomes Failed. For information about assessing and fixing the problem, see Addressing Issues.

Terminating Deployments​

Deployments can be stopped and taken offline as needed. This process is called "terminating" the deployment.

To terminate a deployment:

  1. In the Deployments window, locate the running deployment to terminate.
  2. In the corresponding row, click the More (⋮) menu.
  3. Click Stop.

As the deployment stops, the state of the deployment changes from Running to Stopping to Not Deployed.

If you would like the deployment to remain online but halt its functioning, click Pause instead of Stop. The deployment's state changes from Running to Pausing to Paused.

Addressing Issues​

The Deployments window provides alerts if a deployment has encountered any errors.

Viewing Issues​

Click the ! icon in the affected deployment's Issues column to see the deployment's Issues Log.

The Issues Log displays the following information about each issue:

  • Name: Provides the name (or classification) of the detected issue.
  • Last Detected Date: Shows the date and time when the issue was most recently detected.
  • Count: Shows the number of instances of the issue.
  • Issue Type: Indicates the type (severity) of the issue.

Clicking the Expand (>) icon to the left of an issue's name shows a description of the issue. Clicking the Collapse (v) icon hides the description.

To look for particular issues, enter any relevant criteria in the Search field. The list will be filtered to return matching results.

Diagnosing and Correcting Issues​

A deployment's Flink dashboard may provide additional diagnostic data about the causes of various issues. To access it, click the Flink Dashboard button in the top-right of the Issues Log window. For more information, about Flink dashboards, refer to the official Flink documentation.

To correct the deployment's configuration, click Stop & Edit in the top-right of the screen, then edit the configuration as necessary. For more information, see Editing Deployments.

Dismissing Issues​

Issues that do not need addressing can be dismissed from the Issues Log.

On the far right of an issue's row, clicking the Dismiss button removes the issue from the Issues Log.

To dismiss all issues:

  1. Click the Dismiss All button in the top-right of the Issues Log window.
  2. In the warning dialogue, click Dismiss All to dismiss all the issues, or Cancel to abandon the operation.

Customizing Ingestion Start Date/Time​

Sometimes you may need to adjust a small part of a deployment. To avoid redundant data ingestion and conserve resources, Cogynt includes a "restart" feature that lets users modify and redeploy patterns more efficiently. The feature allows users to specify the time when redeployed patterns should begin ingesting data.

To customize the ingestion start date/time:

  1. On the project screen, click Deployments.
  2. In the Deployments window, locate the deployment to edit.
  3. Click the corresponding Edit (pencil) icon.
  4. Under Step 3: Data Ingestion:
    1. Take note of the settings of the event type to restart. (It may be helpful to record the settings in a text file.)
    2. Click the X icon beside the event type to restart. (Note: This will remove the event type.)
    3. Click + Add Event Type to redefine the event type:
      1. From the Event Type dropdown menu, select the event type to filter against.
      2. From the Referenced Date Field, select the timestamp that the ingestion start date should reference (for example, Kafka Ingestion Time or COG_timestamp). WARNING: If you pick a field inside of your data and make it a filter, Cogynt will have to traverse every entry in your topic to find the time to filter against. Use Kafka Ingestion Time when you can, as it jumps to a time index inside of the message, which saves time and resources.
      3. In the Ingestion Start Date field, specify the date and time to begin ingestion.
    4. Repeat steps i-iii for each event type to restart.
  5. Click Save.

When the deployment is redeployed, the selected topics/event types will only start ingestion at the specified time(s).