PHPackages obviobysage/telemetry - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Utility & Helpers](/categories/utility) 4. / 5. obviobysage/telemetry ActiveLibrary[Utility & Helpers](/categories/utility) obviobysage/telemetry ===================== A Telemetry package for the Obv.io ecosystem 11.3.2(1y ago)043MITPHPPHP >=8.2 Since Sep 30Pushed 1y ago1 watchersCompare [ Source](https://github.com/obviobysage/telemetry)[ Packagist](https://packagist.org/packages/obviobysage/telemetry)[ RSS](/packages/obviobysage-telemetry/feed)WikiDiscussions master Synced 1mo ago READMEChangelogDependencies (5)Versions (14)Used By (0) Obv.io - Telemetry ================== [](#obvio---telemetry) [![Latest Version on Packagist](https://camo.githubusercontent.com/d249e647cfc418c8b03c8cd7f787e2d8efbd2adac01d8de17dc5279f746401f2/68747470733a2f2f696d672e736869656c64732e696f2f7061636b61676973742f762f6f6276696f6279736167652f74656c656d657472792e7376673f7374796c653d666c61742d737175617265)](https://packagist.org/packages/obviobysage/telemetry)[![GitHub Tests Action Status](https://camo.githubusercontent.com/8495d3c77a0be04e903a5a0d1aaa61a6732bdb1510586d51c054e76e70d7f34b/68747470733a2f2f696d672e736869656c64732e696f2f6769746875622f616374696f6e732f776f726b666c6f772f7374617475732f6f6276696f6279736167652f74656c656d657472792f63692e796d6c3f6272616e63683d6d6173746572)](https://github.com/obviobysage/telemetry/actions/workflows/ci.yml?query=branch:master) This Laravel package is a common facility to ship Telemetry payloads from internal Obv.io applications to an Elasticsearch storage, using a Redis transport by default. Custom transports can be configured, if Redis is not the choice. Using various configuration options, honing in the usability per application is straightforward. Enabling Telemetry ------------------ [](#enabling-telemetry) Telemetry is in the **disabled** state by default when you require the package, but a simple switch in your application `.env` is all that's needed to start shipping Telemetry payloads: ``` TELEMETRY_ENABLED=true ``` Then add some events in whatever way makes sense: ``` use ObvioBySage\Telemetry\Facades\Telemetry; protected someFunction() { // ...Things hapen... Telemetry::event('event-name-keyword') ->data(['array' => 'of payload...']) ->fire(); } ``` With no configuration out of the box, Telemetry will use your `default` Redis connection found in `config/database.php` and will publish to a list named `telemetry`. It's up to your ELK stack to consume from this list for the last mile. Changing these two settings is as simple as providing a couple more `.env` directives: ``` TELEMETRY_REDIS_CONNECTION="your-connection-name" TELEMETRY_REDIS_QUEUE="not_telemetry" ``` This Telemetry package is configured to use Redis as a transport by default, but you are free to configure other transport methods if it makes more sense for your application. Any custom transport must implement the `ObvioBySage\Telemetry\Contracts\TelemetryTransport` contract. After that, it's entirely up to you. The assumed storage being shipped to is Elasticsearch, and comes configured with the index setting of `telemetry`. This can be overriden using the `TELEMETRY_INDEX` environment variable. For a view into everything that is configurable, it's likely easier to publish the configuration from the package and peruse the settings: ``` artisan vendor:publish --tag obvio-telemetry ``` This will place a configuration file in `config/telemetry.php`, and from here it's in your hands. Vars ---- [](#vars) Through configuration, there is an array of data that can be included on every payload that is sent through to Telemetry. The idea here, is that there may be some common "constants" that the application should send through, perhaps for some identification purposes. The `vars` key in the `config/telemetry.php` configuration file can be an array of data. It could be an implementation of the `TelemetryVars` contract. Lastly, it could be a namespaced class name that will be resolved out of the container. With these three options, whatever logic you may have for the common vars should be covered. Request Payload --------------- [](#request-payload) Laravel's request is automatically included in the payload being shipped to the Telemetry storage. This can be toggled using an environment variable. Generic headers from the request are included in the payload, but can be configured in your environment(s). The value should be a comma-separated list of headers to try to include from the request object. If a listed header is not found in the request, it's simply not included in the payload to Telemetry. ``` TELEMETRY_PAYLOADS_REQUEST_INCLUDED=false TELEMETRY_PAYLOADS_REQUEST_HEADERS="accept,authorization,content-length,content-type,origin" ``` User Payload ------------ [](#user-payload) The user making the request is automatically included in the payload being shipped to the Telemetry storage. This can be toggled using the an environment variable. When preparing the payload to be shipped, if no user is present in the request, the top-level attribute is not included in the payload. Generic attributes from the user are included in the payload, but can be configured in your environment(s). The value should be a comma-separated list of attributes from your user model. If a listed attribute is not found on the user model, a `null` value is inclued in the payload to Telemetry. A callback method can be supplied in the environment variables, and if present and callable on the user model, will be called when preparing the payload. This method should return an array of data, which will be merged with whatever attributes were able to be taken from the user model previously. ``` TELEMETRY_PAYLOADS_USER_INCLUDED=false TELEMETRY_PAYLOADS_USER_ATTRIBUTES="email,id,name" TELEMETRY_PAYLOADS_USER_CALLBACK_METHOD="myUserMehod" ``` Obfuscated Data --------------- [](#obfuscated-data) There may be some payload attributes that you would like to have obfuscated before they are shipped to Telemetry for storage. By creating a list in the configuration, these items will be iterated and searched for within the resolved payload. If any of those keys are found, recursively..., the values will be obfuscated. The attributes remain in the payload, but they're value is replaced with `****`, the length of the value. In the same fashion as the request headers, or the user attributes, a comma-separated list can be provided to the environment. ``` TELEMETRY_OBFUSCATED_DATA_KEYS="password,password_confirmation" ``` Notifications ------------- [](#notifications) When exceptions are caught, the exception message will be logged to whatever channel is configured in your application's `config('logging.default')`, but this can of course be overriden in your environment(s). Exceptions are not re-thrown by default, it's of the opinion that the application flow shouldn't be interrupted because of a logging/connection issue. If this is coutnerintuitive for you, toggle the setting in your environment and the exception will be logged and then re-thrown. ``` TELEMETRY_LOGGING_CHANNEL="stack" TELEMETRY_THROW_TRANSPORT_EXCEPTIONS=true ``` Configuration vs. `.env` ------------------------ [](#configuration-vs-env) The results are the same in either decision, it's entirely up to you and your application. The exception to that statement is if you require custom transports to ship your Telemetry payloads. There isn't an `.env` solution for this scenario. `TelemetryData` --------------- [](#telemetrydata) Any included object in the resolved payload that implements the `ObvioBySage\Telemetry\Contracts\TelemetryData` contract will provide a shape for the payload to build. Perhaps you have a model that has many attributes that you don't want/need to be sent to Telemetry, within the implemented `telemetryData()` method, you return an array in whatever shape you would like to represent that model. When creating the payload, Telemetry will recursively iterate all attributes and check for: - `TelemetryData` - `Arrayable` - `Carbon` - `UploadedFile` `TelemetryData` and `Arrayable` are self-explanatory. `Carbon` will represent the object as `toISOString()`. The `UploadedFile` will simply get the `getClientOriginalName()`. ### Health Score 30 — LowBetter than 64% of packages Maintenance36 Infrequent updates — may be unmaintained Popularity8 Limited adoption so far Community7 Small or concentrated contributor base Maturity59 Maturing project, gaining track record Bus Factor1 Top contributor holds 100% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~0 days Total 13 Last Release 588d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/c0a2bd1feb4ee9e1410128e6bf293688028480b467099772d3436b011b64eada?d=identicon)[obviotyler](/maintainers/obviotyler) --- Top Contributors [![obviotyler](https://avatars.githubusercontent.com/u/182933281?v=4)](https://github.com/obviotyler "obviotyler (23 commits)") ### Code Quality TestsPHPUnit ### Embed Badge ![Health badge](/badges/obviobysage-telemetry/health.svg) ``` [![Health](https://phpackages.com/badges/obviobysage-telemetry/health.svg)](https://phpackages.com/packages/obviobysage-telemetry) ``` ### Alternatives [illuminate/session The Illuminate Session package. 9937.4M753](/packages/illuminate-session)[illuminate/cookie The Illuminate Cookie package. 224.3M122](/packages/illuminate-cookie)[tomshaw/electricgrid A feature-rich Livewire package designed for projects that require dynamic, interactive data tables. 116.6k](/packages/tomshaw-electricgrid)[aedart/athenaeum Athenaeum is a mono repository; a collection of various PHP packages 245.2k](/packages/aedart-athenaeum) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)