feat: add opentelemetry-instrumentation-aerospike

[KimSoungRyoul]

Description

I am the original author and maintainer of the standalone library opentelemetry-instrumentation-aerospike, which is currently published on PyPI. I am contributing this library to pypi: opentelemetry-python-contrib to integrate it into the official ecosystem.

To support this integration, I volunteer to serve as the Code Owner for this component. I currently hold the ownership of the PyPI package and am ready to transfer it (or grant publish permissions) to the OpenTelemetry maintainers to facilitate automated releases.

Features

Supported Operations

---

• Single Record Operations: put, get, select, exists, remove, touch, operate, append, prepend, increment
• Batch Operations: batch_read, batch_write, batch_operate, batch_remove, batch_apply
• Query/Scan Operations: query, scan
• UDF Operations: apply, scan_apply, query_apply
• Admin Operations: truncate, info_all

Captured Telemetry Data

---

Standard Attributes:

• db.system.name: Always "aerospike".
• db.namespace: Aerospike namespace.
• db.collection.name: Aerospike set name.
• db.operation.name: The operation being performed (e.g., "GET", "PUT", "QUERY").
• db.user: The user connected to the database (if configured).
• server.address: The hostname or IP address of the Aerospike node.
• server.port: The port of the Aerospike node.
• db.operation.batch.size: Number of keys in batch operations.

Aerospike-Specific Attributes:

• db.aerospike.key: The record key (only if capture_key=True is enabled).
• db.aerospike.bins: List of bins being written or selected (for PUT/SELECT).
• db.aerospike.generation: Record generation (from GET results).
• db.aerospike.ttl: Record TTL (from GET results).
• db.aerospike.udf.module: UDF module name.
• db.aerospike.udf.function: UDF function name.

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

I have added both unit tests and functional tests (using Docker) to verify the instrumentation.

• Unit Tests (tox -e py311-test-instrumentation-aerospike): Verified span creation, attribute population (including new db.system.name, db.user, db.aerospike.bins), and context propagation for all supported operations.
• Functional Tests (tox -e docker-tests -- tests/aerospike): Verified integration with a real Aerospike server running in Docker, ensuring correct span generation and attribute values in a real-world scenario.
• Linting: Passed tox -e lint-instrumentation-aerospike (pylint score 10.00/10).

Does This PR Require a Core Repo Change?

• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[github-actions]

This PR has been automatically marked as stale because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 days of this comment.
If you're still working on this, please add a comment or push new commits.

[KimSoungRyoul]

Hi @tammy-baylis-swi,

I noticed this PR has been inactive for a while, so I wanted to leave a note with some context and updates.

First, I very much agree with Aaron Abbott's suggestion (via Slack#otel-python) that the ideal approach would be native instrumentation built into the official Aerospike client. That would provide the best out-of-the-box experience and keep telemetry perfectly in sync with client updates.

However, based on the current state of the Aerospike Python client project, this is unfortunately not a realistic path at the moment. The Aerospike team's priority is focused on performance and the new async Rust-binding-based client (aerospike/aerospike-client-python#263 (comment)), and features like OpenTelemetry support are not on their near-term roadmap. I also opened aerospike/aerospike-client-python#945 to propose native instrumentation, but there has been no response yet. Given this situation, contributing native OTel instrumentation directly to aerospike-client-python seems difficult for the foreseeable future.

In the meantime, I have been actively maintaining this instrumentation and would like to continue doing so as part of the official contrib repository. For reference, I am the organizer of aerospike-py, an open-source project in the Aerospike community ecosystem. While it is still in its early stages, I am continuously improving it. If there are any concerns about my ability to maintain the opentelemetry-instrumentation-aerospike component long-term, I hope this project can serve as a reference for your review.

I have also rebased this PR onto the latest main to resolve all merge conflicts and updated the version references to 0.63b0.dev.

I would appreciate any feedback or guidance on how to move this forward. Thank you for your time!