We are really talking low level, fundamental issues here, and I think if your system simply isn’t starting then digging into the raw text logs is probably best.
If OH doesn’t start, and you have low level issues with apps not starting, then Frontail, or other such applications may also not start.
Absolutely, in such instances, there is simply no substitute for delving directly into the native logs, which are the text files stored on the server. Frontail is not what I would consider “native” - it’s quite a heavy application with a lot of dependencies.
I don’t understand what this achieves. It doesn’t appear to solve the issues in the thread that you responded to - ie if the log viewer (ie MainUI) doesn’t come up, then it still won’t display logs. It also requires that the frontail application is running on the server, so we still have all the same problems - a large set of dependencies required for Frontail, security issues, and it’s unsupported.
If your objective is to get access to other logs (ie outside of OH) then let’s look at that later - I’d say it’s not one of the current requirements, but could be added.
If your objective is to provide the “native logging access” requested above, then it doesn’t achieve this since it still requires Main UI (if I understand your concept).
As I said in my earlier response, IMHO if the system is not coming up, then ssh and text files should probably. be the goto place since that’s bypassing applications such as Frontail or OH that may not be running for some reason.
However, each to their own, and of course everyone is free to run whatever applications they want on their servers. This log viewer was originally designed for openhab though - not for OS level issues.
Yes, this is possible - but it only filters on the logger name - it won’t filter based on message so IMHO it’s pretty limited. At least for me, most of my filtering is done based on the message - if I want to filter on the logger I just disable logging for that package (although the UI filters on both logger and message).
As I’ve mentioned elsewhere, I plan to completely change this to add “proper” server side filtering (ie so we can filter on message and logger name, in addition to time). It uses a JSON package to make it extensible.
The server side requires buffering so that the UI doesn’t need to be open - as mentioned, this is first up (and partly coded). I will look at your suggestion of the getLog method since if this already exists, and can be made “large”, then this will likely be better than implementing a separate ring buffer - thanks for pointing this out.
In openHABian Frontail is installed by default and it’s made available through MainUI in the upper right under “Other Apps” on the Overview Page.
This has been the case since some time in OH 2.x (so many years). People are used to going there for logs.
We are looking to mostly replace Frontail with Log Viewer.
It would ease that transition from Frontail to Log Viewer if the users need change nothing about how they work right now. They would go to the same place but instead of Frontail coming up Log Viewer would come up. This would only occur when Frontail is gone.
I’m not trying to solve any other problems or issues and I’m not trying to keep Frontail around. I’m trying to make it easier for people who are used to accessing Frontail in a certain way (i.e. through the MainUI Other Apps menu or bringing up the URL on port 9001 manually) transition to new Log Viewer with a minimum of fuss.
From the end users perspective I’m talking about:
“I’ve updated to OH 5 and I went to Other Apps like I always do and clicked on “Log Viewer” and this new and awesome log viewer came up.”
compared to
“I’ve updated to OH 5 and I went to Other Apps like I always do and Frontail is gone! How do I see my logs now! What was wrong with Frontail anyway!”
Ok, so maybe I misunderstood. You said “set up a URL redirect on port 9001 to the Log Viewer” which I understood as “redirect front tail to the main UI” since port 9001 is the output from frontail. But I think what you describe here is to allow a user to go to port 9001 like they’ve always done, and see the new log viewer?
That was also my interpretation, but I think this is easy to change to make this more complete. But I understand you think in the same direction.
That’s exactly what I wrote already here:
Ah - apologies - I (mis)interpreted your statement as though that was a benefit of Frontail since most people seem to point at Frontail as a more general solution
The following statements are my personal opinion; I am happy to use OH and I appreciate that it is possible to have an open discussion …
I am in contact with Linux systems since around 1995. So e.g. I am used to using vi as it comes with the system while others use more advanced UI based editors.
I have frontail on the system but I rarely use(d) it. As frontail is ‘only’ a frontend to make the logs available in the browser.
OK - it is nice to have color coding for level of error messages etc.
I like the Linux system because it provides low level access the system and it provides documentation for the low level commands compared to systems that provide UIs and less documentation. If something is broken I need to be able to debug it and have tools on hand that I understand …
This part is kind of outside the scope of what’s being talked about here. Neither Frontail nor Log Reader are available outside of your LAN without some sort of VPN.
All discussions of ssh are, after the discussion, off topic. That’s something that we will explore elsewhere. And it will be a discussion on whether we can safely provide a web based terminal to access openHABian machines.
What we are talking about on this thread is the removal of Frontal, whether the new log reader is a sufficient replacement for Frontal, and what, if anything beyond Log Reader, should replace Frontail.
Nothing being discussed here will change anything about your workflow as you describe it. This is all about Frontail and log reader and as a user of neither, any outcome from this thread won’t impact you.
That’s a good idea. Maybe have a way to change the size of the first two columns or even just fix the size of the first two columns. The Time column definitely doesn’t need to be any bigger even when the screen is wider. Most of the logger names (at least for me) are also relatively short so maybe this field could be made fixed width too. Or make the width adjustable.
Being able to maximize the amount of space devoted to the actual log statment would be a boon.
In the mean time, you can reduce the zoom on the page to get smaller fonts.
It can read all kinds of log files (not only those from OH) and at the same time ‘tail’ new entries. It can also read compressed (.gz) logfiles.
The main advantage to me are the search and filter capabilities. You can filter only what you want to see. You can even use regex expressions for the filters.
It doesn’t consume much resources on my Rpi 3B+, so I start it automatically with cron at boot time.
The highlighting is not as fancy though as Frontail or the new UI log viewer. And I have no idea of security issues.
Why? The screen will scroll left / right so you can scroll them out of the way if you want to only show half or none of the logger class name.
It will only get wider if there’s nothing in the message column. I agree the time column could be fixed, but this doesn’t impact the display of the message data at all since the time will shrink if the message data fills the last column.
Again, you can scroll this out of the way - that way people who want to see this can, and if you don’t, just scroll - you have the control. If you start shrinking it because YOU have short class names, I can guarantee that someone else will complain that they are too short. Personally, most of mine are very long.
You have the full width of the screen already - other than the time.
Agreed - this was a big driver for me. As a developer, the logger was written with debugging in mind. It provides filter and highlight capability, and also the ability to export the data to provide to developers in the highlighted state (or as CSV for further processing). It has always been an issue to get good logging information to debug a binding, so this was a strong focus here.
