pierre-lannoy / wp-decalog Goto Github PK
View Code? Open in Web Editor NEWCapture and log events, metrics and traces on your site. Make WordPress observable - finally!
Home Page: https://perfops.one/
License: GNU General Public License v3.0
Capture and log events, metrics and traces on your site. Make WordPress observable - finally!
Home Page: https://perfops.one/
License: GNU General Public License v3.0
// UPDATE
Describe the bug
The logging of a manual opcache restart is triggered frequently as the compare is only capable of handling a single server. When there are more servers (cluster setup) the state in the WP site meta only reflects one server. Comparing the states of other running servers leads to false assertions and false logging.
Steps to reproduce the behavior:
opcache_reset
on one of the serversmanual_restarts => 0
(WP Site Meta) with manual_restarts => 1
(return of opcache_get_status(false)
) or the other way around - whenever the server with the other value executes code.Fix: Store the Opcache status with a server identifier like the hostname
Quickfix: Restart php-fpm to align the status counter
Describe the bug
5 parameters configured, API only offers 4:
https://developer.wordpress.org/reference/functions/wp_clear_scheduled_hook/
$pre = apply_filters( 'pre_clear_scheduled_hook', null, $hook, $args, $wp_error );
Environment (please complete the following information):
Best,
Jan
Describe the bug
Hi, we are trying to set up Prometheus metrics as explained in https://perfops.one/a-almost-free-observability-platform-part-2/ but we are not able to get metrics in Grafana Cloud.
To Reproduce
Steps to reproduce the behavior:
metrics:
wal_directory: /var/lib/agent/wal
global:
scrape_interval: 60s
external_labels:
cluster: 'clustername'
configs:
- name: integrations
remote_write:
- url: https://prometheus-prod-05-gb-south-0.grafana.net/api/prom/push
basic_auth:
username: 'username'
password: 'password'
scrape_configs:
- job_name: decalog/scrapping
static_configs:
- targets: ['service-name']
labels:
process: 'agent'
metrics_path: "/wp-json/decalog/v3/metrics?uuid=XXXXXX"
Expected behavior
All metrics send by Decalog (those with wordpress_ prefix) are expected to be present. We are able to get Prometheus metrics in local Grafana using Push Gateway, but with Grafana Cloud we cannot use it.
Environment (please complete the following information):
Additional context
Add any other context about the problem here.
Describe the bug
Can't choose which Listeners to show
To Reproduce
Steps to reproduce the behavior:
Expected behavior
On step 4, it should show "Selected Listeners".
Environment (please complete the following information):
Additional context
I've just installed the plugin, I want to disable all listeners and add just my own listener for custom events in my website.
Is your feature request related to a problem? Please describe.
OpenTelemetry is a new and widely adopted standard in distributed tracing. Many well-known backends are OTLP-compatible now, so adding OTLP support will unblock new backends as well as improving already-supported backends like Jaeger.
Describe the solution you'd like
Implements OTLP support and add a new OpenTelemetry-compatible backend support.
Describe alternatives you've considered
Don’t add OpenTelemetry support at this time. OTLP heavily uses Protobuf, which may be troublesome.
Additional context
Add any other context or screenshots about the feature request here.
Describe the bug
After updating our Test ENV to Decalog 3.6.0 we got tons of these in our logs:
Uncaught exception (Error): “Call to undefined method WP_CLI::get_logger()“ at ./wp-content/plugins/decalog/includes/plugin/class-initializer.php:64
.
To Reproduce
Steps to reproduce the behavior:
Update to Decalog 3.6.0 and run code via WP-CLI
Environment (please complete the following information):
<latest>
Is your feature request related to a problem? Please describe.
Currently DecaLog defaults to use the name "WP" as service name in Jaeger. Sometimes we may want to customize the name (since it’s displayed on the tracing dashboard) or avoid collision between multiple WordPress instances.
Describe the solution you'd like
Add a new "service name" setting for Jaeger tracers.
Failure to send logs to Elastic 8
Deprecated: Creation of dynamic property DLGuzzleHttp\Ring\Client\CurlMultiHandler::$_mh is deprecated in /var/www/html/wp-content/plugins/decalog/includes/libraries/guzzlehttp/Ring/Client/CurlMultiHandler.php on line 47
Deprecated: Creation of dynamic property DLGuzzleHttp\Ring\Client\CurlMultiHandler::$_mh is deprecated in /var/www/html/wp-content/plugins/decalog/includes/libraries/guzzlehttp/Ring/Client/CurlMultiHandler.php on line 47
Deprecated: Creation of dynamic property DLGuzzleHttp\Ring\Client\CurlMultiHandler::$_mh is deprecated in /var/www/html/wp-content/plugins/decalog/includes/libraries/guzzlehttp/Ring/Client/CurlMultiHandler.php on line 47
Deprecated: Creation of dynamic property DLGuzzleHttp\Ring\Client\CurlMultiHandler::$_mh is deprecated in /var/www/html/wp-content/plugins/decalog/includes/libraries/guzzlehttp/Ring/Client/CurlMultiHandler.php on line 47
Deprecated: Creation of dynamic property DLGuzzleHttp\Ring\Client\CurlMultiHandler::$_mh is deprecated in /var/www/html/wp-content/plugins/decalog/includes/libraries/guzzlehttp/Ring/Client/CurlMultiHandler.php on line 47
Fatal error: Uncaught Error: Call to a member function error() on null in /var/www/html/wp-content/plugins/decalog/includes/listeners/class-phplistener.php:350 Stack trace: #0 [internal function]: Decalog\Listener\PhpListener->handle_exception() #1 {main} thrown in /var/www/html/wp-content/plugins/decalog/includes/listeners/class-phplistener.php on line 350
Fatal error: Uncaught Error: Call to a member function log() on null in /var/www/html/wp-content/plugins/decalog/includes/listeners/class-phplistener.php:327 Stack trace: #0 [internal function]: Decalog\Listener\PhpListener->handle_error() #1 /var/www/html/wp-includes/functions.php(6031): trigger_error() #2 /var/www/html/wp-includes/functions.php(5975): wp_trigger_error() #3 /var/www/html/wp-includes/query.php(882): _doing_it_wrong() #4 /var/www/html/wp-includes/robots-template.php(93): is_embed() #5 /var/www/html/wp-includes/class-wp-hook.php(324): wp_robots_noindex_embeds() #6 /var/www/html/wp-includes/plugin.php(205): WP_Hook->apply_filters() #7 /var/www/html/wp-includes/robots-template.php(32): apply_filters() #8 /var/www/html/wp-includes/functions.php(3841): wp_robots() #9 /var/www/html/wp-content/plugins/decalog/includes/listeners/class-corelistener.php(1253): _default_wp_die_handler() #10 /var/www/html/wp-includes/functions.php(3763): Decalog\Listener\CoreListener->Decalog\Listener{closure}() #11 /var/www/html/wp-includes/class-wp-fatal-error-handler.php(239): wp_die() #12 /var/www/html/wp-includes/class-wp-fatal-error-handler.php(154): WP_Fatal_Error_Handler->display_default_error_template() #13 /var/www/html/wp-includes/class-wp-fatal-error-handler.php(58): WP_Fatal_Error_Handler->display_error_template() #14 [internal function]: WP_Fatal_Error_Handler->handle() #15 {main} thrown in /var/www/html/wp-content/plugins/decalog/includes/listeners/class-phplistener.php on line 327
I use version 8.2 of PHP.
From WordPress version 6.4.3
From the last edition of the Decalog
But the above error exists for.
Thank you for your guidance.
Hello,
Is there a way to integrate logs directly from decalog to custom SIEM?
Describe the bug
I am unable to configure the Grafana Cloud Traces logger. The best result I could get was an Error 405: Method not allowed.
The Grafana Cloud Events logger works fine.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Traces are sent correctly.
Environment (please complete the following information):
Additional context
At first I thought that authentication was missing as Grafana Cloud mentions using basic auth with api key as password for Tempo.
I tried setting the URL as: https://id:api_key@host:port but that does not change anything. Trying out some API calls to https://: I've seen that only GET request are accepted, all other request give an Error 405 Method Not Allowed.
I tried following this tutorial: https://perfops.one/a-almost-free-observability-platform-part-1/ but it omits the most crucial part - the configuration - and simply tells me the Sending Traces page has all the config info I need.
I'd like to utilize your plugin for syslog forwarding to SIEM. This tool has a cloud hosted syslog collector which should be capable of receiving the logs given your formatting. The issue with this is that it currently only accepts authenticated messages, i.e. with a Token.
Do you think it would be possible to update this file (SyslogHandler.php) potentially on lines 22 & 41 to pass an authentication token? I haven't fully traced your plugin yet, but am curious if you've run into this issue or if I am misusing your tool.
I'd be happy to help with this, curious what your thoughts are.
Thank you,
MG
Add licenses files to each embed libraries.
Is your feature request related to a problem? Please describe.
Currently the menu pages are created at PHP_INT_MAX
and PHP_INT_MAX -1
in the finalize
method. This makes it virtually impossible to remove the pages using own code.
We want to remove the Dashboard (perfopsone-dashboard
) for non Super Admins in Multisite, as we do not want "Site owners" = Single Admins to access POO / Decalog in any way. In addition to that, with our current settings, the Menu page is simply empty for single site admins. There is just the top level entry, but no submenu entries.
This is the relevant code:
wp-decalog/includes/plugin/class-core.php
Lines 111 to 113 in adc7bd2
Describe the solution you'd like
Decrease the priority to reasonable values. Set it as high as necessary, but as low as possible (like 100
, 200
, etc. ?). With this, one could remove the pages using admin_menu
with a higher priority.
Describe alternatives you've considered
Add a filter to disable the POO Dashboard. Currently the Top Level entry is always created and there is no way to disable this. A filter here would be also a possible solution:
wp-decalog/perfopsone/class-menus.php
Line 130 in adc7bd2
Requires PHP: 7.2
We could include Composer's autoloader AND put all of our classes in 1 directory. Now there are two orphans
Of course we still need our own autoloader as this project follows WPCS which - I think - will be deprecated as soon as core gets a namespace.
Is your feature request related to a problem? Please describe.
Currently there is the siteid and the sitename within the meta of an event log entry. The name may not be easily matchable to a single site in a multisite environment. The id again requires an additional lookup step to identify the origin site. Having the domain would allow a direct access to the origin site (/wp-admin for example). In addition to that the domain is more stable than the name of a site and thus better suited as a readable identifier within tools like Datadog. Currently one would have to know the ID to create stable filters / queries. The domain would be better.
Describe the solution you'd like
Add a new field sitedomain
containing the sites domain.
Describe alternatives you've considered
None. Small change, big effect
Describe the bug
Hey @Pierre-Lannoy hope you are doing well :-)
This is quite an "early" bug report while we have not yet 100% identified the root cause but having some quite reasonable ideas of it. Hoping for some highly valued input of yours.
The issue:
We face(d) massive memory spikes when using WP-CLIs search-replace
on tables with many large (~100kb each, several 100s of them) serialized objects. These serialized objects leads WP-CLI to use PHP for the search-replace on these fields.
And as such using the WP PHP API (update_...
functions) to de-serialize, search-replace and then serialize and update the data again. Performing this on a table of ~80MB size lead to a memory consumption of >20GB ending with Out of Memory killer being triggered.
Running the same wp search-replace ...
with --skip-plugins=decalog
mitigated this issue. The search-replace went through in seconds. No memory spikes, no mentionable memory consumption.
We assume - but again have not verified it yet (sorry!) - the buffer
option of Decalog to be the root of this. If this applies to WP-CLI calls as well, it might explain the seen behaviour as the log calls with all the data in it are stored in memory and would only be logged once the CLI "request" ends?! Does that makes sense?
If you agree on this as a possible source, could you suggest a "hotfix" we could try out to ignore the buffer
option in CLI sessions? We could try this out and give you feedback on it as we have this issue reproducible ;-)
Notable: We use a redis object cache (Object Cache Pro) which is inflicted as well. Yet when disabling Decalog that component does not seem to cause any issues.
And we still use Datadog as target log system.
To Reproduce
Steps to reproduce the behavior (not verified yet!):
buffer
option in Decalog is enabledwp search-replace old-value new-value wp_postmeta --dry-run
Memory should spike and the operation should take a long time.
Expected behavior
No memory spike and only some seconds execution time.
Maybe ignore the buffer
option in CLI sessions and always flush the log calls directly? This might increase the CLI runtimes slightly but will prevent scaling effects. If these are the case here.
Environment (please complete the following information):
Thank you very much as always :-)
Is your feature request related to a problem? Please describe.
Metrics are an amazing tool to get insight into an application. But with the major analytics platforms charging by the number of metrics collected, it is a matter of cost to decide which metrics to actually trace. There are several metrics which create an exponential growth in the number of traced metrics.
Describe the solution you'd like
Within admin.php?page=decalog-settings&tab=metrics
allow to enable / disable the single metric. This will allow one to limit the metrics to those really required and thus controlling the created costs by the metrics.
Describe alternatives you've considered
Select the metrics to submit within the configured metrics provider. As it might be different for each provider / connection.
Additional context
We use Datadog. With the Decalog default enabled and metrics submitted on a Multisite Environment we very quickly had several hundred metrics billed there. We then disabled the metrics collection for cost reason.
Design a logo for the plugin.
Is your feature request related to a problem? Please describe.
We currently profile our WP setup. Decalog popped up as a source of too much rendering-time on nearly all requests.
See the profiling chart on the right in light and dark green. In this request the CoreListener::plugin_close
causes about 40% of the rendering time of that page. All Decalog is at about 52% of this single request. The remaining time comes from DatabaseListener::db_monitoring_close
.
The source is within the CoreListener::plugin_close
with its calls to plugin_update
and theme_update
causing HTTP requests to the external repos. As we all know that HTTP requests are bad and evil slow these operations should be used rarely and never in frontend or AJAX requests. DatabaseListener::db_monitoring_close
does uncached SQL queries. Even something I would like to skip performancewise ;-).
Describe the solution you'd like
There are two solutions coming into my mind:
General approach: We do not have any metrics provider configured by choice in this environment. So why are metrics even collected? The plugin_close
method as well as db_monitoring_close
only work on counters which are only relevant if a metric provider is configured, correct?
Could we add a layer of "check what to collect before collecting it"? Like collect_metrics():true|false
and collect_events():true|false
and add them around the proper functions before executing and hooking stuff? Should reduce the footprint of the plugin to the only required level.
For this particular case: Limit the execution of the plugin functions to authenticated admin calls with the capabilities to actually update plugins.
Additional context
WPMU 6.0.2
PHP 7.4.
A logger which uses are "standard" and which implements PSR\Log\LoggerInterface ;)
Describe the bug
When I try to run a CLI command 'wp log listener disable wpdb' it returns a message 'Invalid listener id supplied' and exit.
The 'wpdb' listener definitely exists, as it is a standard one and it is shown in the listeners list after running 'wp log listener list'.
The root cause is in the line 1146 of includes/features/class-wpcli.php
https://github.com/Pierre-Lannoy/wp-decalog/blob/master/includes/features/class-wpcli.php
Looks like the $listeners array is always empty in that condition, so the $uuid becomes empty for each command with arguments.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Disabling the specified listener, in case of disable command.
Enabling the specified listener, in case of enable command.
Environment (please complete the following information):
Site 247 integrations would be great
Hey @Pierre-Lannoy,
more of a question but something we came along trying to do some housekeeping in datadog.
Within
wp-decalog/includes/formatters/class-datadogformatter.php
Lines 41 to 48 in 33f890c
info
, warning
and error
although DD does support all of them actually. We stumbled upon this wondering why all NOTICES
where categorized as info
in DD and expected some wrong at our pipeline config.info
and notice
to store notice
longer and drop info
even quicker.
This helps us optimize mostly the cost structure as well as little bit reducing log bloat in DD ;-).
Just want to get your resoning behind this. As I belive this is intentional as always :-)
If you agree, I would at least move Decalog / PHP notice
to DD notice
. If not even setting all of the to their according DD log levels. But that seems a bit "radical" to me at the moment with no actual need.
Have a great day and all the best as usual :-)
Hi all!,
Im currently testing the plugin, so far I saw how powerful it is by integrating with with Loki, but with prometheus integrations I wasn't as lucky. Im always getting a not found error when trying to push metrics to a prometheus endpoint, Im using the same exact endpoint for remote_write other prometheus instances. There is no much information in the logs aside of that not found error (404), so Im not sure what is wrong with the endpoint url, the domain and port, or the path. And regarding exposing metrics, I wasn't able to find any documentation on the endpoint and path the metrics are exposed.
This is an amazing tool. This is not really a bug request, I just wanted to know if there is any documentation on how to setup the prometheus integrations.
Thanks a lot in advance!
Describe the bug
I am not sure if this is a usage error, a bug or should be a feature request. So let me know if I need to put this in a different spot.
I have enabled the "database" listener. I expected this to mean that information about database queries (ie. what query and how long it took) would be included in the trace data exporter into Jaeger (or whatever trace solution used).
However, all I see are spans relating to WP Core (presumably the "WordPress core" listener). I expected (perhaps incorrectly) that my spans would have what database queries were triggered and how long they took (in an ideal world it would also include any external HTTP requests and how long they took (what line of PHP triggered the request and what parameters were passed).
I was expecting something similar to what is discussed here (https://woocart.com/blog/slow-wordpress)
To Reproduce
Steps to reproduce the behavior:
---
version: '3'
services:
db:
# We use a mariadb image which supports both amd64 & arm64 architecture
image: mariadb:10.6.4-focal
# If you really want to use MySQL, uncomment the following line
#image: mysql:8.0.27
command: '--default-authentication-plugin=mysql_native_password'
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
- MYSQL_ROOT_PASSWORD=somewordpress
- MYSQL_DATABASE=wordpress
- MYSQL_USER=wordpress
- MYSQL_PASSWORD=wordpress
expose:
- 3306
- 33060
wordpress:
image: wordpress:latest
ports:
- 80:80
restart: always
environment:
- WORDPRESS_DB_HOST=db
- WORDPRESS_DB_USER=wordpress
- WORDPRESS_DB_PASSWORD=wordpress
- WORDPRESS_DB_NAME=wordpress
grafana:
image: grafana/grafana:8.1.6
volumes:
- ./ds.yaml:/etc/grafana/provisioning/datasources/datasources.yaml
environment:
- GF_AUTH_ANONYMOUS_ENABLED=true
- GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
- GF_AUTH_DISABLE_LOGIN_FORM=true
ports:
- "3000:3000"
jaeger:
image: jaegertracing/all-in-one:latest
ports:
- '6831:6831'
- '16686:16686'
- '14268:14268'
volumes:
db_data:
Expected behavior
data about SQL queries
Screenshots
Environment (please complete the following information):
Database (MariaDB 10.6.4)
Metatraces listener (DecaLog 3.5.1)
PHP (PHP 7.4.30)
Prometheus-compliant listener (DecaLog 3.5.1)
PSR-3 compliant listeners (DecaLog 3.5.1)
WordPress core (WordPress 6.0.2)
Additional context
Add any other context about the problem here.
Is your feature request related to a problem? Please describe.
The Jaeger endpoint I’m given is shared by multiple users, and it will classify different applications by token
tag. Currently wp-decalog
cannot specify custom tags, so I’m not able to use the service.
Describe the solution you'd like
Allow users to set custom Jaeger tags.
Describe alternatives you've considered
Can’t think of any alternative yet.
Additional context
I’ve opened a PR on the Jaeger client library for supporting client-level tag configuration. Before that work is done, we can workaround by setting the tags on each spans.
Is your feature request related to a problem? Please describe.
Trace and span context can be propagated through HTTP header(s). W3C has a recommended standard compatible with OpenTelemetry, while older Jaeger-compatible clients are using Uber's original format. If possible, we should support both:)
Describe the solution you'd like
Parse the HTTP headers accordingly and, if the content is valid, propagate the trace by overriding the default settings (trace id/parent span id/sampled/...).
Describe alternatives you've considered
Simply ignore it like what we're doing now. The full semantics is rather complex, so it may not worth the effort.
Additional context
https://www.w3.org/TR/trace-context-1/#trace-context-http-headers-format
https://www.jaegertracing.io/docs/1.22/client-libraries/#tracespan-identity
Describe the bug
Happy new year :-)
We have reproducible "Critical" Error log entries in Datadog for this AJAX endpoint. It seems that you already added some code to catch this in the past (2y ago) which doesn't seem to work (anymore?).
wp-decalog/includes/listeners/class-corelistener.php
Lines 1223 to 1227 in bece378
🟥 Critical [0] Permalink:
WP Core handles AJAX Calls in wp_die
slightly different than other calls by defaulting to status 200 instead of 0. Maybe it's a good idea to replicate this handling and add a check for wp_doing_ajax()
to your wp_die_handler
instead of the hack in there?
Then: If is ajax, only log an error if the $args['code'] is > 400 ?
What do you think?
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Log Permalink calls / WP AJAX calls with status code 0 as debug instead of critical.
Environment (please complete the following information):
Write readme.txt
file, see https://wordpress.org/plugins/readme.txt.
Write a comprehensive README.md
(and page header) to provide:
Is your feature request related to a problem? Please describe.
We are investigating using a vendor agnostic collector in our pipeline and would like to send events to a generic HTTP endpoint, since that seems to be a method that is widely supported by collectors like Vector, fluent bit, and Open Telemetry.
Describe the solution you'd like
A new logger that specifies an HTTP:port endpoint, auth method (basic/bearer), and ideally a format choice (json/syslog/gelf/protobuf/avro).
Describe alternatives you've considered
I'm not sure whether any of the existing loggers can be used for this purpose. The fluentd and syslogd loggers will send to a url:port.
Describe the bug
We do tests with the PHP8 upgrade at the moment. After we upgraded the installation to 8.1 our logs were flooded with the "Metric not found" Error above for each and every WP-CLI run.
I hope and believe it is related. But the PHP upgrade is the only recent change which could have triggered this. We were able to reproduce this with Decalog 3.6.0 as well as 3.6.2 against Datadog. We have DD Events and DD Metrics configured and setup against Datadog.
When we pause / disable DD Metrics the error disappears.
Here is the stacktrace which oddly ends with decalog_run
:-/
decalog_run,
include_once(`/plugins/wp-decalog/decalog.php`),
require(`wp-settings.php`),
WP_CLI\Runner->load_wordpress,
WP_CLI\Runner->start,
WP_CLI\Bootstrap\LaunchRunner->process,
WP_CLI\bootstrap,
include(`phar:///usr/local/wp/wp/vendor/wp-cli/wp-cli/php/wp-cli.php`),
include(`phar:///usr/local/wp/wp/php/boot-phar.php`)
To Reproduce
Steps to reproduce the behavior:
Expected behavior
No error at all :-) Or an idea / hint how to do something against this.
Screenshots
Environment (please complete the following information):
Describe the bug
Perfopsone-consoles functionality break under PHP 8.x.x, even though https://wordpress.org/support/topic/php-8-fatal-error-3/ states it should be functional.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
It connects to the API.
Screenshots
Broken: https://i.imgur.com/FdQHn2y.png
Expecting: https://i.imgur.com/UGAM7gJ.png
Environments:
Test server:
Production server:
Additional context
Was mislead about the plugin's status since https://wordpress.org/support/topic/php-8-fatal-error-3/ stated it should be working on PHP 8.
Describe the bug
If pre_clear_scheduled_hook returns anything other than null
the logger logs:
$this->logger->notice( sprintf( 'A plugin prevented the "%s" event to be cleared.', $hook ) );
Yet this message is wrong. In our case we replaced wp-cron with Cavalcade. The WordPress Docs states:
For plugins replacing wp-cron, return the number of events successfully unscheduled (zero if no events were registered with the hook) or false if unscheduling one or more events fails.
https://developer.wordpress.org/reference/hooks/pre_clear_scheduled_hook/#description
Thus an INT return value indicates that there is some wp-cron replacement running. Thus the Log message is misleading.
This kind of has to be considered for all schedule related hooks. If an external cron system is running, many filters / actions behave slightly different. This are the relevant hooks: https://developer.wordpress.org/reference/files/wp-includes/cron.php/?post_type%5B%5D=wp-parser-hook
To Reproduce
wp_clear_scheduled_hook( 'wp_version_check' );
Expected behavior
One of the following:
Environment (please complete the following information):
Best regards,
Jan
Is your feature request related to a problem? Please describe.
Database spans from Dacalog are not recognized by APM dashboards.
Describe the solution you'd like
We would like to make Decalog OTel-compatible. OpenTelemetry has a set of semantic conventions for tagging a span, which is recognized by some APM dashboards.
Describe alternatives you've considered
We can run a "shim" between Decalog and OpenTelemetry backends, but that’s extra amount of work and may be difficult for most users.
A potential solution is introducing hooks into Decalog, to let users modify tags of all traces.
Additional context
https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/
Write all details regarding developing a listener and uses of levels.
Hey @Pierre-Lannoy,
just FYI: https://decalog.io/ seems to be broken. All links lead to the main page only.
Have a great weekend!
Jan
Describe the bug
When for whatever reasons the sitemeta `decalog_loggers' gets corrupted, the site is doomed in an unusable state as long as decalog is enabled. Only way out: Move / Delete the Decalog plugin folder.
Happened to us when our Webservers lost connection to their DB servers due to a network outage. Seemd to be very bad timing as this one value was left filled with garbage. After the connection came back, all sites were in Fatal Error state.
I know, It's en edge case. But it is one that really hurts... Took us some time to figure out what actually was broken as our logging was broken too ... obviously ;-)
PHP Fatal error: Uncaught Error: Call to a member function error() on null in /wp-content/plugins/decalog/includes/listeners/class-phplistener.php:350
Stack trace:
#0 [internal function]: Decalog\Listener\PhpListener->handle_exception(Object(Error))
#1 {main}
thrown in /wp-content/plugins/decalog/includes/listeners/class-phplistener.php on line 350
Fatal error: Uncaught Error: Call to a member function error() on null in /wp-content/plugins/decalog/includes/listeners/class-phplistener.php:350
Stack trace:
#0 [internal function]: Decalog\Listener\PhpListener->handle_exception(Object(Error))
#1 {main}
thrown in /wp-content/plugins/decalog/includes/listeners/class-phplistener.php on line 350
To Reproduce
Steps to reproduce the behavior:
wp_sitemeta
search for decalog_loggers
A.3.0
in there (there should be a serialized object / array in it in a valid case)Expected behavior
Only initialize decalog if all required settings are there AND contain valid data. If invalid data is found, delete, skip, ignore or reset that data instead of continuing initialization with broken data. Or deactivate the plugins. Self-Healing should be technically easy in this case.
Environment (please complete the following information):
Best Regards!
Describe the bug
Installing DecaLog on a fresh WordPress install with no other plugins activated throws the following errors and basically stops the entire site from working with the classic "There has been a critical error on this website. Learn more about troubleshooting WordPress" message. It does appear that it creates a mu-plugins
directory with a _decalog_loader.php
file in it as well as a fatal-error-handler.php
file in the content directory.
Errors:
[25-Jun-2024 15:38:11 UTC] PHP Fatal error: Declaration of Decalog\Logger::emergency($message, $context = []) must be compatible with Psr\Log\LoggerInterface::emergency(Stringable|string $message, array $context = []): void in /app/content/plugins/decalog/includes/api/class-logger.php on line 242
[25-Jun-2024 15:38:11 UTC] PHP Fatal error: Declaration of Decalog\Logger::emergency($message, $context = []) must be compatible with Psr\Log\LoggerInterface::emergency(Stringable|string $message, array $context = []): void in /app/content/plugins/decalog/includes/api/class-logger.php on line 242
[25-Jun-2024 15:38:11 UTC] PHP Notice: Function is_embed was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. Please see <a>Debugging in WordPress</a> for more information. (This message was added in version 3.1.0.) in /app/wordpress/wp-includes/functions.php on line 6078
[25-Jun-2024 15:38:11 UTC] PHP Notice: Function is_search was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. Please see <a>Debugging in WordPress</a> for more information. (This message was added in version 3.1.0.) in /app/wordpress/wp-includes/functions.php on line 6078
To Reproduce
Environment (please complete the following information):
Additional context
Our WordPress environment is slightly unique I guess in the sense that we are running it inside of a docker container, install WordPress core and plugins via Composer, our WP core is installed to it's own directory ("wordpress"), and our wp-content directory is just called "content".
Example:
/content
/plugins
/themes
/uploads
/vendor
/wordpress
/wp-admin
/wp-includes
composer.json
index.php
wp-config.php
Describe the bug
Hey @Pierre-Lannoy, its me again ;-) Hope you are doing well!
Since the last update to decalog 3.4.1 we encounter HTML encoded entities in our DataDog logs:
Alert [1] Fatal error (E_ERROR): “Maximum execution time of 45 seconds exceeded“ at `./wp-content/plugins/decalog/includes/system/class-sharedmemory.php:149`.
The “
and ”
are new. It also happens for other HTML encodeable entities whenever they are part of the submitted log message.
I am quite certain this was not the case before we updated to 3.4.1. Yet I cannot completely rule out a change on Datadog side.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The string should appear in DataDog in its natural beauty without these crude transformations.
I want my to appear among in the supported platforms list. Just like Datadog and Newrelic.
Is there any limitation , technical or legal. Or we can just provide a PR ?
thanks an advance
Is your feature request related to a problem? Please describe.
I would like to export a new metric from the core class. At the moment I can export wordpress_core_wordpress_plugin_updatable
but there is no metric for themes. I've set up a prometheus endpoint and a grafana dashboard. An alert is triggered, when a plugin is updatable. I would like to implement the same process for a theme update.
Describe the solution you'd like
I would like to have an additional Core Class metric, something like wordpress_core_wordpress_theme_updatable
.
Describe alternatives you've considered
No alternatives considered at the moment.
In the WordPress listener, it would be better to display plugin real names than their paths.
To adhere to WP security rules it's needed (but not enforced) to use wp_remote_*
function instead of direct curl calls. Currently Monolog go through curl, so there's something to change ;)
I'm trying to use DecaLog on my development environment (docker container). Despite setting up the Ray logger, no events arrive on Ray.
Perhaps you should allow variables to be modified or use the ray.php ? Or a better solution? ;)
protected $defaultSettings = [
'enable' => true,
'host' => 'host.docker.internal',
'port' => 23517,
'remote_path' => null,
'local_path' => null,
'always_send_raw_values' => false,
];
Is your feature request related to a problem? Please describe.
Hey @Pierre-Lannoy :-)
As a follow up to #24 we took some time to evaluate the solution implemented there. In general it does what it should and prevents any exceptions from happening. But the current implementation leads to resetting the configured loggers whenever the failsafe triggers. It happens surprisingly often whenever an attached object cache might need some time to flush. So the value does not return correctly for <1s. But that's enough to trigger the failsafe.
Describe the solution you'd like
We propose a simple solution. By removing the option_save
calls all the failsafe and default logic will happen only in memory. Unless someone actually changes the logger config manually and thus stores the new values intentionally. This will prevent unwanted resets of the actually configured loggers.
Describe alternatives you've considered
We considered persistent default loggers configured within the wp-config.php as constants. This would require PHP 7+ and knowledge of the internal data structure of a logger config. As one would have to duplicate it into the config. This default logger config could then be merged into the loggers object if missing. As you do already with the shared memory logger.
This solution would require more code then the current approach ;-) But it would also be a possible solution for this.
Additional context
🌻
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.