I have been experimenting with mirroring the gateway logs on a designer window, I find the constant switching between windows and logout of the gateway webpage a pain when making and troubleshooting gateway scoped scripts, so I have experimented with this module, it adds a menu item in the Tools menu that opens a little gateway logs viewer window that mirrors the gateway logs.
I am not sure if there is actually any people that will find this useful, but if you do, I may consider working further on the signed module to use on your dev servers.
What's the stack underlying it - direct HTTP calls to the REST API, or RPC, or push notifications, or something else?
It's using the RPC, converting to some pretty basic JSON and sending them through to the designer.
I use tail -f .../wrapper.log in an SSH window. Tough to beat it, as it doesn't rely on any Ignition functionality.
Port 22 isn't allowed over most of the remote access platforms we do Ignition dev on unfortunately.
SSH can listen on multiple ports, not just 22.
Some see a direct SSH session as a "break-the-glass" operation, and then should only be used when absolutely necessary. Some deployment scenarios may also be containerized, where there may never be an option to expose a SSH server running in a container. In the latter option, though, you should have the ability to tail logs from the container - just not through SSH - and even then, you would have to have a certain level of access to the infrastructure to view logs in the first place.
These are certainly a fresh hell in some environments. The Designer already has its own database management tool, why not add in a log viewer to boot?
Not relying on Ignition functionality is key, IMNSHO. The wrapper log file (stdout from containers) includes information not found in Ignition's logging infrastructure, especially information about crashes and optional GC logging. And various non-logged gateway scoped prints, particularly those from native libraries.
Comparing to the query tool in the designer is a category error. That tool operates on demand--it provides no asynchronous information about DB connections.
I consider access to the wrapper log essential in a dev environment.
As long as we're going down this tangent (sorry, David) - has anyone ever experimented with the service wrapper's syslog output mechanism?
This would be additional keys added to ignition.conf.
Great idea. Would love to give it a shot, as my biggest problem is closing the gateway webpage accidently.. and then having to go thru the process of getting back to the log. Having the log right there in designer would be fantastic.
Module is linked in the first post.