From 9d359e7f3cffc06acbdd281baff10c47b4acb82d Mon Sep 17 00:00:00 2001 From: Reese Lee Date: Fri, 31 Mar 2023 07:02:06 -0700 Subject: [PATCH 1/4] End user discussion summary for March (#2560) Co-authored-by: Adriana Villela <50256412+avillela@users.noreply.github.com> Co-authored-by: Patrice Chalin Co-authored-by: Patrice Chalin --- .../en/blog/2023/end-user-discussions-03.md | 287 ++++++++++++++++++ static/refcache.json | 28 ++ 2 files changed, 315 insertions(+) create mode 100644 content/en/blog/2023/end-user-discussions-03.md diff --git a/content/en/blog/2023/end-user-discussions-03.md b/content/en/blog/2023/end-user-discussions-03.md new file mode 100644 index 000000000000..101e7b339402 --- /dev/null +++ b/content/en/blog/2023/end-user-discussions-03.md @@ -0,0 +1,287 @@ +--- +title: OpenTelemetry End-User Discussions Summary for March 2023 +linkTitle: End-User Discussions Mar 2023 +date: 2023-03-30 +author: '[Reese Lee](https://github.com/reese-lee) (New Relic)' +body_class: otel-with-contributions-from +--- + +With contributions from [Henrik Rexed](https://github.com/henrikrexed) +(Dynatrace), [Michael Hausenblas](https://github.com/mhausenblas) (AWS), +[Rynn Mancuso](https://github.com/musingvirtual) (Honeycomb), +[Adriana Villela](https://github.com/avillela) (Lightstep), and +[Pranay Prateek](https://github.com/pranay01) (SigNoz). + +The OpenTelemetry end-user group meet takes place every month for users in the +Americas (AMER), Europe Middle-East & Africa (EMEA), and Asia-Pacific (APAC). + +The discussions take place using a +[Lean Coffee format](https://agilecoffee.com/leancoffee/), whereby folks are +invited to post their topics to the +[Agile Coffee board like this one](http://agile.coffee/#3716060f-183a-4966-8da4-60daab2842c4), +and everyone in attendance votes on what they want to talk about. + +## What we talked about + +Sampling and collector capabilities continue to be topics of interest, along +with questions about instrumentation and adoption. + +## Discussion Highlights + +Below is the summary of this month's discussions. + +### OpenTelemetry Collector + +#### 1 - Losing gRPC with Azure App Services + +**Q:** When looking at the hosting models in Azure for the OTel Collector, only +HTTP is supported (for running in Azure App Service). What are the risks +associated with losing gRPC capability? + +**A:** If HTTP2 is supported in Azure, gRPC might work there, since gRPC is HTTP +under the hood with extra complications built on top of HTTP2. One suggestion is +to follow up with Microsoft about gRPC support, as it may have very long-running +connections. + +#### 2 - Uptime monitoring/synthetics + +**Q:** Does the OTel Collector have the capability to do uptime monitoring/ +synthetics? If not, are there any plans to work towards such a thing? + +**A:** The +[health check](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/extension/healthcheckextension/README.md) +might be a helpful reference. Also check out the +[http check receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/extension/healthcheckextension/README.md). + +#### 3 - Collector distributions + +**Q:** Should I use a vendor distribution versus the community collector +distribution? + +**A:** Each vendor distribution will come with customizations, whereas the +community Collector distribution will include everything: receivers and +exporters. If you need the flexibility, then you should use the OTel Collector +distro. + +#### 4 - Rate limiting on receivers + +**Q:** Are there any plans for enabling rate limiting and circuit breaks on +receivers? Imagine having lots of clients sending telemetry to the same set of +OTel collectors. + +**More context**: How do I rate-limit in a situation where I have collectors for +traces, metrics, and logs, and I’m receiving traffic from more than 100 +individual apps? If I have even one customer who is generating heavy traffic, it +might impact the overall health of my collectors. + +**A:** Use a reverse proxy. Something to note is that once the data is inside +the collector, the data is already being deserialized, and you’ve already +started firehosing the collector, so it’s a bit late to rate limit at that +point. One approach might be to add additional headers when you configure your +SDKs that contain the additional information, which would help with load +balancing. + +#### 5 - Connectors + +**Q:** What is a connector? + +**A:** A connector is a collector component that consumes telemetry signals as +an exporter in one pipeline, and emits it as a receiver in another pipeline. +[Read more here](https://o11y.news/2023-03-13/#opentelemetry-connectors). + +#### 6 - Definitions of upstream, downstream, and distro + +**Q:** What is upstream? Downstream? Distro? + +**A:** The terms "upstream" and "downstream" refer to how services or components +in a system are connected to each other. Check out +[this article](https://reflectoring.io/upstream-downstream/) for more +information as it applies to different situations in software. + +The term "distro" is short for distribution. For a list of vendors that provide +distros, see [Vendors](/ecosystem/vendors/). + +### Sampling + +#### 1 - Tail sampling + +**Q:** What are the perceived downsides of tail sampling, for example, on all +HTTP requests that have errors or long latencies, instead of just relying on +head-based sampling? Are there best practices around trace sampling? Tail +sampling can get very expensive. + +**A:** Generally, head sampling is not recommended, as you aren’t going to be +able to do 100% of what you want to do with it, but it is true that tail +sampling is expensive. The reason why sampling is such a complicated discussion +is that there really isn’t a universal answer; furthermore, it also depends on +what kind of features are offered by your data analysis tool. For example, do +you have a data ingest or storage cost? If you have ingest cost, you’ll want to +sample before the data gets ingested; if it’s storage cost, you’ll have to +delete a lot of the data, so it depends on the tradeoffs. + +One thing to consider is that you can use tail sampling on attributes, such as +if there’s an error on a span, but it does require more memory. Suggested +further exploration: + +- [Column data store for OpenTelemetry](https://github.com/open-telemetry/oteps/pull/171) +- [OpAMP](/blog/2022/opamp/) +- Your backend vendor’s tail-based sampling strategies +- [Paper by Uber](https://www.uber.com/en-IN/blog/crisp-critical-path-analysis-for-microservice-architectures/) +- [Tail sampling processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/tailsamplingprocessor/README.md) + +### Adoption, Migration, and Implementation + +#### 1 - Common migration challenges + +**Q:** What are common challenges faced by developers when migrating to +OpenTelemetry? + +**More context:** We have hundreds of microservices that need to be migrated, +including big monolith systems with a lot of custom tracing locked into specific +vendors and their libraries. Setting up agents to facilitate this migration is +like having two different sets of observability systems running at the same +time. + +**A:** One user shared their journey: They started by using a backend that +supports OpenTelemetry. The two challenges they faced were: a cultural change in +the engineer’s mindset, and raising awareness of OpenTelemetry, which are bigger +than the technical challenges. The key is to not propose one big change; the +journey of moving from a vendor-based solution to OpenTelemetry should be a +step-by-step process, rather than going into a full transformation. + +Additional suggestions: + +- Start with dev or testing environments first to build trust in the software +- Choose a stack where OTel is more robust, such as Java and Node.js +- For countering developer resistance, using auto-instrumentation modules to +- start with is a good step + +#### 2 - Starting and scaling + +**Q:** What is a good place to start from with OpenTelemetry? For example, from +infra to data collection, or starting in the application? And how do you scale +it up? + +**More context**: Our use case is end-to-end visibility; currently, we are using +a vendor for monitoring logs, metrics, and traces. We are also using things like +RUM (real user monitoring). Can we do the same with OpenTelemetry, and at scale? + +**A:** It depends on if you are starting to use OTel in a new project, or trying +to re-orchestrate an existing or old project. It’s best to start with a +transition plan, make sure the performance impact is not bad, and scale up what +you need. One suggestion is to start experimenting with Java OTel +instrumentation, as the overall performance impact is negligible. + +Another suggestion is to try infrastructure monitoring with OpenTelemetry using +the +[host metrics receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/hostmetricsreceiver/README.md) +in the Collector, as it covers a lot of metrics, and has no dependencies. One +user noticed a 20% reduction in CPU usage when they moved from a vendor-specific +agent to the host metrics receiver for infrastructure monitoring. + +#### 3 - Auto-instrumentation + +**Q:** Is there a way to automatically create spans without code changes? + +**A:** It depends on the use cases: + +- [Auto instrumentation](/docs/concepts/instrumenting/#automatic-instrumentation) + options are maturing in OTel; for example, the Java JAR agent takes care of + instrumenting + [most libraries](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries--frameworks) + that are used by applications. Auto-instrumentation is also available for + [Python](/docs/instrumentation/python/automatic/), + [.NET](/docs/instrumentation/net/automatic/), and + [Node.js](/docs/instrumentation/js/libraries/#node-autoinstrumentation-package). +- If you’re using Kubernetes, they can use the + [OTel operator](https://github.com/open-telemetry/opentelemetry-operator), + which takes care of instrumentations for applications deployed on k8s. The + OTel Operator also supports injecting and configuring auto-instrumentation + libraries where available (see point above). +- If you’re using AWS lambda, you should check out the + [OTel Lambda extension](https://github.com/open-telemetry/opentelemetry-lambda). + +#### 4 - Leveraging telemetry from OTel + +**Q:** Has there been work toward telecommand standards to leverage the +telemetry from OTel? + +**A:** Telecommand is a command sent to control a remote system or systems that +are not directly connected to the place from which the telecommand is sent (per +Wikipedia). Check out +[this paper](https://www.gsse.biz/pdfs/papers/DASIA2018-abstract.pdf), and +[OpAMP](/blog/2022/opamp/). + +#### 5 - Message brokers + +**Q:** What are some use cases for message brokers? + +**A:** IoT use cases (car manufacturer). There is also ongoing work for semantic +conventions support for messages. + +### Updates and Communications + +#### 1 - Unified query standard + +**Q:** Is there an update on the upcoming Unified Query Standard working group +for observability data and discussion at O11y Day at KubeCon EU? + +**A:** The Observability TAG within CNCF is working to launch a working group +that is going to analyze the various query languages that are out there and come +up with use cases, such as, what are your most common alert and diagnostic +types, and what are some uncommon patterns that you’d like to have available? +Then, we’d like to see if there’s any way we can come up with a recommendation +for a unified standard language across vendors. Maybe SQL-ish? + +We’re officially launching the working group at the end of the month; the +charter is open for comments. +[View here](https://docs.google.com/document/d/1JRQ4hoLtvWl6NqBu_RN8T7tFaFY5jkzdzsB9H-V370A). +We are going to start making the conference circuit and gather feedback, the +first place will be at +[Observability Day](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/observability-day/). +Join the discussion at +[#telemetry-analysis](https://cloud-native.slack.com/archives/C04LXHPDW6M) in +CNCF’s Slack instance. + +#### 2 - Documentation and searches + +**Q:** Where do you go to find documentation and answers to your questions? + +**A:** We have many resources, including official documentation and Github +repos. + +To help us improve our resources, it would be helpful to gather feedback from +you as an end user – what is your process for finding OTel information? Do you +search for answers or post questions on Stack Overflow? The community is +researching options that make sense so that questions can be indexed for +searching. One option is Stack Overflow. Please share your answers using one of +the avenues below! + +## Meeting Notes & Recordings + +For a deeper dive into the above topics, check out the following: + +- [AMER](https://docs.google.com/document/d/1p_FoGbLiDC9VPqqLblJqQtHBn3tr-aPxhu2GaIykU6k) + meeting notes +- [EMEA](https://docs.google.com/document/d/1fh4RWyZ-ScWdwrgpRHO9mnfqLSKfxUTf4wZGdUvnnUM) + meeting notes +- [APAC](https://docs.google.com/document/d/1eDYC97LfvE428cpIf3A_hSGirdNzglPurlxgKCmw8o4) + meeting notes + +## Join us! + +If you have a story to share about how you use OpenTelemetry at your +organization, we’d love to hear from you! Ways to share: + +- Join the [#otel-endusers channel](/community/end-user/slack-channel/) on the + [CNCF Community Slack](https://communityinviter.com/apps/cloud-native/cncf) +- Join our monthly + [End-User Discussion Group calls](/community/end-user/discussion-group/) +- Join our [OTel in Practice](/community/end-user/otel-in-practice/) sessions +- Share your stories on the + [OpenTelemetry blog](https://github.com/open-telemetry/opentelemetry.io/blob/954103a7444d691db3967121f0f1cb194af1dccb/README.md#submitting-a-blog-post) + +Be sure to follow OpenTelemetry on +[Mastodon](https://fosstodon.org/@opentelemetry) and +[Twitter](https://twitter.com/opentelemetry), and share your stories using the +**#OpenTelemetry** hashtag! diff --git a/static/refcache.json b/static/refcache.json index 5f656320efa4..939fb8f15654 100644 --- a/static/refcache.json +++ b/static/refcache.json @@ -223,6 +223,10 @@ "StatusCode": 200, "LastSeen": "2023-03-09T15:12:28.826905-08:00" }, + "https://cloud-native.slack.com/archives/C04LXHPDW6M": { + "StatusCode": 200, + "LastSeen": "2023-03-30T19:59:34.460406-04:00" + }, "https://cloud-native.slack.com/archives/CJFCJHG4Q": { "StatusCode": 200, "LastSeen": "2023-02-15T20:37:30.005524-05:00" @@ -647,6 +651,10 @@ "StatusCode": 200, "LastSeen": "2023-03-07T17:15:57.471522-05:00" }, + "https://docs.google.com/document/d/1JRQ4hoLtvWl6NqBu_RN8T7tFaFY5jkzdzsB9H-V370A": { + "StatusCode": 200, + "LastSeen": "2023-03-30T19:59:29.179813-04:00" + }, "https://docs.google.com/document/d/1KtH5atZQUs9Achbce6LiOaJxLbksNJenvgvyKLsJrkc/edit#heading=h.ioikt02qpy5f": { "StatusCode": 200, "LastSeen": "2023-02-15T21:03:45.532027-05:00" @@ -2295,6 +2303,10 @@ "StatusCode": 200, "LastSeen": "2023-02-20T08:02:44.486488-05:00" }, + "https://github.com/open-telemetry/oteps/pull/171": { + "StatusCode": 200, + "LastSeen": "2023-03-30T19:59:09.626563-04:00" + }, "https://github.com/open-telemetry/oteps/pull/173": { "StatusCode": 200, "LastSeen": "2023-02-20T07:59:55.079245-05:00" @@ -2975,6 +2987,10 @@ "StatusCode": 206, "LastSeen": "2023-02-16T17:45:34.220648-05:00" }, + "https://o11y.news/2023-03-13/#opentelemetry-connectors": { + "StatusCode": 206, + "LastSeen": "2023-03-30T19:58:58.251407-04:00" + }, "https://oncallmemaybe.com": { "StatusCode": 206, "LastSeen": "2023-02-16T17:47:29.773741-05:00" @@ -3299,6 +3315,10 @@ "StatusCode": 206, "LastSeen": "2023-02-28T17:42:10.418735+05:30" }, + "https://reflectoring.io/upstream-downstream/": { + "StatusCode": 206, + "LastSeen": "2023-03-30T19:59:03.64709-04:00" + }, "https://rubiksqube.com/#/": { "StatusCode": 206, "LastSeen": "2023-02-18T12:42:41.027605-05:00" @@ -3703,6 +3723,10 @@ "StatusCode": 206, "LastSeen": "2023-02-20T08:26:04.497414-05:00" }, + "https://www.gsse.biz/pdfs/papers/DASIA2018-abstract.pdf": { + "StatusCode": 206, + "LastSeen": "2023-03-30T19:59:23.7534-04:00" + }, "https://www.hangfire.io/": { "StatusCode": 206, "LastSeen": "2023-02-18T13:41:36.36414-05:00" @@ -4059,6 +4083,10 @@ "StatusCode": 206, "LastSeen": "2023-02-18T13:36:51.530459-05:00" }, + "https://www.uber.com/en-IN/blog/crisp-critical-path-analysis-for-microservice-architectures/": { + "StatusCode": 200, + "LastSeen": "2023-03-30T19:59:18.174723-04:00" + }, "https://www.vaultproject.io": { "StatusCode": 206, "LastSeen": "2023-02-18T13:44:21.283098-05:00" From d80c720c1af67ae6fb21dc233c78f91590d67098 Mon Sep 17 00:00:00 2001 From: Brett McBride Date: Sat, 1 Apr 2023 01:13:45 +1100 Subject: [PATCH 2/4] PHP instrumentation improvements (#2552) Co-authored-by: Patrice Chalin Co-authored-by: Phillip Carter --- .../instrumentation/php/getting-started.md | 64 ++++++++++- .../en/docs/instrumentation/php/logging.md | 47 ++++++++ content/en/docs/instrumentation/php/manual.md | 11 ++ content/en/docs/instrumentation/php/sdk.md | 101 ++++++++++++++++++ data/instrumentation.yaml | 2 +- static/refcache.json | 48 +++++++++ 6 files changed, 271 insertions(+), 2 deletions(-) create mode 100644 content/en/docs/instrumentation/php/logging.md create mode 100644 content/en/docs/instrumentation/php/sdk.md diff --git a/content/en/docs/instrumentation/php/getting-started.md b/content/en/docs/instrumentation/php/getting-started.md index be162b0edf75..0639b3841ea9 100644 --- a/content/en/docs/instrumentation/php/getting-started.md +++ b/content/en/docs/instrumentation/php/getting-started.md @@ -5,6 +5,62 @@ aliases: [/docs/instrumentation/php/getting_started] weight: 1 --- +## Requirements + +OpenTelemetry for PHP requires a minimum PHP version of 7.4, and +auto-instrumentation requires version 8.0+. + +### Dependencies + +Some of the `SDK` and `Contrib` packages have a dependency on both a +[HTTP Factories (PSR17)](https://www.php-fig.org/psr/psr-17/) and a +[php-http/async-client](https://docs.php-http.org/en/latest/clients.html) +implementation. You can find appropriate composer packages implementing given +standards on [packagist.org](https://packagist.org/). + +See +[http-factory-implementations](https://packagist.org/providers/psr/http-factory-implementation) +to find a `PSR17 (HTTP factories)` implementation, and +[async-client-implementations](https://packagist.org/providers/php-http/async-client-implementation) +to find a `php-http/async-client` implementation. + +### Optional PHP extensions + +| Extension | Purpose | +| ------------------------------------------------------------------------- | ----------------------------------------------------------------- | +| [ext-grpc](https://github.com/grpc/grpc/tree/master/src/php) | Required to use gRPC as a transport for the OTLP exporter | +| [ext-mbstring](https://www.php.net/manual/en/book.mbstring.php) | More performant than the fallback, `symfony/polyfill-mbstring` | +| [ext-zlib](https://www.php.net/manual/en/book.zlib.php) | If you want to compress exported data | +| [ext-ffi](https://www.php.net/manual/en/book.ffi.php) | Fiber-based context storage | +| [ext-protobuf](https://github.com/protocolbuffers/protobuf/tree/main/php) | _Significant_ performance improvement for otlp+protobuf exporting | + +#### ext-ffi + +Fibers support can be enabled by setting the `OTEL_PHP_FIBERS_ENABLED` +environment variable to a truthy value (`1`, `true`, `on`). Using fibers with +non-`CLI` SAPIs may require preloading of bindings. One way to achieve this is +setting +[`ffi.preload`](https://www.php.net/manual/en/ffi.configuration.php#ini.ffi.preload) +to `src/Context/fiber/zend_observer_fiber.h` and setting +[`opcache.preload`](https://www.php.net/manual/en/opcache.preloading.php) to +`vendor/autoload.php`. + +#### ext-protobuf + +The [native protobuf library](https://packagist.org/packages/google/protobuf) is +significantly slower than the extension. We strongly encourage the use of the +extension. + +## Introduction + +OpenTelemetry for PHP is distributed via +[packagist](https://packagist.org/packages/open-telemetry/), in a number of +packages. We recommend that you install only the packages that you need, which +as a minimum is usually `API`, `Context`, `SDK` and an exporter. + +We strongly encourage that your code only depend on classes and interfaces in +the `API` package. + ## Setup Before you get started make sure that you have php and @@ -160,6 +216,12 @@ trace: The next step is to modify the code to send spans to the collector via OTLP instead of the console. +This will require the installation of the otlp exporter: + +```shell +composer require opentelemetry/exporter-otlp +``` + Next, using the `GettingStarted.php` from earlier, replace the console exporter with an OTLP exporter: @@ -218,4 +280,4 @@ Starting OtlpHttpExporter OpenTelemetry welcomes PHP ``` -Now, telemetry will be exported to the collector process. +Now, telemetry will be exported to the collector. diff --git a/content/en/docs/instrumentation/php/logging.md b/content/en/docs/instrumentation/php/logging.md new file mode 100644 index 000000000000..f0dcbd28bdba --- /dev/null +++ b/content/en/docs/instrumentation/php/logging.md @@ -0,0 +1,47 @@ +--- +title: Logging +weight: 10 +--- + +As logging is a mature and well-established function, the +[OpenTelemetry approach](/docs/concepts/signals/logs/) is a little different for +this signal. + +The OpenTelemetry logger is not designed to be used directly, but rather to be +integrated into existing logging libraries as a handler. In this way, you can +choose to have some or all of your application logs sent to an +OpenTelemetry-compatible service such as the [collector](/docs/collector/). + +## Setup + +You get a logger from a `LoggerProvider`. Log records get emitted via an +`EventLogger`: + +```php +getLogger('demo', '1.0', 'http://schema.url', true, [/*attributes*/]); +$eventLogger = new EventLogger($logger, 'my-domain'); +``` + +Once configured, a `LogRecord` can be created and sent via the event logger's +`logEvent`method: + +```php +$record = (new LogRecord('hello world')) + ->setSeverityText('INFO') + ->setAttributes([/*attributes*/]); + +$eventLogger->logEvent('foo', $record); +``` + +## Examples + +The +[monolog-otel-integration example](https://github.com/open-telemetry/opentelemetry-php/blob/main/examples/logs/features/monolog-otel-integration.php) +demonstrates using the popular Monolog logger to send some logs to a stream (in +their usual format), as well as sending some logs to an OpenTelemetry collector. diff --git a/content/en/docs/instrumentation/php/manual.md b/content/en/docs/instrumentation/php/manual.md index aa538f5b5083..7daa7070799c 100644 --- a/content/en/docs/instrumentation/php/manual.md +++ b/content/en/docs/instrumentation/php/manual.md @@ -70,6 +70,17 @@ $instrumentation = new CachedInstrumentation('example'); $tracer = $instrumentation->tracer(); ``` +It's important to run the tracer provider's `shutdown()` method when the PHP +process ends, to enable flushing of any enqueued telemetry. The shutdown process +is blocking, so consider running it in an async process. Otherwise, you can use +the `ShutdownHandler` to register the shutdown function as part of PHP's +shutdown process: + +```php +\OpenTelemetry\SDK\Common\Util\ShutdownHandler::register([$tracerProvider, 'shutdown']); +\OpenTelemetry\SDK\Common\Util\ShutdownHandler::register([$meterProvider, 'shutdown']); +``` + ## Acquiring a Tracer To do [Tracing](/docs/concepts/signals/traces/) you'll need to acquire a diff --git a/content/en/docs/instrumentation/php/sdk.md b/content/en/docs/instrumentation/php/sdk.md new file mode 100644 index 000000000000..2cf1874086d8 --- /dev/null +++ b/content/en/docs/instrumentation/php/sdk.md @@ -0,0 +1,101 @@ +--- +title: SDK +weight: 8 +--- + +The OpenTelemetry SDK provides a working implementation of the API, and can be +set up and configured in a number of ways. + +## Manual setup + +Setting up an SDK manually gives you the most control over the SDK's +configuration: + +```php +addSpanProcessor( + (new BatchSpanProcessorBuilder($spanExporter)) + ->setMeterProvider($meterProvider) + ->build() + ) + ->build(); + +Sdk::builder() + ->setTracerProvider($tracerProvider) + ->setMeterProvider($meterProvider) + ->setPropagator(TraceContextPropagator::getInstance()) + ->setAutoShutdown(true) + ->buildAndRegisterGlobal(); +``` + +## Autoloading + +If all configuration comes from environment variables (or `php.ini`), you can +use SDK autoloading to automatically configure and globally register an SDK. The +only requirement for this is that you set `OTEL_PHP_AUTOLOAD_ENABLED=true`, and +provide any required/non-standard configuration as set out in +[sdk-configuration](/docs/concepts/sdk-configuration/). + +For example: + +```shell +OTEL_PHP_AUTOLOAD_ENABLED=true \ +OTEL_EXPORTER_OTLP_PROTOCOL=grpc \ +OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4317 \ +php example.php +``` + +```php +getTracer('name', 'version', 'schema.url', [/*attributes*/]); +$meter = OpenTelemetry\API\Common\Instrumentation\Globals::meterProvider()->getTracer('name', 'version', 'schema.url', [/*attributes*/]); +``` + +SDK autoloading happens as part of the composer autoloader. + +## Configuration + +The PHP SDK supports most of the +[available configurations](/docs/concepts/sdk-configuration/). Our conformance +to the specification is listed in the +[spec compliance matrix](https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix.md). + +There are also a number of PHP-specific configurations: + +| Name | Default value | Values | Example | Description | +| ---------------------------------- | ------------- | --------------------------------------------------------------------- | -------------- | --------------------------------------------------- | +| OTEL_PHP_TRACES_PROCESSOR | batch | batch, simple | simple | Span processor selection | +| OTEL_PHP_DETECTORS | all | env, host, os, process, process_runtime, sdk, sdk_provided, container | env,os,process | Resource detector selection | +| OTEL_PHP_AUTOLOAD_ENABLED | false | true, false | true | Enable/disable SDK autoloading | +| OTEL_PHP_DISABLED_INSTRUMENTATIONS | [] | Instrumentation name(s) | psr15,psr18 | Disable one or more installed auto-instrumentations | + +Configurations can be provided as environment variables, or via `php.ini` (or a +file included by `php.ini`) diff --git a/data/instrumentation.yaml b/data/instrumentation.yaml index 294848566a8d..2a5663f0a2b7 100644 --- a/data/instrumentation.yaml +++ b/data/instrumentation.yaml @@ -34,7 +34,7 @@ languages: status: traces: beta metrics: beta - logs: not yet implemented + logs: alpha python: name: Python status: diff --git a/static/refcache.json b/static/refcache.json index 939fb8f15654..a37f97667d38 100644 --- a/static/refcache.json +++ b/static/refcache.json @@ -899,6 +899,10 @@ "StatusCode": 200, "LastSeen": "2023-02-15T21:14:26.223031-05:00" }, + "https://docs.php-http.org/en/latest/clients.html": { + "StatusCode": 200, + "LastSeen": "2023-03-29T03:57:45.844229122Z" + }, "https://docs.python.org/3/library/sys.html#sys.implementation": { "StatusCode": 206, "LastSeen": "2023-02-15T21:12:08.314891-05:00" @@ -3119,10 +3123,30 @@ "StatusCode": 206, "LastSeen": "2023-02-16T17:45:10.013699-05:00" }, + "https://packagist.org/": { + "StatusCode": 200, + "LastSeen": "2023-03-29T03:57:46.228775307Z" + }, + "https://packagist.org/packages/google/protobuf": { + "StatusCode": 200, + "LastSeen": "2023-03-29T03:57:52.438347267Z" + }, + "https://packagist.org/packages/open-telemetry/": { + "StatusCode": 200, + "LastSeen": "2023-03-29T03:57:52.875982797Z" + }, "https://packagist.org/packages/open-telemetry/opentelemetry-instrumentation-installer": { "StatusCode": 200, "LastSeen": "2023-03-14T18:07:43.947011+01:00" }, + "https://packagist.org/providers/php-http/async-client-implementation": { + "StatusCode": 200, + "LastSeen": "2023-03-29T03:57:47.546094076Z" + }, + "https://packagist.org/providers/psr/http-factory-implementation": { + "StatusCode": 200, + "LastSeen": "2023-03-29T03:57:46.915444079Z" + }, "https://packagist.org/search/": { "StatusCode": 200, "LastSeen": "2023-02-18T09:19:42.398761-05:00" @@ -3983,10 +4007,34 @@ "StatusCode": 206, "LastSeen": "2023-02-28T03:33:34.741771102Z" }, + "https://www.php-fig.org/psr/psr-17/": { + "StatusCode": 206, + "LastSeen": "2023-03-29T03:57:45.198897206Z" + }, "https://www.php-fig.org/psr/psr-18/": { "StatusCode": 206, "LastSeen": "2023-02-28T03:33:35.061283512Z" }, + "https://www.php.net/manual/en/book.ffi.php": { + "StatusCode": 200, + "LastSeen": "2023-03-29T03:57:50.206342903Z" + }, + "https://www.php.net/manual/en/book.mbstring.php": { + "StatusCode": 200, + "LastSeen": "2023-03-29T03:57:48.558076531Z" + }, + "https://www.php.net/manual/en/book.zlib.php": { + "StatusCode": 200, + "LastSeen": "2023-03-29T03:57:49.468930417Z" + }, + "https://www.php.net/manual/en/ffi.configuration.php#ini.ffi.preload": { + "StatusCode": 200, + "LastSeen": "2023-03-29T03:57:51.220192806Z" + }, + "https://www.php.net/manual/en/opcache.preloading.php": { + "StatusCode": 200, + "LastSeen": "2023-03-29T03:57:51.962566491Z" + }, "https://www.python.org/dev/peps/pep-3333/": { "StatusCode": 206, "LastSeen": "2023-02-18T13:41:14.813514-05:00" From 94bd832600b56249619c149474fced121e3d9383 Mon Sep 17 00:00:00 2001 From: Austin Parker Date: Fri, 31 Mar 2023 11:25:32 -0400 Subject: [PATCH 3/4] add march otel in focus blog (#2562) Co-authored-by: Patrice Chalin --- content/en/blog/2023/otel-in-focus-03.md | 112 +++++++++++++++++++++++ static/refcache.json | 48 ++++++++++ 2 files changed, 160 insertions(+) create mode 100644 content/en/blog/2023/otel-in-focus-03.md diff --git a/content/en/blog/2023/otel-in-focus-03.md b/content/en/blog/2023/otel-in-focus-03.md new file mode 100644 index 000000000000..06a8926dfc4f --- /dev/null +++ b/content/en/blog/2023/otel-in-focus-03.md @@ -0,0 +1,112 @@ +--- +title: OpenTelemetry in Focus, March 2023 +linkTitle: OTel in Focus 2023/03 +date: 2023-03-31 +author: '[Austin Parker](https://github.com/austinlparker)' +--- + +Welcome to this month’s edition of **OpenTelemetry in Focus**! It's been another +busy month in the OpenTelemetry community, with some big announcements and new +releases from our core repositories. I've also put together an overview of some +[blog, website, and project highlights](https://arc.net/e/18897C6F-3A57-4769-A929-902A18AB1B04) - +give it a look, and tell me what you think. + +Are you a maintainer with something you’d like featured here? Get in touch with +me [via email](mailto:austin@lightstep.com), or on the +[CNCF Slack #otel-comms](https://cloud-native.slack.com/archives/C02UN96HZH6) +channel. + +## Releases and Updates + +Here are the latest updates from our core repositories. + +##### [Specification](/docs/reference/specification/) + +[Version 1.19](https://github.com/open-telemetry/opentelemetry-specification/releases/tag/v1.19.0) +has been released with a number of important udates. + +- OTLP/JSON has been declared stable. +- To clarify its purpose, the Logs API has been renamed to the Logs Bridge API. +- Semantic convention updates. + +##### [Collector](/docs/collector/) and contrib + +[Version 0.74/v1.0-rc8](https://github.com/open-telemetry/opentelemetry-collector-releases/releases/tag/v0.74.0) +has been released for the collector, resulting in a new +[operator](https://github.com/open-telemetry/opentelemetry-operator/releases/tag/v0.74.0) +version as well. Highlights include: + +- Connectors are enabled by default. +- The `spanmetricsprocessor` has been deprecated in favor of the + `spanmetricsconnector`. Other changes have been made to the behavior of this + component. +- A new receiver for CloudFlare logs has been added. +- Many bugfixes and enhancements. + +##### [Go](/docs/instrumentation/go/) + +[Version v1.15.0-rc.2](https://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.15.0-rc.2) +has been released. Version 1.15 will ship with Metrics v1 support, and its +associated stability guarantees. Other highlights of the release candidate +include: + +- Support for global meter providers. +- Exemplar support added for metric data. +- Several optimizations, bugfixes, and removals/deprecations. + +##### [Java](/docs/instrumentation/java/) + +[Version 1.24.0](https://github.com/open-telemetry/opentelemetry-java/releases/tag/v1.24.0) +of the Java SDK has been released, featuring several optimizations and bugfixes +to the metrics SDK. + +In addition, the +[Java Instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/tag/v1.24.0) +package has been updated to 1.24 as well, featuring several new instrumentations +and fixes: + +- Apache Pulsar and Jodd-Http can now be instrumented automatically via the + agent. +- Ktor and Spring Webflux libraries can be instrumented using the library. +- Improvements to the RxJava2, Cassandra, Spring Boot, and other instrumentation + packages. + +##### [Python](/docs/instrumentation/python/) + +[Version 1.17](https://github.com/open-telemetry/opentelemetry-python/releases/tag/v1.17.0) +has been released with a handful of fixes and improvements, most notably support +for exponential histograms! + +## Project Updates + +The proposal to merge the +[Elastic Common Schema (ECS) into OpenTelemetry](https://github.com/open-telemetry/oteps/pull/222) +has been passed! This is a big step towards reducing competing standards and +aligning the open source observability ecosystem around a common data model. + +A proposal to +[donate OpenTelemetry Instrumentation for Android](https://github.com/open-telemetry/community/issues/1400) +has been made. You can follow along with the discussion in the linked issue -- +exciting to see more options for client observability in OpenTelemetry! + +We're on a mission to reduce the number of unanswered OpenTelemetry questions on +Stack Overflow. Be sure to check out the +[Stack Overflow Watch in the Monthly Highlights](https://arc.net/e/18897C6F-3A57-4769-A929-902A18AB1B04) +to learn how you can help, and get some cool swag in the process. + +The +[Logs Bridge Specification](https://github.com/open-telemetry/opentelemetry-specification/issues/2911) +is in the final stretch before merge. If you'd like to help proofread, or have +any comments, now's the time to get involved! + +## News and Upcoming Events + +The +[schedule for KubeCon EU](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/schedule/) +is up, and there's a lot of OpenTelemetry to go around! We'll also be at +[Observability Day EU](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/co-located-events/observability-day/) +-- which will be live-streamed, including project updates and a panel discussion +featuring several OpenTelemetry maintainers. Will you be there in-person? Find +me (I'm the guy with the hat) and say hi -- I'd love to meet you (and I'll have +some stickers to give away). We'll also have a project booth, so swing by -- and +stay tuned for another blog detailing our full involvement at KubeCon EU. diff --git a/static/refcache.json b/static/refcache.json index a37f97667d38..1cceafc924be 100644 --- a/static/refcache.json +++ b/static/refcache.json @@ -83,6 +83,10 @@ "StatusCode": 200, "LastSeen": "2023-02-15T20:20:27.656229-05:00" }, + "https://arc.net/e/18897C6F-3A57-4769-A929-902A18AB1B04": { + "StatusCode": 206, + "LastSeen": "2023-03-30T22:09:42.695295-04:00" + }, "https://avajs.dev": { "StatusCode": 200, "LastSeen": "2023-02-15T20:20:38.73133-05:00" @@ -1179,6 +1183,10 @@ "StatusCode": 206, "LastSeen": "2023-02-28T15:13:33.601955-05:00" }, + "https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/schedule/": { + "StatusCode": 206, + "LastSeen": "2023-03-30T22:09:49.39441-04:00" + }, "https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/": { "StatusCode": 206, "LastSeen": "2023-02-15T21:20:28.432278-05:00" @@ -1683,6 +1691,10 @@ "StatusCode": 200, "LastSeen": "2023-02-20T07:54:28.153336-05:00" }, + "https://github.com/open-telemetry/community/issues/1400": { + "StatusCode": 200, + "LastSeen": "2023-03-30T22:09:47.719278-04:00" + }, "https://github.com/open-telemetry/community/issues/828": { "StatusCode": 200, "LastSeen": "2023-02-20T07:54:34.277707-05:00" @@ -1779,6 +1791,10 @@ "StatusCode": 200, "LastSeen": "2023-02-20T07:49:18.98199-05:00" }, + "https://github.com/open-telemetry/opentelemetry-collector-releases/releases/tag/v0.74.0": { + "StatusCode": 200, + "LastSeen": "2023-03-30T22:09:43.555519-04:00" + }, "https://github.com/open-telemetry/opentelemetry-collector-releases/releases/v0.53.0": { "StatusCode": 200, "LastSeen": "2023-02-20T07:50:24.877598-05:00" @@ -1999,6 +2015,10 @@ "StatusCode": 200, "LastSeen": "2023-02-28T15:13:30.12689-05:00" }, + "https://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.15.0-rc.2": { + "StatusCode": 200, + "LastSeen": "2023-03-30T22:09:43.965879-04:00" + }, "https://github.com/open-telemetry/opentelemetry-helm-charts": { "StatusCode": 200, "LastSeen": "2023-02-20T07:50:02.628017-05:00" @@ -2039,6 +2059,10 @@ "StatusCode": 200, "LastSeen": "2023-02-28T15:13:31.303363-05:00" }, + "https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/tag/v1.24.0": { + "StatusCode": 200, + "LastSeen": "2023-03-30T22:09:45.008698-04:00" + }, "https://github.com/open-telemetry/opentelemetry-java/releases": { "StatusCode": 200, "LastSeen": "2023-02-20T07:55:19.188338-05:00" @@ -2055,6 +2079,10 @@ "StatusCode": 200, "LastSeen": "2023-02-28T15:13:30.740402-05:00" }, + "https://github.com/open-telemetry/opentelemetry-java/releases/tag/v1.24.0": { + "StatusCode": 200, + "LastSeen": "2023-03-30T22:09:44.443634-04:00" + }, "https://github.com/open-telemetry/opentelemetry-js": { "StatusCode": 200, "LastSeen": "2023-02-20T07:46:10.029871-05:00" @@ -2115,6 +2143,10 @@ "StatusCode": 200, "LastSeen": "2023-02-20T08:14:32.809155-05:00" }, + "https://github.com/open-telemetry/opentelemetry-operator/releases/tag/v0.74.0": { + "StatusCode": 200, + "LastSeen": "2023-03-30T22:10:50.802176-04:00" + }, "https://github.com/open-telemetry/opentelemetry-php": { "StatusCode": 200, "LastSeen": "2023-02-20T07:46:48.628475-05:00" @@ -2175,6 +2207,10 @@ "StatusCode": 200, "LastSeen": "2023-02-28T15:13:31.868472-05:00" }, + "https://github.com/open-telemetry/opentelemetry-python/releases/tag/v1.17.0": { + "StatusCode": 200, + "LastSeen": "2023-03-30T22:09:45.466603-04:00" + }, "https://github.com/open-telemetry/opentelemetry-ruby": { "StatusCode": 200, "LastSeen": "2023-02-20T07:47:04.881373-05:00" @@ -2243,6 +2279,10 @@ "StatusCode": 200, "LastSeen": "2023-02-28T17:42:13.21374+05:30" }, + "https://github.com/open-telemetry/opentelemetry-specification/issues/2911": { + "StatusCode": 200, + "LastSeen": "2023-03-30T22:09:48.838694-04:00" + }, "https://github.com/open-telemetry/opentelemetry-specification/issues/335": { "StatusCode": 200, "LastSeen": "2023-02-20T08:02:19.969848-05:00" @@ -2271,6 +2311,10 @@ "StatusCode": 200, "LastSeen": "2023-02-28T15:13:29.505888-05:00" }, + "https://github.com/open-telemetry/opentelemetry-specification/releases/tag/v1.19.0": { + "StatusCode": 200, + "LastSeen": "2023-03-30T22:09:43.12427-04:00" + }, "https://github.com/open-telemetry/opentelemetry-swift": { "StatusCode": 200, "LastSeen": "2023-02-20T07:47:21.042534-05:00" @@ -2323,6 +2367,10 @@ "StatusCode": 200, "LastSeen": "2023-02-20T08:13:31.349963-05:00" }, + "https://github.com/open-telemetry/oteps/pull/222": { + "StatusCode": 200, + "LastSeen": "2023-03-30T22:09:47.191499-04:00" + }, "https://github.com/opentelemetry-php/contrib-auto-psr15": { "StatusCode": 200, "LastSeen": "2023-02-20T07:44:32.187118-05:00" From 7f1501407b9643b4f517a189b3544ad08ec6ca07 Mon Sep 17 00:00:00 2001 From: Diego Hurtado Date: Fri, 31 Mar 2023 15:52:37 -0600 Subject: [PATCH 4/4] Document temporality presets in Python (#2551) --- .../docs/instrumentation/python/exporters.md | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/content/en/docs/instrumentation/python/exporters.md b/content/en/docs/instrumentation/python/exporters.md index d34c0659f502..d8c5aa592e58 100644 --- a/content/en/docs/instrumentation/python/exporters.md +++ b/content/en/docs/instrumentation/python/exporters.md @@ -43,6 +43,52 @@ different interval, change the each instrument kind, or change the default aggregation for each instrument kind. +#### Temporality Presets + +There are temporality presets for each instrumentation kind. These presets can +be set with the environment variable +`OTEL_EXPORTER_METRICS_TEMPORALITY_PREFERENCE`, for example: + +```console +$ export OTEL_EXPORTER_METRICS_TEMPORALITY_PREFERENCE="DELTA" +``` + +The default value for `OTEL_EXPORTER_METRICS_TEMPORALITY_PREFERENCE` is +`"CUMULATIVE"`. + +The available values and their corresponding settings for this environment +variable are: + +- `CUMULATIVE` + + - `Counter`: `CUMULATIVE` + - `UpDownCounter`: `CUMULATIVE` + - `Histogram`: `CUMULATIVE` + - `ObservableCounter`: `CUMULATIVE` + - `ObservableUpDownCounter`: `CUMULATIVE` + - `ObservableGauge`: `CUMULATIVE` + +- `DELTA` + + - `Counter`: `DELTA` + - `UpDownCounter`: `CUMULATIVE` + - `Histogram`: `DELTA` + - `ObservableCounter`: `DELTA` + - `ObservableUpDownCounter`: `CUMULATIVE` + - `ObservableGauge`: `CUMULATIVE` + +- `LOWMEMORY` + - `Counter`: `DELTA` + - `UpDownCounter`: `CUMULATIVE` + - `Histogram`: `DELTA` + - `ObservableCounter`: `CUMULATIVE` + - `ObservableUpDownCounter`: `CUMULATIVE` + - `ObservableGauge`: `CUMULATIVE` + +Setting `OTEL_EXPORTER_METRICS_TEMPORALITY_PREFERENCE` to any other value than +`CUMULATIVE`, `DELTA` or `LOWMEMORY` will log a warning and set this environment +variable to `CUMULATIVE`. + ```python from opentelemetry import metrics from opentelemetry.sdk.metrics import MeterProvider