aboutsummaryrefslogtreecommitdiffstats
path: root/includes/libs/telemetry
Commit message (Collapse)AuthorAgeFilesLines
* Replace remaining gendered pronounsTacsipacsi2025-03-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | To respect all genders, fix comments to not assume users use binary pronouns (or even that users are “he”s), but rather use singular “they”. Also fix some typos that happened to result in gendered pronouns, and a few incorrect commas and missing articles in comments near the fixed pronouns. I skipped four files: - HISTORY – the release notes were made with the wording they were made with, I’m not sure if rewording them afterwards is okay - tests/phpunit/data/preprocess/All_system_messages.{txt,expected} – these are test cases generated from somewhere, I’d regenerate them rather than updating - languages/i18n/qqq.json – fixed on Translatewiki instead to make their edit histories more useful Bug: T387626 Change-Id: I282406a0e1407be548e917735fe7eb9a6bf8b136
* doc: SpanInterface: more dev-friendly commentsChris Danis2025-01-301-24/+48
| | | | | Bug: T340552 Change-Id: I6e4520381a52486c8c8d0a341b78e398f6acfde8
* tracing: lowercase headers before processing themChris Danis2025-01-231-0/+1
| | | | | | | | | This seems the cleaner fix, since we do want to emit output headers in lowercase, as that's what the rest of mediawiki/core emits nowadays, as well as basically the rest of the world. Bug: T384629 Change-Id: I8ea568e316c6e06b8c3d6f370b04be57dcbddc0a
* Remove 2-line PHPDocs that just repeat the types from the codethiemowmde2025-01-172-3/+0
| | | | | | | | | | | | | | | | Same as Ia294bf4 did for 1-line comments. This patch removes slightly more complex 2-line PHPDoc comments that don't add any new information to the code, but literally repeat what the code already says. They say "don't document the code, code the documentation", and we are doing this more and more. We just tend to forget to remove the obsolete comments. Note I'm also removing a line of text in a few cases when it's very short and literally says the same as the method name. Again, such comments add zero new information. Change-Id: I01535404bab458c6c47e48e5456403b7a64198ed
* Remove trivial 1-line PHPDocs that just repeat the codethiemowmde2025-01-161-3/+0
| | | | | | | | | | | | | I assume these are all either auto-generated by an IDE or the language-level type declarations have been added later. In any case the comments don't add any new information to what the code already says. This is just extra clutter that makes the code harder to read, I would argue. There are many, many more comments like this. In this patch I intentionally focus on the most trivial 1-line comments. Change-Id: Ia294bf4ce0d8a77036842fe25884bc175c2b0e7d
* feat: Make ContextPropagator::inject() params immutablePiotr Miazga2025-01-136-13/+14
| | | | | | A good practice is to make method params immutable. Change-Id: I27fa363e4a4ffad89e05a26b2af99813dc9a9663
* telemetry: Factor out context propagationChris Danis2025-01-108-31/+214
| | | | | | | | Also condition using incoming span context upon $wgAllowExternalReqID Bug: T340552 Change-Id: Ib1cf361dd800c81a7943231441d58c790191ef5a
* Tracing: span statuses for root spansChris Danis2025-01-071-1/+6
| | | | | Bug: T340552 Change-Id: I18ffd0e36efbabe82313de685ca8c6c99341c6f3
* Tracing: add span statusesChris Danis2025-01-074-0/+50
| | | | | | | | | Shows up nicely in Jaeger: https://phabricator.wikimedia.org/F58139011 Also a searchable attribute of spans. Bug: T340552 Change-Id: I5bbbb3df08c5d8ac213228aeaf4b7c4048779453
* Span: fluentize activate()/deactivate()Chris Danis2025-01-073-8/+12
| | | | | Bug: T340552 Change-Id: I96c8e62954d86d7ced2c5503cd16edcf061063dd
* NoopSpan: optionally activateChris Danis2025-01-033-7/+14
| | | | | | | | | | | | | | Why: If tracing is enabled, but the sampling probability is <100%, we may set a NoopSpan as the root span. Without this patch, the NoopSpan cannot be activated, and thus creating child spans will fail with PreconditionException. This is a minimal patch to allow the NoopSpan to be activated, while not affecting existing testing codepaths that don't require a root span. Bug: T340552 Change-Id: Ib8a2d7b483190bba21a2f3b82fcd0e0b5756e750
* Setup: parse incoming traceparent headerChris Danis2024-12-201-0/+28
| | | | | | | | If present and valid, connect our root span to the input parent span. Bug: T340552 Change-Id: I3530c3b6be95c7b4a8960ad25929f795c4514db0
* tracing: Merge span attributes on consequent setAttribute() callsMáté Szabó2024-12-202-1/+3
| | | | | | | | | | | | | | | | | | Why: - SpanContext::setAttributes() currently overwrites existing attributes on each call, instead of merging them. - This behavior isn't documented and is confusing, especially since official OTEL clients usually merge attributes. What: - Have SpanContext::setAttributes() merge attributes instead of overwriting the existing ones and add a test for this. - Document the behavior on the public-facing SpanInterface::setAttributes() API. Change-Id: Ib2995c492b503ad84104deab9c227cfb62bffc55
* Add request-level OpenTelemetry instrumentationMáté Szabó2024-11-261-0/+32
| | | | | | | | | | | | | | | | | | | | Why: - Now that we have a basic OpenTelemetry library available in MediaWiki, we would like to start instrumenting code and propagating the trace context. What: - Start a root span in early setup code once the service container is available, so that subsequent setup logic (e.g. session initialization) can already be instrumented. - End the root span in restInPeace() after the main transaction round ended, so that the normal LBFactory shutdown process can be instrumented. - Have TracerSharedState hold the root span throughout. Bug: T340552 Change-Id: I0785204a6989787a492a08b78c40c6df91106f23
* Introduce minimal OTEL tracing libraryMáté Szabó2024-10-0915-0/+980
In T340552, the official PHP OpenTelemetry client was effectively rejected for inclusion in MediaWiki due to its size. Implement a minimal tracing library instead that eschews conformance with the OTEL client specification in favor of simplicity, while remaining capable of emitting trace data in OTLP format and thus retaining compatibility with any ingestion endpoint capable of handling OTLP. In its current state, the library supports a basic feature set that should be sufficient for basic tracing integration: * Span creation, inclusive span activation and automatic parent span assignment, * Span attributes and span kinds, * Basic resource (process/request)-level metadata generation, * Data export over OTLP. Additional functionality, such as trace propagation, can then be incrementally added to the library. Bug: T340552 Change-Id: Ibc3910058cd7ed064cad293a3cdc091344e66b86
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-25 12:37:22 +0000