Added Vertex AI instrumentation #3069

aabmass · 2024-12-05T18:07:28Z

Description

Part of #3041

Adds vertexai instrumentation with updates to match the latest semantic conventions.

Type of change

Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
This change requires a documentation update

How Has This Been Tested?

Added some new Cassette tests with a lot of sanitization logic which seems to work.

Does This PR Require a Core Repo Change?

Yes. - Link to PR:
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

codefromthecrypt

glad to see this! I have some initial comments which are basically an effort to conserve time.

If the first PR has basically exactly the same tests, readme and examples that are in openai, we have less to talk about which means less latency in getting this merged.

Afterwards, we can build on it to additionally add vision model etc. Meanwhile, please keep tests and fixtures exactly the same except for obvious s/openai/vertexai and library invocation differences. Then, if you can self-review highlighting parts unique to vertex for the next person.

Hope this guidance helps!

...pentelemetry-instrumentation-vertexai-v2/tests/cassettes/test_vertexai_generate_content.yaml

codefromthecrypt · 2024-12-05T23:44:48Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/tests/conftest.py

+@pytest.fixture(autouse=True)
+def vertexai_init(vcr: VCR) -> None:
+    # Unfortunately I couldn't find a nice way to globally reset the global_config for each
+    # test because different vertex submodules reference the global instance directly


mind opening a github issue on this in the google project, so we can link it and click there to see the details?

To be clear this isn't a bug or anything. It's just difficult to monkey patch. This more of a note to self during development, I'd prefer to remove this comment as it's a bit distracting

codefromthecrypt · 2024-12-05T23:45:54Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/tests/test_gemini.py

+
+
+@pytest.mark.vcr
+def test_vertexai_generate_content(exporter):


maybe start with plain chat tests from openai (just convert them) I think vision/multi-modal could be better discussed in aggregate across the two?

Will update tomorrow

codefromthecrypt · 2024-12-05T23:46:51Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/example/main.py

+import vertexai
+from vertexai.generative_models import GenerativeModel
+
+vertexai.init(location="us-central1")


can this be set via ENV in the normal client? It would be nicer to adjust .env vs edit the source

I think i can actually just remove location and allow the the Vertex SDK to decide. That would be even less distracting.

For example program, I think we can keep those values as hardcoded?

codefromthecrypt · 2024-12-05T23:47:54Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/example/main.py

+
+vertexai.init(location="us-central1")
+
+model = GenerativeModel("gemini-1.5-flash-002")


similar can you use an ENV? even better to basically copy the openai example word for word then adjust the library calls etc. This reduces the amount of attention needed to land your change vs having differences in setup and also library https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/instrumentation-genai/opentelemetry-instrumentation-openai-v2/examples/zero-code/main.py#L9

I actually copied this directly from the Vertex quickstart. I can try adapt it to be the same as the OpenAI sample

aabmass

Thanks for the review @codefromthecrypt. Before you do a full review (I'll mark the PR as not draft), I know this PR is big with a lot of boilerplate and copied code from openllmetry package. I could split it into multiple PRs so we don't need to bikeshed on code from openllmetry and can rather just review the changes. Wdyt?

All the tests were disabled in openllmetry so I'd like to get test coverage up before doing any serious refactoring.

aabmass · 2024-12-06T04:34:28Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/example/main.py

+
+vertexai.init(location="us-central1")
+
+model = GenerativeModel("gemini-1.5-flash-002")


I actually copied this directly from the Vertex quickstart. I can try adapt it to be the same as the OpenAI sample

aabmass · 2024-12-06T04:36:13Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/example/main.py

+import vertexai
+from vertexai.generative_models import GenerativeModel
+
+vertexai.init(location="us-central1")


I think i can actually just remove location and allow the the Vertex SDK to decide. That would be even less distracting.

...pentelemetry-instrumentation-vertexai-v2/tests/cassettes/test_vertexai_generate_content.yaml

aabmass · 2024-12-06T05:15:04Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/tests/conftest.py

+@pytest.fixture(autouse=True)
+def vertexai_init(vcr: VCR) -> None:
+    # Unfortunately I couldn't find a nice way to globally reset the global_config for each
+    # test because different vertex submodules reference the global instance directly


To be clear this isn't a bug or anything. It's just difficult to monkey patch. This more of a note to self during development, I'd prefer to remove this comment as it's a bit distracting

aabmass · 2024-12-06T05:18:57Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/tests/test_gemini.py

+
+
+@pytest.mark.vcr
+def test_vertexai_generate_content(exporter):


Will update tomorrow

codefromthecrypt · 2024-12-06T05:52:29Z

@aabmass since the code style, conventions, semver, approach to handling events etc are very different in openllmetry vs how openai is instrumented, still suggest to start with how openai is done here and adapt vertexai vs the other way. That's just my opinion considering how many review comments may result from doing otherwise. You choose!

gyliu513 · 2024-12-06T14:06:34Z

@lmolkova @lzchen @nirga @karthikscale3 @alizenhom I can see we have different coding pattern and file layout for instrumentation from different repos

https://github.com/traceloop/openllmetry/tree/main/packages this is from traceloop/openllmetry.
https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation-genai/opentelemetry-instrumentation-openai-v2 This is contributed by langtrace, and using langtrace coding pattern and file layout.
Now the Vertex AI is from openllmetry, using openllmetry format and file layout.

Shall we reach to an agreement for the coding pattern and file layout, filing naming style etc. in this early stage? Thanks!

aabmass · 2024-12-06T16:39:08Z

Now the Vertex AI is from openllmetry, using openllmetry format and file layout.

@gyliu513 I actually think everything in this draft PR is matching the format and file layout of this repo. Is there something in particular that's different?

aabmass · 2024-12-06T16:44:11Z

Taking a step back, can we agree on a step by step process of migrating a package into this repo from openllmetry? As a reviewer it is easier to review PRs that are focused. I think it might be easier to have folks first send a PR copying the code in without any significant changes. Then they can send smaller focused PRs (a PR to get CI running with tox, then a PR migrating to events, etc.) to bring them up to repo style.

There are 26 instrumentations in openllmetry to migrate, and it seems daunting to review a full rewrite for each one.

I can write a proposal for this on an issue if folks would be interested.

gyliu513 · 2024-12-06T17:08:21Z

@aabmass I totally agree with you, based on the comments from yesterday's discussion, I think @nirga is going to share some migration plan soon.

The first instrumentation for OpenAI is from https://github.com/Scale3-Labs/langtrace-python-sdk/tree/main/src/langtrace_python_sdk/instrumentation/openai , and it has different code style compared with existing traceloop/openllmetry instrumentation code, that's my concern.

aabmass · 2024-12-06T17:26:01Z

The first instrumentation for OpenAI is from https://github.com/Scale3-Labs/langtrace-python-sdk/tree/main/src/langtrace_python_sdk/instrumentation/openai

Ah thanks I didn't know this came from langtrace.

and it has different code style compared with existing traceloop/openllmetry instrumentation code, that's my concern.

any specific differences you would like to call out? IMO it's OK for the structure to be different

xrmx · 2024-12-06T17:28:06Z

Taking a step back, can we agree on a step by step process of migrating a package into this repo from openllmetry? As a reviewer it is easier to review PRs that are focused. I think it might be easier to have folks first send a PR copying the code in without any significant changes. Then they can send smaller focused PRs (a PR to get CI running with tox, then a PR migrating to events, etc.) to bring them up to repo style.

There are 26 instrumentations in openllmetry to migrate, and it seems daunting to review a full rewrite for each one.

It really depends on the library to trace I guess, haven't looked at vertex ai but for openai it was splitted like this:

sync chat client
streaming chat
async chat
events
metrics (TODO)

So I would do more or less the same for others too. Maybe we can add a first step adding only the instrumentor class with the tox and workflows to remove some boilerplate for later.

gyliu513 · 2024-12-06T18:08:25Z

any specific differences you would like to call out? IMO it's OK for the structure to be different

@aabmass please take a look at the __init__.py for langtrace and traceloop for instrumention code, traceloop init file contain all functions that needs to be instrumented, and the major instrumentataion logic is also there. Langtrace is using a file named as patch.py to instrument the code, this is not a big deal, but I prefer we should keep same pattern for all instrumentation code here.

Having same code pattern, coding format, style etc. can help future contribution as well.

aabmass · 2024-12-07T17:48:14Z

@gyliu513 I see what you mean. I want to call out that there are already 51 instrumentation packages in this repo, with lots of different patterns and idioms. The techniques used for GenAI instrumentation are not really that different and we still don't have a consensus on how to instrument.

So my preference here is more practical–I think we should lean on existing implementations (langtrace, openllmetry, etc.) and not make updating to the openai-v2 idioms a blocker to initial inclusion. If we can agree to "trust" the existing implementations we are starting with, it will cut down on a lot of review. Once the package is in, we can split up the work and send small focused PRs.

codefromthecrypt · 2024-12-09T00:42:00Z

TL'DR' Ultimately, if the maintainers of this project are happy with intentional anchoring towards external repos, that's ok with me. Just it is more work to maintain change that crossed multiple projects and there will be a lot of that. So, just be conscious and meanwhile glad to see folks joining and I'll help regardless.

FWIW, my main concern is at least the tests are the same as how we do them in openai-v2, as for example, this helps with things openllmetry doesn't yet do, like content capturing into logs.

The openai-v2 code had a lot of diverse feedback, folks from openllemetry, developing alternatives, as well folks not using openai but experts at this repo.

I believe it is helpful to look at that work in openai-v2, but even having many more people involved, it is indeed not a pure consensus (no code is with an unbounded group).

I strongly believe in house rules. This is not the openllmetry project, this is opentelemetry contrib. We should try our best to follow what the maintainers here have approved, and not intentionally deviate in style or structure. This makes maintenance so much easier especially staring down many potential refactors in the future.

If I've not convinced, that's fine, but thanks for reading!

codefromthecrypt · 2024-12-09T00:45:21Z

Another thing I will mention is that the authors of "openai-v2" were subject to a higher bar in review. They weren't told to skip steps in the process of review for convenience of making it similar to their original source. While we aren't talking about fairness, I think knowing that we are following a different model now is important. Fast and fix later vs get in in a shape we want.

cc @lmolkova as if this is the case, we should probably appoint zookeepers to go back and fix the new packages once merged. I'm ok doing that.

codefromthecrypt · 2024-12-09T02:26:27Z

can we agree on a step by step process of migrating a package into this repo from openllmetry?

With many vendors involved and the first LLM providers PRs not authored by openllmetry, rather by different folks, with openllmetry also contributing, this begs some Q&A:

Can we assume new providers mean copying from openllmetry?

Not so far, but if it helps someone can make a gist about when things are inspired by openllmetry, what are the steps? sounds helpful!

Can we assume we can copy paste any vendor's code?

Likely, by the time things complete the code is different than whatever you might start with. Resisting copy/paste of anything not merged here. So, starting small from scratch, is a good way to avoid requiring license NOTICE headers forever.

I started a google doc that isn't yet and may never be sanctioned by this group. I want to emphasize that there are several active, code contributing vendors who also have many of the same instrumentation. The process of merging openai-v2 was the first time multiple folks got together and agreed on a style. That is a moving target as more features are added. The main point is, let's please not assume there is one source project that code comes from, as so far that hasn't been the case.

https://docs.google.com/document/d/16KLUHUUXKyNmpE8Vt9VFcJTiCcYd6AckL222b_DujAU/edit?tab=t.0

gyliu513 · 2024-12-12T18:31:38Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/example/main.py

+import vertexai
+from vertexai.generative_models import GenerativeModel
+
+vertexai.init(location="us-central1")


For example program, I think we can keep those values as hardcoded?

gyliu513 · 2024-12-12T19:11:00Z

...emetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/__init__.py

+
+
+def should_send_prompts():
+    # Previously was opt-in by the following check for privacy reasons:


openai is using parameter as this to control https://github.com/open-telemetry/opentelemetry-python-contrib/blob/main/instrumentation-genai/opentelemetry-instrumentation-openai-v2/src/opentelemetry/instrumentation/openai_v2/utils.py#L39-L42

@aabmass FYI, @lzchen is building some common utiles to help this https://github.com/open-telemetry/opentelemetry-python-contrib/pull/3081/files#diff-cebc2e35b4637202a2226845d87b5093dff75151a31c30000201327be64e6cf0

gyliu513 · 2024-12-12T19:13:47Z

...emetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/__init__.py

+        # https://github.com/traceloop/openllmetry/blob/v0.33.12/packages/opentelemetry-instrumentation-vertexai/opentelemetry/instrumentation/vertexai/__init__.py#L141-L143
+        # I guess prompt may be in kwargs instead or in addition?
+        prompt = kwargs.get("prompt")
+        if prompt:


why did we handle prompt twice here? Another one is in Line 165

I added a comment, was wondering the same thing lol hoping to get clarity from TraceLoop folks who originally wrote this code.

@aabmass @gyliu513 it's to support the original language_models API:
https://cloud.google.com/vertex-ai/generative-ai/docs/reference/python/latest/vertexai.language_models.TextGenerationModel#vertexai_language_models_TextGenerationModel_predict

nirga · 2024-12-13T10:55:50Z

@aabmass @codefromthecrypt @gyliu513 @xrmx my 2c for the discussion around structure above -
the structure of code in OpenLLMetry was actually the one we saw commonly used across instrumentations in this repo - where most instrumentation code is just in the __init__.py file (see boto3, Elasticsearch, Kafka, MySQL as some random examples I've picked up). So I think the OpenAI instrumentation we approved is the exception, not the rule.

lmolkova · 2024-12-13T22:34:56Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/tests/test_gemini.py

+        "gen_ai.system": "vertex_ai",
+        "gen_ai.operation.name": "text_completion",
+        "gen_ai.request.model": "gemini-pro-vision",
+        "gen_ai.response.model": "gemini-pro-vision",


is it always the case that vertex request and response model are the same? If so, we should probably clarify semconv and only populate the request model in this case. WDYT?

lmolkova · 2024-12-13T22:37:47Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/example/.env

@@ -0,0 +1,10 @@
+OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
+OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
+OTEL_SERVICE_NAME=opentelemetry-python-openai


nit

Suggested change

OTEL_SERVICE_NAME=opentelemetry-python-openai

OTEL_SERVICE_NAME=opentelemetry-python-vertex

lmolkova · 2024-12-13T22:38:52Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/example/.env

+# Change to 'false' to disable logging
+OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED=true
+# Change to 'console' if your OTLP endpoint doesn't support logs
+OTEL_LOGS_EXPORTER=otlp_proto_http


nit:

any reason to not use defaults?
openai example does this now

opentelemetry-python-contrib/instrumentation-genai/opentelemetry-instrumentation-openai-v2/examples/manual/.env

Lines 9 to 12 in 5dfe192

# Uncomment and change to your OTLP endpoint

# OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

# OTEL_EXPORTER_OTLP_PROTOCOL=grpc

lmolkova · 2024-12-13T22:55:11Z

...emetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/__init__.py

+        span, event_logger, llm_model, complete_response, token_usage
+    )
+
+    span.set_status(Status(StatusCode.OK))


we don't set span status in instrumentations to OK - only to ERROR if there is an error. In general case we don't know what constitutes a success.

https://github.com/open-telemetry/opentelemetry-specification/blob/b9b6d8f698f82cd321fbe4fcc15b76d49902c14e/specification/trace/api.md?plain=1#L611

lmolkova · 2024-12-13T22:56:18Z

...emetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/__init__.py

+):
+    complete_response = ""
+    token_usage = None
+    async for item in response:


is there a way to know if response terminates due to an error? we should try to catch it and record an error.

lmolkova · 2024-12-13T22:56:25Z

...emetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/__init__.py

+        span, event_logger, llm_model, complete_response, token_usage
+    )
+
+    span.set_status(Status(StatusCode.OK))


Suggested change

span.set_status(Status(StatusCode.OK))

lmolkova · 2024-12-13T22:56:38Z

...emetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/__init__.py

+            response.usage_metadata,
+        )
+
+        span.set_status(Status(StatusCode.OK))


Suggested change

span.set_status(Status(StatusCode.OK))

lmolkova · 2024-12-13T22:57:25Z

...emetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/__init__.py

+        return await wrapped(*args, **kwargs)
+
+    llm_model = "unknown"
+    if hasattr(instance, "_model_id"):


it seems like a slippery slope to rely on internal APIs, is there some way we can avoid it?

lmolkova · 2024-12-13T22:58:19Z

...emetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/__init__.py

+        **kwargs,
+    ):
+        tracer = get_tracer(
+            __name__, __version__, tracer_provider=tracer_provider


let's add schema_url - that's important for consumers to know which version is being emitted.

lmolkova · 2024-12-13T22:58:34Z

...emetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/__init__.py

+        event_logger = get_event_logger(
+            __name__,
+            version=__version__,
+            event_logger_provider=event_logger_provider,


please add schema_url here too

lmolkova · 2024-12-13T22:59:41Z

...elemetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/events.py

+def user_event(
+    *,
+    gen_ai_system: str,
+    # TODO: should I just leave role out since it's not required if "user"


yeah, I don't see why it'd be necessary in the event body given it's already in the name.

lmolkova · 2024-12-13T23:00:40Z

...elemetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/events.py

+        },
+        body={
+            "role": role,
+            "content": content,


do we record content only if it's enabled?

lmolkova · 2024-12-13T23:01:08Z

...lemetry-instrumentation-vertexai-v2/src/opentelemetry/instrumentation/vertexai_v2/version.py

+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+__version__ = "2.1b0.dev"


why not "2.0b0?

lmolkova · 2024-12-13T23:25:05Z

From my perspective what's important (in descending order):

Having consistent user-facing parts (APIs, examples). Consistency with the instrumented library examples is more important than consistency between different genai instrumentation libs.
Providing coherent telemetry from instrumentations following otel semconv
Making it easy for folks to contribute new and maintain old things
Test coverage and testing edge cases

All of this things are fixable while libs are not stable. It's definitely easier to maintain any of these libraries if they follow the same patterns and layout, but it not should be a hard requirement.

I think we can move faster if reviewers would point to specific discrepancies if they see them and maybe we can create a template with all the boilerplate someone would copy when they contribute new instrumentation.

Talking about copy-paste:

CNCF policies allow it as long as license of the other project permits it and with appropriate attribution
- https://github.com/cncf/foundation/blob/main/recommendations-for-attribution.md
- https://github.com/cncf/foundation/blob/main/license-notices.md#reusing-content-from-part-of-a-file-from-another-project
Vendors may consider donating their code to OTel following the donation process and in this case, we won't need any attributions.

I'm not aware of any repos in OTel that prohibit legal copy-paste and I don't see why this repo should.

lmolkova · 2024-12-13T23:55:19Z

instrumentation-genai/opentelemetry-instrumentation-vertexai-v2/pyproject.toml

+build-backend = "hatchling.build"
+
+[project]
+name = "opentelemetry-instrumentation-vertexai-v2"


I believe this package will have feature parity with https://github.com/traceloop/openllmetry/blob/main/packages/opentelemetry-instrumentation-vertexai/

I think we should publish it as opentelemetry-instrumentation-vertexai

@nirga what would be your thoughts on this?

In particular, OTel can start publishing to v1 (or v2) train and OpenLLMetry can still continue v0 train if necessary.

codefromthecrypt · 2024-12-16T02:37:24Z

On if we should copy paste, I wrote this

This is also what I meant by writing "So, starting small from scratch, is a good way to avoid requiring license NOTICE headers forever."

To answer that, @lmolkova clarified we don't mind copy/pasting and pointed a document describing what to do about it

For example this sort of NOTICE entry or similar:

# The foo() function was copied from Project XYZ, and is
# provided here subject to the following:
# [copyright notice]
# [license notice]

Since I gather at this point, the genai team are happy with copy/pasting, next step is to attribute copy/pasted parts back to openllmetry either file by file, a NOTICE in the package root or something else. A soft agreement in the PR comments won't be visible to those using this package, so I think a file change is needed.

@lzchen @xrmx since this is ultimately a python repository and you are maintainers, what should be done here? I didn't see any NOTICE files, so it isn't quite clear in this specific repo the way out?

aabmass added 10 commits December 5, 2024 17:47

Add VertexAI instrumentation boilerplate

aa9e148

Copy in files from openllmetry

6081d3a

Add OTel copyright headers

d36bfee

Run ruff

623038d

tox.ini boilerplate

79214d5

Update span attribute semconv besides events

15d14f9

Working with events

034dc7d

Remove _with_tracer_wrapper in favor of partial

4551c88

Working sanitized VCR for tests, but missing some assertions

6ddf7e2

tox -e generate-workflows

88fd4bc

aabmass changed the title ~~Vertexai~~ Added Vertex AI instrumentation Dec 5, 2024

github-actions bot assigned codefromthecrypt, gyliu513, karthikscale3, lmolkova, lzchen and nirga Dec 5, 2024

aabmass added 3 commits December 5, 2024 19:33

Fix requirements to work with python 3.8

069e808

generate and lint

b87ab01

Remove placeholder/disabled tests and fix lint

858c23a

aabmass force-pushed the vertexai branch from 58fec0c to ac9d404 Compare December 5, 2024 21:51

codefromthecrypt reviewed Dec 5, 2024

View reviewed changes

try to get CI passing

6a8878d

aabmass force-pushed the vertexai branch from ac9d404 to 6a8878d Compare December 6, 2024 00:40

aabmass added 2 commits December 6, 2024 03:58

Disable pypy since shapely fails to compile its native extension

b25a9e4

Pretty format yaml cassettes

5dfe192

aabmass commented Dec 6, 2024

View reviewed changes

gyliu513 reviewed Dec 12, 2024

View reviewed changes

lmolkova reviewed Dec 13, 2024

View reviewed changes



		@pytest.mark.vcr
		def test_vertexai_generate_content(exporter):


		vertexai.init(location="us-central1")

		model = GenerativeModel("gemini-1.5-flash-002")



		def should_send_prompts():
		# Previously was opt-in by the following check for privacy reasons:

	OTEL_SERVICE_NAME=opentelemetry-python-openai
	OTEL_SERVICE_NAME=opentelemetry-python-vertex

	# Uncomment and change to your OTLP endpoint
	# OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
	# OTEL_EXPORTER_OTLP_PROTOCOL=grpc

Added Vertex AI instrumentation #3069

Are you sure you want to change the base?

Added Vertex AI instrumentation #3069

Conversation

aabmass commented Dec 5, 2024

Description

Type of change

How Has This Been Tested?

Does This PR Require a Core Repo Change?

Checklist:

codefromthecrypt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aabmass left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codefromthecrypt commented Dec 6, 2024

gyliu513 commented Dec 6, 2024

aabmass commented Dec 6, 2024

aabmass commented Dec 6, 2024

gyliu513 commented Dec 6, 2024

aabmass commented Dec 6, 2024

xrmx commented Dec 6, 2024 • edited Loading

gyliu513 commented Dec 6, 2024

aabmass commented Dec 7, 2024

codefromthecrypt commented Dec 9, 2024

codefromthecrypt commented Dec 9, 2024

codefromthecrypt commented Dec 9, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nirga Dec 13, 2024 • edited Loading

Choose a reason for hiding this comment

nirga commented Dec 13, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lmolkova commented Dec 13, 2024 • edited Loading

Choose a reason for hiding this comment

codefromthecrypt commented Dec 16, 2024 • edited Loading

xrmx commented Dec 6, 2024 •

edited

Loading

codefromthecrypt commented Dec 9, 2024 •

edited

Loading

nirga Dec 13, 2024 •

edited

Loading

lmolkova commented Dec 13, 2024 •

edited

Loading

codefromthecrypt commented Dec 16, 2024 •

edited

Loading