Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow plugins to create diagnostic tools that are available via CLI and the web #7235

Closed
diosmosis opened this issue Feb 18, 2015 · 17 comments
Closed
Assignees
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. RFC Indicates the issue is a request for comments where the author is looking for feedback.
Milestone

Comments

@diosmosis
Copy link
Member

To provide tools, both for us to diagnose user problems and for users to attempt to diagnose problems themselves, I think we should provide a method for users to easily create and expose diagnostic tools to their users.

I imagine that the diagnostic tools would be defined similarly to the way plugin settings are defined, by subclassing a base type and defining input metadata. Then Piwik would make the tool available both via CLI and via an admin page (needed since some users do not have the expertise or permissions needed to run CLI commands).

Running the CLI command would allow a user to use -vvv to get full debug output. The webpage should capture full debug output and display it to the user in the UI.

An example of diagnostic tools for the plugin LoginLdap:

  • The existing command loginldap:synchronize-users can be used to see why a user cannot login.
  • A tool to run any LDAP search through LoginLdap's code could be used to find compatibility issues w/ the plugin and certain LDAP servers, as well as bugs in the code.

An example of how a diagnostic tool might look like in code:

class MyDiagnosticTool
{
    function configure()
    {
        $option = new ToolOption();
        $option->name = "myoption";
        $option->desc = "...";
        $option->type = "...";
        // ...
        $this->options[] = $option;
    }

    function execute($myoption, $myOtherOption)
    {
        // ...
    }
}

I might also be possible to just use commands and execute them via the browser if those commands implement a certain interface in addition to being a console command.

@diosmosis diosmosis added Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. RFC Indicates the issue is a request for comments where the author is looking for feedback. labels Feb 18, 2015
@mattab
Copy link
Member

mattab commented Feb 18, 2015

Related to / could maybe be included in scope of: #6726

@tsteur
Copy link
Member

tsteur commented Feb 18, 2015

So basically said you have a command, and you want to also have it available via UI with some input fields? #6726 is not really in scope

@mattab mattab added this to the Short term milestone Feb 19, 2015
@diosmosis
Copy link
Member Author

@tsteur Not really. Making commands available via UI is a way to achieve this, but the idea is to make diagnostic tools (of which Piwik currently has few or none) which would normally be available only through commands available through the UI. In the UI, some extra information should be displayed, for example, getting debug logs and displaying them beside the tool output.

This is mainly to reduce spurious support requests where users could potentially solve it themselves, and aid in debugging technically inept users who won't give us access to their servers. Which I think PRO does quite a bit.

Sidenote: creating an API dedicated to creating diagnostic tools might encourage developers to include them in their plugins. Which might, again, hopefully reduce support requests in the long run.

@tsteur
Copy link
Member

tsteur commented Feb 23, 2015

Would it make sense to maybe split some parts of the PiwikDebugger plugin in a separate plugin PiwikDiagnostics or so? Which would then do this? (in case PiwikDebugger already does something like this I'm not sure)

@diosmosis
Copy link
Member Author

Maybe, as long as we can include it in core in live production instances. I think most clients that are hard to debug won't actually install the plugin, even temporarily. At least, the one I recently dealt w/ seems unlikely to.

@mattab
Copy link
Member

mattab commented Feb 24, 2015

to decide and prioritize this maybe you have some examples of such commands? in general I have the idea of improving the System Check to report such important things that could help us debug, but maybe im missing the advantage or other uses of diagnostic console commands?

@diosmosis
Copy link
Member Author

Here are the diagnostic tools I've added or will add to LoginLdap:

  1. the loginldap:synchronize-users can be used w/ -vvv to diagnose why LDAP user => Piwik user synchronization fails.
  2. the new loginldap:count/loginldap:query commands (added for the client) can be used w/ -vvv to determine if the plugin code is incompatible w/ the specific LDAP server being used or if certain queries don't work w/ the current LDAP user. If for example, the command fails, but ldapsearch succeeds, there's something wrong w/ the plugin or PHP's ldap extension.
  3. the loginldap:bind command (will add soon) can be used to check if the plugin can bind to a specific user and if not, what the specific error is
  4. the loginldap:check-ldap-servers command (may never have the time to add) could be used to check whether different configured ldap servers have the same info (in case backup LDAP servers are used). LDAP servers that do not have the exact same entries would result in very strange errors.

Some possibilities regarding Piwik:

  1. a tool to check whether there are duplicate actions (for the whole table or just one table) would be useful (especially to those
  2. a tool that lists scheduled tasks and performs a dry-run of re-scheduling or a dry-run of executing tasks would be useful (w/ of course much better debug logging)
  3. once the archive purging bug is figured out, tools that execute different parts of that system could be used to diagnose future problems. right now since the system is defined in several different parts of Piwik, this isn't exactly do-able.
  4. a tool to check for duplicate/unnecessary archive entries might be useful to diagnose large archive table issues

etc.

@diosmosis
Copy link
Member Author

It would be easier to create diagnostic tools if Piwik core's subsystems were more modular.

@mnapoli
Copy link
Contributor

mnapoli commented Apr 17, 2015

Now that #7646 is merged, should we close this or is there still something to do?

@diosmosis
Copy link
Member Author

I'm not sure the Diagnostic interface handles all the use cases in this ticket, eg, diagnostics can't be run through the UI outside of the SystemCheck page (some of the tools I have in mind shouldn't be run on that page, eg, testing an LDAP connection).

@mnapoli
Copy link
Contributor

mnapoli commented Apr 17, 2015

OK I see, but for those use case do we need to standardize it? Plugin developers can create their own custom diagnostics if they need?

@diosmosis
Copy link
Member Author

I would say, yes. At least for core + supported plugins.

This was added in response to a support call where the client did not know how to run a bash command, would not give us access to our servers, would not install plugins like PiwikDebugger on a staging server and after using Piwik since version 1.X, still did not know they should not modify global.ini.php. To support debugging these clients' installs, we'd need a very easy way for them to run these sorts of diagnostic tools.

@mnapoli
Copy link
Contributor

mnapoli commented Apr 17, 2015

Maybe we are not talking about the same thing. I meant do we need to (e.g.) create an PHP interface they need to implement, do we need to write any helper class/API for plugin developers, etc?

I don't see the point of that because the current system brings convenience to writing small diagnostics without having to write a page to display them and a cli command to run them.

However for diagnostics that don't fit in this concept (e.g. those that need a whole page, or a whole separate command), then what's the point of writing anything in Piwik? Plugin developers will have to write a UI/command anyway. I don't see any gain for plugin developers as we couldn't imagine a page or CLI command that is generic enough for all diagnostics, and at the same time saves plugin developers some time. So what I'm saying is that in those cases we could let plugin developers write their own UI/CLI command.

But maybe I'm wrong! I'm just not seeing it right now. E.g. could you illustrate what we could add into Piwik for those extended diagnostics?

@diosmosis
Copy link
Member Author

I was thinking of something similar to the plugin settings page, ie, each plugin has a section and the UI is auto-generated. So heavier diagnostics could be run when desired.

@mattab
Copy link
Member

mattab commented Apr 20, 2015

Hi guys, could we close this RFC and create a follow up issue (if applicable?)

@diosmosis
Copy link
Member Author

@mnapoli If you don't see a reason to make tools like this easily accessible via web, feel free to close. It's not something I'd probably get to anyway.

@mnapoli
Copy link
Contributor

mnapoli commented Apr 20, 2015

I'm not convinced right now but maybe I'm just not seeing it. Let's close and if the need appears we'll create a new issue with an example and we'll think of a solution

@mnapoli mnapoli closed this as completed Apr 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. RFC Indicates the issue is a request for comments where the author is looking for feedback.
Projects
None yet
Development

No branches or pull requests

4 participants