[Security Solution] Siem migrations UI telemetry

[semd]

Summary

Created a telemetry client with all SIEM migration telemetry events.
And added the calls to track them

New events

SetupConnectorSelected {
  connectorType: string;
  connectorId: string;
}

SetupMigrationOpenNew {
  isFirstMigration: boolean;
}

SetupMigrationOpenResources {
  migrationId: string;
  missingResourcesCount: number;
}

SetupRulesQueryCopied {
  migrationId?: string;
}

SetupMigrationCreated {
  migrationId?: string;
  rulesCount: number;
  result: 'success' | 'failed';
  errorMessage?: string;
}

SetupMacrosQueryCopied {
  migrationId: string;
}

SetupLookupNameCopied {
  migrationId: string;
}

SetupResourcesUploaded {
  migrationId: string;
  type: 'macro' | 'lookup';
  count: number;
  result: 'success' | 'failed';
  errorMessage?: string;
}

StartTranslation {
  migrationId: string;
  connectorId: string;
  isRetry: boolean;
  retryFilter?: 'failed' | 'not_fully_translated';
  result: 'success' | 'failed';
  errorMessage?: string;
}

Existing events (Translated rules actions):

Also integrated into the telemetry client

TranslatedRuleUpdate {
  migrationId: string;
  ruleMigrationId: string;
}

TranslatedRuleInstall {
  migrationId: string;
  ruleMigrationId: string;
  author: 'elastic' | 'custom';
  enabled: boolean;
  prebuiltRule?: {
    id: string;
    title: string;
  };
}

TranslatedRuleBulkInstall {
  migrationId: string;
  enabled: boolean;
  count: number;
}

[elasticmachine]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[michaelolo24]

As an aside, just realized we have no way of identifying if we have naming collisions in the telemetry event types. It shouldn't really ever happen since the naming is pretty well isolated, but in the future may be worth adding some check for that

[semd]

I added the test here 671771f

[michaelolo24]

Just confirming you want the batch processing to stop in the event of an error, rather than just moving on to the next batch?

[semd]

Yes, I think that's fine for now. Since the migrationId is passed back to the API once the first batch is created, I decided it's better to stop if there's an error, to avoid creating multiple migrations if something goes wrong.
We can improve this error handling later though.

[michaelolo24]

nit, consider raising the logic here out of reportEvent

const prebuiltRuleConfig = { author: 'elastic' };
if (elasticRule?.prebuilt_rule_id) {
 prebuiltRuleConfig.author = 'custom';
 prebuiltRuleConfig.prebuiltRule = { id: elasticRule.prebuilt_rule_id, title: elasticRule.title };
 }
 ...
 {
   ...prebuiltRuleConfig
 }

[semd]

done here 671771f

[michaelolo24]

Thanks for adding the telemetry!

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 8c68d69

Failed CI Steps

• Serverless Rule Management - Prebuilt Rules - Security Solution Cypress Tests #1

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	6695	6696	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	21.4MB	21.4MB	+3.1KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
securitySolution	88.7KB	92.3KB	+3.6KB

History

• 💛 Build #274237 was flaky d4edcf2
• 💔 Build #274095 failed 59aae05

cc @semd

[kibanamachine]

Starting backport for target branches: 8.18, 8.x, 9.0

https://github.com/elastic/kibana/actions/runs/13244014330

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.18
✅	8.x
✅	9.0

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation