Add stats tracking for semantic highlighting

[junqiu-lei]

Description

Add stats tracking for semantic highlighting:

• semantic_highlighting.semantic_highlighting_request_count: total semantic highlighting request count.

Stats response example:

{
        ......
	"all_nodes": {
		"semantic_highlighting": {
			"semantic_highlighting_request_count": 4
		},
		"processors": {
			"ingest": {
				"text_chunking_executions": 0,
				"text_embedding_executions": 2,
				"text_chunking_fixed_length_executions": 0,
				"text_chunking_delimiter_executions": 0
			}
		}
	},
	"nodes": {
		"T8ecJ133T0ywVhuPg3NPcQ": {
			"semantic_highlighting": {
				"semantic_highlighting_request_count": 4
			},
			"processors": {
				"ingest": {
					"text_chunking_executions": 0,
					"text_embedding_executions": 2,
					"text_chunking_fixed_length_executions": 0,
					"text_chunking_delimiter_executions": 0
				}
			}
		}
	}
}

Related Issues

Follow up #1182

Check List

• New functionality includes testing.
• New functionality has been documented.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff.
• Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[q-andy]

We should rename the stat names to semantic_highlighting_request_count and semantic_highlighting_error_count. The stat name is used as a unique identifier across all stats without the path. Maybe also shorten the path from semantic_highlighting -> highlighting?

[junqiu-lei]

We should rename the stat names to semantic_highlighting_request_count and semantic_highlighting_error_count.

It can make the full path redundant in naming.

The EventStatName class already has a getFullPath() method that combines the path and name with a dot (e.g., semantic_highlighting.request_count), which seems like a more robust way to handle uniqueness?

The stat name is used as a unique identifier across all stats without the path. Maybe also shorten the path from semantic_highlighting -> highlighting?

I prefer to keep using with semantic_highlighting which is consistent with the origin feature name.

[junqiu-lei]

Offline talked with @q-andy, the stats filter is being used along with child stats name, like semantic_highlighting_request_count , this function is introduced since 3.0.0 OpenSearch. To keep the function same and backward compatibility, we'll use name semantic_highlighting_request_count and semantic_highlighting_error_count.

[q-andy]

lgtm, thanks!

[heemin32]

Is it necessary to correct the error count? The primary purpose of this stats API is to track adoption metrics or current state of the cluster. As for the error count, it's unclear whether any specific actions would be taken even if the number increases.

[junqiu-lei]

Is it necessary to correct the error count? The primary purpose of this stats API is to track adoption metrics or current state of the cluster. As for the error count, it's unclear whether any specific actions would be taken even if the number increases.

@heemin32 Removed error cont metrics. Initially wanted to use the error metrics for debug purpose, but agree the primary purpose is to track adoption metrics.

[heemin32]

Is it necessary to correct the error count? The primary purpose of this stats API is to track adoption metrics or current state of the cluster. As for the error count, it's unclear whether any specific actions would be taken even if the number increases.

@heemin32 Removed error cont metrics. Initially wanted to use the error metrics for debug purpose, but agree the primary purpose is to track adoption metrics.

Thanks. Please update the PR description as well.

[q-andy]

Do you think we may add more non-semantic highlighter, but still highlighter related features in the future? Maybe having the path be highlighter.stat_name instead of semantic_highlighter.stat_name would give us a shared path to put possible future highlighter stats too, and reduce redundancy

[junqiu-lei]

Do you think we may add more non-semantic highlighter, but still highlighter related features in the future? Maybe having the path be highlighter.stat_name instead of semantic_highlighter.stat_name would give us a shared path to put possible future highlighter stats too, and reduce redundancy

In neural plugin, I think we'll just have the semantic highlighter to use, we would increase feature related stats inside it. highlighter would confuse why we don't have other existing highlighters stats inside it.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 0.00%. Comparing base (33b399b) to head (875b659).
Report is 2 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #1327       +/-   ##
============================================
- Coverage     82.64%       0   -82.65%     
============================================
  Files           149       0      -149     
  Lines          7242       0     -7242     
  Branches       1163       0     -1163     
============================================
- Hits           5985       0     -5985     
+ Misses          808       0      -808     
+ Partials        449       0      -449     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.