Skip to content

May 21, 2012

8

A note on View 5.1 Support for the PCoIP Log Viewer

Some of you may know by now that the PCoIP log files are the bane of my existence. Since I began building the log viewer almost 2 years ago now, I have been in a constant battle to try and build a parser that can handle these ever-changing files. So far I’ve managed to make it happen with each release, thought not without much fighting, clawing, and gnashing of teeth.

Once again, with View 5.1 I find myself in a position of chasing a new file format that clearly was never intended to be machine parsed. Data is randomly placed, and formats and positioning data are altered from previous releases – seemingly for no good reason.  New data is mingled with old and some data has simply vanished entirely.

With the 4.x series of releases the changes were there but relatively minor from release to release. With the move to 5.x and the introduction of the APEX2800 card, the changes are much more significant. I assume this is because someone is making the assumption that if people want to monitor PCoIP they’ll use the WMI counters to do so and that the logs are irrelevant. However, it’s not always feasible to get direct access to be able to monitor via WMI and in some areas the logs do contain more information than the WMI counters have available. So it’s been a worthwhile struggle to keep updating the parser to get meaningful data out of the logs.

At this point though, the changes for both View 5.0 and 5.1 look to be quite significant. And updating the existing parser for these formats while retaining the old formats is becoming a significant challenge. I am thinking it might be time to reconsider the entire parser framework to make it more easily expandable and maintainable for future releases. This means, without question, a longer downtime before View 5.1 support will appear. It also quite possibly means the end of a standalone parser as my direction would be a cloud-based design and/or integration of the parser into the viewer directly.

I’d like to try and solicit some feedback on these new directions, so here’s a few questions, please respond in the comments:

  • Do you currently use, and see value in, the continued support of a standalone parser executable?
  • Do you see value in supporting log file parsing for View releases prior to 5.0 in a new parsing framework? (the standalone parser as-is will still be available to parse older files)
  • If you  had to rank in order of preference a cloud-based parser vs. an integrated parser in the log viewer which would you prefer to see first?
  • Do you see the need for continued log file parsing support or is WMI support alone enough going forward?

I will determine the future course of Log Viewer development based upon your answers (or lack thereof).

 

Thanks,

Chuck

Read more from PCoIP, Tools, VDI, View, VMware
8 Comments Post a comment
  1. May 23 2012

    I currently use the standalone parser, and can really use the log file parsing functionality. I always have internet access, so moving the parser (and meybe even the viewer?) to a cloud version is certainly no problem for me. The advantage of an integrated parser would be that I would not need internet access, but I almost always have.

    Support for the most recent and the most recent -1 version is sufficient for me. Thanks for this nice tool and keep up the good work, I wished this functionality got integrated in the View Administrator someday…

    Reply
    • RexRemus
      May 23 2012

      Excellent feedback. I have considered making a cloud/web-based version of the Viewer as well, but it’s a much larger commitment than just the parser for right now. I’m holding off because I think once VCOPS for View gets a bit more put together the need for this tool will probably diminish. Not sure I want to commit to totally rebuilding things if that’s the end game – but time will tell.

      Reply
  2. l8nighter
    May 23 2012

    Thank You so much for updating the viewer and for making it available to all of us. Before we had your viewer it was so hard to convince the ISP’s for our Work at Home staff that it was their problem the users were getting disconnected due to latency or packet loss. Now we just generate the graph from their sessions and send it on over. This is so much better because otherwise we would have to have the Perfmon counters running on all machines just in case they have the problem. With your app we just gather the logs sometime during that week before they roll off and graph the data. We have the trial of vCenter Ops for View running and it looks amazing so far! If we do decide to purchase it I am not sure how much we will continue to use your viewer than but I am sure I will still use it from time to time or for other people that don’t have the money to purchase vCenter Ops.

    We are still running View 4.6 and will be upgrading to 5.1 later this year. For us as long as you kept the old parser and viewer around it would be great either way. I have a Winbatch written that the techs can type in the remote VDI machine and it parses the logs to get session connected and reason for the disconnect in a simple line to read. Then they have a button if they want to generate the graph which launches your parser and viewer. If you made it cloud based it would be hard to call it from a script but I could just change my code to have them open a webpage instead.

    So to answer your questions it would be:

    Do you currently use, and see value in, the continued support of a standalone parser executable? Yes for having the ability to call it from scripts or to parse all files in a folder, but making it web based would probably be just as easy for a user.
    Do you see value in supporting log file parsing for View releases prior to 5.0 in a new parsing framework? (the standalone parser as-is will still be available to parse older files) I wouldn’t say so because most people should be switching to View 5.1 soon anyways.
    If you had to rank in order of preference a cloud-based parser vs. an integrated parser in the log viewer which would you prefer to see first? Either one would be fine
    Do you see the need for continued log file parsing support or is WMI support alone enough going forward? Like I pointed out above I don’t believe WMI counters are always running on all machines by default are they? If not then you would never know when a user is going to have bandwidth problems so having the parser is very vauable unless you have vCenter Ops gathering everything.

    Thanks again for the great work!

    Reply
    • RexRemus
      May 24 2012

      Awesome and informative reply. Exactly the kind of feedback I am looking for.

      It may be ironic but I am hoping the day comes that people don’t need this tool – but I imagine there’s always a place for it. When I built it I was trying to fill a void, as more tools come in to fill that void I tried to skirt the edges – good features and capabilities but not trying to complete with Lakeside, Liquidware, Xangati, or even vcops – just be a quick, simple, and free alternative for rapid troubleshooting during a POC or pilot before a major investment in an enterprise tool has been made. For a smaller scale business it might be the only tool and the price is right. But don’t get me wrong – I’d love for this information to be so easily accessible that the viewer is not needed – it’s better for all of us that way.

      Your scripting example is exactly why I broke out the parser in the first place and why I am interested in, but not entirely sold yet, on a cloud-only approach. However the cloud-based approach offers a lot of benefits – immediate updates, one point of distribution, no more worrying about specific platform support(32/64bit, XP/Vista/7). Scripting can still be done, but you’ll be wrapping some kind of HTTP POST most likely – but that’s easily done via PERL, Python, VBScript, PowerShell, .NET, or just about anything else these days. I also worry about offline mode or access via heavily restricted (Military/Gov’t) networks as I know many of the VMware Federal guys use the tool. Since I plan to use Cloud Foundry as the platform I imagine you could still download the micro-cloud and run your own parser locally on a machine. It’s a lot to ask of someone who is not already running a development environment on their machine – but it IS an option for those corner use cases.

      Still a lot of thinking to do I suppose but your feedback is extremely helpful.

      Reply
  3. Primoz
    Aug 7 2012

    – Do you currently use, and see value in, the continued support of a standalone parser executable?
    Yes we do. It’s great for scripting.

    – Do you see value in supporting log file parsing for View releases prior to 5.0 in a new parsing framework? (the standalone parser as-is will still be available to parse older files)
    No, if the old parser will still be avaliable.

    -If you had to rank in order of preference a cloud-based parser vs. an integrated parser in the log viewer which would you prefer to see first?
    None of this. Separate solution as it is curently works great and it’s flexible.

    -Do you see the need for continued log file parsing support or is WMI support alone enough going forward?
    Yes. Most times we need to check logs for the previous days when some user had problems.

    Reply
    • RexRemus
      Aug 7 2012

      Excellent feedback. I have been tied up in my new position and have not really committed to this work yet so every opinion counts and helps me determine where to take this tool. Thanks!

      Reply
      • Primoz
        Aug 7 2012

        What abot going open source with this project ?
        I guess that there are many people interested in improving this tool.

        Reply

Trackbacks & Pingbacks

  1. PCoIP Log Viewer Updated | MindFlux

Share your thoughts, post a comment.

(required)
(required)

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments