* Add instrument advisory parameter
* Undo bucket boundaries change to preserve BC
"SDKs SHOULD use the default value when boundaries are not explicitly provided, unless they have good reasons to use something different (e.g. for backward compatibility reasons in a stable SDK release)."
* Add note that passing callback instead of advisory is deprecated
a bug in 1.23.0 meant that cloud, container and oci resource attributes were incorrectly published under trace attributes.
sort the attributes, so that future diffs are easier to read.
* update semver to 1.22.0
Since 1.19.0, the source has been split out of opentelemetry-specifiction into semantic-conventions. Update the build script accordingly.
Update to latest generator.
Add 2 new deprecations for semconvs which were renamed since 1.19
* update telemetry semconv
8.3 is in RC, so add it to the matrix.
bump 8.2 to non-experimental, which should have happened some time ago.
remove deprecated assert_options call from test bootstrap
Exposing it through Globals can cause a race condition. If something (eg, a contrib module)
retrieves the configuration resolver from Globals too early during autoloading, then it
causes the rest of the objects from Globals to be initialized. This can happen before all
required modules have been registered (depending on autoload->files execution order, which
is variable). Instead, create a simple API config resolver which does the basics of what the
SDK one does (without all the type checking and validation).
Whilst investigating upgrading to psalm 5, I notice that it generates a lot of new complaints. This fixes the ones that looked legit and
require an API change, or were trivial. Does not upgrade to psalm 5 yet, though. That's a bigger job for another day.
send errors/warnings/etc by default through PHP's error_log. This gives more control to administrators, since error_log can
be configured to write to any stream (file, stderr, etc). I think it's also less surprising for people trying out otel (particularly
with development PHP settings, where trigger_error often breaks an application).
Adding a configuration value to control where logs go: OTEL_PHP_LOG_DESTINATION.
per TC review, temporality is not part of MetricExporterInterface. Riffing on Java's solution, this moves
`temporality` into `AggregationTemporalitySelectorInterface`, and adds that interface to MetricExporter instances
that use it (everything except `NoopMetricExporter`).
https://github.com/open-telemetry/opentelemetry-specification/pull/3563 clarifies the behaviour of
forceFlush with push/non-push metric exporters.
Break forceFlush out into a PushMetricExporterInterface, and update ExportingReader to only collect/flush
if exporter is a push metric exporter.
noted in TC review. Java moved their examplar code into an internal package, and
documented that it may change. We don't have an internal package, so document
the warning in a few places.
adding a configuration resolver interface, and api+sdk implementations. the resolver is globally configured.
this allows contrib modules to fetch config if an SDK is installed, without directly using the SDK (per spec).
They aren't _truly_ safe on NTS builds either, as the functions used
are only expected to be set at certain times of the lifecycle, but in
practice it's safe enough on NTS.
However, for ZTS, these APIs are not safe to call at runtime at all.
fixing static analysis complaints, most of which were from psalm
when run with --show-info
remove deprecated httplug discovery
static data providers (phpunit10 requirement)
if an array is non-simple (has keys), it should be represented as a KeyValue in the generated
protobuf-encoded output.
Since we also need to support simple arrays of primitives, I've added a basic check so that
those are still represented as ArrayValue.
moving private method into a testable class, introduce attribute validation class
which applies to most attribute. LogRecord attributes are allowed to be complex,
so introduce a validator for these which lets everything through.
We made protobuf implementation optional back in #949 however it seems to be tripping up
a number of developers. Since native + extension can be installed at the same time (with
extension taking priority), I think that users will be less surprised when starting out
if there is a working implementation by default.
* adding badges to the various readme files to make more obvious the current versions
* list all packages and versions in main readme
* remove old README documentation (excluding development-specific), and direct users to opentelemetry.io
* link to opentelemetry.io where possible in package readme
* adding a badge to link to releases
releases are not easy to find, since they exist only in the subtree split repository
to make getting started easier (in opentelemetry.io docs), create an sdk-based metrics
exporter. this means we can export all signals without needing a protobuf implementation.
since console export is only useful for playing around, the change in format to a
simpler human-readable output seems reasonable.
* adding some links to try to make it easier for users to find the right support/repositories etc
just doing one composer file to see if it works, and will follow-up with more in a later PR
* change forum to chat
* Adding a backtrace to the errors reported via error_log (which is the default)
* Implement OTEL_LOG_LEVEL, which can be used to control which errors are reported via error_log. Note that
this doesn't use configuration code from the SDK, as the usage is in the API (because messages are logged
from many packages) and deptrac rightly complains about the dependency on SDK.