For me I see two areas I would use this:
Monitoring Performance and machine behavior.
Troubleshooting. This happened to me a couple of months ago. A high percentage of our machines in our data center hung during a patch reboot. After troubleshooting I noticed a particular event id being popped out by our antiVirus client. I also noticed one being generated by our password reset client. Of course these events one machine or even two does not prove anything. I had to create a script that used psloglist to run against a list of machines looking for those two events and other criteria. I gave the report to supervision that indicated that the root cause was not LANDesk patching but an issue with our AntiVirus, Password Reset, and RDP.
Another example is how we use the event logs and LANDesk now is that the current primary owner attribute in LANDesk was not really a true indication in our shop. We wrote a script that scrapes the security log looking for the most prominent account that logged in over that last 30 days.
I beleive the event logs are the most over looked source for troubleshooting. It is the first item I ask a tech and I search for when troubleshooting issues. Just look at sites like eventid.net. Examples - Is MSI working correctly, Is there an issue with DNS, hard Drive errors, NIC issues, etc....
Write a query for all machines that have the MSI failed to connect to server over the last 2 weeks and run a task to fix. Try to be a little bit more proactive.
Another example would be more broad. How about how many entry types in the last X time frame (number of critical events in the last 2 weeks) or even better (as the LANDesk Engineers cringe) Give me the top 5 critical events entries over the past 2 weeks.
I agree that his is a new area and how it can be integrated into LANDesk is up for debate but I think it is worth pursuing. Usually anything that can bite you in the @ss is in the event logs.
I'm thinking purely of specific hunts for known strings, though it might also be useful to report on generalized stats like "lots of errors in system log".
The log analysis conversation touches on two areas with challenges: using the right tool for the job, and doing the job in the first place.
The right tool for the job in this case may or may not be LDMS... there've been some stabs at log gathering in LDSM, and some of that has boiled over into LDMS, but there are no analysis tools outside of the query engine. Meaningful analysis is not a small job.
Doing the job in the first place is traditionally outside of the scope of desktop management, where there's often been an attitude of "if a reboot doesn't fix it, reimage". A lot more effort is put into preventative measures than diagnostic, and so far I've seen little indication of changes in that mindset.
Managed Planet has a product called Execute Report Pack and one of its features is the ability to pull Event Log info into the inventory database. I would not recommend pulling it all in, but specific ids would work just fine. Ask your LANDesk reseller about it.