The information below is a living document about the use of VMware’s Log Insight. As always, double-check the official documentation as this page may be out of date over time.
General Notes
- If you have more than 1 VIP assigned to Log Insight’s load balancer, be aware that currently the IP addresses are sorted alphabetically not numerically. So 192.168.1.143 would actually come before 192.168.20. The first in that list is then used for email alerts etc so choose your IP addresses appropriately.
Agents
- Typical liagent.ini locations
- Windows – %ProgramData%\VMware\Log Insight Agent\liagent.ini
- Linux – /var/lib/loginsight-agent/liagent.ini
- Photon OS (New in 4.5)
- Useful settings within liagent.ini. See official documentation for additional details.
[server] hostname= proto= port=<9543 for cfapi with ssl which includes tags defined in the agent groups> ssl= reconnect=<30 set in minutes to force reconnect preventing long-lived tcp connections> ssl_cn= ssl_accept_any_trusted= ssl_accept_yes= [storage] max_disk_buffer=<200 is default in MB. 2000 is max> [update] auto_update=
Agent Group Configurations
- Microsoft – SQL Server Agents – These usually need unique directory parameters defined for SQL logs so a shared group config might not be that useful if they are all different. Separate groupings or modify liagent.ini directly could be some options.
- vROps Agents – These have unique tags that need to customized.
- vSphere – There are different builtin groups for 5.x and 6.0. 6.5 not listed yet. Be sure to change it if you upgrade/migrate to get all of the new logs.
Content Packs
- Cisco – Nexus
- This pack needs it’s own VIP setup which lets you then tag “product=nxos” to all inbound syslog. Look through the content pack instructions for details.
- Nimble Storage
- This pack needs it’s own VIP setup as well. It will then tag “product=nimble” to all inbound syslog. Again, look at the content pack instructions for details.
Unique Support Cases
- There are some unique ways to deal with the log insight archived log bundles, but you need to open a support case to work through that since it’s probably on the edge of unsupported. As far as I know you can’t just modify or delete the log files directly since that would defeat the security of the logs.
- Upgrading from 3.x to 4.0.0 had failed ons several of my instances with the upgrade pre-validation checks.
- Errors in the log showed up with: SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
- The problem was due to TLS 1.0 being disabled. The fix was to re-enable TLS 1.0. Upgrade. Then re-disable it.
define | broken 