Need your feedback about Log Browser in Plesk

[custer]

Hi everyone,

As those of you who follow Plesk 12.1 previews know, we have added realtime Log Browser to Plesk and we are interested in what you can say about this feature. We're also interested in your feedback on certain ways to improve this feature.

For those of you who want to learn more about this feature, we suggest to install Plesk 12.1 preview and go to Logs screen on any subscription. The following page can help you out with installing preview build:

http://odin.com/products/plesk/preview/

We would appreciate if you could give us your feedback about this feature via the following form:

https://docs.google.com/forms/d/1sU0X8kwZlTpC7ZoK4OsQpZ8w8Hgr44_IHusdsc6wJTo/viewform

If you want to ask a question or provide feedback beyond the form above, please use this thread. Thank you very much in advance!

 

[trialotto]

Custer,

Filled in the form, but one general question about the Log browser: what is the intended function, besides providing sysadmins (note: it is not desirable to give customers and/or resellers access to server critical information) with easy insight into a limited number of log files?

In general, most (Plesk) sysadmins do not "read" the logs properly and providing them with "lazy access" to a limited number (!) of log files provides them with an incentive to be even more inaccurate with the information provided, primarily in log files that are not handled by the Log browser.

In my humble opinion, clear presentation of information is a good idea, but not if that causes sysadmins to be careless with log files, not handled by Log browser.

In addition, it should be noted that the average sysadmin that uses (all) log files properly, will not gain advantage with the Log browser, for many reasons.

In short, what is the essence of the intended function of the Log browser, taking into account all of the above?

Kind regards, Alexander

 

[custer]

Thanks for your feedback and questions, Alexander.

The intended function of Log Browser is to provide app developers and webmasters (that is, customers of hosting) with a tool that allows them to view and monitor log files in a convenient manner. Obviously, customers can only view log files that belong to their website/subscription (apache access, apache error, nginx access, nginx error, etc). When customer is trying to figure out what's wrong with his or her website or app and he or she doesn't have access to server via SSH (so I cannot simply do tail -f for a log file I want to monitor, etc), Log Browser should provide capabilities for real-time website log monitoring and filtering log results.

The form is asking how critical is to have this real-time filter-friendly Log Browser technology available to server admins for system logs viewing (mail logs, Plesk logs, etc). It is also asking how important is to give users the ability to view any arbitrary log file (for example, Zend or Symphony log) via this convenient technology.

Hope this explanation clears things up -- let me know if you have additional insight, Alexander.

 

[trialotto]

Custer,

I can imagine the convenience for many customers, even though I have stated some (mild) criticism.

The Log Browser opens up a new array of notifications and/or insight into hosting related errors, without the possibility to do something about it, in absence of server access.

Hosting customers do not really require to have insight into hosting related errors, it is the responsibility of the sysadmins with SSH (or other) access.

In the best case, hosting customers cannot do anything with error and normal notifications (as presented in logs), except for notifying the sysadmin (who, on the one hand, can do nothing with customer reports concerning "normal" log entries and who, on the other hand, has done a bad job if customers report error notifications).

In the worst case, hosting customers are uploading their own "solutions" to the server, by means of ftp and/or other protocols.

In the latter (worst) case, the whole server can be compromised and/or becomes a security risk.

In short, the abbreviation "TMI" (too much information) is applicable and, in my humble opinion, the Log Browser does not add to Plesk.

After all, the Log Browser, combined with a sysadmin following "good practice", will only present information that does not have to be acted upon.

It maybe more worthwhile to include a scan tool in Plesk, that scans for abnormal processes, files, activities and so on.

This is also a more decent approach to determine potential, future or factual (i.e. occurring) issues and errors, as opposed to the Log Browser that inherently (only) determines errors after they have been occurring and that (more important) presents these errors between a lot of lines, to be considered normal log output.

In short, the idea of "clarity" is good, but I am pretty sure that the Log Browser is not the appropriate solution.

Kind regards, Alexander

 

[custer]

I think we're talking about different logs or different scenarios here, so I'll try to clear up this misunderstanding.

As a website owner, I am typically doing a lot when I see errors presented in error_log of my own website. For example, if I see a lot of 404s in error_log and most of them are GET requests to a file that I've uploaded and linked to from my website, it means that I've placed a wrong link to this file on my website and I can definitely fix that by changing the link. That's not really TMI, that's basic website management that all webmasters do. I have a feeling you're talking about server-level stuff, while Log Browser in its current incarnation is simply a replacement of plain-text log viewer present on Logs screen in previous Plesk versions.

Does this clarify the feature purpose, Alexander?

 

[trialotto]

Custer,

The purpose of the Log Browser was already perfectly clear.

The only thing I noted is that the Log Browser will give rise to a lot of hosting customers taking matter into their hands, they can or will act upon information from logs presented by the Log Browser.

From that perspective, there is nothing wrong with the Log Browser.

However, Plesk customers are the sysadmins choosing for Plesk Panel as the system managing web hosting.

For sysadmins, the fact is relevant that hosting customers, taking matter into their hands, will often poorly patch specific errors.

That is, with the Log Browser, sysadmins will very likely notice an increase in errors (on the server level), directly or indirectly caused by hosting customers (not by Plesk panel).

As a result, it is very (very) likely that complaints about Plesk will increase, even if that is unjustified (since errors are directly or indirectly caused by hosting customers).

In short, with the Log Browser, there is a high(er) probability that sysadmins will question the proper functioning of Plesk and/or will seek alternatives (such as cPanel).

I am not sure whether you are and/or Parallels is aware of the economic effects a simple functionality like the Log Browser can have upon sales and/or general satisfaction with respect to Plesk Panel.

It has to be noted that general satisfaction of Plesk customers (i.e. sysadmins) is dependent on the number of issues occurring with Plesk AND their ability to resolve them.

When looking at the Parallels forums thoroughly, one can see that a lot of unjustified dissatisfaction is present already.

It also has to be noted that sales have been both increased and decreased by introducing specific functionalities in Plesk in the past.

When considering the above, many examples can be given, but I can only speak for myself: for instance, up till a recent past, I did not want to host Wordpress within Plesk, due to vulnerabilities in Wordpress versions, the lack of perfect updates via the Plesk Panel and, primarily, the fact that hosting customers are often using (insecure) plugins and/or own customizations, leading to general server vulnerabilities.

Simply stated, I just used another web hosting system for hosting Wordpress sites.

In short, all the above seems not to have any relation to the good idea (!) of the Log Browser, but an actual relation is present.

Naturally, you are right to state that we discuss different dimensions and/or implications of the Log Browser.

However, the way of viewing is not that different: we agree that the Log Browser is a good idea.

The only thing I add is that the Log Browser is a "method of gaining insight into information, that should be exclusively visible to sysadmins, not hosting customers".

The conclusion from that addition is that an increase in vulnerability of the whole Plesk Panel can (no certainty there) occur.

Another conclusion, following and based upon before mentioned conclusion, is that the true Plesk customers (i.e. not being hosting customers) can become dissatisfied, with a potential drop in sales for the Plesk product range.

The choice is completely up to Parallels.....and the actual implications will only be visible after some time.

As a personal and final note, this is the end of the benevolent feedback from my side.

Kind regards...

 

[Faris Raouf]

Maybe making it a selectable option in the Service Plan definition would enhance this feature and resolve trialotto's reservations.

 

[trialotto]

Faris,

That partly resolves my reservations.

However, there are also some practical considerations.

Providing information of any kind to end-users, plesk sysadmins and/or different parties should be accompanied by knowledge of interpretation of that information.

Knowledge is the result of information, a lack of (proper) knowledge can also occur by misinterpretation of information.

The above misinterpretation is found daily in the Parallels/Odin forums, in which a lot of strange, obvious or even rhetorical questions are asked (understatement of the century).

The before mentioned questions are those of sysadmins, encountering problems that end-users are very likely to have reported to those sysadmins.

In a world of non-issues and (very) minor problems, a Log Browser can EITHER increase the number of non-issues (i.e. not desirable) OR (significantly) increase the number of identified ACTUAL issues and (major) problems, that truely require updates and patching (i.e. desirable for the Plesk customer AND end-user, not desirable for Parallels/Odin).

The major practical considerations are therefore:

a) how many actual issues and major problems does the Plesk customer and end-user want to see (before giving up on Plesk)

b) how many actual issues and major problems does Parallels/Odin want to see (that is, from the perspective that these eventually have to be patched or updated)

c) how many actual issues and major problems can be handled and resolved by Parallels/Odin, on a short-term basis (that is, before Plesk customers and end-users give up)

d) is a Log Browser, adding only functionality to non-root users, the appropriate tool to conclude and/or expose actual issues and major problems

e) is a Log Browser, adding only functionality to non-root users, not aiming at the wrong target group (partly to be resolved by the suggestion in your post)


All in all, I am not sure whether the Log Browser, as such a wonderful tool when not taking the necessary context into consideration, will reach the intended goals.

Personally, I believe that Parallels is emphasizing customer satisfaction (of all customers), whilst the actual merits of the Log Browser are not very likely to be found in that area, but only in the area of the Log Browser being a exclusive tool for (only) sysadmins (with or without root access).

Kind regards, Alexander

 

[custer]

It was quite useful and enlightening to hear another perspective on this feature - thank you, Alexander.

 

[trialotto]

Custor,

No problem, the "thanks" are not really necessary.

I must admit, it is difficult to stay obective and on-focus, when discussing the matter.

I also have to add that all customers (i.e. end-users and sysadmins) can benefit from a log environment, including the Log Browser, if that log environment enables feedback on issues and/or errors, that are not identified by automatic (scripted) feedback systems within Plesk.

In a sense, it is all about goals, functionality and target groups and the precious balance that exists them.

I certainly would acclaim any log environment that allows Parallels to enhance the process of improvement of Plesk.

Kind regards, Alexander